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:
| Stakeholder (user/customer) | Situation | Need | Feature/Solution |
|---|---|---|---|
| Daily mass transit commuter | Commutes daily for 60 minutes or more by bus or train.
Long, repetitive journey becomes boring. |
… something to make the idle time more stimulating, fun, enjoyable, or enriching. | • Portable audio player with headphones (eg. iPod, walkman) |
| Air traveler | On a long plane ride. There is a lot of idle time. | ||
| Fitness buff | Running or working out gets boring without something to occupy the mind, making it hard to stay motivated. | ||
| Teenager | Has a lot of free time on his hands.
Musical preferences are a part of their social identity. Effective brooding demands physical, sonic and symbolic isolation. |
…a way to listen to parent-repelling music at high volumes without getting yelled at. |
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:
| Stakeholder (user/customer) | Situation | Need | (potential) Feature |
|---|---|---|---|
| Daily mass transit commuter | Has to stand while holding a handrail, leaving only one hand free | Be able to operate the device with one hand | • Scroll wheel and buttons that can be operated with one hand |
| Sometimes has to hold a bag as well as a handrail, leaving no hand free | Be able to operate the device without holding it. | • Remote control on the headphone wire to control playback, so the device can be controlled without having to be held continually.
• Belt clip to make it easy to reach |
|
| When fumbling with a device with one hand in a crowded situation, it’s possible to inadvertently press a button, ruining a nice song | A way to prevent inadvertent button presses | • Lock switch | |
| Is seen in public with the device, which therefore becomes an accessory to their image | Make the user look cool, distinctive, special | • distinctive, trendy, exclusive, expensive-looking industrial design |
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
- The Design Pyramid
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]
[...] are connected to SSNiFs – the underlying scenarios. Every need is traceable back to a Stakeholder in some Situation, and [...]
[...] elements should be familiar to you if you’ve learned about SSNiF scenarios as a way of modeling customer’s [...]
[...] without undermining the value of the current release, by shifting the line between the SSNiFs addressed in version x and version [...]
[...] (2003) – As with any great product vision, there is a powerful SSNiF behind Skype: expats in any country need to get in touch with their loved ones elsewhere, and [...]
[...] Since this is a table of customer needs, we are intrinsically seeing the product in terms of its relevance to customers. Using needs for dimensions is not arbitrary, because needs can always be traced to specific real-world scenarios (see SSNiF Analysis). [...]
[...] ask yourself questions like, “What need does that flux capacitor serve? What are the SSNiFs behind it? How well is the needs addressed relative to the degree of need that customers [...]
[...] Introduction to SSNiF Analysis [...]
[...] empathy through out your organization for customers and [...]
[...] empathy through out your organization for customers and [...]