Clickbait title notwithstanding, this article aims to share some of my learnings in product design.
Let’s start with the high level stuff.
1) Define“the only metric that matter.”
The seasoned PM turned VC, Josh Elman argues that the key question that product people should ask, is “how many people are really using your product?” Elman points out that most of the fluffy numbers such as page views and monthly active users don’t reveal much. Instead the only question that matters is “who is really using the product?” The answer to this question should be in defined in the form of “x amount of users did these thingswithin this time frame.” An example of this can be “100 users performed three or more searches within the last 15 days.”
This metric doesn’t always have to be this detailed, but the key is to give context to a number. Are people really using your product? That’s the question we need to address. The reason is that we the product team can use it to figure how to really help, add value, and benefit the people buying and using our product.
Defining it with the product manager can inform of the short-term and long-term design goals. Knowing it will also help to clarify sub-goals, and frame design decisions. At the very least, having this conversation with the PM can help to uncover and evaluate pre-existing assumptions.
2) Apply the 80/20 rule.
The 80/20 rule means that often in a large system, 80% of the output is caused by 20% of the input. You see this pattern repeatedly, whether it’s economics, transportation, human habits, etc. Here are some examples:
- 80% of traffic is on 20% of the roads
- 80% of a company’s revenue is generated from 20% of customers
- 80% of the product experience comes from the 20% of the UI
This pattern is also known as the “Pareto principle”, which is a rule of thumb for denoting power law distribution. The takeaway is that having this rule in mind allows us to define the order of importance of the problem set at hand. It allows us to focus on finding and pulling the right levers that moves us to the goal, one at a time — deploying our limited time and resources to uncover and address the most important areas at each stage.
One story that comes to my mind is Tian Ji’s Horse Race. It’s a Chinese idiom about a military general in the Warring States period who won a best-of-three horse race despite having slower horses.
Essentially Tian Ji gathered intel on the opponent’s horses before the race and deployed his horses on race day in a way that matched his best horse with his opponent’s medium horse, and his medium horse with his opponent’s weakest horse. The result was that Tian Ji narrowly edged out his opponent in both matches despite losing the race between his weakest horse and the opponent’s strongest horses. He won the series two games to one.
The lesson here is that applying the 80/20 rule is about 1) getting to know the situation, the problem, resources and constraints, 2) identifying the 20% area you should be spending energy on and deploy your resources on it, 3) repeating the process of gathering intel, strategizing for the next stage. This process of solving for one critical issue at a time can propagate from business strategy all the way down to individual UI decisions.
3) Design for “Minimum Viable Personality.”
The absence of a personality is still a personality. So whether you like it or not, your product will have a one. Rather than leaving it to chance, it’s better to have a say in what that personality should be.
Some have referred to this notion as developing a minimum viable personality. Others have called this the creation of a minimum desirableproduct or minimum delightful product. I think the core idea of all this minimum XY jargon is the same. It revolves around one question:
- How can we create a satisfying product experience?
I think there are three steps to getting this right. First, we have to stand for something. We have to have a vision of the future; an answer to the question of why we’re doing what we do — a vision of the world that we hope our product will help to bring about. In doing so, we’re offering our customers a reason to stay, even if the product is not good yet. Tesla’s roadster was a perfect example of this — it was a bold statement, a stake in the ground about the kind of future that Tesla stood for. Even though the MVP was full of issues, people stuck around.
Second, the product should have a guiding principle, a gestalt, a core experience or technology that is 10x better than what’s out there. When Google’s search, the iPhone’s touchscreen first came out , they were 10x better than what was out there. There has to be something that stands out so much (in a good way) that customers can easily bring up to evangelize or defend your product. Just having a vision is not enough, your product needs to have at least one single experience that is 10x better.
Third, the product has to get enough details right. Not all the details, but enough has to be right. Lines, layout and colors matter. Words, images and illustrations matter. Interactions and animations matter. To determine which details you really need to get right, think about what the core paths and features of the product are, and whether those experiences are delightful. In the original iPhone’s example, there were many things that weren’t good (battery life, camera, price, etc.) but the core experience of listening to music, browsing the web, and scrolling through song list and cover flow were absolutely delightful.
The section below is about the specific ways to motivate and guide people to accomplish the jobs they hire products to do.
4) Tell stories.
Before there were written words, human beings passed down stories by memorizing them into rhyming verses — it is the original way of passing knowledge. Maybe that’s why stories are so powerful at communicating information — our attention is almost instinctually drawn towards them. When it comes to product design, a good use of stories can make information understandable, interesting, and memorable.
For sale: baby shoes, never worn.
This powerful story had been frequently attributed to Ernest Hemingway, although its origins are unclear. It demonstrates that stories don’t have to be long to be meaningful or memorable.
Use the simplest language to tell a story about your product. In five words or less, people should instantly get its purpose in the world.
This is also why anecdotes often persuade better than data. All of the companies above feature user testimonials on their websites.
The core of Airbnb’s business is about trust, so it makes sense that Airbnb is not only using its clean, beautiful design aesthetic to invoke trustworthiness, but it’s using real user stories to convey that message, both in the format (testimonials) and in the content (stories about strangers connecting).
5) Provide just enough choices.
Hick’s Law states that the time required to make a decision increases logarithmically with increases in the number of choices. The cognitive load in making a decision adds up quickly. People find it difficult to choose. More choice also increases expectation and decreases satisfaction. That’s the paralysis of fearing to make a wrong move. Perhaps this is what FOMO is about — there are too many ways to stay connected and entertained, to the point that being present no longer seems like a satisfying option.
If possible, our product should figure out the right path for people instead of making them choose. If we have to make them choose, try to minimize the number of choices, and provide recommended solutions for the undecided users. They will appreciate that.
Instead of building digital products in the way we build analog products by displaying all the options, exemplified in the cockpit above, remember that we have the ability to easily change the interface. So let’s do a damn good job of figuring out when decisions are not necessary. Let’s ask for fewer decisions, and make the ones we do ask more relevant and contextual.
6) Progressively disclose information.
Human brains can only perceive a few chunks of information at a time. To avoid overwhelming the user, it’s better to progressively disclose information. Google Docs’s contextual menu is an example of this. Using drop-downs and buttons, Google Docs progressively discloses controls for editing text without overwhelming the user with a bazillion buttons and swatches jammed into the contextual bar.
Progressive disclosure is especially useful on mobile where the standard steps and flows on desktop are no longer feasible.
Oscar Health does a great job of progressively disclosing a long form into simple conversational steps that the user can a) focus on each chunk of information; b) follow through without diverting precious mental energy to the the cognitive task of jumping from one question to the next.
7) Show progress and status.
People are motivated by progress, mastery, and control. The closer people get to a goal, the more they are motivated to accomplish it. The systems we design should inform users clearly of their location within the system, their status, and the tasks in front of them.
Nextdoor uses a simple task list to: 1) show that you’ve already finished registration, 2) encourage you to help them grow by inviting your friends and family. It’s questionable whether this is the most effective place to surface the invite, given that the app hasn’t demonstrated much value yet, but the intention of the designer is clear — “We’d like to you to help us grow. Here’s a link for you to do that.”
Amazon uses a vague progress bar to track packages. It’s not clear that the progress bar indicates time rather than distance. But it doesn’t matter, since the user knows that the package is on its way in a simple glance.
8) Communicate change with motion.
Interface design has already merged with motion design. This is because motion is one of the best way to capture attention and communicate change. So let’s take advantage of our natural affordance with the physical world to design intuitive motions that communicate system change, whether user-initiated or not.
9) Test with 5 users.*
* Correction: actually you can run all kinds of A/B tests with way more users. However when it comes to the scrappy, iterative kind of product design, especially early in the problem scope , 5 users are all you need.
Do impromptu one to two-day mini design sprints, even if you’re the only designer on the team. Gather what you’ve learned beforehand, hypothesize, sketch out ideas, prototype and put them in front of 5 target users. Spending 15 minutes with each users can get you much more insights than you may assume. Remember, the key here is to make the prototype real enough so that they overcome the hurdle of thinking “oh this is not the real thing” and actually treat it like a product.
Be okay with staying silent. Observe and listen carefully, rather than trying to ‘help’. The goal is not to get them to the end of the flow. The goal is to help you uncover how users think and feel while using your product, and pinpoint where your product shines, where it falls flat. Note down what they did, said, and expressed non-verbally. Analyze the results when the session is over. If somethings worked, great! Go work on the things that didn’t work. If many things didn’t work, it’s actually also great — because now you know and can use that knowledge to improve.
Bonus: Design for the Context
These hacks I listed are guidelines and heuristics to be applied by you. They don’t exist in a vacuum — whether they should be applied or not, depends entirely on the context. At the end of the day, product design is about using our knowledge of human cognition, behavior and culture to make products that benefit people. So use critical thinking to assess each situation, and apply these ‘hacks’ when appropriate.