Hopefully I have persuaded you in Parts 1 and 2 that SSNiF analysis is a worthwhile technique for modeling scenarios and understanding customer needs.
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.
Hi Philip Haine,
This is the most useful article/process I have read in years. It has the solution to a constant deilima that I am faced with at the start of every new project ie. the deilima of finding where to start from? Would it be good to start working on persona of users, do task analysis, or perform a heuristics evaluation, and it gets worse when we are designing a product for the first time.
Thank you for sharing.
Mansoor.
Thank you, Manroor! That is great to hear that you are finding value in the SSNiF technique.
Philip