Hi, I'm Ryan Singer. I design products and manage teams at Basecamp.

« See my home page for more articles about interface design and product management.

Get the RSS feed to find out when I post new articles.

Follow me on Twitter for a steady stream of thoughts and relevant links.

Sep 9, 2011

Identifying conflicts in a UI design

When I’m working on a UI design I look for things that are wrong. I have to do that because there’s no checklist of things that are ‘right’ that make a perfect product. You can’t check a requirements list and say “Yep, everything’s there!” and conclude that you made a good design. You have to look at the design itself and hunt around for problems: things that cause friction, things that aren’t clear, things that take too long, things that break expectations.

These conflicts are the heart of design. If we could just pile features one on top of the other, we wouldn’t have to do design. Design is what you do when piling elements onto each other doesn’t work. It’s the process of identifying and resolving conflicts.

There are three main areas of conflict that I look for when I’m working on a design:

1. The Domain

The first area of conflict is in the so-called “domain.” The domain is your encyclopedia of knowledge about what the user wants to do and how they see the world. Suppose you’re designing a product for a hotel front desk. What is the first thing the check-in staff cares about when a guest arrives? What kind of information does the staff need to record before the hotel can release the room? What words does the staff use to talk about their job? What do the words “booking,” “reservation” or “customer” mean to them? When I’m diagnosing a problem in an interface I always check my domain understanding first. If the screen isn’t trying to solve the right problem for the user or if it’s not speaking to them in their language, the other fixes below won’t help.

2. The Eyes and Brain

A second area of conflict is with the users eyes and brain. Regardless of which domain you are working in, the eyes have certain ways of scanning the screen, responding to contrast, interpreting spatial relations and so on. Words are easy to see at the start of a line but hard to find in the middle of a paragraph. A bright red button is easy to spot and a tiny grey footnote easy to ignore. It’s not enough for the right features to be included in the screen’s layout; they have to be presented in the right way so they jump out and make sense to the user’s eye and brain.

3. The Implementation

The third area of conflict is the implementation. Our choices in the design determine whether it’ll be easy or difficult to build, how it will perform, and how the feature can change over time. A giant high-rez background image might be beautiful, but it may also take too long to load. Setting privacy permissions on records and mixing them in a combined view might be good from the interface point of view but slow to query and difficult to cache. Network latency, browser version, and your choice of programming language can all introduce conflicts at the implementation level.

These three areas — the domain, the eye/brain, and the implementation — intertwine with each other. A single element may have conflicts in one area or all three at the same time. Much of the work designing interfaces involves teasing apart these conflicts in order to solve the right problem. Is the action correct, but it’s too hard to find? That’s a conflict with the eye/brain. Is the screen clear and simple but it doesn’t show the right information? That’s a conflict with the domain. Does it take too long to get feedback from a common action? That might be an implementation problem.

Try to see if these distinctions help you to untangle the conflicts the next time you are working on an interface. I’d be curious to hear if they are useful for you.

Update: Maria Ramos offered a Spanish translation of this article.

What do you think?