Focus
I’d like you to take your idea, and try to frame it inside the following mission statement:
A common response is something like this:
Unfortunately, that’s a bad mission statement. Let’s break down why:
- It limits the solution.
At this stage, your mission should only address your problem. You’re going to be iterating on solutions, so why artificially limit it? For now, let’s keep it wide open, and rewrite our focus.
2. It’s trying to be everything for everyone.
Don’t try to make a one size fits all solution for literally all humans. Really, who is this for?
If you’re at a hackathon, chances are it’s something like
3. This is an artificial need.
Nobody inherently wants to “more quickly message their friends,” or “have faster email,” or “get longer battery life”. These needs are a product of the platforms and paradigms they exist in.
Let’s connect our statement to more fundamental human needs — why would people want to more quickly message their friends?
There are two parts to that statement — the first is the desire to message with friends.
That’s pretty easy — it connects to our fundamental desire to collaborate, to be social, and to connect with other human beings. It’s also extremely practical — we live in a networked world where we’re constantly coordinating, scheduling, asking for feedback, and just communicating.
So let’s rewrite that part —
Now, our need is platform agnostic — we don’t bundle a solution — some form of instant messaging — with our stated need.
The second part is the desire to “more quickly” do something. Where does that come from?
We want speed in our lives because it’s more convenient. So that we can spend more time doing more things.
Maybe communication is the focus when people want to use this product, and we simply want to do it faster so that we can do more of it.
Or maybe, making communication more convenient allows us to do it in more places, enabling us to communicate when we ordinarily wouldn’t be able to.
Both of these are viable needs, but the latter is a little bit lateral, and a little less obvious. You can imagine the inventors of the telephone, or the SMS, or email, asking themselves, “how can I make something that lets people communicate in situations they right now wouldn’t be able to?”
Kinda interesting. So let’s pursue that.
The second half rewritten, our final statement reads
Not bad.
To recap: we ensure that people want to use what we make by explicitly articulating how our product’s goals line up with fundamental human wants and needs, using mission statements. This also allows us to probe the less obvious needs — the ones people themselves might not be aware of.
Our User and her Constraints
Let’s explore who we’d like to use the product. Normally, we’d go out into the field and actually perform user research, building up personality archetypes we call “user personas”. But since our user for today is ourselves, I’ll just throw up an archetype onto the board.
The average college hacker is probably pretty busy, and has an unstable schedule. They live pretty close to who they enjoy being with every day.
In this context, what do our users use electronic communication for?
When they’re busy, most of their communication is probably terse and asynchronous. They’re generally coordinating later times to communicate, meet, or work together.
When they have free time and would like to be social, they’re probably either already hanging out with people (meaning they don’t need to electronically communicate with these people), or they’re making plans to.
In either context, communication tends to be quick, to the point, and not super planned.
This lends itself to shortform, asynchronous communication like texting (and messaging), which happen to be existing solutions to our needs statement.
But even texting has its flaws. Due to its asynchronous nature, we’re almost always multitasking while texting.
This is okay if the other thing we’re doing also involves the phone or computer, because it’s a similar interaction space. It’s pretty easy to switch windows or tap on a push notification to respond to a Facebook message.
But what if our user is doing something more active? What if she’s walking to class, driving, or has something in her hands?
An example — I bike a lot in the fall, and tend to wear gloves in the winter. In either situation, it’s ridiculously annoying to [stop my bike,] pull out my phone, [take off my gloves,] and start typing on a tiny keyboard. There’s not really a good solution out there.
Exploration
That’s where you come in — given our mission statement, and a set of specific examples where existing solutions to our mission fall flat, I want you to come up with at least 10 ideas that might tackle the solution better.
Connect them to each other. Swap out the parts and mix them up. Know your platform, and think about how new capabilities negate existing preconceptions (actionable push notifications! Now on Tap! split screen multitasking! etc). Ask your friends, and teammates! At this stage, there are no bad ideas — write them all down. We can filter them later.
Don’t be afraid to go broad, but don’t be afraid to embrace simple, practical solutions. Not everything requires a new paradigm, or yet another wearable. Not everything requires a new app even. Try to come up with a continuum of solutions, from simple to complex. And remember, your design and your product shouldn’t take center stage — your user’s needs should.
Recap: Design is driven by constraints. We explore our user’s current pain points, and identify what our constraints are. Solutions can exist in spaces where the two don’t quite line up.
Expansion
Got your 10 ideas? Cool. Now, start expanding on them a little. Draw out some stories and sketch some key points in those stories. This shouldn’t be too hard, since we already started ideating with a story in mind.
(I’ll go over the details of prototyping and refining toward a final product in next week’s post, and highlight a couple of tools and things I use. Interested? Follow me, and/or the HH Design publication.)
At this point, you’ll naturally start to prefer a couple of ideas over the other ones. Try to create variations on the ones you like. But don’t completely converge yet. As a rule, you shouldn’t settle on a solution until you’ve prototyped at least a couple of them, and talked to your users about them.
There are no hard and fast heuristics for determining which of your ideas are good, and which are bad. The final arbiter is to just test them out — how well does your proposed solution hold up in the real world? But as you gain experience, you’ll learn to recognize when an idea is Really Something, and when it’s Just Not That Great. But don’t completely trust yourself. Validate your assumptions, prototype, ask questions, and get critiques!
Most importantly — keep making. Keep a bias toward action, and remember — in a world of undo, non-destructive editing, and A/B testing, failure is cheap. Just give it a shot! And afterward, don’t forget to gather feedback, and constantly improve.
For an overview of design (and an idea of the trajectory of this series, read this).
HH Design is a community around design in the context of technology.
