A brief break from finals to share a bit from Hugh Dubberly

Hey world! I'm always a bit surprised and humbled about who reads these posts! I'm realizing more and more that readers come from all sorts of backgrounds, design and non-design. So this post is for you non-designers out there who happened to come across my site somehow. (Also, this gives me a mental break from pumping out app page designs and wireframes for a plethora of different projects which will appear on my website in the coming weeks, following presentations).

In 2008, Mr. Dubberly wrote an article called "The Analysis-Synthesis Bridge Model". I'd like to discuss this further today.. perhaps in less elegant non-designer-y wording. He starts the discusssion with this well articulated set of questions: 

The simplest way to describe the design process is to divide it into two phases: analysis and synthesis. Or preparation and inspiration. But those descriptions miss a crucial element—the connection between the two, the active move from one state to another, the transition or transformation that is at the heart of designing. How do designers move from analysis to synthesis? From problem to solution? From current situation to preferred future? From research to concept? From constituent needs to proposed response? From context to form?How do designers bridge the gap?

People throughout the years have attempted to visually communicate their take on models and processes. I'll share a few below, as quickly crafted images from illustrator:

Don Norman, a well known designer and author, shared a divergent/convergent model within his book "Design of Everyday Things". It's still very commonly referred to when explaining the design process.


Another commonly mentioned model is that of IDEO, perhaps because of their popularity and wide reach to the larger audience. (When I say "design thinking" to someone, especially non-designers, they often say something like "Oh, like IDEO?").

Finally, there's our model we use at the Institute of Design, put together by Vijay Kumar. The only change I made to his model is omitting "prototyping" from the last square (Delivery). Perhaps it's my background in architecture and comfort using prototypes to figure things out and test with prototypes, but I join a group of other students and professors at ID that are starting to advocate for prototyping to be the grout, or the area between the squares as prototyping (those little black arrows). I should clarify as well that sometimes the hypothesis comes from the client- their understanding and explanation of what the problem is (and/or what they want you to solve). We call this a design brief. 

Grounded Theory vs. Scientific Method

Now comes the explanation part. These are all forms of reasoning based on the Grounded Theory method, which differs from the Scientific Method (yes, that we all learned in middle/high school) in that you don't approach the problem with a solution in mind already. Maybe it's best to start with explaining the scientific method first since I imagine that might be a little more familiar.

Within the scientific method, one looks at a problem, understands different components about said problem, and then develops a hypothesis about it. Through a series of tests, he or she can determine if that hypothesis is correct or incorrect. If correct, further testing can be done to back up initial findings. If not correct, the preliminary hypothesis must be altered. The problem with this method in innovation is that it only solves one YES/NO question: "Will _____ solve my problem?"

If your test shows it does solve your problem, that's great! But, unfortunately, when your hypothesis is proven incorrect, you're only left knowing your initial assumption was incorrect. Where does that leave you? You likely know a little more about the problem to create another hypothesis, but this still leaves you repeating the process again and again in a linear pattern, to keep whacking the problem with a hammer that will hopefully someday find the nail. 


Instead, Grounded Theory approaches the problem without assumption of a hypothesis. One goes into the field and simply observes, asks questions, and takes notes. He or she looks at phenomenon, coping strategies, learned behaviors (habits), and other traits people might not even be aware they're doing related to the problem, context, or object being studied. This ranges from watching people throw away trash (yep, I've done this), to watching people check out at McDonalds or deal with the awkwardness of waiting around at a hotel for your colleagues after you've checked out (yep, done that too). You can use prototypes to help in interviews to discover more about users that they may not initially tell you- see: cultural probes. I made a prototype for interviewing for my summer research project this past summer. Read more about it, and see it, here.


From there you gather all of your findings, notes, surprises, and recordings and structure/sort them in different ways using different frameworks to see what you've collected. Are there trends in what you observed? What kind of users were present during your observation? Were there activities you anticipated seeing that you didn't see? What orthodoxies exist that could be challenged within a solution? (Here's where you figure out what the crux of the problem is. Now you can redefine your problem... which could be different from what your client initially thought was wrong, or add to their hypothesis of the problem). 

Synthesis + Delivery

From these learnings, you can start to "synthesize" or come up with solutions that meet the now-structured findings from your research. (Here's where you think about that second part of the double diamond approach... you're diverging and coming up with lots of solutions). From these ideas, you can then look at them through a business perspective to figure out which ideas are both desirable (for users, company, etc.) and also importantly, feasible from a business, technology, cultural, and capability perspective. This goes into the delivery stage which has many more factors, depending on the industry.

The really awesome thing about grounded theory is that you can keep repeating the process- it's not linear. For example, following that flow above, let's say you came up with a really cool idea for an app that was feasible to make and helped the bottom line of the business you're working for. What's next? You can build prototypes of the app and conduct usability testing! Back to square one- research! How you improve your app concept will follow that same path described above. Not only can you test the app to find small bugs in your design, you can also test whether your findings were on track: Are users responding to your product or service in the way you expected? If not, what can we learn from this and build out in our offering?

Now, instead of simply knowing if your initial idea is correct or incorrect, you have a variety of different ideas derived straight from user behavior/feedback you can build strategies around which could influence tons of different ideas that inform the problem you identified through research and analysis. There is the caveat of our own biases and influences, so as researchers and designers, we have to address these in advance, be be aware of these throughout the process, and also be sure to identify them as you take note of your process and findings.

I know that's not an exhaustive explanation of the whole process, but hopefully it gets you thinking a little about how to approach problems and see innovation and ideation in new ways! Designers as you read this, if I butchered anything, please feel free to shoot me an email and I'll be sure to address your concerns with updates/edits as needed :)

Have a great week, more after finals!