#idsn540

[ashrithaachu-blog]

Process Journal: Evaluation

“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. 

Overall, this entire experience has pushed me WAY out of my comfort zone in terms and has forced me to try to utilize different methods and techniques than the ones that I am used to using. I am definitely someone who is drawn to creativity because of the ability to dedicate one’s time and energy to learning the craft, but I also am someone who easily gets impatient when things don’t work out the way that they are supposed to. When creating a product, creativity is important, but it is also important to be realistic and understand that you are creating something for more than just yourself to enjoy. It is more about quality than quantity, because it is better to have one thing that works and improves someone’s life rather than many things that hinder someone. I am definitely excited that this process is over, but I look forward to taking what I have learned over the course of this project and applying it to future projects and products that I design. 

[hunter-mw]

On Evaluation

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.

At the end of the day, this program is about divergent thinking. That means rejecting certain established truths - in my mind, that absolutely includes this curriculum. I don’t hesitate to find valid opposing points for platitudes like the “masterpiece vs iteration” ceramics thought experiment.

[ashrithaachu-blog]

Process Journal: Implementation Pt. 2

I feel like coming off of last week, our team had a more solidified idea of what we wanted to design, as we set a target demographic and medium for how we wanted our product to be offered and implemented. After getting feedback from our professor, we realized that we wanted the product to enhance an already existing service, like an Apple watch, since there is already a lot of competition in terms of the product we are trying to sell. This made me feel really eager as we headed into this next phase of implementation, since it was nice to know that we weren’t starting totally from scratch. 

However, our group has a really difficult time meeting up to collaborate and sync up on what exactly we want in our design and how we want it to function, so the actual implementation process was rather stressful. We used Slack a lot, but it was hard to physically communicate the specs of my designs to the group since everyone had a different idea in their minds of how they wanted the flow of the product to be. While we all wanted it to be as simple as possible, what would the pages look like? Did we want the product to prioritize medical records? Or did we want it to mainly be an AI doctor? Even after our discussion last week, I was still utterly confused (which is rather embarrassing to say so), so I just went ahead and continued building off of my ideas from last week, while my group created a website that would contain our product and the necessary resources. 

As much as I love this project and am passionate about it due to personal reasons, I am finding it to be a huge learning curve in terms of collaboration to ensure that all of our ideas are as feasible as they are impactful. I honestly feel a little bit of imposter syndrome creeping in as I feel like I don’t know how to contribute to the project, since the rest of my group is really knowledgeable and has a wealth of information on how to implement and sell this product. These thoughts race through my mind every time I think about this project: How do I contribute and feel positive about my impact if I barely know the subject matter? How do I make my voice feel heard if we only sync up for 30 minutes after a long class, during which I struggle to understand the terminology that my group uses for the project? What will be my impact on this team? 

There are only a few more weeks left in this project, and so I hope that as we move forward, the collaboration will get easier and that we will settle on an idea and focus on trying to solve one area of healthcare instead of trying to change the whole world. My imposter syndrome may not go away due to how challenging the scope of the project is in terms of the subject matter our group has chosen, but I feel slightly more at ease knowing that our project has the potential to change lives and the future of healthcare. 

[hunter-mw]

On Implementation

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.

It’s easy to talk about the problem for hours and hours, but at a certain point, you have to start implementing to find out all the things that you didn’t know in the first place. Usually, there’s a LOT that you didn’t know. It’s only then, that you can start this entire process over, and use the result of your implementation in your next ideas.

[ashrithaachu-blog]

Process Journal: Implementation

After our last class ended, our group divided up the work in terms of how we wanted to implement our product. Did we want it to be a product that could be accessed on a computer from the comforts of their own home, or did we want it to be slightly more portable and accessible on a mobile device or tablet? We began our implementation process by conducting additional research to see what other products similar to ours are doing currently, and split up the tasks as to what each of us felt comfortable doing for the deliverables. I opted for designing the app, as I have a lot of experience with sketching and wireframing and wanted to flesh the idea out a bit to validate the potential and feasibility of the current product. 

I was really excited about the idea of implementation and finally being able to apply all of our ideas into one cohesive product. However, due to the fact that our initial solution itself was so broad and our definition changes the more we do research every week, this phase proved to be the most difficult and arduous. Every time we seem to come to a conclusion on what to finalize, the more we want to add, which makes me realize how important it is to come to a “moment of truth,” where we put in writing exactly what we want to commit to as a group. I feel like defining our exact target audience and what realm of healthcare we want to focus on as a group would definitely help us figure out exactly what we needed to design. Would it be an app to contain medical records like we initially planned? Or would it be a virtual healthcare portal that users could open and receive treatment, even if they weren’t at the doctor’s office? These many questions made it almost impossible to decide what to design as the possibilities were endless in our group’s minds. After much deliberation and idea dumping in Google Docs and through Slack, we decided to make a customizable product that focused on providing treatment through an AI doctor and made it easier to access medical records. 

Even though I may have stated that the process was arduous, it was definitely a learning curve to be able to compile all of our various ideas into one cohesive product and find a healthy balance between all of the things which we wanted to achieve. I am definitely excited to see how the product continues to develop and grow as we prototype and possibly connect with users, through usability testing, if given the opportunity. I honestly could keep talking about the excitement I have to see this product through, as it is something that I am very passionate about, but I will save that for another journal when the product has developed a sense of identity and has more functionality. 

[hunter-mw]

On Ideation

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. 

In programming, after conceptualizing different possibilities, I dive right into whichever idea is the best fit. Once that first idea inevitably doesn’t work, that’s when its time to truly ideate. 

[ashrithaachu-blog]

Process Journal: Ideation

The ideation phase, to me, has always been the most exciting, but also nerve-wracking part of the problem solving process, as it is the place where we as a team and respective individuals can get our authentic ideas flowing. As a group, we came to the conclusion that we wanted to focus on wearable technology and how to incorporate them in the healthcare space, and shared our viewpoints on what we would hope to achieve and create by combining all of our ideas. However, even though our group had an idea of where we wanted to focus our energy, the brainstorming phase proved to be rather difficult, as we ended up going too deep into our research and uncovering other ideas that we wanted to explore instead of honing on the problem at hand. 

“What wearable technology should we use? What will it be used for? I want to solve that, but there is a product that already exists; maybe there is a way we could make it better though?” These were all questions that came up in our conversation and made me realize that coming up with just 3 ideas would be difficult, as there were so many problems that our passionate group wanted to solve. The ideation phase was slowly turning into the IDK-tion phase, since I was not sure whether or not we would be able to come up with ideas by the deadline. 

However, after much discussion and idea dumping in a Google Slides presentation, our group began to see some overlap in our ideas and narrowed it down to using wearable technology as our primary product. Since we wanted to keep our idea simple, but still innovative and unique, we decided to build upon the existing technologies and came up the ideas of creating an app that works alongside wearables to detect chronic disease in the early stages, an app that can be integrated alongside Apple Research and targets a particular health issue (i.e., diabetes, obesity, autism, etc.), and a medical records passport chip/transplant that “communicates with” other connected devices for doctors to scan. 

Overall, our ideas could still use a little bit of refinement, as our group is still debating about which direction to take due to the overwhelming amount of research with regards to our problem space, but I am excited to see how we hone in on our ideas as we go through the rest of the problem solving process.

[ashrithaachu-blog]

Process Journal: Definition

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?

After I noted down all the various themes that we discussed during the process of researching ideas, I noticed a clear overlap between all of our ideas and an opportunity to incorporate all of our visions into one cohesive product. As a result, I feel like it would be most beneficial if we focused on the idea of using the latest technology (i.e., wearable technology, mobile apps) as a platform to revolutionize the process of receiving healthcare, to ensure practicality and feasibility of completion. Overall, I think that our definition is a cohesive collection of our diverse inputs, since all of our ideas feed into each other in some way or the other.