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.
