Excel SSNiF template

Excel is the most polished and efficient tool for brainstorming SSNiFs.  It’s fast and scales to a large number of SSNiFs.  Excel supports boldfacing of words within cells, one of my tips.  Using my favorite launcher, I can have a fresh, blank matrix ready to go in seconds.

Nothing is perfect, and a disadvantage of Excel is that it does not allow multiple paragraphs or bullet points per cell (another tip).  Excel does not make it easy to collaborate; you must send copies to multiple people and then merge the results.  I suggest starting with Excel if you don’t need to immediately collaborate with others electronically.

Excel has an AutoFilter feature that helps to organize and analyze.  AutoFilter makes menus out of each column header, from which you can sort or filter the rows of the table.  Good columns to sort and filter are: Area of the Product, Big vs. Little SSNiF, and, if you have it, Priority.  To activate AutoFilter, select the title row and choose Data -> Filter -> AutoFilter.

Download Excel templates:

• Blank Excel SSNiF template (zip)
• Excel SSNiF template with sample data (zip)-  (This document includes a few sample SSNiFs behind the design of a commuter coffee mug.)

Google Spreadsheets

The free FREE Google Spreadsheets, part of Google Docs is fantastic for online collaboration.   Multiple people can edit a shared copy on their schedule, and even simultaneously with others.  You can link to the SSNiF analysis from anywhere, which facilitates access and usage.  Google Spreadsheets scales up very well.

The downsides are: you cannot yet boldface individual words within a cell, you cannot have paragraphs per cell, weak conditional formatting, you cannot merge cells vertically (right?), the user experience is clunkier than a modern desktop-based app.

Google Spreadsheets has a very good Excel import tool, so you can start your SSNiFs off in Excel and migrate them over when it’s time to collaborate.

You can access my Google Spreadsheets SSNiF template and make a copy from there (while signed in, choose File -> Copy Spreadsheet…)

• Google Spreadsheets SSNiF analysis template

Apple Numbers

I like where Apple is going with their Pages and Numbers.  They have a number of innovations, and they certainly look sharper.  But they are not quite mature yet for prime time use.

Nevertheless, here is the template I have for their spreadsheet, Numbers:

• Apple Numbers SSNiF analysis template (zip)

Word Processors

Word processor tables give full control over formatting your SSNiF tables.  They are useful when you will be communicating a small set of finely tuned SSNiFs to someone (for example, when using Big SSNiFs as the basis of the product vision).  You can generally merge cells and make them look exactly how you want.

Downsides: they don’t scale up as well as spreadsheet table, they get clumsy when there are additional columns, it’s hard to rearrange rows,

Here’s the SSNiF table in Microsoft Word format:

• MS Word SSNiF analysis template (zip)

HTML tables

Web/HTML editors – SSNiFs look  good in HTML tables, which support wrapping, multiple paragraphs in a cell, merging and highlighting.

The problem is that formatting can be a bear and takes time and mind juice away from thinking about the SSNiFs themselves.  I only use them once I have worked out the SSNiFs elsewhere, when I have to express them on a web page.

• HTML SSNiF analysis template – (bring your own CSS)

Google Sites

Google Sites is the wiki concept evolved.  It lets you publish always-available, hyperlinked documentation that anyone can read and refine at any time.  I’ve replace most of my paper-based design documentation with it.

Google Sites’ table editing functionality is crude, but sufficient for communicating small- to medium-sized SSNiF tables (from one to about 30 SSNiFs).  It allows tables to be interspersed with regular text, as I’ve demonstrated in some previous articles.  This makes Sites great for capturing requirements using SSNiFs.  (More on SSNiFs and requirements in Part 2)

Here is a simple Google Sites page you can copy for your own use:

• Google Sites SSNiF analysis template

Good luck using these templates.  If you make worthwhile refinements or versions in other formats, please send them to me for inclusion.

Email or link to this article at: http://stealthisidea.com/articles/ssnif-templates

<< Back to beginning SSNiFs Part 1: Introduction

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.

Here are some pragmatic tips to help you get going, based on several years of practice.

What to put in the Stakeholder column

• Usually the stakeholder is a customer or user of the product.
• If you have personas defined, by all means use them in the Stakeholder column.
• Not all stakeholders are users or customers.  Others may include: the company creating the product, its partners, and advertisers.
• When you discover a stakeholder a unique situation, don’t feel like you have to pigeonhole them into a preconceived segmentation of users.  Add them to the stakeholder column, no matter how small and specialized the group.

What to put in the Situations column

Most of the time the situation really is, as the word suggests, a predicament of some sort that the user is in.  For example, in the domain of PDAs, the stakeholder is on the phone with someone asking about her availability tomorrow for a meeting .  That’s the situation.  She needs to be able to look up her schedule and without hesitation and without distracting from the phone call.  (As I pointed out, this is a SSNiF that the Palm has always satisfied well, but one which the iPhone fails.)

Occasionally things aren’t quite so neat.  The purpose of the Situation column is to explain why the stakeholder has the need.  Do whatever it takes to make it fulfill this mission, even if you have to interpret the word “situation” liberally.

For example, sometimes the situation is a characteristic of the stakeholder.  A physically large PDA user may have big stubby fingers, making it hard to target small buttons.  That’s the situation.  The resulting need is for a UI that works with large hands. The SSNiF might be resolved with various potential features: larger physical buttons, larger on-screen buttons or even a voice-driven UI that minimizes button presses to begin with.

Sometimes the situation could also be an observation about the state of the world.  In the PDA world, the situation could be the reality that reasonable-sized batteries don’t last long with 3G technology.  The need for someone on the go is for extended battery life.

Just remember the rule that the SSNiF ought to capture the reason why the stakeholder has the need, and that the situation column is the place to put it.

What to put in the Needs column

The need is a very important column, because it is where you get to clearly articulate the problem, separate from the solution.  Sometimes this is the first time that anyone has attempted to do so, and it can take some thought to get right.  But doing so makes you smarter and better looking.

Deconstructing familiar, assumed features into needs sets you up for coups of innovation.  With both need and feature in front of your face, you can ask yourself, “is this solution really the best way we can think of to address this need?”  You’ll often discover a better way.  This is one of the thought patterns to get used to if you are trying to fundamentally rethink how a problem has been solved for years, as Apple has so often done.

In Jeopardy you have to phrase the answer in the form of a question.  With SSNiFs, you should get into the habit of phrasing the need as completions of the phrase: “The stakeholder has a need for…” or “a need to…”

Thus in the example above, I didn’t say that people on the go “bigger batteries,” I said their need is for” extended battery life.”  Whether this is solved by bigger batteries, or better battery chemistry, or replaceable battery packs, or a hand-crank charger is not for the needs column.  These are all potential features that may resolve the need.

Procedural tips

When you get started on analyzing a problem or modeling your assumptions about customers, do the SSNiFs in two passes.  First, brainstorm the SSNiFs as quickly as you can, filling in just one or two cells per SSNiF:

• Drop new customer groups into the Stakeholder column.
• Drop use cases, edge cases or error cases into the Situation column
• If you identify a problem that someone has, put it in the Need column.
• Drop feature ideas that pop into your head into the (potential) Feature column

When you get stuck on a SSNiF, don’t dwell.  Leave a note and move on.

When you have captured most of the SSNiFs you can think of, do another pass to connect the dots:

• For the customer groups you identified, ask yourself what distinct situations they find themselves in.
• For the situations you identified, try and articulate what precise needs fall out of them.
• For the needs you identified, try taking a stab at what types of features might resolve the need. Doing so gets the juices flowing on coming up with a solution, and deflates the tension of having known, unresolved problems linger for a long time.
• If you started the SSNiF with the feature idea, you have a puzzle to solve, of figuring out exactly what need it satisfies, for whom, and in what situation.  Sometimes I need to sleep on it to get this clarity.   In the meantime, I’ll put a tentative answer in each column, with a “(?)” to remind myself and anyone who reads it that this is a tentative answer.

Capture a superset of what you intend to do.  It doesn’t hurt, and it gives context to what you are more likely to do.  You can annotate scenarios that are explicitly off the table with the reasons they are rejected.

If you are in a research phase, don’t knock yourself out trying to come up with a potential feature to resolve each need.  Your focus at this point is on modeling reality, not designing a solution.  Only drop in potential feature ideas if a customer mentions it or a competitor has it or a solution pops into your head.

I’ve conducted customer interviews and observation sessions taking notes directly into the cells of a SSNiF matrix.  After the session I will go back and fill in the adjacent cells.

Refine your SSNiFs whenever you return to them.   When you return to your SSNiFs your mind will think of cases you missed or clearer ways to articulate the problem.  Get into the spirit of continually refining your SSNiFs.  When it’s time for you or someone else to pick up the ball, there is an evolved starting point.

Be brutally honest. Maybe there is a time for deliberately looking at the world with rose-colored glasses.  But the time you are trying to understand and model reality is not one of them.  SSNiFs are an analysis technique and if they aren’t challenging assumptions, something is probably going wrong.  If you notice that SSNiFs are being contrived to shoehorn a preconceived solution, break the glass and sound the alarm.

Ancillary columns in the SSNiF table

Depending on how the SSNiFs will be used, I add additional columns to the matrix, above the core S, S, N and F:

• Big vs. little SSNiFs – whether the SSNiF capture the reason the product or feature exists, or a specific detail?  (See Part 1)
• Notes – Capture anything relevant that you didn’t get to express within the SSNiF itself
• Area of the product -  You can put keyword in this column corresponding to feature areas like, “Security/Privacy” or “Home page” or “Preferences”.  Later you can sort this column to group related SSNiFs.
• Serial number of the SSNiF, so they can be referenced in other documentation.  (I like to number them S1, S2, etc.)
• Reviewer Feedback – I have had SSNiF matrices with 3-4 feedback columns, one for each reviewers.  This lets everyone see where everyone else is coming from and build on what other say.  Once the feedback is processed the columns can be eliminated.
• Priority – SSNiFs make wonderful feature requirements (as described in part 2).  You can columns to support the feature rating scheme you use.  (I’ll cover SSNiF priorities in a different article.)  During the Vision phase you will sift through the SSNiFs and pick out which ones to pursue.
• To be researched – It’s a great idea to do a SSNiF analysis even before you go out in the field.  When holes or controversies are discovered, they can be dropped into the “to be researched” column.

Tactical tips

• Sometimes there are clusters of SSNiFs all describing the same customer or resolving the same need with different features.  It can be convenient to put multiple related situations, needs or features in a single cell, rather than having a separate row for each.
• Boldface the operative words in each SSNiF, to make it easy for someone to skim the matrix or search for a SSNiF.  The operative words might point out a non-obvious stakeholder, a unique situation, a need that had been under-appreciated, or a nifty feature. (You can do this in Excel and word processors, but not yet with Google Spreadsheets.)
• In Excel, you can use conditional formatting in Excel, to automatically highlight Big SSNiFs, making them jump out of the pack of little SSNiFs (thanks to product designer Josh Hall for this tip).
• Use Excel’s AutoFilter feature (Choose: Data -> Filter -> Autofilter) that lets you reduce distractions of a long SSNiF list and zero in on one feature area at a time.
• Sometimes a cluster of distinct SSNiFs will share the same stakeholder or situation or need.  If you have a small, polished set of SSNiFs to publish, it’s polite to merge clusters of identical cells.  It makes the table easier to read as you can see in these examples.  However when you are in heavy analysis mode with your sleeves rolled up don’t bother merging.  Spreadsheets become brittle and inflexible with lots of merged cells and you end up spending too much time futzing with formatting.

Please give SSNiFs a try, feel free to bend it to suit your needs, and let me know if you have any questions or observations about the process.

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.

In the Introductory article I described Big and little SSNiFs, showed a couple of examples, and laid out the benefits of capturing scenarios in terms of Stakeholders, Situations, Needs and (potential) Features. Here I’ll  talk about how they fit into the product creation process.

SSNiFs have a role to play in the four major stages of designing things:  1. understanding your customers  2. formulating a vision, 3. generating requirements and 4. solving the design itself.  Not coincidentally, these correspond to the four layers of the Design Pyramid.  Let’s dive into each layer.

SSNiFs at the Understanding layer

To properly solve problems for people, we must first understand them.  We gain this understanding by conducting customer interviews, observing them in their natural habitats, and trying their jobs out for ourselves.

The findings of this research are typically communicated as reports or presentations.  Here, problems arise.  The presentations are usually fascinating but there can be a gap between each learning and what we are supposed to do with it.  If the client cannot see a path for turning insight into action the research will languish.

To make research findings more digestible, it helps to cook them a bit.  The most useful findings are scenarios that no-one anticipated, resulting in needs that are unmet.  Expressing each scenario as a SSNiF packages it into a self-contained, bite-size story.  Each one represents a discrete customer problem that we can consider addressing in the product.

The SSNiF format invites the researcher to take a stab at capturing the potential Feature that resolves the Need.  While it is not expected to be the final word on the subject, it has the effect of letting everyone see how the raw insights connect to enhancements to the product, and getting the juices flowing.

Now’s a good time for me to make a subtle point the Design Pyramid.  See that little cylinder sticking out the top?  No, it’s not a cake topper.  It’s actually a peg of the Understanding level that threads through the layers, like the baby’s plastic ring toy you might have seen.  The message of this metaphor is that understanding touches each level of the Pyramid, and holds the whole thing together.

Likewise, the SSNiF scenarios that we discover at the Understanding level bubble up through the Vision, Requirements and Design stages.

SSNiFs at the Vision layer

During the discovery phase, we will generate many more SSNiFs than we can possibly address.  Our mission at the Vision level is to sift through and select a cohesive, achievable set of Big SSNiFs to take on.  This is the problems to solve and it’s the heart of the product vision.

The vision can be communicated directly using a SSNiF table, or paraphrased as prose or bullet points.  Expressing the vision as SSNiF scenarios conceptualizes the product on the basis of customer needs.  This is the customer-centric way of doing it.  It steers everyone away from thinking about the product in the perilous terms of a technology, a set of features, or a the competition.

There are always some reasonable-sounding SSNiFs that a team will choose not to pursue.  It is helpful to explicitly list these out, along with the reasons for rejecting it.  This acknowledges the merit of rejected ideas, while helping to maintain focus by making it explicitly out of bounds.

Before proceeding to requirements and design it’s important to achieve team buy-in on the chosen SSNiFs.   The rest of the work is guided by this vision.

SSNiF at the Requirements layer

In bowling, it’s impossible to score a strike without all the pins standing.

I think of design the same way.  For our noggin to synthesize elegant, complete solutions, we have to stuff all the pins into it.

The design requirements are the pins.  Requirements aren’t anything mysterious; they are simply an expression of what the design must accomplish.  They afford us the chance to think through what we have to do before we do it.

SSNiFs are my favorite form of requirements.  They connect the need to the underlying scenario, which maintains the context.  They give the person doing the requirements (the product manager, or a slightly younger version of ourselves) a place to capture their first instinct of what the solution might be, but without being committed to it.

If we’ve done our homework at the Understanding and Vision levels, Requirements will be a piece of cake.  We can simply flesh out the Big SSNiFs already developed.  Before starting a new design, I will rapidly brainstorm dozens of little SSNiFs into Excel, filling in just one or two cells per SSNiF at first.  Use cases, edge cases and error cases are captured in the Situation column.  Newly identified user types go into the Stakeholder column.  Design ideas go into the (potential) Feature column.  I’ll then do a separate pass to flesh out the more important and less obvious SSNiFs and to determine what SSNiFs are worth covering.

Then, I’m ready to bowl. 

SSNiFs at the Design layer

At this point, we can stop looking at the SSNiFs.  They’ve been internalized, and design ideas should be bouncing around our head like popcorn.  I don’t consider myself qualified to do a design until I’ve reached this point.  It’s too easy to get excited and put pencil to paper before we’ve done our due diligence.  We end up doing a bang-up job solving the wrong problem.

Once we have a candidate design or three, it’s time to return to the SSNiF-based requirements to see if we’ve covered everything.  We walk through each SSNiF scenario and ask ourselves, “for this user, in this situation in this need, will our solution truly satisfy the need?”  This lets us catch and fix design issues on paper at the earliest, cheapest and fastest point in the process.

You can show a prototype of your design to users for feedback at any time.  If your SSNiF model is strong most of the feedback you receive will be at the Design level.  They will give rise to refinements to the details of the solution, and not fundamental challenges to which problems we should be solving.

Your understanding of the problem will be further ripened through the design phase.  It’s worth returning to the SSNiFs and touching them up, because they continue to justify your design choices and educate others on the team, and they form the basis of the next iteration of the product.

Now, enough with the meta-talk about SSNiFs.  Next, I will give some tips from the trenches for composing SSNiFs.

<< Back to SSNiFs Part 1: Introduction |  Continue to Part 3: Tips for SSNiFs >>

Email or link to this article at: http://stealthisidea.com/articles/how-ssnifs-fit-in

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.

One of the best skills a designer can have is empathy with the user.  And one of the best ways to achieve empathy is by looking at things from the user’s perspective using scenarios.

Scenarios have been around a while in different forms and flavors, but I haven’t found the standard formulations entirely satisfactory.  They are either too verbose, or too unstructured, or not scalable, or they don’t articulate the underlying need or explain why the need exists to begin with.

Over time I converged on a different, simpler way of composing scenarios which I thought worth sharing. I have been using this technique since 2002.

Elements of a SSNiF Scenario

The technique is based on the observation that there is a common storyline and set of elements to all good scenarios.  There is a stakeholder, typically a user or customer or persona, in some situation.  The situation results in a need. The need is resolved by a feature, or by the product as a whole.

The first three elements, Stakeholder, Situation, and Need, express the problem.  The Feature is the solution.  Adding a gratuitous “i” to suggest a pronounciation spells SSNiF.

I like the metaphor: on a new project we need to SSNiF out the domain to make sense of it, as a dog sniffs out strange new territory.  To test whether a proposed idea is a good one, we SSNiF it out.

Big SSNiFs

SSNiFs come in two sizes, big and little.  Big SSNiFs describe the overall purpose of a product or feature.  Little SSNiFs delve into detailed use cases.  They describe why individual features exist, or aspects of the design.

Let’s look at some big SSNiFs related to the iPod.  One key group of stakeholders are those who must take public transportation on a regular basis.  The journey is long, repetitive, and boring — that is the situation.  The need that results is for something to make the idle time more enjoyable.  The iPod is the solution that addresses the need.

We can lay this scenario out in a SSNiF table.  I’ve added a few other Big SSNiFs representing other key usage scenarios of the iPod:

Some Big SSNiFs for a portable audio device

These Big SSNiFs clarify why the product is needed. In fact, the essence of a product concept can be conveyed in terms of few Big SSNiFs.  With a tight set of Big SSNiFs in hand you should have no trouble conveying to someone what problem the product will solve for customers.

Little SSNiFs

Whereas Big SSNiF are for clarifying the big picture, little SSNiFs are for working out the details. Here are some little SSNiFs of mass transit commuters:

Notice how each feature is connected back to its underlying use cases.  We could enumerate all of the features this way, tracing them to their purpose.

How SSNiFs fit into the product creation process

SSNiFs are involved at each level of the Design Pyramid.

• At the Understanding level, customers research is made more actionable by synthesizing it down to a set of big and little SSNiFs.
  
• At the Vision level, we can sift through the all the big SSNiFs we discovered, and sculpt a product vision out of the right set of Big SSNiFs.
• At the Requirements level, we can play out the Big SSNiFs into lots of little SSNiFs.  SSNiFs make wonderful requirements, as I’ll get to in a minute.
• At the Design level, we create a solution with the scenarios in mind.  We test our design by walking through the selected big and little SSNiFs from each stakeholder’s perspective, asking ourselves, “does the solution we came through truly address the SSNiF?”

If you chose important SSNiFs, and if your solution addresses them, you will have a pretty good product.

So what’s the big deal?

SSNiF scenarios have a number of benefits:

SSNiFs are relentlessly user-centric. SSNiFs force us to figure out not just what users need but why.  This emphasis on understanding why is unique to this method.  Knowing why is the test of true mastery over the user’s world.  It is what lets us interpolate and extrapolate from what customers are able to articulate to us directly.  It is a critical aptitude for visionary thinking.

The purpose behind each feature is clear at all times. Every feature is connected to the scenario it addresses.  You will appreciate this if you have encountered features in your product whose existence no-one can explain.

Real-life SSNiF table in Excel

SSNiFs distinguish stakeholders – There is a common trap of thinking of “the user” as part of a single, homogeneous bunch.  You cannot fall into this trap if you do SSNiFs, because identifying differing stakeholders is inherent in the process. SSNiFs help us stay connected to to the different worlds of different audiences.

SSNiFs are scalable enough allow you to model as many narrow user groups as you come across in the real world.  You can capture and model what you see without oversimplifying it.  This is useful because observations about obscure groups and their predicaments is grist for the idea mill.

SSNiFs give us a place to capture the hot feature ideas, but without committing to them.  No designer enjoys it when our colleagues wildly jump ahead to the feature they envisioned while taking a shower.  We’d rather have a calm conversation about what the requirements are, then work out the best possible solution from there.  Designers are always trying to get product managers to think in terms of requirements, not concrete features.

In practice though, our human brains can’t help but think in terms of the concrete.  SSNiFs offer a compromise: it gives us a slot to place our (possibly lame) initial solution as long as (a) we agree to call it the potential feature, and (b) we back-fill the other columns of the SSNiF.  The spontaneous feature idea then turns into a vehicle for getting at the scenario.  The initial solution is traced back to the problem (where the important part of the idea lies anyway), and from there we can move forward and see if we can find a better solution to the SSNiF.

Which leads to the next benefit:

SSNiFs leave the door open to a better solution – By labeling a feature as potential, we are making it clear that this is a tentative idea on how we might solve the need.  The door is open to other potential approaches.  If someone comes up with a better way to solve it, we’re happy to toss the earlier concept.  Because this is built into the process, this helps prevent us from getting too wedded to our ideas.

SSNiFs make user research more actionable – Have you ever attended a fascinating, informative research presentation that was completely forgotten by the following morning?  The problem is that the findings just are not boiled down to an actionable format.

I have found that almost all of the actionable findings from ethnographic research boil down to either SSNiFs or “key observations and their potential implications to the product” (the subject of a future article).  SSNiFs go a long way towards making user research actionable.

Anyone doing basic user research should try distilling their findings down into a prioritized table of SSNiFs.

SSNiFs provide a reality check – To fill in a SSNiF that backs a proposed feature you must ask some key questions: “What need does it solve?  For whom?  Under what circumstances?”

Merely asking these questions puts the new idea in perspective.  We’ll find that there just aren’t that many users of that type, or that the situation just doesn’t come up that often, or that when it does, the need is not terribly strong.  At this point we should take a courageous gulp and just cut the feature.  Worthwhile features will have solid answers to these questions.

Next time someone proposes a feature, try asking the three key SSNiF questions to see what is behind it.

SSNiFs are thorough – some approaches to scenarios buckle under the weight of complex-real world design problems.  They become onerous to author, review and maintain.  SSNiFs scale easily from a handful to scores or even hundreds of SSNiFs for large-scale initiatives.

Process benefits

As a process for capturing scenarios, they have more benefits:

SSNiFs are easy to understand – a SSNiF table makes sense to anyone on first reading.  Others can jump in and start contributing right away by following examples.

SSNiFs are concise – SSNiFs distill the minimum and sufficient elements of a scenario into a tabular form.  This makes it possible to categorize, prioritize, sort and filter any numbers of SSNiFs.

My preferred medium for capturing SSNiFs is the spreadsheet.  I use Excel when capturing lots of little SSNiFs just before doing a design.  I’ll even capture SSNiFs live, while conducting customer interviews, dropping new insights into any of the four columns and back-filling the other columns later.

SSNiFs work in a group process – Initial SSNiFs can be captured using a spreadsheet projected onto a screen or with a wall of sticky notes.  I also have had success with Google Spreadsheets, because it allows anyone on the team to annotate or refine the SSNiFs at any time.  (See also: Free templates for SSNiFs)

SSNiFs get everyone’s assumptions on the table – It is fascinating what comes out of a group SSNiF process. Different team members will have different insights, ideas and scenarios weightings.  SSNiFs provide a medium to capture the “best of” multiple peoples’ perspectives.  When a fundamental difference in belief about a user scenario arises, we can add it to a “to be researched” list and get to the bottom of the discrepancy later.

More examples of SSNiF Scenarios

Here are some prior articles that involve SSNiFs:

• Open, yet encrypted Wi-Fi
• Hosted vs. Local applications
• Marriage Sav-R Toothpaste Tube
• Who Read your Email this Morning?

Summary

SSNiFs are a concise way to model scenarios that emphasizes the connection between features of a product and the underlying customer scenario and need.

Please give SSNiFs a try and feel free to write me with questions or comments at: phaine at obvious design dot com.

Continue to Part 2: How SSNiFs fit into the product creation process >>

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.

[6/24/09 Did editing pass based on feedback]

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]

the thing that continues to amaze me is that smart people at successful companies still form weak visions based on features, assumptions and the competition, not on customer needs. [..] Executives ask the question “How are we going to beat [most successful competitor]?” Features are added just to put a check mark on the box. And when you ask why, nobody can say the true reason any of these things are a good idea. [..] all the effort spent ultimately amounts to nothing.

Amen to that, brother!

Marty points out a troublesome pattern at some companies where there is no single product owner. A “business person” defines the high-level product definition and the product manager writes the requirements.

The problem is that neither person truly owns the product, and more importantly, neither person feels and behaves like they are the one ultimately responsible for the product.

This is true. If the business person is an executive, they may not have the deep, detailed understanding of customers that is essential for defining a product vision.

I do have a quibble to pick with a side point in Marty’s essay. He goes on to say:

Further, this model is based on a flawed view of software that believes that you can define high-level product requirements independent of detailed requirements and especially the user experience.

I respectfully disagree. Not only is it possible to separate the vision (high-level requirements) from the detailed requirements and design, it’s a very good idea.

Most companies obsess about the details too early and too often. They have trouble breaking away and questioning the purpose of the product and its features, and they lose sight of the big picture. When you see products that are perennially mired in incrementalism and features wars, this is what is going on.

The remedy is to treat product vision as a distinct problem to solve. It requires putting aside the product’s details, having faith that they can be worked out later. The first job is to figure out the important needs to solve. Hold those needs sacred. Ignore constraints and precedent, requirements and design. Trust that a great solution will be found. Then, during requirements and design, find it.

Apple seems to demonstrate this mentality over and over. With the iPhone, they figured out that a voice prompts-driven UI for voicemail was terribly inefficient, and that users needed a more streamlined approach. They set about building a UI they call “visual voicemail.” This required changes well outside Apple’s purview, at the mobile phone carrier’s back-end system. By focusing on the “what” and (temporarily) ignoring the “how” they were able to achieve a breakthrough solution.

Inventor Charles Kettering (1876-1958) said, “A problem well-stated is a problem half solved.” Product vision is about stating the problem. Detailed requirements and design come later.

by David S. Cortright

There has been a lot of talk about “design thinking” in the press over the last few years. Design thinking is literally thinking like a designer. Designers keenly observe the world around them, identify users who have unmet needs, and design solutions that fulfill the needs for those users.

I saw the movie March of the Penguins about a year ago. It’s a great documentary that follows the yearly cycle of reproduction for emperor penguins in Antarctica. The penguins make a long trek inland, pair up, and mate. After the female lays her egg, the male guard the egg and keeps it warm for four months with no food or water, in near total darkness, at bitter cold temperatures, huddling together with other males to keep warm, all the while balancing his egg on their feet and keeping it warm and protected under his belly. Meanwhile the female reverses the trek back to the ocean to stock up on food for her family while doing her best not to get eaten by a leopard seal, and then walks back to her mate to relieve him of the now-hatched chick, both of whom are extremely hungry.

And the whole time, while I’m marveling at this amazing and beautiful process of nature, in the back of my mind I’m thinking, “these penguins have a lot of unmet needs.” They are hungry, cold, and tired; they need to keep their egg safe, gather food for their chick, and meet up with their mate again after an extended separation. So many unmet needs, out of which fall so many possible solutions.

There could be penguin shelters for getting out of the cold and wind; penguin egg incubators, where you could check in your egg and have the service keep it warm and safe; penguin snack stands for taking the edge off those 4-month-long hunger pangs; a penguin communication service to keep in touch with your mate while separated (which of course would alert the male if the female gets eaten, and alert the female if the male loses the egg). This is a vast, untapped market.

Now if only penguins had money…

David S. Cortright is a veteran Bay Area interaction designer.  He was at Yahoo! when he wrote this and is now, as of summer 2008, the proprietor of Rated-Best.org, a list of highest rated products.

A recent NYTimes article, “With Popcorn, DVD’s and TiVo, Moviegoers Are Staying Home” describes the decline in moviegoing:

“With box-office attendance sliding, so far, for the third consecutive year, many in the industry are starting to ask whether the slump is just part of a cyclical swing driven mostly by a crop of weak movies or whether it reflects a much bigger change in the way Americans look to be entertained – a change that will pose serious new challenges to Hollywood.”

The lack of certainty about the underlying cause is not helpful. When a business is in peril it must identify the right cause: the correct explanation leads to action that can save the business; the wrong explanation can lead to actions which hasten failure.

This problem is of interest to us because it’s an instance of a common strategic predicament: an established class of products is being threatened by the emergence of a new class of products. Is the newcomer merely a passing fad? Or is it a disruptive innovation that will render the incumbent obsolete?

We will look at these questions using our preferred tool for the job, Formal Needs Analysis. We will first deconstruct moviegoing into the the primary customer needs it satisfies, then consider how well those needs are met by the competitors, in this case TiVo-style DVRs, Netflix, the web and videogames. This will isolate the points of overlap, clarifying when the alternates are as good or better than the incumbent.

What needs are met by moviegoing?

To model moviegoing and its competitors, we’ve established a needs space of seven primary needs and four supporting needs. Primary needs are the key reasons people purchase a product. For movies, we have:

1. The need to escape – to temporarily get away from the incessant stresses and pressures of life.
2. The need to feel good – to be put in a happy mood, say after a difficult week.
3. The need for stimulation – to be raised into a heightened emotional & physiological state.
4. The need to learn things – to be left with the new knowledge or insight into the human experience
5. The need for social interaction – to feel connected with others.
6. The need for social status – to feel worthy within the social group. With respect to pop culture including movies, it feels good to be in-the-know and it feels bad to be left out of the conversation everyone else is having.
7. The need for fun – to have a good time in the moment.

In addition, there are these supporting needs. Supporting needs help the product fulfill its primary needs better. They are like salt to french fries: salt makes the food taste better, but you don’t buy you buy the fries soley for the salt. For moviegoing, we have the following supporting needs:

1. The need for affordability – other things being equal, the more affordable a product, the more desirable.
2. The need convenience - another cost the customer incurs is non-monetary — the logistical hassle in using it.
3. The need relevance - Relevance of a piece of content is how well it relates to you. When it comes to matters of taste or interest, different folks require different strokes. Thus for content, relevance is largely a function of the breadth of selection available.
4. The need for long experience – the persistence of the experience.

Let’s walk through each of these to see how movies and the newcomers compare. We’ve assigned rough scores from zero to three to each competitor in the table below for reference.

Primary needs

Summary of needs fulfilled by moviegoing and its comparison points, rated from 0 to 3

1. The need for escape

Movies do a good job of providing escape. A darkened movie theatre away from home, interesting characters and an intriguing plot can immerse the viewer in an alternate reality.

Netflix shows the same movies, but at home. This experience is not as immersive as in a theatre, but the gap is narrowed for those fortunate enough to possess a decent home theatre. TiVo or web surfing can provide escape for hours, but today’s best videogames provide immersion to such an extent that time flies.

2-4. The need to feel good, for stimulation, to learn things

The movie industry is adept at crafting films that play directly against different emotional needs. The need to feel good is literally matched by the Hollywood “feel-good” movies. The need for stimulation, both emotional and physiological, is provided by thrillers, sci-fi, action and suspense movies. The need to learn things is met by watching characters in dramas and by documentaries.

As for the comparison points, Netflix has the same content and thus the same potential, minus some points for the less immersive experience. TiVo loses points for commercial interruptions (skippable though they may be) and for lower audio/visual quality relative to DVDs. (We could have added a/v quality as a secondary need.) Videogames can be extremely stimulating. Web surfing may not exactly be emotionally stirring, but it has great potential to help anyone learn anything about anything at any time.

5. The need for social interaction

While watching a movie is itself passive and solitary, going out to the movies is social in multiple ways. Going through an experience with friends makes it more enjoyable and gives common references for future conversation. A crowded movie theatre also provides a lighter version of the mob experience common at sporting events or huge rock concerts. Finally, if we take moviegoing to include activities before and after such as travel, dinner and drinks, there is ample opportunity for personal bonding.

Watching the same movie at home with Netflix or TiVo is rarely as social. Videogames played alone are decidedly not social. But endless hours spent playing videogames with friends is a strong bonding experience.

6. The need for social status

Coolness points are gained or lost based on how up-to-date one is with the latest trends. The movie industry plays this up well, fostering the notion of the must-see movie. You just have to watch it (otherwise what good are you?).

But while watching every top movie may necessary for hipness, but it is not sufficient. No medium has a monopoly on conferring social status. One must also be up to date on the latest TV shows, sports standings, celebrity gossip, fashion, videogames, news, technology and blogs.

We can say that the Netflix movie, arriving in the mailbox months after the playground or water cooler chatter has moved on to something new, is not so hip anymore.

7. The need for fun

The prior needs don’t completely capture the overall feeling of fun and excitement of going out to the movies, so we included it as another dimension of need. It overlaps some of the others, but that’s okay; we are free to choose the dimensions that give us useful insight.

Staying home and watching TV or TiVo or Netflix isn’t quite as fun. But high quality videogames can still be an addictive blast.

Supporting needs

8. The need affordability

Moviegoing is expensive. Aside from the ticket cost there are ancillary costs of parking and dinner. TV, Netflix and videogames are far more affordable per hour of use, and thus they get betters scores on the need for affordability.

9. The need for convenience

Going out to see a movie incurs non-monetary costs of time and logistics. One must get to and from the theatre, park and wait in lines. Staying home is far more convenient.

10. The need for relevance/choice

The Matrix and A Room With a View are highly compelling for their respective audiences, and highly irrelevant to one another’s. When it comes to content, relevance is gained through breadth of choice. The movies offer just a couple of dozen choices at any one time.

Regular TV has dozens of channels, yet there is often nothing to watch. TiVo, on the other hand, filters through thousands of channel-hours a week, leaving the viewer with a concentrated set of extremely relevant programming. Netflix offers an impressive selection of 50,000 movies, old TV programs and special-interest content findable nowhere else.

As for videogames, there is not as yet something for everyone. Many have no interest in videogames at all.

11. The need for a long experience

The moviegoing experience, fun and immersive as it may be, is fleeting. On the other hand, people can spend hours a day with TV, TiVo, videogames and web surfing.

Conclusions & Predictions

Now that we’ve broken moviegoing and its challengers into its component needs, what can we make of all this? Is the bad fortune of moviegoing due to a passing spate of poor product? Or is it indicative of deeper, long-term trends to other media? By walking through the chart above we can lay out some specific conclusions and predictions:

• Moviegoing is still a unique product. Its needs profile — its row in the chart above — is distinct from the others. None of the alternatives are a superset. This suggests that moviegoing will not be obviated by new media (the way that word processors obviated typewriters), but will live alongside them.
• Moviegoing has specific advantages. It is a better escape than home media, more engaging and more social. A night of moviegoing is simply more fun than staying home and watching the same thing at home. First release movies are also trendy and confer social status on those who watch the blockbusters early.
• Moviegoing has weaknesses relative to its competitors. It is costly, both monetarily and in convenience. The home media is far more convenient. Moviegoing is also a fleeting, and leaves discretionary time for other products to fill. The comparison points, TiVo, videogames and the web can occupy the user for hours without extra cost.
• The competitors pose real and specific threats. Videogames are an excellent escape. Netflix and TiVo let the user select from thousands of choices, thereby greatly increasing the relevance and appeal. Videogames played with friends fulfill needs for social interaction.
• All of these dynamics are about the medium of moviegoing itself, not the content within that medium. The threat is systemic, not a result of a spate of poor movies.
• Video-over-the-net has the potential to meet a superset of the needs met by Netflix. Current offerings are of lower a/v quality and limited selection, but this can change. Once it does, the DVD-by-mail model will become niche.
• While moviegoing will persist, it won’t be without pain to the industry. The competition for discretionary time is hot, leaving less of the pie for the movies than they are used to. Movie attendance can be expected to decline, even if quality recovers.

How can the movie industry respond to these threats? I will save that for another article.

.

For more on needs analysis, please see:

• Needs analysis technique at ProductVision.org
• Needs Analysis of Vehicles