Our Big Idea: Reverse Brainstorming
We finally figured out how to diverge meaningfully with the help of our Penn team. There was one thing that we were missing in the process of prototyping. And that was the thought that people respond more to the ‘quality’ a prototype has than the value it possesses. For each problem statement there could be defined set of qualities that the potential solution would contain in parts or in whole.
For example, a potential solution for the problem: Information is confusing would contain some or all of the following attributes:
It would provide the user with mindless access to information
It would be available at the moment of need
It would be relevant to user’s needs
It would be personalized for every user
And, it would demonstrate organization
Recording what qualities are more important to people in a particular prototype would hint towards their priorities, thus leading us to very informed decision making in this prototyping phase of our project. Getting a sense of what the users respond to the most, or their priorities would be ideal for an iterative process. Bam! That’s our big idea- Reverse Brainstorming (as my team-mate calls it).Following this method of discovery, we revisited our problem statements and started listing down the qualities that a potential solution would contain for each of them. There were obvious overlaps but that might not necessarily suggest its importance.
In interest of time and efficiency, we decided to focus on two prototypes (not problems) that we found to be most valuable and approachable in the context of our project and expanded upon them taking in consideration of the qualities generated earlier. Our hope was to then present them to our users to identify what they like and dislike about each element and base our iteration on the elements most preferred. Just to mention again, we were looking for valid feedback on the elements/qualities and not the form/content of the prototype.
Prototyping for finding a doctor
However, what we did was not what we were supposed to do. We still hadn't focused on one and only one problem to develop prototype on. In such case, people tend to respond to the form of the prototype again which wouldn't serve our purpose at all. So, we decided to ‘really’ focus this time to two problems: Finding a doctor and under-utilization of informal social networks (For more details on problem statements, refer to my previous post). Among these two problems we further decided to focus on finding a doctor utilizing the informal social networks. A lot of things in such a big health care system are dependent on recommendations from co-workers. So, the question became, “How might we harness the power of these informal social networks to help people find a doctor more efficiently and turn to Penn’s services?”
We would again be prototyping now carefully incorporating the qualities into our solutions which are now going to be more focused. The framework of the prototypes have to be designed in a way that it allows the user to interact with the function more than the form of it, generating useful data for us. I would shed more light on designing those frameworks my next post. Stay tuned!