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 not concise enough or not structured enough or they don’t scale or they don’t articulate the need clearly or explain why the need exists to begin with.
Over time I evolved a different way of composing scenarios which has proven to be so simple and powerful that I thought it worth sharing. I have been using this technique since 2002.
Elements of a SSNiF Scenario
The technique is based on the observation that scenarios all have the same core elements and storyline. There is a stakeholder, often a user or customer, in some situation. The situation results in a need. The need is resolved by a feature or the product as a whole. The first three elements, Stakeholder, Situation, and Need, are the problem. The Feature is the solution. Adding a gratuitous “i” 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.
Big SSNiFs
SSNiFs come in two sizes, Big and little. Big SSNiFs describe the overall purpose of a product or feature, whereas little SSNiFs delve into the detailed use cases.
As an example, 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 other Big SSNiFs representing key usage scenarios of the iPod, fitness buffs and teenagers:
| 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. Proper 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, a product’s vision can be conveyed in terms of few Big SSNiFs it satisfies. With a tight set of Big SSNiFs in hand you should have no trouble pitching your idea to the next VC you meet in an elevator. (Do VCs ever have offices?)
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.
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, research and analysis about customers and their needs can be synthesized in terms of 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, create a solution with the scenarios in mind. We test our design by walking through the SSNiF scenarios.
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 why is somewhat unique to this method and to me is the test of true understanding of the user’s world.
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 seen features whose existence no-one can explain.
SSNiFs distinguish different stakeholders - There is a common trap of thinking of “the user” as part of a single, uniform bunch. You cannot create SSNiFs and fall victim to this fallacy. SSNiFs allow for as many narrow user groups as you can identify in the real world. This perspective helps us see the trade-offs made for different audiences.
SSNiFs give us a place to capture the hot feature ideas that are burning a hole in our brain. In theory we don’t want our team mates wildly jumping to knee-jerk solutions. We’d rather have a calm conversation about what the requirements are, then work out the best possible solution. In practice though, everyone is human, and we humans think in terms of the concrete. SSNiFs offer a compromise: it gives us humans a slot to place our lame initial solution as long as we (a) agree to call it the potential feature, and (b) we do the diligence of back-filling the other columns of the SSNiF. In effect, the feature idea is a vehicle for getting at the scenario. This 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 first concept.
SSNiFs make user research more actionable - I have attended fascinating, informative research presentations that were nevertheless forgotten soon after by the design team. I believe the problem is that the findings just are not boiled down to an actionable format.
I would venture that three quarters of user research findings can be synthesized down to SSNiFs, which are very actionable. I would encourage anyone doing user research to try distilling their findings down into a prioritized table of SSNiFs.
SSNiFs provide a reality check - To fill in a SSNiF behind a proposed feature you need to ask the questions: “What need does it solve? For whom? Under what circumstances?” Just asking these questions puts the new idea in perspective. Often 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 cut the idea. The worthwhile features will have solid answers to these questions.
Next time someone proposes a feature, try asking the three SSNiF questions to see what is behind it.
SSNiFs are thorough - some methods buckle under the weight of complex-real world design problems, becoming hard to author, review and maintain. SSNiFs scale up well.
Process benefits
The benefits above are focused on how SSNiFs help set us up for better design solutions. SSNiFs lend themselves
SSNiFs are easy to understand - a SSNiF table makes sense to anyone on first reading. Others can jump in and start contributing right away.
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.
SSNiFs work in a group process - Initial SSNiFs can be captured using a projected spreadsheet or with a wall of sticky notes. For follow-up, I like using Google Spreadsheets, because it allows anyone on the team to annotate or refine the SSNiFs at any time.
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. These lead to very fruitful discussions, as the SSNiFs provide a medium to capture the “best of” multiple peoples’ perspectives. When fundamental differences arise, we can add items to the “to be researched” list so we can get to the bottom of the scenarios.
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 need. A richer understanding of customers, their needs and why the needs arise lets us create better products for them. SSNiFs are comprised of a Stakeholder in a Situation with a resulting Need that is resolved by one or more Features. Big SSNiFs capture the ultimate purpose of a product or feature. Little SSNiFs capture individual use cases. SSNiFs are concise yet thorough and work well in a group process.
Please give SSNiFs a try and feel free to write me with questions or comments at: phaine at steal this idea dot com.
Continue to Part 2: How SSNiFs fit into the product creation process >>
Email or link to this article at: http://stealthisidea.com/articles/ssnifs/
Philip Haine is a product vision specialist and founded Obvious Design, LLC in 1997 in San Francisco.
[...] 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 [...]