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. */

---

1. That’s how science works, right? ↩

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.

I’m currently designing an Admin Console for enterprise software, and it’s going pretty much as you’d expect it to go, which is like this:

Every time I think I’ve made a breakthrough and sit back to enjoy my handiwork, I realize I missed something, and back into the abyss I go. I’ll probably write an emotional case study once this is all said and done, but for now there’s one breakthrough that has actually lived up to repeated scrutiny, so I wanted to share that.

First, let’s define what an admin console is. It’s that area of a site where admin users go to manage users, content, billing, notifications, and all kinds of other admin-y things. It’s also the area of a site that mostly gets ignored because (1) very few people have to use it, and (2) it’s freaking hard to design. There can be hundreds of options, and figuring out how to make it all fit together while still providing a good user experience can drive a grown man to tears very quickly. But if you don’t spend the time on this, and admins can’t do what they need to do, the whole site can fall down for its users.

So onward we go.

Initially I approached the design as primarily an Information Architecture problem to solve. I assumed that the main concern for admin consoles is findability of features. Where do you go to send invites? Manage authentication options? Set up analytics? But as I thought about it more, I realized that when it comes to admin consoles, there are actually two very distinct user actions, and they need to different design paradigms:

• First, there’s the action of finding the thing you’re looking for. And yes, that’s primarily an Information Architecture problem to solve.
• Second, there’s the action of doing the thing you found. And that is less of an IA problem, and much more a user experience problem to solve.

In most admin consoles the acts of finding and doing are both built on the same interface. What this usually means is that even if you get your IA right, performing the action you go there to do can be really difficult and confusing because the interface is still in finding mode. What we need is to separate those two actions. How do we do that? I have pictures!

Let’s begin with how most admin consoles work:

In this case, the whole thing is a mess. The Information Architecture is not well thought through, so finding what you’re looking for is extremely difficult. To add insult to injury, if you do manage to find your path and switch to doing, all those distractions remain in the interface, and you’re left to fend for yourself amidst the chaos.

Now, let’s see what happens if you look at this only as an Information Architecture problem, as I did at first:

We’re certainly making progress now. The list of things you can do is neatly ordered, so it’s much easier to navigate. But there’s still a problem: the interface remains consistent during the doing phase, so the probability to get confused is still high.

So what happens if we look at finding and doing as completely separate actions? What if we try to solve both the IA and the UI problems, depending on which phase we’re in? I think we end up with something like this:

Now we’re talking. With every step, you get fewer choices, so you’re essentially getting guided to the most appropriate choice. And even more importantly, once you enter the doing phase, there is no more distraction. Everything is focused on completing the task at hand. Maybe this results in more clicks overall, maybe it doesn’t. That’s not important, though. What’s important is that the next action to take is as obvious as possible.

This approach is in direct contrast with progressive disclosure. Instead of starting with a few options, and opening up to more options as you go, you start with many options (which is essential in a complex UI like an admin console), and provide fewer options as you go. Perhaps we can call it regressive disclosure? I don’t know, I’m bad at naming things.

How is this thinking manifesting itself in my current project? Well, instead of providing a traditional navigation—however well thought out it might be—I’m leaning towards a design that is much more linear, and provides fewer choices as the user goes along. I’m also working on a full-screen design for the doing phase, where the rest of the IA disappears completely once you move on from finding. As an added bonus, this is a much more natural design on mobile is well, so it’s going to make our responsive efforts easier as well.

There’s still a long way to go, but at least I now feel like the framework is solid. Hopefully you can use this for something you’re working on as well!

As if feature prioritization isn’t hard enough, many companies are starting to introduce another tricky variable into the mix: remote teams. If you’re a product manager who spends a lot of time on video calls with team members in different parts of the world, you’ll be forgiven for feeling like involving the team in prioritization is too much to deal with. But don’t give up on the dream yet. One of the teams on a project I’m working on is very much distributed, and I think we may have found a reasonably painless way to do prioritization together.

Here are the ingredients you’ll need:

• An account on Mural.ly
• A good understanding of the Kano model

Let’s discuss the recipe in detail…

On Mural.ly

Mural.ly is virtual whiteboard software. Before you scream “BLASPHEMY!”, I want to assure you that I still enjoy physical sticky notes as much as the next person. Nothing compares to the feeling of ripping a bad idea off the board and rage-throwing it into the closest trash can1. That said, physical sticky notes have two major drawbacks:

• It’s hard to get remote teams involved in the process.
• Transcribing them is such a chore.2

And that’s where Mural.ly comes in. It lets you create virtual sticky notes on a whiteboard, move them around, change their color, and best of all: the whole team can play along. You can do voting sessions, multiple people can edit at the same time, etc. This tool has really done wonders for our collaboration efforts across offices.

On the Kano model

The Kano model isn’t new, and it’s been fairly widely used in software product development for a while. Developed in the 1980s by Professor Noriaki Kano for the Japanese automotive industry, the model is a helpful method to prioritise product features by plotting them on the following 2-dimensional scale:

• How well a particular user need is being fulfilled by a feature
• What level of satisfaction the feature will give users

The model is generally used to classify features into three groups:

• Excitement generators. Delightful, unexpected features that make a product both useful and usable.
• Performance payoffs. Features that continue to increase satisfaction as improvements are made.
• Basic expectations. Features that users expect as a given — if these aren’t available in a product, you’re in trouble.

Here is a visual representation of the Kano model:

So, as we started our prioritization exercise, I drew the x and y axes on a new mural. We then listed out all the features that we’re thinking about for the next few months—one feature per sticky note. We proceeded to go through each sticky note, and discuss where it fits on the Kano model—how far are we in meeting the need currently, and how satisfied do we believe users will be once we’ve met the need better?

We ended up with something like this:

(Yes, it’s small—unfortunately I can’t show the feature details. Maybe once they’re live…)

This now becomes a great tool for prioritization and release planning. There are couple of rules of thumb I like to stick to when doing sprint/release planning:

• Make sure there is a balance between the 3 different types of features. Don’t overemphasize one type over the other.
• Start with the features with the biggest upside. For Basic expectations, that means features on the far left, where a little work would result in a big increase in satisfaction. For Excitement generators that shifts to features closer to the y-axis, since the real benefits start to kick in exponentially once you go the extra mile on fulfilling the need. For Performance payoff features the story is a little less clear since the relationship is linear, but I would still argue for starting on the far left. The sooner you can get users on the “satisfied” side of the scale, the better.

We’re still learning our way through this, but so far I’m happy with the process. It’s a model that everyone understands and can rally around, and with Mural.ly at our side we get to involve the whole team. I believe marketers call that a win-win.

---

1. Why do rage-throws always miss the basket? Such a let-down. ↩

2. Funny how you never see photos of the lone product designer sitting in a room, tearfully writing down every sticky note in an Evernote document as everyone else leaves the room high-fiving each other. ↩