Hi, I'm Ryan Singer. I design software and manage teams at 37signals.

What is at the core of an interface design? I think of the design not as a collection of screens or buttons or pixels, but as a collection of jobs that the user wants to do. In this article I want to give you a feeling for how to think of interfaces as made up of jobs, each with a beginning, middle and end.

Shifting our focus from visual concerns like pixels and proportions to the jobs an interface should do helps us articulate the function of each element on screen. We can differentiate elements that make the possibility of a job known and offer the means of performing it. For example a button that says “Post a message” is the entry point for that job. We can further identify elements involved with intermediate steps of a job, or that indicate a job was completed, or suggest other jobs that the user might want to perform next.

We can think about whether a job is performed in one stroke (“delete the file”) or if it requires intermediate steps or extra information to be completed (“rename the file”). In the former case, the action will be immediately followed by elements on the screen that communicate that the job has finished and what the result was. In the case of intermediate steps, elements on the screen communicate whatever further work should  be done in order to perform the job. For example a print dialog asks which of two available printers to use. It could also be that no further information is needed, but the job cannot be completed instantly, and so the interface communicates to the user an intermediate state where the software is working via a spinner.

Break jobs up into beginning, middle and end

From all of these examples we can see generally that jobs may have a beginning, a middle, and an end. This is a useful segmentation. It gives the designer a way to think at the same time about what the user is trying to do and what the interface should look like at each phase of the job. Thus ’jobs’ as units of design extend in the dimension of the screen as pixels and also extend through the dimension of time as processes. They are more fundamental than both.

Having understood jobs as processes that simultaneously  specify user intentions and screen elements, it becomes possible to describe the design problem in an interesting way. We can distinguish two classes of design problems, a simpler one and a more complicated one. First are those problems where we know exactly what job the user is trying to perform, at what time, and under what conditions. Second, and more complicated, are those where we know a set of possible jobs the user might want to perform, but we don’t actually know which particular job they want among that set.

A one-job interface

An example of the simple one-job case is a machine for paying a parking garage ticket by credit card. There is one possible sequence of steps (we can imagine such a simple version), and every user who approaches the interface approaches it with the exact same intention: to transform an unpaid ticket into a paid ticket so they may be allowed to leave the garage. A designer making an interface for this machine basically has an optimization problem: how to take users from point A to point B with maximum clarity and the fewest points of friction possible.

Many jobs on the same screen

To understand the second kind of problem where a set of jobs is known but not which particular job, consider a smartphone home screen. When the user unlocks their phone, what are they trying to do? They might want to make a phone call, or check for new emails, write a text message, search for an address, or many other things. In a case like this the designer’s problem is to design not only the individual jobs, but also a portal of job possibilities. Many alternate jobs are presented as potential processes that have not yet begun. The user identifies these possibilities and uses affordances in the interface to enter into one of them. They tap ‘Mail’, wait while the software checks for new messages over the network, and then see a handful of messages appear. Beginning, middle and end. Having checked for mail and found new messages, the user again rests at a portal of possibilities. Would they like to read one of the messages? To mark one as spam? To compose a new message? To check a different mail account? Or leave the Mail app and do something else entirely?

First order and second order job problems

If you’re technically minded, you could call these “first order” and “second order” design problems. On the first order, we’re designing one job so that the beginning, middle, and end are all clear and frictionless. On the second order, we offer multiple job options at once. We’re not only designing individual job flows but also figuring out how multiple jobs can share space on the same screen, how the jobs are related, where users will look to find one versus another, which job a user will want to perform after the present one is finished and so on.

A web designer might consider these second-order problems “navigation” problems, but that makes it too easy to fall into unconscious patterns. We often assume that “navigation” is a necessary ingredient because we don’t understand the fundamental problems of offering and relating jobs to the user. As a result we fall back without thinking on patterns like tabs, nav bars, and collections of links. Focusing on the jobs and their beginning, middle and end helps us to think about what the interface really needs to do for the user instead of which patterns are the most worn and comfortable in our hand.

Putting jobs to work

How do these ideas apply to everyday work? On the first order, focusing on jobs helps us to identify each element in an interface as part of a process. We can ask of each element not only “why is this here?” but also “how did the user get here?” and “what will come next?” Is each element a stumbling block or a smooth step on the way? Looking for the beginning, middle and end of each process helps us remember to set clear expectations, remove friction from flows, and show clear results and effects when the job is done.

On the second order, we can become sensitive to priority and hierarchy in an interface by looking at how jobs coexist and compete on the same screen. Four links treated equally suggest the designer could only call even 25% odds on the job you want to perform. On the other hand a big button with a small link below makes a statement about which job the designer thinks you want to do (or what they wish you would do in the case of a checkout process.)

As interface designers, it’s important that we not only put buttons and text together, but that we put them in the right place, at the right size, in the right moment at the right time. These decisions are only partly visual and partly artistic. At their core should be an understanding of what jobs the interface fulfills and how those jobs intertwine in both the product and the users’ lives.

—

Related: Part One of my PeepCode video includes a number of segments where I talk to Geoffrey about the beginning, middle and end of each task. You might like to check it out for real life examples of jobs in the design process.

Last month the folks from PeepCode visited the 37signals office and asked to record my design process. Geoffrey told me not to prepare anything. He said he’d show up with a sample problem and simply record whatever I did with it. The result is two 75-minute videos (Part One, Part Two) that show my thought process step-by-step, starting with paper sketches and then moving on to HTML/CSS.

The hard thing about demonstrating design is the sample problem. The problem should be simple enough that the details don’t bog down the audience, but complicated enough that you run into real-life conflicts and constraints.

Fortunately Geoffrey picked a really good sample domain. He asked me to design a UI for picking the top five finishers out of 200 participants in a pro bicycling race. The task was rich and interesting enough that we spent the first 75 minutes purely sketching and analyzing the approach.

The first video, Part One, covers the sketching process. A lot of good material came out of this section, including:

• How to tackle a UI problem by dividing it into tasks that each have a beginning, middle and end
• How to use sketching as a response to uncertainty, and when to stop sketching and move on to HTML
• How to focus on the most natural solution so that people will intuitively grasp a design
• How to focus your design process on conflicts and friction points, attacking them one by one until the design works

This video also gave me a chance to explain the UI design process through an analogy to software testing. Kent Beck’s Test-Driven Development had a huge influence on me, and I’ve always had trouble explaining the connection. In both videos I continually refer to setting up “tests” — specific things in the design that aren’t working or aren’t resolved — and then design against those tests until they “pass” (that is, until the problem goes away). This loose analogy articulates that tricky and hard-to-pin-down process where a designer continually moves their focus among pieces of a problem and along the way settles conflicts step-by-step in a constructive sequence.

I think the process will be interesting to both designers and coders. Designers can compare the process to their own, while coders can use the analogies to software testing to see design as an extension of concepts they already know.

In the second video, Part Two, I take the sketches and ideas from the first session and build them out in HTML and CSS. Along the way I dip in and out of Photoshop, explaining the time and place for each tool.

Part Two especially focuses on getting quick results in the browser. I sketch out dom elements, give them classes to communicate their purpose, and gradually decorate them with inline styles until the design comes together in the browser.

I would prefer videos like this to be free. But Geoffrey came up with the idea and his PeepCode team did all the hard work. I just showed up one Friday morning for a couple hours of design practice. So if the material is useful to you I encourage you to support their effort and buy the videos at $12/each.

Here are the links:

1. PeepCode Play by Play: Ryan Singer Part One
2. PeepCode Play by Play: Ryan Singer Part Two

There’s also a 10 minute preview on the Part One page.

I hope this material is useful to you and welcome your comments here.

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.

I gave a talk at Refresh Chicago last week, and afterwards a fellow came up to me with a question. He does UI on a team of mostly engineers, and the engineers are big fans of the “Minimum Viable Product” concept. MVP, if you aren’t familiar, is an idea from the Lean Startup scene. In a nutshell, it means to do as little as possible so you can learn if you did the right thing or not. The fellow who approached me after the talk was having a problem with MVP. It seemed like their product suffered from bad experience holes. Their team was trying to do the minimum possible to ship, but their definition of minimum didn’t include things like a smooth way to reset your password. Things like password-reset were “never important enough”, so they languished as swamps of bad experience among the dry hills of minimally viable features.

Does the minimum-viable approach lead to gaps in the user experience? It doesn’t have to. There’s a distinction to make: The set of features you choose to build is one thing. The level you choose to execute at is another. You can decide whether or not to include a feature like ‘reset password’. But if you decide to do it, you should live up to a basic standard of execution on the experience side.

Features can be different sizes with more or less complexity, but the quality of experience should be constant across all features. That constant quality of experience is what gives your customers trust. It demonstrates to them that whatever you build, you build well.

I like to visualize software. Here’s an intuition that works for me. Feature complexity is like surface area and quality of execution is like height.

I want a base level of quality execution across all features. Whenever I commit to building or expanding a feature, I’m committing to a baseline of effort on the user experience. That way feature complexity — scope — is always the cost multiplier, not user experience. There aren’t debates about experience or how far to take it. The user experience simply has to be up to base standard in order to ship, no matter how trimmed down the feature is.

Minimum viable products are about learning what you need to build. They are matters of surface area. Whatever minimal feature set you decide to build, you can decide to build it properly. That commitment to quality at every step is the way to keep customers with you as you work upward from minimally viable to featureful and beyond.

There’s a phase we go through in our maturity as designers. At first we don’t have a lot of confidence in our process, so we hide while we work. We take feedback from directors, programmers, customers, and say “Ok let me go away and work on that and I’ll get back to you.” Then we go away for a few days or a week and monkey around with our mysterious process until we feel good enough to show something again. We don’t like to show things that are still in progress. If somebody checks in we say “I’m still experimenting with a few things.” We design in secret.

When we get more confident a new phase opens up. We believe more in our process and we know that things are never perfect. So we start showing work earlier and start talking about our rationale at a given step. We’re excited for feedback on a clumsy design because we know feedback will steer us to a better one. We might even be unafraid to open our tools and do some real work in real time in front of people. This is designing in the open.

Is there anything we can do to speed the transition from designing in secret to designing in the open? My experience is yes, it can happen with a little help from the outside. Whoever is managing the project or directing it can ask for smaller, more frequent steps.

Instead of asking for 10 changes and waiting a week, you can ask for 1 change and wait 15 minutes. Evaluate the change, praise it or identify weaknesses, and suggest the next change. By asking for small changes, you take the pressure off the designer because you aren’t asking for miracles. You also take the pressure off the review process because the set of constraints and motivating concerns is smaller. The design is easier to talk about because there are fewer factors involved.

By working hand in hand, reviewing small changes as they are made, designers gain confidence and learn to expose their process. And this technique is no training wheel. The better a designer is, the more open they are to discussing small changes and getting feedback. It’s a virtuous cycle leading out of secrecy and into productive openness.

Update: Pixar President Ed Catmull makes the same point in this quote on getting over embarrassment:

In the process of making the film [Toy Story], we reviewed the material every day. Now this is counter-intuitive for a lot of people. Most people—imagine this: you can’t draw very well, but even if you can draw very well, suppose you come in and you’ve got to put together animation or drawings and show it to a world-class, famous animator. Well, you don’t want to show something that is weak, or poor, so you want to hold off until you get it right. And the trick is to actually stop that behavior. We show it every day, when it’s incomplete. If everybody does it, every day, then you get over the embarrassment. And when you get over the embarrassment, you’re more creative.

As I say, that’s not obvious to people, but starting down that path helped everything we did. Show it in its incomplete form. There’s another advantage and that is, when you’re done, you’re done. That might seem silly, except a lot of people work on something and they want to hold it and want to show it, say two weeks later, to get done. Only it’s never right. So they’re not done. So you need to go through this iterative process, and the trick was to do it more frequently to change the dynamics.

Thank to Ben for pointing me to the Catmull quote.

Andrew Wicklander interviewed me for his Project Idealism podcast and our 45-minute chat is now online. Andrew’s background in software project management led to a lot of questions about how we work at 37signals. I was glad to dig into a number of topics including:

• How we emulate our “cowboy days” with teams of three
• How a growing company is like a cocktail party
• Picking and choosing from XP and Agile, and why basic values are more important than methodologies
• Why methodologies lose their meaning over time
• Why features become bloated when they are made for cases you don’t understand
• The overlap between UI design and product design
• How programmers and designers should negotiate on cost
• Who should manage projects: a designer or a programmer?
• How to not get lost in a project and the central challenge of doing just one thing at a time
• The costs of unfinished work
• The power of working in small steps and being in a “known state” between steps
• How doing less is still the hardest standard to keep
• and why 37signals won’t be competing with Cisco anytime soon

Thanks a lot to Andrew for interviewing me and asking such thoughtful questions. The podcast is on his website and also available as episode #11 on iTunes.

If I asked you to visualize a software product, a picture of the interface would probably come to mind. That’s natural because the interface is the product from a user’s point of view. But for us on the development side, products are more than just interfaces. They’re also the code, the connections between code and UI, the separations of concerns and the boundaries between features.

To visualize a product from the development side, I start with two layers: the code and the UI.

Depending on the product or the feature, the code and the UI can be in very different proportion to each other. On one extreme there are features that expose very little UI but require a lot of code. Think about a recommendations system for an e-commerce store. Hundreds of lines of code might analyze your buying patterns, the items you look at but don’t purchase, attributes across products and so on. But the only change in the UI is a simple list of products with a header that says “recommended for you.” Projects like this are icebergs: there’s a tiny bit of UI supported by a large amount of code. It’s also hard to draw correspondences between the code and the UI. Most of the code interfaces to other code, not the user.

On the other hand, there are many projects where the UI and the code layers are in balance. Take a typical CRUD-style web app for example, like a blogging tool. There is UI for creating posts, showing posts, editing posts. And behind each piece of UI is a small amount of code to write the post to the database, read and display the posts, update the records and so on. A lot of everyday business apps have this structure, and they basically look like layer cakes. Each piece of UI sits on top of a corresponding piece of supporting code.

It’s interesting to note that you can apply the distinction to whole products or to individual features. It helps me to have these pictures because they affect how I estimate the work. Icebergs are notoriously difficult to estimate. You have to really understand how the code is factored into different concerns in order to guess at how long each piece will take to build. Layer cakes are much easier because you can roughly estimate them by looking at the surface area of the UI.

These UI and code layers are a good starting point for seeing the product as a whole. A next step is to define scopes of work that cut across both layers. With a good picture of scopes we can try to visualize feature development as a step-by-step process. I’d like to address that in a future post.

Someone on Quora asked “Should I focus on getting a good UX or getting something quick out of the door?”

This raises a question about the order of events in design. Design is a path-dependent process. That means the early moves constrain the later moves. Think about the cycle. On the very first iteration the design possibilities are wide open. The designer defines some screens and workflows and then the programmer builds those. On the next iteration, it’s not wide open anymore. The new design has to fit into the existing design, and the new code needs to fit into the existing code. Old code can be changed, but you don’t want to scrap everything. There is a pressure to keep moving with what is already there.

Our early design decisions are like bets whose outcome we will have to live with iteration after iteration. Since that’s the case, there is a strong incentive to be sure about our early bets. In other words, we want to reduce uncertainty on the first iterations.

Uncertainty and scope are the same thing. The more scope, the more uncertainty and vice versa. So a good strategy is to reduce your scope on the first iteration so your design/build cycle is centered on a very well understood problem. Build one little feature and nail it. Then build the next one, so your path-dependent process is always moving forward from a state you are proud of.

The alternative is to make many decisions at once, with high uncertainty, and all those so-so decisions multiply as they constrain future decisions. You can never really catch up.

Every feature can be better. It doesn’t have to be perfect the first time. But each element should be solid and well thought-out before you move on to the next.

I like finding areas where programming and interface design overlap. One example is the principle of “cohesion.” Let’s take a look at how programmers understand the idea, how designers use it, and what the two have in common.

Programmers say that code is cohesive when functions that belong together are close to each other and functions that don’t relate are far apart. It’s a question of whether the code is one giant bowl of spaghetti or many small plates.

You’ve probably seen PHP projects (or even written them — I have) where the whole project is in one file. Code that’s all mixed together has low cohesion because there’s no separation between functions that handle, say, logging in, and totally different functions like payment processing. Compare that with a well composed object-oriented app where the code for logging in is neatly organized in a Session class and code for payments is bundled inside a Payment class. Code cohension means that the parts you need at a given moment are close together and the things that don’t matter are somewhere else.

For interface design, “cohesion” happens on two levels: the large-scale level of multiple pages and the small-scale level of elements on a single page. First we decide how to divide functions of the product across different pages. What should the user see at the same time? Let’s say the product is a hotel reservation system. What does the front desk staff need to see and do on a single page when guests want to check in and get their room keys? Are there operations that should be placed on different pages — like offering a full refund — because they don’t happen as often?

On this larger scale, a UI is cohesive when information and actions relating to the same activity appear together on the same screen. And actions that don’t relate or aren’t as common are placed at a distance on separate screens. That’s the first level: grouping things into pages and separating them with navigation.

The second level of interface cohesion happens on a single page. There could be twenty different elements on a page. A guest name, a balance, a check-in date, a notice about special requests, a check out date, a button to perform check-in, a function to take payment, and so on. All these elements aren’t placed randomly. They’re grouped into different units depending on their relationships and the way that our eyes scan them.

Elements with strong contrast catch our eyes as they scan the screen. When an area of strong contrast carries a pertinent message (like “Reservation dates”, or “Create a room key”, or “Balance “) a halo of attention settles on that area. With our attention landed, we notice smaller nearby elements that didn’t have enough contrast to stand on their own across the whole page. These elements are grouped together with proximity and contrast to make up a gestalt. The page is then made up of many of these gestalts with space in between them. That’s the second level of cohesion: the page elements are organized into groups that tie elements together and separate them from other groups.

It’s interesting how these different kinds of cohesion on the software side and UI side share the same motivation. The compiler doesn’t care if functions are placed together in a way that is easy to understand in the source code. And the browser’s rendering engine doesn’t care if elements are placed into coherent gestalts on a web page. In both cases it’s the reader who creates the requirement that things should be clearly grouped and separated. The difference is only whether the reader is looking at code or looking at a rendered interface. Programmers have to “use” their code just as much as our so-called “users” use the interface.

This principle of cohesion is one example of how designers and programmers face similar problems in the different software layers. It would be smart for the two to collaborate early in the design process so that decisions about how to cohere the functions of the app can run up and down the stack, from UI to controller to model to data store. The more we can see coherency connecting the layers of the app, the easier it is to hold a clear picture of the system in our heads as we fix, change and improve our software products.