As I discussed in the previous post, many products have terrible design because the design team doesn’t get to use the product, and because design is brought into the process too late.
I’m going to discuss two more reasons which extend beyond the design team.
The first one will not be a surprise to anyone who reads this blog regularly — most products are poorly designed because the product leadership failed to get out of the building and talk to customers. Another way to state it is an overvaluing domain expertise.
Don’t get me wrong – complex products require a product manager who understands the rules of the game. I don’t want to use brokerage software created by someone who doesn’t know a 401K from a 529 plan.
But it takes more than knowing the conventions and constraints to build a great product experience. You need to be able to anticipate your customers’ concerns and fears, to know where they’re likely to be confused and need reassurance, to understand the context in which they’re using your product.
When you have deep domain knowledge, it’s hard to remember what it was like when you did not have that information. (see: the “curse of knowledge”, popularly explained in the book Made to Stick).
When I worked with financial software, I commonly heard product managers and engineers explain a certain workflow with “but this is the logical choice!” How many people do you know who are logical about their money? Money is emotional. Things that threaten our money (or anything that is important to us) scare us and turn us into irrational creatures.
Products that are designed by rational humans but used by irrational humans… usually doesn’t result in a positive user experience.
To overcome this, you need to make a conscious and deliberate effort to understand your customers. What is their mental model? What are they concerned about? What is their comfort level with this task? You need the ability to put aside your domain expertise and see your product through the eyes of the uninitiated — and this is a challenge.
Most of us work really hard to become experts at something, and it goes against our nature to spend time pretending to not be experts.
The final reason why most products are poorly designed is that the product development process doesn’t get feedback fast enough.
Raise your hand if this sounds familiar:
Company: “Oh, we always do user testing to identify any usability issues or confusion with our products.”
Me: “That sounds good. When do you usually do your testing?”
Company: “We do our testing when we have a real working beta; that way we’re testing the real app so we get the most accurate results.”
Me: “So, if your testing uncovers major issues, how long do you have to address and fix them?”
Company: “…A few weeks.”
User testing is too often just lip service. If your product is fundamentally wrong — and if you made the first 3 mistakes I discussed, it almost certainly is — you can’t just patch that up in a couple of weeks. Not only would that require your engineers working 36-hour days, but now your whole organization is invested in the thing that has already been built, is already working, was already promised to customers.
Even if you made incredibly good guesses, even if you talked to customers before you started building — if you wait until the product is 90% complete to get feedback, you might as well have not bothered. You’ll learn what you should fix in the next version, but for startups, you may not have the luxury of a next version. This version needs to meet a minimum value threshold or you’re headed for the deadpool.
The way to fix this is simple.
Get feedback sooner. Build that into your schedule:
- Interview customers before you start building and use that feedback to identify changes to your requirements.
- Show early mockups to customers and iterate based on that feedback.
- Show early prototypes to customers and iterate based on that feedback.
- Find ways to manually emulate the “finished product” experience and share that with customers, iterate based on that feedback. And, of course
- Look for ways to build the 2-week version and then another 2-week version and then another 2-week version — instead of the 6-week version where you’ve invested a lot of all-or-nothing time.
Sounds like a lot of work. But the hours you spend on gathering that feedback pale in comparison to the hours you waste when giant features or releases have to be thrown away and redone. (And let’s not even talk about the morale hit…)