I’ve switched over to the Google Assistant app as “the official way to use Google on my phone.” Having the chat thread there to reference the last few things I’ve searched is great, and the suggested actions are generally useful.
Email from LinkedIn
If you’ve ever been part of a user-centered design project, you’ve probably heard the term persona when referring to something like this:
It appears to be a bio for a fictional person, meant to represent a specific type of user of your product. Typically, someone compiles a slide deck containing a handful of different personas, and that deck is presented to the team. Everyone is then supposed to “keep them in mind” during the design phase so the resulting product “works for them.”
There’s only one problem: you can do all that and not improve your product in any meaningful way.
The salient fact about design personas is that most “designers” don’t understand them and use them wrong.
— Alan Cooper, March 26, 2013
That’s a quote from the inventor of personas (and Visual Basic, among other things). The trouble is, there’s a lot of nuance to creating and using personas effectively. In my experience, it’s really easy for the team to slip up somewhere along the way. So what should we do instead?
A Useful Tip
One great piece of advice came in the form of a metaphor from Jonathan Korman during CooperU’s UX for Product Managers class:
Imagine you’re setting up a tent, and you’re trying to place the minimum number of tent poles in the optimum locations to get the most coverage. The poles are your personas, and what you’re covering is your target market.
So in a health care app, for example, you might have the following personas:
Julian, a physician who only needs to use a few key features of the system, but is impatient with technology
Lou, an elderly patient who has trouble with vision and fine motor control
Carol, a nurse who does the bulk of the heavy lifting in the app while juggling a massive patient load
All three personas “stretch the tent,” applying pressure on the design. To improve the product, the team might remove some friction for the physician, increase accessibility for the patient, and build some extra power user features for the nurse.
Each additional piece work contributes to a business goal: increasing the number of customers that can be served. If each of these demanding user’s needs can be met, the product will slightly overserve everyone “behind” them who’s not as demanding.
We used this technique in some recent work we did building a recruiting system. The behavior pattern we noticed was those asked to interview candidates do so “on the side” and aren’t deeply engaged with hiring. Hence, we created a way for them to view a candidate’s resume without even logging into the recruiting tool.
Meet Cornelius
MillerCoors takes this to a comical extreme with Cornelius, the lead character in a new series of ads for their Smith & Forge brand of hard ciders. Cornelius, and his extremely manly associates, enjoy a Smith & Forge beverage after a hard day’s work in the 19th century: blacksmithing, chopping down trees with an axe, and so on.
The message is simple: if this drink is manly enough for him, it’s manly enough for you.
The Presentation Zen Sketchbook is the first sketchbook I actually filled, and re-ordered. It’s great because:
Some pages have a 2×4 grid of boxes, which is perfect for multi-step user flows or planning presentations, but
Some pages are blank, allowing you do to freeform sketching, but
Most of the “blank” pages actually have small images and phrases, which avoids the mental block of staring at a blank page, and
It’s not too big or too small
Highly recommended if you’re not happy with what you have.
You look like a smart cookie. You already know starting your software effort with a giant requirements document isn’t the best plan. (Much has been written about that, though I have a favorite.) It’s counterproductive to pretend like you know every detail of what you’ll build before you start.
On the extreme other end of the spectrum, you can question every assumption, choose a few key targets, and test multiple ideas to see which hits those targets best. (Much hasbeenwritten about that, too.)
But what if you’re in the middle?
What if you’ve got a feature idea that “has to get in”—don’t gimme that look, it still happens—but you’ve got wiggle room on the specifics? Or maybe you already have validated learning behind the basic concept, and now it’s time to flesh it out further? How do you present this to your team?
To be more specific: what’s the best way to engage your development and testing teams on a new idea so it becomes a robust feature by release time?
My strategy is to give the team an overview of the feature, and then work together on all the picky details.
The Feature Overview has a few different pieces to it, and a minimum of jargon so non-technical folks can follow along.
There are five or six sections, depending how you count it. Here’s a sample.
Goal
Part of our culture at Appiphony is asking, “what’s the goal?” at the start of anything. (It’s great for meetings; try it sometime.) I often go with a simple “Allow users to…“ since that’s natural for developers. If you want to zoom out a bit, that’s great too; you can phrase it as the user’s goal or maybe use a job story. Just make it clear what success means.
Key Concepts
There are usually a few critical things the team needs to understand about a design to fully “get it.” This is where I include those. If I can anticipate some questions ahead of time, I’ll answer them preemptively. You may also want to call out something that’s easy to miss, particularly if it’s tricky to implement. Direct their attention.
Inventory
This is a flat list of each component that’s part of the design. In addition to the screens, don’t forget copy for error/information states, subject lines and body text for email templates, and anything else that needs to be coded or tested. Review this list multiple times.
Exception Cases
I call this out as a separate section because I usually forget some of them, and my partners in QA swoop in and help. They’re almost always able to spot one or two “unhappy paths” through the flow we need to smooth out.
Known Risks
There may be parts of the design that simply can’t be built within the time and budget constraints. Call these out if you know them, and don’t be surprised when the developers add to the list. Once the concerns are all on the table, assign tasks to write just enough proof-of-concept code to determine if the design needs to change to account for reality.
Images and Files
This is a separate section in my document that functions like a list of appendices. Depending on the tools you use, you may be able to place the attachments inline where they apply to support your ideas with visuals. Don’t just use words.
To paraphrase Scott Berkun, nobody wants your requirements. They’ll be OK with theirs, though. Engage your people to define the details and everyone will benefit.
You hired smart people, right? Bring your technical teams ideas at a medium level of grain and tap into their talents. They’ll contribute ideas you never would’ve considered, and some you didn’t even know were possible. You’re a smart cookie, but not the only one in the jar.
I’m one of those people who loves to see the details of how others do their jobs—especially if it’s similar to mine. So I was very grateful when Abi Jones, a designer on Google’s Search team, tweeted a UX comic she drew at work.
The lack of ceremony is great, but the light bulb moment for me was the contrast between the suboptimal current state and ideal future state. I realized the majority of my design work is for net-new functionality, and I needed a different way to pitch reworking something we already have. I made two separate images, but ideally they would fit on one page.
Thanks, Abi!
Diagram of a typical OAuth user flow
From a user experience perspective, I’d be lying if I said I was nuts about OAuth.
Much like The Most Interesting Man in the World, I don’t always create detailed UI sketches. But when I do, I find it faster to create them on paper. So what’s the best way to share them with the team?
After lots of experimenting, I’m pretty happy with the Whitelines Link system. Here’s how it works.
You’ll notice that the notebook’s “natural” orientation is vertical.
I usually end up rotating it for a wider surface, but not always.
The mark on the left/bottom tells the Whitelines Link app to send this image to Evernote after scanning it in.
Then, I “scan” the page with the app. You can hold your phone at a sloppy angle, but the app seems to require photos to be taken in “portrait mode.”
The app recognizes the image, removes the gray background, and detects Evernote as the destination.
If need be, I crop and rotate in Evernote.
Storing the sketch in Evernote allows me to organize sketches into different notebooks while also making them searchable.
Usually, I export the image to send it to a teammate or post it to Basecamp/Trello/etc. This is an example of the final image people see.
This may seem like a lot of steps, but it’s the shortest amount of time from idea to posted image. Try it for yourself—without the fancy notebook—by downloading and printing a template from the Whitelines web site.
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. 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.
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.
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
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.
Would you like to try some dry cake? I didn’t think so.
Instead, make your MVP a cupcake. Be lean, not cheap.
If you feel like the word “innovation” is being diluted to the point of meaninglessness, you’re not alone. Thankfully, Horace Dediu has done a nice job of explaining that innovations must be useful, not just new—or even valuable.
When you change the conversation and ask, “what’s useful?” you can talk about the scenarios in which your product gets used. At that point, you’re making real progress towards innovation.
