Most businesses don’t admit how costly things like company wide announcements, project management, interviewing, internal politics, and large scale collaboration are on productivity. They all work against flow, and should be considered a handicap on product teams. Small teams substitute process with trust, eliminating overhead.
— Kyle Neath, Million Dollar Products
I’ve long held Jakob Nielsen’s Useful = usability + utility formula in high regard. The Introduction to Usability article it comes from is still one of the best intros to user experience I’ve seen. That said, I’ve recently started to wonder about the ideal ratios on the right side of the equation. What combination of usability and utility results in the most useful product? Is it a 50/50 split? 70% usability, 30% utility? It’s a purely academic exercise because there’s no way to prove any of it, but it did lead me to a theory:
I believe that utility (whether a product provides the features users need) is initially more important than usability (how easy & pleasant these features are to use) in product design.
Let me say right up front that I’m not saying usability isn’t important. I’m just saying that when it comes to a product being used extensively (and payed for) by users, it is more important to get the utility right from the start. Users will struggle through bad usability (up to a point), but they won’t use a wonderfully usable product that doesn’t serve a real need (see Path).
I’ll give two personal examples to back up this view1. My favorite social network at the moment is Goodreads. The site is slow, the UI is confusing, and the mobile apps make me feel completely lost, and yet I keep coming back to it. Because Goodreads is extremely good at what it does: helping me find books I’d enjoy, and letting me share good books with friends.
The second example is Pinboard. If I could take only one website with me to a deserted island it would be Pinboard. I use it more than any other online service. It helps me save, categorize, and find all the useful articles I’ve read over the 5 years I’ve been using it. The UI has tons of little weird quirks, and it’s very much barebones. But that doesn’t matter. It’s indispensable to me, so I care very little about its usability.
These two examples lead me to a second theory:
The more utility a product has, the less its usability matters.
I like Goodreads, but at some point if the usability becomes too frustrating, I’ll just leave. For Pinboard, on the other hand, I’ll walk through usability hell and back just to keep using it. It’s that essential to my work.
I’ve said this a few times in this article, but let me reiterate: I’m not, for a second, saying that usability isn’t important. I’m proposing that if you have a product that has insane levels of utility, its usability becomes a secondary factor in its success. To put it another way, the ROI on increasing utility is probably much higher than the ROI on improving usability.
The moral of the story is this: first find an idea that people can’t live without, then make it a beautiful, usable product. It’s very difficult to do it the other way around.
If you liked this article, you can sign up to get an email every Friday with all new posts that appeared on the site that week. You can, of course, unsubscribe at any time.
#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */
Back in my eBay days, when Net Promoter was just becoming a huge deal, there came a time when we were asked to include the measurement in our user research. Even then I was extremely uncomfortable with the simplistic nature of the measure, but I just didn’t have the experience to speak up about it. It seems that NPS is finally getting the wind taken out of its sails. The latest takedown I read is Matt LeMay’s excellent On Net Promoter and Data Golems:
This very ubiquity is a huge part of what makes Net Promoter so attractive. It’s a system with an official-sounding name that consistently produces a measurable quantitative output. The score it produces can be easily benchmarked against that of any other company. And this is why, no matter how many times it is critiqued and debunked, Net Promoter only seems to grow in power and pervasiveness. The primary value of Net Promoter is not how effectively it predicts customer loyalty, but rather how effectively it covers your ass.
The main problem with the NPS question—“How likely are you to recommend [product] to a friend or colleague”—is that it’s a data model that doesn’t fit the social model of recommending products.
But by oversimplifying the multifaceted and highly variable human context around recommendation, Net Promoter falls into one of the biggest pitfalls of the “data-driven” age: it puts forth a data model that does not accurately reflect the underlying social model. When’s the last time you thought to yourself “I am likely to recommend this product to my friends or colleagues” as opposed to something like, “I can’t wait to tell my friend Tricia about this new slow cooker because I know that she doesn’t like to cook things on the stove”?
Luckily, Matt provides some really good ways to improve the use of NPS. Is this is something you deal with in your company I highly recommend his article.
My latest column for A List Apart was published today. From The Analog Revolution:
So I wonder. I wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the product we make might not only be done at some point, but might be something that lasts for a while? Would we make it fit into the web environment better, give it a timeless aesthetic, add fewer unnecessary features, and spend more time considering the consequences of our design decisions?
It’s not the best thing I’ve ever written, but I have to say, it’s one of my favorites. This is something I’ve been thinking about for a very long time, and to condense those thoughts into just over 1,000 words that include subtle references to The Hobbit and Zoolander feels pretty good.
I find the common meme of “Oh, that’s ugly—a developer must have designed that” pretty misguided (and I’m not even a developer). The reason is that most developers I know have exceptional ideas (and taste). So these words from Marty Cagan really resonated with me:
I consider this mindset of the product owner (or more generally, the CEO or stakeholders) as the only one that can determine what to build, as toxic to teams, and a major reason for the lack of innovation. I’ve tried to explain many times that often the best single source of true innovation are our engineers. That doesn’t mean every engineer is going to be like this, but the mindset where no engineers can do this is a very serious problem. The engineers are working with the technology every day and are in the best position to see what’s just now possible. They are also disproportionately very bright people. When you combine this deep knowledge of technology, with a first-hand experience of the customer problems, great products can result.
“The best single source of true innovation are our engineers.” True that.
If you invest in growth before you have retention, you’re renting users, not acquiring them.
— Gillian Morris in a great post about what users say vs. what they do.
I really love the product strategy direction Marty Cagan proposes in The Alternative to Roadmaps:
Ensure your product organization has a compelling product vision. Ensure that each product team has a clearly defined, prioritized set of business objectives. Make sure any commitments that must be made are high-integrity commitments.
This means that instead of prioritizing features (and the timing of those features), the leadership team prioritizes business objectives and problems to solve. There are two components to this:
First, the product vision is about setting OKRs—Objectives and Key Results (again—not features or solutions). From The Art of the OKR:
The objective sets a goal for a set period of time, usually a quarter. The key results tell you if the objective has been met by the end of the time.
Second, high-integrity commitments mean we give teams the time they need to figure out how long something will take. From Managing Commitments in an Agile Team:
So the way we manage commitments is with a little bit of give and take. We ask the executives and our other stakeholders to give us a little time in product discovery to investigate the necessary solution, and validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business (they can support this solution).
Once we have come up with a solution that works for our business, we now can make an informed and high-confidence statement about when we could deliver this and what type of business results we can expect. We can also decide if it’s even worth doing.
One day when I grow up, this is how I will run my product team.
In my latest column for A List Apart, called The Distance to Here1, I discuss a theory I’ve had for a while now:
The larger the distance between people who build a product and people who make decisions about the product, the harder it is to make a good product.
The post goes into detail on how I think companies can continue to make good products as they grow.
I don’t want Yelp; I want to know where to eat. I don’t care about Google Calendar; I care about not missing appointments. I don’t buy iPhones; I buy best-in-class pictures of my kids. I’m loyal only to results, and I suspect you are, too.
— From John Pavlus’s Apple and Google Race to See Who Can Kill the App First, a good reminder that users care about outcomes, not features
I’m seeing this sentiment about Slack quite a bit these days:
Am I the only person who feels like Slack has turned into an even less controlled, one-more-thing-to-check, inbox?
— Craig Mod (@craigmod) June 2, 2015
I am now on nine Slacks and I get DMs in all of them and this is rapidly becoming untenable
— Erin Kissane (@kissane) June 2, 2015
This is such an interesting side effect of being successful. Slack is an amazing product, and the way they’re building it is nothing short of remarkable. From their launch strategy to the way they keep innovating, it’s a wonderful case study.
But now something else is happening. Slack is so successful that public groups have exploded, and it’s not uncommon for people to switch between 5 or more Slack accounts during any given day. I think we’re now learning that the thing that makes Slack so useful also requires it to remain a relatively small part of one’s workday.
Slack is a great communication tool, with integrations that make it possible to reduce the amount of time spent on other services. But once you have multiple accounts and multiple rooms to contend with every day, it has the potential to become worse than that technology we all love to hate—email. At least with email there’s an assumption of asynchronous communication. With Slack there’s always an expectation to get an answer immediately, so the stress it induces can really skyrocket out of control.
What a predicament. This is a product that is incredibly useful, but that needs a relative measure of quietness to remain so. This means that explosive growth actually hurts its utility. What an interesting design problem to solve…