When did you last write a user story? If you’re unfamiliar with the term, a quick google search will tell you that a user story is “an informal, general explanation of a software feature written from the perspective of the end user or customer.” Basically, it’s a way of describing what a user wants to achieve from your app or product.
What’s missing from the definition, and something that is very important, is that every user story must contain a who, a what, and a why. Here’s some examples:
As a customer, I want to enter my credit card information so I can purchase a product.
As an admin, I want to delete comments in order to prevent spam.
As a manager, I want to view page analytics to see where my customers are spending the most time.
Each of those stories includes a WHO (customer, admin, manager), a WHAT (enter credit card information, delete comments, view page analytics) and a WHY (to make a purchase, to prevent spam, to see where customers are spending the most time).
Notice one thing that user stories DO NOT include? The how.
Nowhere in any of those stories does it lay out exactly how any of those whats will be accomplished. And that’s why a lot of founders don’t use them. Instead, they often turn to wireframes.
Wireframes are visual interpretations of your website, app or software product. They feel tangible, and they make it seem like you’re making progress. Often, that progress is a bullshit KPI. And there are many, many problems with it.
For one, wireframes should really only be built in order to visualize the output of the user stories. Properly developed user stories define all the needs of all various users of your product, and it’s unlikely that you will account for every single user need with wireframes alone. Very, very unlikely. Starting with wireframes is the equivalent of “Ready, Fire, Aim”. Even before you’ve spent the time to capture all of the user needs, you’re off to the races, drawing pretty pictures.
Wireframes also often lead to CEOs going outside the bounds of their job description. As the CEO, you are responsible for defining the what and the why, NOT THE HOW. Or at least, you’re not responsible for the how until you’ve clearly defined the what and the why.
The chances that you as the CEO are an expert in UX/UI probably aren’t great. I know this from experience. I’ve spent 27 years launching technology companies, and every time I create wireframes, I remember there are people way better at design than I am.
The idea that you can sit down and design a mobile app simply because you’ve used lots of apps is the height of hubris. It’s like listening to the complete works of Mozart then sitting down at a piano and thinking “88 keys, 12 scales, eight notes… how hard can it be?”
Another reason to start with user stories is that wireframes are very easy to get attached to. Even if they’re just lines. Even if they’re full of lorem ipsum. When someone sees a wireframe of something that has previously only been in their head, they fall in love. I’ve seen it hundreds of times, with both founders AND users. Which can be devastating. Because early on, when you haven’t nailed product-market fit yet, the chances are high that you’ll need to make changes. Having users (let along managers) who are already in love with your design makes changing more difficult. And having features in your MVP just because it “looks better” is a fucking awful reason to have a feature in your MVP. The rug doesn’t always tie the room together, Lebowski.
Finally, if you give a developer a wireframe, the odds are they will build exactly what you give them. Doesn’t matter if they’re a contractor or an employee. What’s so bad about that you ask? Well, when you don’t give them any greater context, you’ll go back to them frustrated and ask them, “why did you do it this way?” And they’ll say “Well, you gave us the wireframes.” “But it’s so dumb this way,” you’ll say. They’ll reply, “Well, we didn’t know what you were thinking.” AND THAT’S A TOTALLY FAIR RESPONSE.
Yes, ideally you’d have a team that can read your mind and figure it all out on their own. But if they could, they’d probably be off starting their own companies. Or working in Vegas.
User stories provide the context of what a wireframe is for. When you give user stories to a developer, you greatly increase the chances they will be thoughtful about the product and features they are implementing. When they understand the bigger picture — who is this for, what are they trying to accomplish and why are they trying to accomplish it — they can take ownership over the project.
I work mainly with offshore developers where English is a second language. That might seem like a hurdle, but when I explain to them who the product is for, what we’re trying to do and why, they are just as thoughtful about it as any U.S. based team. Don’t fall into the trap of thinking that a language barrier means they can’t understand what you’re trying to build. These guys ask fantastic questions, are incredibly thoughtful, and take ownership over what they produce.
Now, it is true that your developers need wireframes along with the user stories. And if we’re just talking about things like colors, fonts or logos, it’s fine to develop those things in tandem with your user stories because they don’t impact functionality. It’s only when the design crosses over into defining functionality and interactions that you’ll wind up in the perilous space of, “now that it’s on a screen it’s no longer up for discussion.”
Wireframes should be built based on user stories. If you try to do it in reverse, your user stories will just end up documenting the wireframes. ProductHunt’s celebrated Product Requirements Doc is a great example. It offers ideas like “Any registered user can upvote/like a post, incrementing its vote count by one,” but provides no context on why users would like to upvote a post, or what increasing its vote count means. They took their wireframes, which showed buttons for liking a post and its vote count, and turned it into words.
You need to start with the words. This is who it’s for. This is what they want to accomplish. This is why. Then, design away.
— Eric Marcoullier
Even I fall into the wireframe trap. This past weekend I had an idea for a new app and the first thing I did was open Balsamiq and begin mocking up the home screen. About five minutes in I thought “WTF am I doing?!?” and opened up Google Docs to write up all the user stories.
I have several (as in more than three) clients right now where we’re taking a hatchet to their wireframes because they started with pictures instead of the abstract concept “what does a user need to do in order to receive the core value of this product?” If you’d like to avoid that pitfall, send me an email at eric@marcoullier.com or visit my coaching web site.
One comment