Philip Haine's articles on Product Vision, Innovation and Design

The Design Pyramid

How research, vision and design fit together to make breakthrough products

Philip Haine's Design PyramidWhy is great design so elusive?  Why do requirements so often shift late in the game, wasting months of effort and millions of dollars?  Where should we look to come up with breakthroughs product concepts?  And above all, how can we make our design process less chaotic?

For years, I have sketched out a simple diagram to explain my answers to these types of questions.

This diagram, the Design Pyramid, suggests that the design we can see and touch is just the tip of the iceberg.  It is supported by layers of information and prerequisite decisions that are largely invisible to the naked eye.  The four layers of the Pyramid are, from top to bottom: Design, Requirements, Vision, and Understanding.

The key premise of the Design Pyramid is that each layer can only be as good as those below it.

The Design Pyramid clarifies why many products and designs fail, and suggests what should be done differently in the product creation process to achieve breakthrough products.

Let’s go through each layer.

The Design Layer

The Design layer is simply the solution to a design problem.

The solution takes different form depending on what is being designed.  For software products, the solution includes the user experience architecture, the interactions, conceptual model, and the internal software architecture.  For a process design, the output is a process map.  For public policy, it’s a legislative bill, and so on.  In all cases, the design is the solution to a functional problem.


The Requirements Layer

Design requirements are detailed criteria that describe what the solution must accomplish.  They provide enough detail to give the team concrete guidance for designing and building the product, and for knowing when it is done.

Requirements can sometimes be a big, onerous deal.  When that’s the case it’s often because its authors are trying to do more than one thing at at time.  They are trying to write down requirements while they still figuring out the vision for the product.  Trying to do them both at the same time is like trying to paint a room while still deciding on a paint color.  It’s a lot easier to paint if you only have to worry about painting and not color schemes.

If the vision is flawed, incomplete or not properly thought through, the requirements will be difficult to write.  And they will be bound to shift radically, because the flaws in the vision can’t be swept under the rug forever.  Eventually they will make themselves known and will force the team to make major course corrections.

When the vision is clear and correct, the requirements fall out easily and are much more stable.

The Vision Layer

If you’re going to cross the sea in search of riches, it helps to know where you’re going, and it helps to know that where you are going will be a worthwhile destination.

A product’s vision is like the destination port.  It establishes the direction in which everyone should be paddling.   If the destination is not well-defined, at best, time and energy will be wasted making course corrections.  (If the new direction is chosen by the same means as the original destination, I would start to worry. Who’s to say that the new destination is much better?)

In the worst case, the ship runs out of supplies and never I makes it.   With a badly chosen destination, the journey has actually failed before it begins.  It couldn’t have made it no matter how hard everyone paddled.

And so it goes with products: a faulty vision dooms the initiative before it sets off.  When you see requirements shift repeatedly, or when you see a product get canceled just before or after launch, it’s a sure sign that the vision was fundamentally flawed from the get-go.

How can we translate the idea of product vision in more concrete terms that we can do something with?

Think of it this way.  Any group of customers has not one, but a whole host of needs.  We can’t possibly solve all of them, especially in the near term.  Before even attempting to solve them, we must first select which needs are worthy of solving, and we need to formulate the set of needs into a cohesive package.

This is the purpose of product vision process.  The vision establishes which problems the design should solve.  (This is equivalent to establishing which profile of customer needs we should address out of the universe of possibilities.)

That is the vision layer.  Where do the flaws in the vision arise?  They often stem from missing or erroneous assumptions, which reside in the Understanding layer below.

The Understanding Layer

If the vision is the destination port of the journey, then our Understanding is the map of the seas and ports.  We need the map to peruse our destination options.

This is where the Understanding layer comes in.

The Understanding layer is made up of pretty much any insight that help us come up with a good solution.  That is a pretty broad definition.  In practice, there is a core set of elements that we need to understand no matter what we are designing — a software product, a business process, a building, or a piece of legislation.  We need:

  1. Understanding of stakeholders: who the customers and users and others?  How they naturally segment themselves, so we are clear on who needs what?
  2. Understanding their specific situations and needs: we need to understand not only what matters to them, but why it matters.  Achieving the “why” is what lets us attain the deeper empathy with the stakeholders that lets us put ourselves in their situation.  It’s what allows us to interpolate and extrapolate beyond what they tell us they need —  beyond what they may even be capable of telling us — to what they actually need.  And this is what lets us create things that customers will want, but which they cannot anticipate  (Hint: this is a key source of innovation!)
  3. Understanding of the competition: It does us little good to address needs that are already solved well enough by the competition.  We need to understand where the competition is now and where they are heading.
  4. Understanding of the status quo:if we are improving on an existing product, we need to get honest and lay bare its limitations, devoid of spin.
  5. Understanding of technology: Technology is not an end in and of itself.  It’s a means to addressing important unmet needs.  We need to understand the nature of current and emerging technology so we can connect what is needed by customers with what is possible thanks to technology.

How well we understand all of these things determines the upper bound on the quality of our vision.  A shallow understanding begets shallow, unimpressive product visions.  Breakthrough insight leads to breakthrough product vision.

Now that we’ve touched on all four layers, let’s use the Design Pyramid to get back to some of the questions I opened with.

Why is great product design so elusive?

Each layer of the Design Pyramid is only as good as those below it.  If the requirements don’t make sense, then neither will the design. If the vision is flawed, the design will be irrelevant; the product is solving a problem that is unimportant to customers.  If the understanding of customers and their needs is flawed, it will misinform the vision and undermine the whole effort.

Great product design is elusive not because of flaws in the design effort but because of inadequacies at the lower two levels of the Pyramid: Understanding and Vision.

The vision layer gets short shrift in common practice, despite its profound influence on the outcome.  Organizations have teams that are are eager to jump in the boat and get paddling, and they rarely allot time to properly draw a map and chart a course to a worthy destination.

Some organizations do put effort into arriving at breakthrough product visions.  But without clarity on the ingredients, without a good conceptual model and process, the efforts often fall flat.  (This is something I help clients with!)

Product vision is the missing discipline in product creation, and a ripe area to be matured over the next ten years.  (I’ll have heaps more to say about this in the coming months!)

Where does the Design Pyramid apply?

The power of the Design Pyramid is that its lessons apply to all types of functional design.

I’m using the term “product” in this article, but the Design Pyramid also applies to any functional design problem including interaction design, information architecture, services, database design, new process workflow, retail store layout, public policy, architecture, legislation and more.

All of these type of functional problems have the same intrinsic nature: we need masterful understanding of customers, competitors and technology to sculpt a vision of a problem with solving.  The high-level vision needs to be translated into concrete and actionable requirements so we know the characteristics of a “good” design.

[nb. Designs that are primarily about aesthetics, emotions, taste, and fashion operate under a different set of rules.  I would not look to the Design Pyramid for guidance on composing a song, writing a poem or painting a mural.]

Where do breakthrough products come from?

Breakthrough product ideas come from from breakthrough understanding.  The spark happens at the understanding level and bubbles its way up the Design Pyramid, inspiring the vision that guides the requirements that guides the design.

Take, for example, the overused example of the iPod.  Apple noticed that early batch of MP3 players played music well enough, but getting songs on the device was excruciatingly slow over the USB 1.0 interfaces common at the time.  Plus, the quirky, proprietary music transfer software was hard to manage.  This was a real problem.  The solid-state devices of the day had such small capacity that unless you liked listening to the same three albums over and over again, you had to spend a lot of time transferring new music onto the device.  Because of this cost, MP3 players often ended up gathering dust in a drawer.  These were Apple’s core insights, at the Understanding level of the Pyramid.

The iPod vision was sculpted to address these problems: make music management easy with great desktop software (iTunes); make transfers fast (using Firewire) and make transfers rarely necessary (with a high-capacity, hard-drive based player). Beyondthis, Apple understood that the that gadgets you are seen with in public are a reflection of your image, and that an MP3 player should look and feel cool.

Their easy, fast, high-capacity, cool looking iPod was a breakthrough product that virtually owned the digital music market through its entire arc (until smartphones and pocketable computers like the iPod Touch relegated the single-purpose music player to niche product).

If you examine other breakthrough innovations (see the product vision hall of fame), you will find this same pattern: key insights into customer needs (understanding) leading to radically different problem definition (visions), translating into unique requirements.  When a good vision is followed through with excellent design (not to mention engineering, marketing, sales, distribution and support… you know, the easy stuff) the stage is set for a breakthrough product.

There is heaps more to say about product vision, so stay tuned!

Philip Haine is principal of Product Vision Associates, a product innovation consultancy that helps product leaders and their teams envision new, breakthrough products and reboot older ones.  To follow him on Twitter click here.

Thanks to Michael Poremba and David Cortright for reviewing earlier drafts of this article.

[Updated 10/14/09 - Edited for clarity]


Posted by Philip Haine on Thursday, July 31st, 2008 at 10:33 pm.
See similar articles in: Commentary, Design Tools & Resources, Vision Process.

8 Responses to “The Design Pyramid”

  1. Tartle wrote on August 2nd, 2008 at 2:12 am :

    Thoughtful article:
    In my view
    Co-creating the Vision of how the ‘work-product’ will benefit the users seems to be the strongest ‘barrier’ to mediocre/incremental design that delivers little value (to anyone- developers, users, etc.). As people’s uncertainties press them to be less radical the vision can be used to re-invigorate the team…and challenge gatekeepers who are using yesterday’s criteria to measure tomorrows winner…we can ask “good idea but are will it be adventurous enough to achieve our vision?”

  2. Philip Haine wrote on August 2nd, 2008 at 10:33 am :

    Thanks for the thoughts, Tartle… here is how I paraphrase it:

    - Uncertainties over what to do lead to indecision and therefore lack of “boldness” on the vision and therefore mediocre products.

    - The “old guard” tends to use outdated criteria to judge ideas

    - Involve the product team in defining the vision to re-invigorate everyone

    - Define the vision in terms of user needs. This is starting with the end in mind, rather than defining the next product relative to where we are now.

    - If the team drifts back towards incrementalism, offer the reality check question: is this bold enough to fulfill our vision?

  3. Picking a frame: Activities vs. Goals vs. Needs | Product Vision blog wrote on October 1st, 2008 at 2:13 pm :

    [...] also: Design Pyramid | SSNiF [...]

  4. When Product Vision Goes Right | Product Vision blog wrote on October 21st, 2008 at 11:37 am :

    [...] that competitors leave behind. (These are key elements of the Understanding layer of the Design Pyramid.)  This insight leads to great product visions. Important unmet customer needs are addressed far [...]

  5. Formal Needs Analysis Part 2: Differentiating Based on Needs | The Product Vision blog wrote on August 22nd, 2009 at 6:42 pm :

    [...] us mastery over the competitive field.  This is part of the Understanding level at the base of the Design Pyramid.  You cannot go through the needs exercise without gaining clarity on your personal or your [...]

  6. Quote: Philip Haine at Sushi & Robots, by Jina Bolton wrote on September 2nd, 2009 at 12:36 am :

    [...] – Philip Haine [...]

  7. Alyssa wrote on March 22nd, 2010 at 8:13 am :

    eww there is not even a pyramid there is just a thing explaining what you need to do frist befor you make it now how you do

  8. Iceberg analogy to design thought | The Product Vision blog wrote on June 3rd, 2010 at 11:48 am :

    [...] described the Design layer of the Design Pyramid as being the visible tip of the iceberg.  These folks used the same analogy to describe Design [...]

Leave a Reply