#processjournal

“It’s the final countdown!” These words from my favorite 80s song echo in my head as I think of finally reaching the evaluation stage of this project. It’s definitely been a long road to get here, but the journey has definitely been worth it as now I can finally see an idea through to the finish. Throughout this entire process, I’ve dealt with a lot of imposter syndrome that has prevented me from speaking up in class and voicing my opinion, as I was scared that my ideas were too “up-in-the-air” and “dumb” as compared to my teammates who were a little more knowledgeable about the subject matter and how to realistically implement the solution. I can probably say that the idea of having to be responsible for a portion of the project definitely hindered me from fully investing myself into the work as I was so clouded by doubt whether or not I would fail or have a large enough impact on the project itself. 

I remember my team always used to tell me to get my voice out there in class to feel like I was an adequate member of the team. At the time, I always used to wonder “why are they pushing me to be so uncomfortable? I DONT WANT TO SPEAK!” However, the more I think about it, the more I realize that a team is only as strong as those who voice their opinions. If I wasn’t voicing my opinions, what exactly was I doing for my team? I have never been good at taking criticism as I am a perfectionist who gets married to their ideas, but the more I listened to the feedback we were getting repeatedly from the professor each week, I knew that I had to step in and find some way to change the product, or else we would never get any work done. It was definitely challenging to be okay with having team members and outsiders pick apart something that you are passionate about, but at the end of the day, no pain no gain. It was time to let my guard down to be open to the discomfort so that the product would have the best chance of success and viability. 

I quite enjoy the evaluation step, where key metrics are observed, and projects either make or break. In the spirit of iterative design philosophy, I think that in some ways, the project doesn’t even truly begin until there are evaluation statistics to consider and a new iteration is in the headlights.

Now that we’re on the tail end of the creative problem solving process as defined by this curriculum, I’m struck by how several of the steps along the way can have a recursive quality - for each step, you can apply the entire process! For this step, coming up with an effective criteria requires ideation, selection, implementation, and then you have to evaluate how effective your criteria were as this chapter itself has described.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Also, for those that disagree with my comments on the “iterate vs. masterpiece” discussion: First of all, I’m sorry that you have to be subjected to my rants on zoom - it’s not easy to convey potentially disagreeable points of view with such haste. Second, I think this subject is one of those things where you can turn the “iterate” dial up so high that it eventually goes all the way around and back to “Masterpiece.”

To continue to take the “David” example for instance... to us, it seems to be a complete masterpiece. It took 26 year old Michelangelo 2 years to carve out of a singular block of marble. Marble was so expensive at the time that it took the government’s special order to just get a block big enough for the commission... meaning, there was zero room for iteration - it was a job only a master could do.

However... to Michelangelo, David was only one in a series the dozens of enormous efforts in master works he created during his lifetime. To a student, impossible, but to him, It was just another iteration (an iteration of his process, not of a singular work). Masters come to the table having iterated and failed more times than an amateur has ever attempted.

This is all to say, that this discussion is one purely of perspective. If iterating is the only means to become a master, and masters are only iterating on their processes, is there even really such a thing as a masterpiece? Is it just a matter of scale? If you’re already comfortable with being a “fierce iterator” where you accept that no design is ever complete... is it so wrong to have the mindset of a master? Is there even a difference between a fierce iterator and a master?

Perhaps what I’m really describing and getting caught on here is the leap from design/pre-production into production/construction... this is a dichotomy that often crosses my mind as a software developer. Iterate a million times in design, so that when it comes time to CREATE the design, you can produce that masterpiece. In this example, the students are kind of designing and creating at the same time.

In the spirit of this chapter on “Evaluation,” the criteria for success makes such a difference here. I think that in a vacuum, the ceramic students trying to produce an arbitrarily “high quality” ceramic via constant iteration may create the most commercially viable, most structurally tested, most mass-appeal, most generically applicable ceramic... but it is not likely that they create the most provocative, most illustrious, most unique, most full-scale, most detailed, most emotional... etc. Those types of qualities arise from masterful vision, pre-meditation, and singular execution.

Implementation is my favorite step and where I personally can make the biggest contributions. Its that step that finally INTEGRATES design, business, and technology. 

Previsualization is an essential step, but it is only a means to an end, and that end is when those that can, do. It’s why skills like programming are so sought after by both employers and employees.

Ideation is a concept which I have a love/hate relationship with. As I’ve covered previously, I feel that my strong instinct for inspiration sometimes supersedes my desire to “brainstorm,” proper. 

After going through the research process with my team during last week’s class, I realized that there were multiple areas that the problem could take the form of. Due to the fact that our team came into the research process with multiple ideas that we were passionate about creating a vision for, I felt that it was important to consider all of the ideas before coming up to a singular definition. 

I began by synthesizing all of the research that we gained as a team and finding the various themes across our various interests. Using the “keywords” approach, I was able to find the areas of intersection across our team’s diverse ideas and begin to narrow in on the main problem scope. Since our ideas mainly focused on how to improve healthcare, I began to dig a little deeper into the current healthcare system, which allowed me to uncover additional problems that would need to be addressed. For example: 

With the increasing rise of wearable devices being utilized as a fitness tracking device, what was stopping users from storing their medical records on them? 

What were the current issues that users dealt with while using fitness trackers? 

How can fitness trackers and various wearable devices make the process of receiving healthcare and viewing medical records more efficient for users?

How can healthcare be made more accessible, so that all users can easily access their records at any time on any device?

Many of the topics covered in this chapter stuck out to me as techniques I use in my practice as a digital professional. In the world of code, everything is abstracted, so defining problems, boiling things down to the core, and emphasizing priorities can be essential to the success of the developer and especially a development team.

When interfacing with less-technical team members, techniques such as Diagrams, Sketches, Analogies, and Terminology Simplification are absolute musts. I also find these methods useful in creative endeavors, where there is often no better way to describe a composition or technique without a visual aid of some sort. 

Turning thoughts into words is also a trusted addition to my toolbelt. I’m the kind of person that can synthesize a large sum of ideas quickly, which has forced me to learn that it “don’t mean a thing” until you get it down on paper. Sometimes, you can find that you didn’t have such a great idea in the first place. Just as the chapter provided for, I often start with a “list of everything” or “mind-map” kind of setup, which I can then organize and prioritize. In software, there is often a “order of operations” that must be adhered to. In art, gathering reference is an essential step that informs the entire process.

Everyone dreams of living in a fairy-tale world where problems can be cured with something as simple as a “spoonful of sugar to make the medicine go down.” Unfortunately, this fairy-tale dream of doctors being Mary Poppins who can snap their fingers and cure you with a song, will never be our reality due to the inaccessibility of healthcare treatment around the globe. The process of getting treatment is tedious and time consuming and far from being easy for most patients. 

This project would allow us to reinvent the current healthcare system around the globe. Through utilizing the latest technology in the form of wearable devices, patients could easily access their medical records and test results, no matter where they are. They would not have to wait on anyone to send them anything that is imperative to their health and would have the power to be more autonomous. In addition to being able to see their medical records with just a single click, patients can also receive reliable forms of treatment depending on their diagnosis.