How to Make Something People Actually Want
I spent 5 years working on a passion project (aka I was stuck on a side project for 5 years. Here’s how I finished it). The project was for learning statistics via a story-game. I was fortunate enough to spend the last 6 months of those 5 years finishing the project at Google, where I received good advice from the top-notch design team.
Frustratingly, their advice was too late for me. It turns out that making something people actually want starts at the design phase — before you actually start building.
Here is what they taught me.
1. Be clear on the target audience and the desired outcome
Whenever I showed the in-progress project to a designer they would ask, “Who is the target audience? What is your desired outcome?”. I only had nebulous answers to these questions like, “Uh… HackerNews readers? I want 10K people to look at it and like it.”
They wanted concrete answers, like “The target audience are 20-40 year old college educated folks who have previously tried to learn statistics for fun post-graduation because it seemed useful. They tried using a MOOC but dropped out after a few lectures because it was too math heavy and didn’t seem useful enough.” Being clear on the audience enables you to make clear and optimal design decisions targeted toward your audience.
2. Do user interviews
How do people arrive at such crisp definitions of the target audience and problem? They talk to users and conduct qualitative interviews. Qualitative interviews allow for better understanding of the “user journey” and where the pain points are.
In a qualitative interview, you ask open-ended questions, and see what naturally arises. Examples:
- What is your background in statistics?
- How does statistics make you feel?
- Do you use any statistics in daily life?
- What tools have you tried to learn statistics? Did they work for you?
- What are you currently learning about and why?
- What are your most pressing problems and worries?
3. Do cognitive walkthroughs
The “cognitive walkthrough” is a different type of interview where you ask users to say aloud everything they think or feel as they go through an experience. Ask them to share their stream of consciousness.
What are they walking through? Before you build anything, you can find people to do cognitive walkthroughs of similar offerings in the market. You can do cognitive walkthroughs of fake landing pages of products that you are thinking to build. When you have prototypes, walkthrough them. Cognitive walkthroughs will reveal what resonates with users -- and more importantly why.
4. Pretotyping not prototyping
Stanford lecturer and ex-Googler Alberto Savoia coined the term “pretotyping” to mean “pre-prototyping”.
It basically means, cut corners on your prototype. The pretotype only needs to be good enough to gather data on user interest. The pretotype should take no more than a few days to make.
Examples of pretotypes include Wizard of Oz demos (have a human in the loop faking the experience), sign-up forms to gauge interest before building the product, and unscalable pop-up experiences.
5. Paper mocks
Sketch things out before you make them, right? Wait, there’s more.
UX Engineer Ric Ewing taught me this. Take an 8.5x11 sheet of paper. Cut it in half so that it’s the same proportions as a screen. Draw every interaction you intend to build on a separate half sheet.
Previously I had saved paper by sketching interactions all onto one sheet of paper, with lots of arrows saying “and then this happens”. Putting all the interactions on different half sheets of paper allowed me to see the true complexity of what I was proposing -- allowing me to simplify the design. It also allows for easy editing of the interaction.
6. Make it smaller
Most importantly, make it smaller.
When I started the shed project, I had the vision that it was going to be grand, epic, yet also intuitive, fun, and playful, as well as a useful and applicable guide to statistics. There were going to be many chapters to cover all the concepts useful to daily life (expected value, variance, common distributions, Central Limit Theorem, Bayes Rule, regression, maximum likelihood, whatever else I’d just learned). As the surface area became larger quality declined, which was demotivating; now I was building a not-very-good thing. And any changes to make it better meant reworking that very large surface area.
The takeaway is: Scope the project to be the smallest possible compelling thing. It allows the thing to get more love and polish. It allows it to get more feedback cycles. You can always make it bigger once you’ve discovered the small compelling thing.