The directors wanted San Fransokyo to be a place audiences would want to visit. Artist, Lorelay Bove created various travel posters for San Fransokyo to showcase the different things you can do while visiting. Share your favorite.
It’s all about the detail.
Scale 3D diorama used by Disney designers to create Peter Pan’s Flight
Seen at Disney’s Hollywood Studios
Walt explaining the vision behind EPCOT—John Slattery’s take on this in Iron Man 2 is reason enough to watch the movie.
Seen at Disney’s Hollywood Studios
Your product will need time to evolve.
(This is just the first 15 years of Salesforce.com.)
What do you get when you talk to customers?
I just finished a large round of customer interviews and was reminded of something in Tony Ulwick’s great book, What Customers Want.
When you talk to customers, they don’t give you “requirements.” In fact, requirements don’t really exist; they’re not tangible in the real world. Instead, people make statements, and the statements they make can be separated into four buckets:
Solutions
Specs
Needs
Benefits
The sketches above give you an idea of what that sounds like. Usually, these statements aren’t directly actionable by the product team and need to be “unpacked” to some degree. You need to translate what you’re hearing into either:
Outcomes they’re trying to create
Goals they’re trying to achieve
Jobs they need to get done
Constraints they’re under (don’t forget these!)
There’s lots of information available on how to translate the statements into actionable insights: you can use Tony’s book, refer to The Jobs-to-be-Done Handbook, go with the Lean Startup approach, or use the traditional Cooper design methodology.
Talk to customers, but don’t take their statements at face value.
The Kano Model helps us understand what we can build easily that delights customers and what to avoid overinvesting in.
I knew the traditional Agile user story was lifeless and disconnected from the real world long before I could articulate why. Then I came across Alan Klement’s post on replacing user stories with Job Stories, which builds on top of the Jobs-to-be-Done framework.
Instead of the usual “As a / I want / so that” structure, a Job Story looks like this:
I’m in the middle of synthesizing a pile of customer research right now, and I’m kind of amazed how well the Job Story lets me encapsulate what I’ve learned in literally one sentence. Traditional design methodologies offer other ways to capture and share these insights, but boiling it down that much is very compelling.
Another benefit I’m seeing is knowing how much more research is needed. That is, if you can’t write the Job Story to explain a behavior, you’re not done interviewing.
I was listening to the TED Radio Hour today and ran across a great word: etiology.
It’s the study of causation, as in:
What causes someone to contract polio?
For those of us doing product work, it’s critical to know what causes someone to use a particular feature. What caused this user to run a certain report? What’s causing these other users to create a given workaround?
Your product will improve when you understand the etiology of each user behavior.
Today, I gave a talk at Prototype Camp Chicago on Prototyping Pitfalls, which amounted to one big story about what happened to our team when we swapped out wireframes and comps for prototypes. Prototypes bring benefits to designers, but introducing them into your process affects everyone else on the team.
We realized if you simply trade static comps for clickable prototypes and change nothing else about your process, you probably won’t get the benefits prototyping is supposed to bring. My hope is that sharing our solutions to these problems will help other design teams thinking of changing how they work.
If you’d like the slides, I posted them on SpeakerDeck.
The Double Diamond
This model, created by Peter Merholz of Adaptive Path and Groupon fame, best represents the product design process in a way that’s both complete and digestible. I wish I’d seen this when building out our process at Appiphony a few years ago.
Peter mentions creating it to clarify the full extent to which the design team is involved, and that definitely resonates with me. The piece I keep needing to explain is that design does not happen “up front” before “the work starts.” The detailed design of each component is part of the work, and it’s baked into each iteration cycle. The design-related work we do before that is figuring out how many of those components to build and doing the customer research we’ll need to fuel later phases.
Note: this model is only meant to highlight work done by the design team. It under-represents the effort needed by development, QA, marketing and others to actually ship.
Have you ever seen something like this listed in a requirements document?
Financial analysts need to manage the month-end close process
If you’re like me, you may wonder, “what does that mean, exactly? How might one manage a month-end close process?”
The problem is the word manage; it can mean nearly anything. Without being a finance expert, you can understand that you manage a month-end close differently than you manage a summer intern—but, for some reason, we use the same word.
When I encounter a similar requirement, I ask this:
What would someone put on their to-do list to finish this work?
In this case, it might be:
Tally the accounts receivable
Tally the accounts payable
Send a profitability report to the executive team
Now we’re getting somewhere! You can begin to imagine what a user might do to complete those tasks, and how you can help that user.
I had a great conversation with Shay Howe as part of presenting at next month’s Prototype Camp. Check it out.
I stumbled across this introductory Pascal book at a relative’s house and was intrigued by a brief section called The Phases of Development, which breaks the task of programming into four phases:
Clarify the problem requirements.
Design a program strategy.
Specify critical data structures.
Write the program statements.
I particularly love some of the quotes on problem clarification:
Surprisingly, clarification of the problem is a major phase of the process. It would seem reasonable that a clear and precise statement of the problem would be given but in fact this is rarely the case and more programming disasters can be blamed on failure in this regard than any other.
Today’s coding skills won’t be relevant in thirty years, but we’ll still need to clearly define the problem.
It’s not uncommon for a designer to join a project in which “the use cases are already written.” This documentation attempts to describe in words how a user will complete a particular task within the system.
Scenarios take this further and include the context around the action to form a complete story of a person in the real world using the product to create a positive outcome. In the example shown here (Square’s credit card reader), I’ve intentionally de-emphasized the steps around charging the card to highlight the surrounding context. Reviewing the full story helps the team identify additional functionality the product needs to serve this customer:
The charge needs to be authorized in less than 5 seconds. (Count it out and imagine being the buyer, waiting and drumming your fingers.)
The seller needs an easy way to cancel or refund the charge. (Someone will hit the wrong button in the chaos of the trade show floor.)
A simple way to keep/decrement inventory would be a value-add for the seller.
Imagine if this team stopped at simply “meeting the requirement” that the seller swipe the card and the buyer signs with their finger. That notion is abstract beyond the point of helping the team know if they can serve this customer. Instead ask how your product will help a specific person get through a specific situation.
Analyzing the final product: staring at the scoreboard
Let’s say you’re building a product, and you do some competitive analysis to see how others have addressed the same problem. Sounds reasonable, right?
Here’s the trouble: if you can only look at the final product, and can’t see any of the work that led up to it, you’re missing most of what’s interesting. What trade-offs did the team make based on what they learned along the way? What’s planned for the next release? How did they arrive at their design decisions?
It’s like staring at the scoreboard of a baseball game after it’s over. If you didn’t watch the game, you won’t get much out of it. You missed all the action.
Photos courtesy of Eric Kilby and Keith Allison
Your product can be the newest, coolest thing around, but it still needs to serve existing demand in the market. Even the iPad was introduced by listing the activities people already do that it improved upon:
Web browsing
Photo management
Watching video
Listening to music
Playing games
Reading eBooks
By itself, the list borders on mundane.
Ash Maurya, a leader in the Lean Startup community, made this great point on the latest episode of the Jobs-to-be-Done podcast. Check that out for more.
The Rumsfeld Theory of Analytics
Google’s digital marketing evangelist created this humorous take on analytics. I especially like the idea of acknowledging what you know you don’t know as questions to answer.
“If only we could get more customers, this thing would really take off.”
Why hasn’t that happened yet? Well, it’s partly because no matter how cool your product is, there are forces conspiring against you.
There are four forces at play when someone makes a decision to buy or use your product (shown above).
Many companies make an implicit assumption that if their new product has more/better features than a competing product, customers will transition to them. That’s simply not true; features aren’t nearly enough. You need:
Push: The consumer needs to have some problem or dissatisfaction with the solution they’re using now.
Pull: Your product needs to have a compelling feature set, ideally one that speaks to the problem they’re having.
To address Anxiety: Customers won’t implicitly trust you and your offering, and will worry about what bugs/issues they’ll run into.
To address Inertia: People have built up habits that will be hard to break. Installed base, existing integrations and behavior habits are all working against you.
Let’s step though an example to see how this works.
Microsoft realizes they’re behind in the smartphone race, and that many new users of Windows Phone will have to be former Android or iOS users. Android seems like the better target, with 22% of Android users surveyed in September 2012 saying they would switch to the iPhone 5 when it was released.
With this in mind, Microsoft released an Android app that scans what’s installed on your phone and recommends a substitute app for Windows Phone. In doing so, they’re addressing the forces of Inertia (“can I do what I’m used to with my phone?”) and Anxiety (“what will I be giving up?”).
So here’s one way the forces could play out:
Push: “This old Android phone as a very glitchy touchscreen.”
Pull: “Wow…this new Nokia is really elegant. It’s very smooth to go from screen to screen.”
To address Anxiety: “I wonder how good the reception is. I’ll keep an eye on that.”
To address Inertia: “Ah, perfect…I can still use Pandora to listen to music.”
If the Push and the Pull are greater than the combined Anxiety and Inertia, then the customer will switch from Android to Windows Phone. If not, they don’t switch. This example also illustrates how the forces play out differently for every individual.
Even though each person experiences the forces in their own way, most of the time you will only release one product. So how do you position your offering for maximum switching?
The good news is, you will almost always see patterns in customer behavior (“everyone hates the glitchy screen”), and you can have some confidence you’re investing in the right areas. Even better, the patterns can emerge with less than 10 customer interviews. But the only way to tease out those patterns is by talking to customers.
You can’t rely on traditional market research, since it focuses on people’s feelings towards the product/brand and does not dive into usage patterns. Interviewing or observing customers is the only way to reliably map out the Push, Inertia and Anxiety your product will face as it enters the market. Don’t you want to know what you’re up against?
In Econ 101 terms, this comes down to understanding everything around the demand for your product. Framing this in terms of supply and demand also helps you see why you shouldn’t iterate your way through this problem. It’s wasteful to simply build something and obtain feedback, since that’s focusing on what you can supply instead of the demand. To gauge the demand, you can focus that more precisely. Figure out what people are doing now.
A concise, easy way to communicate customer needs to design and engineering teams to build the right things.
Answer these questions for the team building your product:
Why are we working on this next?
In what scenario is this used?
What problems do we need to solve?
What future considerations must be accounted for?
How will we know this is a success?
I’ve been thinking about what it means to document and communicate a product at a medium level of grain—between 10,000 feet and the weeds. This helps in that regard.
Since anyone can understand a story, designers often use scenarios to explain how a user would complete a task or accomplish a goal in a given system. These short stories can be written in words, and are sometimes paired with quick sketches to make a storyboard.
I happened to be working through a lot of design scenarios recently, and these guidelines from Dan Saffer have proven extremely valuable:
Remove all adverbs
Remove all interior monologue
Remove any adjectives that don’t relate to system feedback
Here’s what happens when you don’t do that:
Susan stayed up late working on her personal newsletter. My subscribers are counting on my insights and links! she fretted.
— Dan Saffer (@odannyboy) April 29, 2014
These elements make the story sound cheesy, which effectively makes it seem less truthful. Your audience will smell the B.S. and your credibility as the storyteller will be undermined. The perceived quality of the design idea also goes down.
Few of us are great writers; I’ve found it surprisingly easy to fall into that familiar rhythm. But unless you want to be lumped in with the ShamWow—which has “sham” right in the name—don’t write a pitch that sounds like a late-night infomercial.
I remember one story that felt dry when I first removed the cheese, but the audience didn’t notice. And even the driest story about a user accomplishing a task will serve you better than something reminiscent of Saved by the Bell.
Once the cheese is gone, run through your story a few times with a colleague to smoke out the “plot holes.” You’ve been focusing on the design idea itself, not the presentation, and there will probably be one or two places where the audience feels like you jumped from Point A to Point C. The practice run is a simple idea, but it has a great bang for your buck.
After you’ve mastered the basics, Dan suggests the following:
Add problems and resolutions
Remove anything that sounds like ad copy
Vary user behavior
This is great advice, though instead of writing more/deeper scenarios, I usually put the time into storyboarding a rock-solid happy path scenario that I’m 100% sure my audience will understand. People can’t get on board with a plan they don’t understand, and you are presenting new ideas they may not “get” right away. Adding visuals is a great way to build understanding, and trading words for pictures makes it less likely you’ll write cheesy copy.
Thanks to Dan Saffer, Kevin Cheng and Dan Roam for improving my stories.