UI and Capability

It’s easy to get overwhelmed with details when you’re designing a UI. That’s why I try to keep hold of which things “really matter” and continually come back to them. In a software tool, the important things are the capabilities you give your users.

People use your product because they are trying to get somewhere. You can imagine them standing in front of a chasm with their goal on the other side. They want to do something, but they can’t do it without help. Your product is there to bridge the gap.

Here’s a way to understand “what matters.” The person standing there really wants to get to the other side. They aren’t just flipping channels on TV or scrolling through Facebook. They opened your app because they want to accomplish something. You can either help them or not. They care.

What exactly they care about depends on the domain — the world your app lives in. Maybe they care about shipping an order in time for Christmas. Or they want to document the client’s approval to avoid an argument later. Whatever it is, they didn’t come for the drop-shadows or gradients. They came for the capability.

To help somebody, a capability has to have two things. Think of it like the two handrails on the bridge. First, it has to be implemented on the back-end.The package has to go on the truck, the client approval has to be saved to disk.

Second, the interface has to offer that implementation to the user. The user has to know it exists, be able to find it, and figure out how to operate it.Designers have a word for this: “affordance.” The interface “affords” the capability to the user.

When it comes to design, thinking about the capability you are affording can help you refocus when you’re lost in details. Designing isn’t just pushing pixels around and playing with type. Ask yourself: does this change affect whether a user can discover the feature? Does it clarify how to operate it? What am I helping them do right now?

I’m very conscious of whether I am affording a feature or styling it. It’s important to distinguish because they look the same from a distance.

The right information has to stand out for a user to notice a feature. You use contrast, color, and size to make it pop. When you design the feature itself, proper alignment, bold phrases, and small print all contribute to clarity. You need these visual distinctions to show how the feature works and help the user see the right things.

On the other hand, when you style the feature you use the same techniques for a different purpose. Color, weight, and proportion all create an aesthetic feeling and tone. A button may be equally clear and understandable whether it’s blue or green, but you still fuss over the decision.

Affording a capability and styling it are both important. But it’s essential to know which one you are doing at a given time. Style is a matter of taste. Capability and clarity are not. They are more objective. That person standing at the edge of the chasm cares more about accomplishing their task than the details of the decor.

Styling also consumes time differently. Since the definition of success is a matter of taste, you can’t incrementally measure progress. You can circle around on styling for a long time without increasing the capability for your customer.

This is why I do very little styling at the front of a project. I’m not religious about it — I do some rough styling to feel good about what I’m working on. But I don’t allow myself to linger or circle around it. I prefer to play with styling later in the project after I know that the capability is complete in its two main aspects.

This is the framework I use when I design products. The core of the product is its capabilities. Capabilities are the things that customers care about and depend on you for. Capabilities are afforded by the interface. The interface reveals them, explains them, makes them possible. And finally the capabilities are implemented in code so something tangible happens when users operate that interface.

Knowing which capability you are building and whether you are implementing, affording, or styling it enables you to maintain focus. Be conscious of the feature you are working on and what it lacks to carry users over the gap. Check yourself when you make visual decisions. Are you trying to reveal the feature? To explain how it works? Is the problem artistic or does it hinder users from reaching their goal?

Design isn’t a sea of pixels and code isn’t a tangle of functions. The more you see how each piece of design and code supports a specific capability, the easier it is to find order in the chaos of product development. In the end nothing is more satisfying than seeing users standing on the other side of the chasm and thanking you for it.