The Double Diamond Model of Product Design

This model, created by Peter Merholz of Adaptive Path and Groupon fame, best represents the product design process in a way that’s both complete and digestible. I wish I’d seen this when building out our process at Appiphony a few years ago.

Peter mentions creating it to clarify the full extent to which the design team is involved, and that definitely resonates with me. The piece I keep needing to explain is that design does not happen “up front” before “the work starts.” The detailed design of each component is part of the work, and it’s baked into each iteration cycle. The design-related work we do before that is figuring out how many of those components to build and doing the customer research we’ll need to fuel later phases.

Note: this model is only meant to highlight work done by the design team and under-represents the effort needed by development, QA, marketing and others to actually ship.

The Double Diamond Model of Product Design

This model, created by Peter Merholz of Adaptive Path and Groupon fame, best represents the product design process in a way that’s both complete and digestible. I wish I’d seen this when building out our process at Appiphony a few years ago.

Peter mentions creating it to clarify the full extent to which the design team is involved, and that definitely resonates with me. The piece I keep needing to explain is that design does not happen “up front” before “the work starts.” The detailed design of each component is part of the work, and it’s baked into each iteration cycle. The design-related work we do before that is figuring out how many of those components to build and doing the customer research we’ll need to fuel later phases.

Note: this model is only meant to highlight work done by the design team and under-represents the effort needed by development, QA, marketing and others to actually ship.

The “to do” method of unpacking user activity

Have you ever seen something like this listed in a requirements document?

Financial analysts need to manage the month-end close process

If you’re like me, you may wonder, “what does that mean, exactly? How might one manage a month-end close process?”

The problem is the word manage; it can mean nearly anything. Without being a finance expert, you can understand that you manage a month-end close differently than you manage a summer intern—but, for some reason, we use the same word.

When I encounter a similar requirement, I ask this:

What would someone put on their to-do list to finish this work?

In this case, it might be:

  • Tally the accounts receivable
  • Tally the accounts payable
  • Send a profitability report to the executive team

Now we’re getting somewhere! You can begin to imagine what a user might do to complete those tasks, and how you can help that user.

The critical problem: their feedback is next to worthless if they didn’t struggle through the actual problem the product solves and make trade offs.

Not only did they not make any trade offs in their decision, they didn’t even select the product!

Still defining the problem after all these years

I stumbled across this introductory Pascal book at a relative’s house and was intrigued by a brief section called The Phases of Development, which breaks the task of programming into four phases:

Clarify the problem requirements.
Design a program strategy.
Specify critical data structures.
Write the program statements.
I particularly love some of the quotes on problem clarification:


Surprisingly, clarification of the problem is a major phase of the process. It would seem reasonable that a clear and precise statement of the problem would be given but in fact this is rarely the case and more programming disasters can be blamed on failure in this regard than any other.


Today’s coding skills won’t be relevant in thirty years, but we’ll still need to clearly define the problem.

Still defining the problem after all these years

I stumbled across this introductory Pascal book at a relative’s house and was intrigued by a brief section called The Phases of Development, which breaks the task of programming into four phases:

  1. Clarify the problem requirements.
  2. Design a program strategy.
  3. Specify critical data structures.
  4. Write the program statements.

I particularly love some of the quotes on problem clarification:

Surprisingly, clarification of the problem is a major phase of the process. It would seem reasonable that a clear and precise statement of the problem would be given but in fact this is rarely the case and more programming disasters can be blamed on failure in this regard than any other.

Today’s coding skills won’t be relevant in thirty years, but we’ll still need to clearly define the problem.

Scenarios are much more than Use Cases

It’s not uncommon for a designer to join a project in which “the use cases are already written.” This documentation attempts to describe in words how a user will complete a particular task within the system.

Scenarios take this further and include the context around the action to form a complete story of a person in the real world using the product to create a positive outcome. In the example shown here (Square’s credit card reader), I’ve intentionally de-emphasized the steps around charging the card to highlight the surrounding context. Reviewing the full story helps the team identify additional functionality the product needs to serve this customer:

  • The charge needs to be authorized in less than 5 seconds. (Count it out and imagine being the buyer, waiting and drumming your fingers.)
  • The seller needs an easy way to cancel or refund the charge. (Someone will hit the wrong button in the chaos of the trade show floor.)
  • A simple way to keep/decrement inventory would be a value-add for the seller.

Imagine if this team stopped at simply “meeting the requirement” that the seller swipe the card and the buyer signs with their finger. That notion is abstract beyond the point of helping the team know if they can serve this customer. Instead ask how your product will help a specific person get through a specific situation.

If you don’t know what situations your customers are in, try this.

Analyzing the final product: staring at the scoreboard

Let’s say you’re building a product, and you do some competitive analysis to see how others have addressed the same problem. Sounds reasonable, right?

Here’s the trouble: if you can only look at the final product, and can’t see any of the work that led up to it, you’re missing most of what’s interesting. What trade-offs did the team make based on what they learned along the way? What’s planned for the next release? How did they arrive at their design decisions?

It’s like staring at the scoreboard of a baseball game after it’s over. If you didn’t watch the game, you won’t get much out of it. You missed all the action.

Photos courtesy of Eric Kilby and Keith Allison

Revolutionary products still meet existing demand

Your product can be the newest, coolest thing around, but it still needs to serve existing demand in the market. Even the iPad was introduced by listing the activities people already do that it improved upon:

  • Web browsing
  • Email
  • Photo management
  • Watching video
  • Listening to music
  • Playing games
  • Reading eBooks

By itself, the list borders on mundane.

Ash Maurya, a leader in the Lean Startup community, made this great point on the latest episode of the Jobs-to-be-Done podcast. Check that out for more.

Your app inside Salesforce is like a Starbucks in China

Our work with clients often involves rewriting their Java or .NET on-premise app to run inside Salesforce.com. We’ve noticed, however, that dropping the existing app concepts into Salesforce wholesale does not work well. Salesforce is a development platform, but also a suite of robust apps—not a blank slate. Those apps are already there and customers are used to them. Designing the “Salesforce version” of an app involves reworking the ideas to deliver the same core value proposition in a new setting.

It’s not unlike how Starbucks found success in China by adjusting for local tastes. The classics are still on the menu, accompanied by Chinese tea and red bean beverages. It’s still great, just different. BusinessWeek reports that “China will replace Canada as Starbucks’ second largest market by store count and sales” sometime this year.

The Wall Street Journal contrasts this with “businesses that have failed to grasp the local culture, importing alien models.” Both Home Depot and Best Buy closed all of their China locations after failing to meet local demand.

“We don’t do one size fits all,” said Starbucks’ China president. They adapt, and thrive.