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 can¹. 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.²

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.