Archive for the ‘Research Methods’ Category

Focused Brainstorming


There are times when you want to do blue-sky brainstorming – forget about the constraints and come up with crazy ideas that might lead you to revolutionary software designs. But there are also times when you want to come up with creative, but realistic ideas that can actually be developed into a concrete design. Here are the steps that my project team took today which led to a very productive and fun brainstorming session.

1. Understand the needs and constraints – You need to understand what you’re brainstorming about. Understand what the users’ problems and needs are, and what constraints exist.

2. Come up with brainstorming seed questions -You might be able to brainstorm directly from the needs and constraints you’ve developed in the previous step if the problem isn’t too large. But the scope of our project is pretty big and it needed some processing to be digestible. We came up with what we called “design challenges” or “brainstorming seed questions”. Some examples could be “How can you make instant messaging notification easy to notice, but not annoying?”, “How can you track multiple instant messaging conversations?”

3. Brainstorm and visualize the ideas – ALWAYS DRAW! Coming up with an idea you can write down in a few words might take 10 seconds. Being able to draw even a rough sketch makes you flesh out the idea and think about important aspects of it. This could take 5-10 minutes or even more to do, but it’s the process of validating the idea and developing it to make sense. Also, brainstorming ideas can be pretty vague and a drawing is one of the best ways to get your idea across to the team. Another thing we did was to do some brainstorming on your own before coming to the brainstorming meeting. Doing some work ahead of time made it possible to go through many more ideas in the limited amount of time.

4. Build on top of other ideas – Don’t criticize other people’s ideas and don’t get attached to yours. Every idea that you toss out to the team is no longer yours. Try to build on top of others’ ideas. This is the typical brainstorming process, so I won’t elaborate too much on this part. One thing that went well today was to prevent the team from going too deep into each of the ideas. You want to get all the breadth out first before you dive deep.

5. Critically examine the ideas, refine and re-brainstorm – This is where you critically question each idea. Think of how this fits into an actual user scenario. Think of all the different ways the idea or feature has to work. This will help pull out details or constraints that you might not have thought of.  Refine ideas, further develop them. This might lead to new ideas that might solve the problem in a better way.

Another thing to remember: even brainstorming sessions, just like any other meeting, needs to have a well thought through process and a goal which the whole team understands. Otherwise, you can end up just going around and around throwing out ideas that aren’t really helpful. Brainstorming is a fuzzy process that is used in different ways and it’s important that the team understands what you want by the end of the day.


Affinity Diagrams


The 8-month MHCI Capstone project has started a little over 3 weeks ago and we are well into the research phase. The biggest portion of our research is Contextual Inquiries and before that all happens, its good to know who you plan to interview and what is it that you want to learn from the interviews. I’ve found affinity diagrams to work very well for this process.

The main purpose of affinity diagrams in Contextual Design is to organize a wide range of ideas that are produced from brainstorming, usually in a group of multiple people. All the ideas are written on post-its and put up on the wall and everyone can group the ideas as they want. This is usually a process including discussion so that everyone understands each other’s ideas and there is a level of consensus in the grouping. An important thing to remember is that groups of ideas should be small, usually not more than 4-5 items. Also, group descriptions or group names should be descriptive phrases, not vague, general words such as “task management”, “search”. This all helps people think carefully about how they group the items. The following images show an example of how many ideas slowly create groups and become organized.

Another aspect of affinity diagrams that I’ve found to be very valuable is that they help the participants to understand different perspectives, create a common understanding and naturally come to a consensus, even without making decisions or compromises. Everyone thinks they all have different ideas and that the ideas conflict, but as you actually describe and share your thoughts, everyone realizes that they aren’t actually so different.

This has actually been proved in both of the two Contextual Inquiry focus setting meetings that I’ve had until now. Before creating the affinity diagram, everyone has different ideas on what to focus on and what we want to achieve from the CIs. But once everyone writes out their thoughts on “What do you want to learn from the CIs?”, shares the ideas, learns others’ different perspectives and realizes all the things you haven’t thought of before, all the participants have a much better understanding of each other and naturally achieve a pretty good consensus of the CI focus. We’ve found this to be one of the most valuable and rewarding parts of the whole process.