Hi, I'm Ryan Singer. This is Felt Presence, where I write about user interface and product design.

Product design can look like magic. When I started doing it ten years ago, the small team I worked on made decisions intuitively. There was no system and it worked fine. But as the company grew, I found myself unblocking teams and diagnosing problems. When I saw patterns repeating themselves I decided to codify the questions I was asking. I hope that by sharing my techniques, people will learn to unblock themselves and diagnose their own product design problems.

The categories I introduce below aren’t arbitrary. They are extracted from years of solving real problems. They aren’t the only way to slice things, but they are the way I have used repeatedly with success. I can’t see any way to design without them, and when one is missing, things go wrong. That’s why I’m confident calling them vital.

You can broadly separate product design into two phases. First you come up with the concept of what you are doing, and then you implement it. The concept you come up with is like a map for the implementation. It tells you where you are, what you are working on, and what’s left to do. Many of us use iterative processes to implement. We learn through the process of iterating and change our original plan. I am not going to talk about the implementation phase. (I wrote about it here.) This article is about how you define the problem to begin with and how you get from there to a concept.

Three places to look for problems

Problems with product and feature design often trace back to the initial approach. Either the problem wasn’t well defined, the concept wasn’t well defined, or – in the case of beginners and newcomers to a platform – your bag of tricks wasn’t adequate to address the problem. Questioning each of these areas can open up new insight and unblock you.

I’m going to describe the problem you are addressing as the job a user is trying to do. We’ll look at the bag of tricks you bring to the problem in terms of patterns you’ve seen and applied before. After you know the job your product is supposed to do, and you have a collection of patterns from past experience, you can create a product concept. The concept unifies the relevant patterns you know into a composite design that does the job.

The Job

I need to relate the problem to a situation in order to understand it. The reason I am making a product is to give people capability they lack. That’s why they pay for it. The gap between the person’s current situation and the situation they want to be in defines value for them. They hire your product to do a job. The job is their definition of progress from here to there.

When the job isn’t well-defined, the team doesn’t know what to include and what to omit. They design based on logical speculations, not real situations. Instead of targeting a problem like a sniper, they cast a net and hope to catch the value somewhere within its expanse. Casting a net means building more functionality in more places, so the project grows in scope and complexity.

Sometimes people think they have defined the problem, but they really just defined a feature. Like “users want file versioning.” It’s important to understand that a feature is not a situation. You can dig into a situation to learn what is valuable and what is not according to the goal. Digging into a feature definition doesn’t do that. It has no origin and no goal. Analyzing a feature definition leads you to play out all the things a person might value from the feature instead of learning what they actually value.

Suppose a team is building a “file versions” feature. Two situations define the value differently and lead to different designs.

In one situation, a person catches an embarrassing mistake in a proposal and wants to know who to blame. In order to do this, they need to see information about intermediate versions. They value the product telling them who made what changes and when.

On the other hand, consider a situation where they want to send the latest version of the proposal to the client. They don’t care how it got to its current state. They just want to send the correct file. In this case intermediate versions have no value. The user just wants to know where the latest version is.

Deciding which situation you are designing for focuses the problem. Focusing the problem focuses the team. When the team knows where the value is, they stop speculating about all possible cases and they get down to business. It’s easier to make decisions about what’s in and what’s out. This leads to a clearer criteria for which patterns are appropriate, in turn leading to a clearer product concept.

Patterns

After you’ve identified the job, what enables you to do something about it? Your library of design elements and techniques separates you from a non-professional. Your patterns are the building blocks you combine into a product concept.

When we are beginners, we copy designs whole hog. It’s natural when you don’t understand how individual parts work in isolation. You’ll often see beginners template their designs after well known apps like Facebook or Basecamp.

As we mature, we see patterns at work in the designs we admire. Instead of copying Facebook whole hog, we realize a timeline is what we want for our design. Patterns like collection view and detail view, nav bar, and multi-step process enter our vocabulary. These large scale patterns structure our designs.

There are patterns on the small scale too. Within a stream of comments, you design the display of an individual comment. There might be an avatar on the left to anchor the block, or a bold name on top. The time stamp might sit below the header or float to the right in its own space.

Some people think patterns are formal things written in a book or collection, but they aren’t like that. They are natural and spontaneous just like spoken language. We learn a language by hearing it and speaking it. Words, phrases, and constructions come to mind as if by magic. We don’t hold a dictionary in our hand as we talk to people.

In the same way, we learn patterns by exposing ourselves to designs and designing ourselves. We put elements together and learn what works and what doesn’t. Then, just like our habitual words come to mind more easily than others, the patterns we used with success will appear again and again in the face of future problems.

One thing to watch for with patterns is the beginner mindset I mentioned. We’ll sometimes copy whole designs without knowing how they work. This also happens when we work on new platforms. Until we speak the native language of, say iOS, we will find it easier to follow what other apps do and whatever is easiest in the APIs. This a natural learning process, but we should be conscious about it. Otherwise our product concepts will be limited by our small vocabulary and they won’t target the job as well as they could.

The Product Concept

When we apply our patterns to the job we create a product concept. It is a whole idea knit out of patterns that solves a problem. It often takes the form of some key sketches or mockups that define the project.

Here’s an example. Basecamp grew out of a very focused concept.

37signals was a web design company in 2003. One person talked to the client and another did the design. When we showed work to the client, it was a game of telephone back and forth. Doing the design was simple but showing it to the client, passing the feedback around, and submitting new work for review was a mess.

We wanted something to make it easier for us to show work to the client and get feedback. That was the job.

Blogs were a new phenomena in 2003. The patterns like posts, comments, and permalinks were high in our minds. We had also seen things like password protected web pages and interfaces for user management.

We put these patterns together into a product concept: a private project blog where you could post work to clients and they could comment on it. That’s the heart of Basecamp.

Sometimes teams start building without an explicit product concept. It’s easy to do that when you think you understand the problem and you’re confident in your skills. The problem is that when the concept isn’t explicit, the project becomes a drunken walk. It becomes opaque and hard to estimate because the goal isn’t clear.

A product concept gives you a map of the territory you are trying to cover during implementation. Looking at that map shows you which areas you covered and which ones you haven’t yet. It helps you answer “are we there yet?” with more precision.

Be wary when technical people on a project start implementing without an explicit interface or end-point in mind. Good product development is a sequence of bets. You bet on a concept, implement it, and test it in context. Did it do the job? What worked and what didn’t?

The goal of the design process is to reach fitness between problem and solution. The job defines the problem and your concept defines the solution. The moment of truth happens when you fit the two together. That’s when you test your bet.

If you aren’t explicit about how you defined the problem versus how you build the solution, you will get lost in debate when things aren’t right. One person will be talking about the problem while another is questioning the solution, and yet another person is pointing out details of the execution. Focus on one aspect at a time to make the debate productive.

General and recursive

If you take time to consider the three elements, you’ll discover they apply at many scales of a project. A product has an overall job and concept. Each feature has a job and concept. The same applies to individual methods in the code. And there are patterns at all levels, from large scale structure to individual design elements to code choices.

The generality of these elements makes them powerful. This article itself is designed for a job (debug problems in a product design), uses patterns of construction (illustrations, headers and paragraphs), and follows an overall concept (the three elements as a system and their one-by-one explanation).

When you should not use this

Since this article is itself a product, there are situations where it is valuable and those where it isn’t. It applies when you are struggling to reach a particular goal. Problem definition and concept definition help us to the extent that we are trying to get somewhere in particular.

This works against you when your work isn’t goal-directed. R&D projects and exploratory design don’t benefit from narrow problem definition. Platform and infrastructure projects are different in kind from product projects because the platform is meant to enable products on top of it, which are themselves targeted at specific situations.

The more you are trying to provide specific capability for a specific situation, the more these vitals elements – the job, your patterns and your product concept – take you there.

People mix the terms UI and UX together. UX is tricky because it doesn’t refer to any one thing. Interface design, visual styling, code performance, uptime, and feature set all contribute to the user’s “experience.” Books on UX further complicate matters by including research methods and development methodologies. All of this makes the field confusing for people who want to understand the fundamentals.

That’s why I avoid teaching the term ’UX.’ It means too many things to too many different people. Instead I focus on individual skills. Once you understand the individual skills, you can assemble them into a composite system without blurring them together. For software design, the core skill among all user-facing concerns is user interface design.

You can define UI very precisely. An interface is a place where two things meet: the human and the computer. The computer has functions it can perform. The human needs inputs and outputs to take advantage of those functions. The interface is the arrangement of inputs and outputs that enable people to apply the computer’s functions to create outcomes they want.

Here’s a minimal example. A computer can calculate the square root of any number, like 167391. I can’t do that in my head or even on paper. In order to apply the computer’s square root function, I need inputs and outputs. The input could be an alert box with a text field and submit button. The output could be another alert box that displays the answer with a text label.

That interface offers one function. Things get more interesting when you offer multiple functions. Take an ATM machine as an example. First imagine an ATM that only dispenses cash and doesn’t show balances, take deposits or do anything else. The design task is just like the square root calculator — input and output. Now imagine you want to upgrade that ATM to offer both withdrawals and deposits. The new interface needs to provide a way to choose which of the two functions you want. That’s what “navigation” is.

Those are the ingredients: functions, inputs, outputs, and navigation. You arrange the inputs and outputs on screens and connect them with navigation. The interface works when people can perform the function they need — when they get the square root answer, the $60 cash or the bump in their bank account.

This description is tangible. You can actually point to the inputs, outputs, functions, and wiring between them and say “this is the interface.” Then you can evaluate the experience of using that interface and identify activities you could perform to improve it.

You could apply visual styling to make it more aesthetically pleasing. You could research your users to find out how adequately the interface fits their needs and habits. You can do so many things.

But for software makers, I recommend starting with a strong understanding of UI by itself. The fundamentals can take you very far.

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.

Chasm sketch inspired by Bob and Chris at the Re-Wired Group. Thanks to Bob Moesta, Jason Zimdars, Jonas Downey and Nathan Barry for feedback on a draft.

The other day I wanted to sign in to a video site to watch a lecture by Clayton Christensen. The bumpy experience I had provided a good lesson in designing user flows.

The site requires you to authenticate in order to watch any of the videos they host. The brand looked familiar and I thought I might already have an account. I tried to sign in with my usual username and password combinations, but they didn’t work. Then I tried to create a new account to get access to the site. When I filled out the new account form, the site gave me an error: “That email address is already in use. Please enter a different email address.”

It turns out I did have an account already, but now I was stuck in an error state on the account creation form. I was highly motivated to see the video, so I mucked around with the back button, found the authentication screen again, looked for a “forgot password?” function, waited for the email and eventually got it. I doubt a high percentage of users would have gone through such a hassle to follow a video recommendation on Twitter.

This is an interesting case because it shows how user goals can be in conflict with the implicit goals of an implementation. The app assumed my goal was to create a new account. When I didn’t meet the criteria for new accounts (a unique email address) I was told I couldn’t proceed. But in reality I didn’t care about creating a new account. I was just trying to get in so I could watch Clay’s lecture video.

This is a product design topic. What is the user trying to do, and how can you help them do it?

The product brought me to a dead-end on the create account form because it assumed that the only thing that mattered was creating an account. The error state was narrowly limited to account creation while my actual goal was to get into the site and watch the video.

When I run into problems like these, I ask myself: how did this happen? Could I be making a similar mistake in my own apps? Instead of a clumsy design, I view it as an opportunity to learn something.

This kind of mistake is one that we make all the time. It happens when we focus too much on getting the components right and forget about what the user is really trying to do in the first place.

It’s easy to see how it happens. Someone on the business side decides the site should require people to create accounts to see the content. Therefore “user authentication” becomes a requirement on the designers’ and developers’ plates. Everybody knows how to do user authentication. You need a few key screens: new account, log in, recover password, etc. Somebody with a manager hat divides the work. New-account is a scope. Log-in is a scope. Recover-password is a scope.

Now it’s somebody’s job to implement the new-account scope. What are the boundaries of this chunk of work? Everybody knows, let’s say, that to create a new account you need a new account form, error states, a success state, and an email notification. In addition you have requirements about what kind of information you need to collect and whether things like non-unique email addresses are allowed. Given this set of boundaries and requirements, the person responsible for the new account process builds a solution.

Their solution looks like this:

The account creation process in flow shorthand. States are above the bar, actions are below the bar. Click to enlarge.

It covers all the cases for account creation and it perfectly respects the requirements. Somebody with a manager hat agrees that it checks all the boxes, and the team moves on.

What could be wrong with this? Actually this is all a nice process. The problem happened in the very beginning. As soon as a team breaks a problem like user authentication into component pieces – like create account, sign in, recover password – it easily starts to mistake those pieces of implementation with user goals. People tasked with a component forget that nobody cares about creating an account just for the sake of the account. They start imagining a user driven to create an account. Real users live in a larger context. They’re trying to do something more interesting like watch a Clayton Christensen video.

That’s why it’s important for product people not to fall into the trap of designing and reviewing components in isolation. Yes you need to divide a problem into component pieces, build the pieces, and evaluate them individually. But you don’t stop there. After you divide and conquer you have to reintegrate and review.

How do we integrate the components back into a context for review? Ask the question: “What is the user trying to do here?” The job the user has in mind is the best integration point because the user’s mind doesn’t tidily follow the boundaries of implementation.

Let’s apply this to the example problem. Say we have a fixed requirement that all users on the video site must have a unique email address. What do we do if somebody tries to create an account with an email address that is already taken?

From the perspective of the component alone, the goal is to make new accounts per the validation rules. A programmer will naturally see a non-unique email as an impediment to creating an account and interpret the resulting state as failure. From there it’s logical to respond to the user with an error. “Sorry, it didn’t work.”

From the user’s standpoint, the job is different. They are trying to watch a video. They are only creating an account because it seems necessary to reach their goal. From this perspective, if their email address is already in use, this is good news. They already have an account! We can offer them a link to confirm via email that they own the email address. When they click a verification link in the email we can immediately take them to the video they were trying to watch in the first place. No detective work or back buttons necessary. That’s a better design.


The improved account creation process with an exception for existing email addresses in flow shorthand. States are above the bar, actions are below the bar. Click to enlarge.

This shows how the same process can be designed in two different ways depending on whether your view is confined to the edges of components or widened to the scope of the user’s job. Insights like these come when we step back from the individual components and look at the larger process in which the components participate.

This is not an argument against divide-and-conquer. We still need that. This is a reminder that whatever component we build, we should step back again and again and ask ourselves the question: What is the user really trying to do here?

I’ve been asked to explain my approach to managing product development. This topic applies to individual designers and programmers as much as managers. The goal is not to take what we already do and do it faster or more efficiently. The goal is to have more information and flexibility in our process so we can make better decisions and better products.

If you build the same product over and over, this article is probably not for you. I work on new things and I never know how long it will take or what will work and what won’t. Therefore I design my approach for dealing with unknowns.

When I start designing and developing a product, it doesn’t exist yet. There are a lot of intentions and expectations and aims, but nothing to ship to users. And while the product doesn’t exist yet, there are hundreds of individual points I can imagine should be addressed. Take for example a product for managing conferences. I know there should be an event setup process, a registration form, a check-in process, payment processing, ways to apply credits and discounts, and more. All of these things are contingencies waiting to be proved out by a real design and real implementation.

Each of these broad areas of concern is itself made up of many smaller contingencies. The registration form contains specific fields, validation rules, error states, browser compatibility, art direction, and more. Then down to the programming, all of the elements should be implemented with well-factored functions that reliably perform their roles and allow for easy change and maintenance.

If you take all these levels of contingencies across all the areas of concerns you have a lot to account for in a product that doesn’t exist. And that doesn’t even touch on interconnections and dependencies between concerns.

So how do we manage all this? I like to imagine this mass of contingencies as an unmapped terrain. The terrain is everything needed to solve the customer’s problem, and my responsibility is to map and explore the whole thing. In order to know what has been explored and settled and what is still wilderness, I want to have some areas defined on the map.

The illustrations are just to show how I visualize them. In practice, I track these areas in plain list form.

After I have a lay of the land, the next step is to determine what to work on first, second, third etc. Not every concern in the product provides equal value to the customer. Some parts are core to the problem. Without them the app has no purpose. Others are necessary but have nothing to do with the domain, like user-authentication. As I look at these different areas on the map, I ask myself three important questions:

1. How valuable is this, from the perspective of the customer’s problem?
2. How necessary is this, from nice-to-have to must-have?
3. How far do I have to take it? How good should this particular piece be in order to call it ”done” and move on?

It’s crucially important to understand: all parts of the product do not have equal value. Designers and programmers have a tendency to make everything they work on as good as possible. Once you go beyond a baseline standard of quality, this tendency can lead you to over-deliver on features that don’t matter at the expense of more important features. (See my article on user experience in a minimum viable product.)

In order to get moving on the product, I will do a rough ranking to determine which areas are most important per the three questions above. This is what Getting Real calls finding the epicenter.

A good way to think about this is: which parts of the app will teach me the most about the problem by working on them? This is the exact opposite of what programmers often do when they build the “knowns” first, like user-authentication, before they dig into the hairier domain-specific features.

The end result of this ranking is something like a heat map that reflects my assumptions about where the value is in the product.

I don’t care about ranking every single area. The point is to identify the top few things I need to focus on first. After I hit the top items, I can repeat the ranking process and find the next most important thing, cycling like that until everything is done.

In this case, customers for the conference management product get the most value out of the online registration form and payment processing. They basically hire the product to allow attendees to sign up online and pay. A close second to that are reports on the registrations so far. Customers use those to figure out how big the venue should be and how many sandwiches to order for lunch. Beyond that, it’s necessary to provide things like user authentication and account management, but these are secondary to the domain-specific areas. Finally there are some nice-to-haves like data export which would be fine to ship without.

Now it’s time to do some work. Say we are starting with the registration form, the most important item. The interface design comes first because I want the design to drive the decision tree, not programmer convenience. As I pull out my pen and paper to sketch the UI, I realize there is still a lot to figure out.

The registration form is itself a cluster of contingencies. There is more to the flow than just a form. What happens on success? What happens on failure? Are there email templates involved? If I don’t note these things, I won’t be sure to hit them all. In order to get a clear view of all the pieces, I repeat the same mapping exercise from before but scoped to the registration form area. It’s a recursive process.

Now the concerns are low-level enough to design. I start designing the form, first sketching the different states and then implementing static mocks and templates. Soon I’m far enough to bring a programmer in. This is when the real ”management” begins.

The natural approach most people take at this point is to divide the work by role. They create a ”design” todo list and a ”programming” todo list.

The problem with this approach is nobody can glance at these two lists and absorb a ”state of the world” from them. They don’t correspond to a map.

Here is the same todo list refactored to show areas of concern instead of division of roles:

When I look at lists like this I can see exactly how each aspect of the registration form is coming along. Whenever a list is finished, it shows a piece of the product is ready to review and mark ”done.” It feels great to know one part of the product has no remaining contingencies. It’s ready to go.

Marking one piece ”done” is powerful because it requires design, programming, support and review to integrate around a specific point in the product. When the programmer has questions about the design all the forces and constraints are fresh in the designer’s mind. Likewise when QA or support raise an issue, the programmers don’t have to pull out their archeological tools. The code is still fresh and programmers can anticipate exactly where to look to improve the issue. When all parties are present it gives reviewers the maximum possible leverage because all aspects of the team are available and prepared to act on feedback.

These benefits are the same whether you work alone, with another person, or a larger team. The prize is productive focus and the steady, gradual transformation of contingencies into settled facts. As you shift focus from one area to the next you can conquer and resolve territories on the map. It feels great to check off whole globs of contingencies and wipe them off your mental plate.

At any given time, I want to ask ”where are we?” and see something like this map reflected in the project’s todo lists. I want to know what is done, what’s not done, which aspects are ”solved” and which are still open. Grouping the hundreds of low-level contingencies into higher-order units of concern has enabled me to keep this clear view on all the substantial projects I’ve managed over the past few years.

This article touched on a number of important points:

• View undeveloped parts of the product as contingencies, not truths.
• Bundle contingencies into areas of concern so you have a mental map of the main pieces of the product.
• Consciously judge the value of each area, with regard to how necessary it is and also how domain-specific it is. Don’t be fooled by focusing on “necessary” things that don’t differentiate, like user authentication.
• Areas of concern are themselves bundles of contingencies, and you can recursively apply the same analysis to find where the value is and what needs to be done.
• Tracking work by role doesn’t show progress. Group tasks by concern so checking off a set of contingencies means you have covered all aspects of one piece of the product and you can move on.
• Integrating all roles around one piece of work allows everyone to keep the problem in context while feedback, pushback and new insights arise.
• A healthy development process is a steady, gradual transformation of unproved contingencies into settled facts.
• The goal is a clear head focused on outstanding unknowns. The manager should be able to ask “where are we?” at a high-level at a given moment and see what is done, what is not, what’s in process, what is open, what is satisfactory and what isn’t.

Since this post covers so much ground in summary form, I would be happy to elaborate on specific points. Please share your thoughts or questions in the comments below or via Twitter at @rjs.

The concept of design ”patterns” is widely misunderstood. I want to give you a solid understanding of what patterns really are and how they reflect what designers already do every day.

What is the misunderstanding? First, in the 90s the idea of “design patterns” became popular in the software world, and mentioning the term brings specific, enshrined programming techniques to mind (eg. Strategy Pattern, Decorator Pattern). Later some UI people tried to create pattern libraries, but they focused on collecting examples and formalizing their presentation instead of explaining what a pattern really is and how it plays into daily design work.

A pattern is a simple thing, and you already use patterns every day when you design. You’re thinking about a problem and all of a sudden a solution pops into your head. “Aha. I could put those things in a list.” “I’ll float that link on the right side of the header.” “I’ll write that in a bold headline, and put the details in a smaller line underneath.”

A pattern doesn’t need to have a name, and it doesn’t have to come from a book. A pattern is some design trick that is lying around in your head, and when the right problem rises up in front of your nose, the pattern pops into your mind as a solution. You know the feeling, right?

Here are a few off-hand examples from my own mental library:

You can probably fill a few pages with your own favorite patterns. They are as simple as this.

But there is also more to the story. Why is a certain pattern appropriate in this situation and not in that situation? What dictates a pattern’s fitness to a given problem? To answer that, think of each pattern as more than a possible solution in your bag of tricks. Each pattern is also a definition of a problem.

Let me show you what I mean. Here’s a pattern I use all the time:

In practice it often looks like these:

That’s what the pattern looks like and how I think of it. The ”problem” side of the pattern is made up of these forces:

• The user is in a process where they have uncommitted state (eg. they composed a comment on a blog but haven’t posted it yet.)
• Most users who reach this state will want to commit what they did and move forward.
• Some users, fewer than the others, will reach this state and decide they do not want to commit and move forward.
• Users who do not want to continue aren’t satisfied with getting up and walking away from the screen. They want to clear out the uncommitted state or do something else in the app.
• Users on the majority forward-moving path would be negatively impacted if they clicked on the wrong action.

These forces are the context that I had in my mind when I first used this design. Later, when I encountered those same set of forces again, I recalled the solution that I came up with earlier and how well it fit. A large button with a smaller adjacent link came to mind, it again fit the bill, and again reinforced the pattern.

This happens over and over as we design. Patterns entrench themselves in our mental library through this process of encountering a situation, designing a solution, recognizing the same situation again, and recalling and applying the earlier solution.

The forces don’t have to be explicit. I never wrote them down before this post. But being aware of the forces makes it possible to critically analyze why you are making a specific design choice and how well that choice fits with the situation.

Taking patterns off the pedestal and noticing them in your everyday work is empowering. You don’t have to think about whether a pattern is a ”real” pattern or not. A pattern doesn’t need to be written in a collection or formalized to be part of your design toolbox. Then once you start to notice your own common patterns, you can begin to analyze the forces behind them. When you are aware of the forces that motivate your decisions, you can be conscious of whether you are designing by habit (“this is what I always do here…”) or whether you are actually applying the most fitting solution to the problem at hand.

References:

1. On the interplay of forces and design solutions: Notes on the Synthesis of Form (Amazon)
2. My talk on the design process as the resolution of conflicting forces: http://vimeo.com/10875362
3. Christopher Alexander’s original book on patterns: A Pattern Language (Amazon)

I received an email the other day from a fellow asking for help defining a product management “philosophy” or “process” at his company. I wasn’t sure I would be able to help, but once I started typing a lot of information came out.

I’m reposting my response here in case it’s useful to other software product managers who are trying to define their role and improve their process.

What is product management?

“Managing the product” means deciding what we do to the product and then making it happen.

When you unpack that, it involves strategy (what is important to do?), resources (how much time can we spend on it?), managing development (what do we need to build in order to do it?), managing experience (how will it look and work, how does it integrate into what we already have?). And all of it with regard to the bottom line of the business. Given a strategy, resources we have, a user experience bar to uphold — given all that, what can we do and why is it worth doing?

Defining units of work

In order to manage this, we have to be able to break our ideas and efforts down into manageable projects. I try to find ways to define any effort in a < 2 week chunk. If there’s truly a lot to do, like a complicated new feature or a big change, I’ll try to break up the work into orthogonal or serial pieces that can be done in separate < 2 week chunks.

A core skill with defining units of work is being able to understand dependency in the design and code. What can we change without affecting other things? What can we change that creates the improvement we want while staying isolated within known boundaries?

In other words, you don’t want to start working on something and realize it opens cans of worms and affects everything else. You have to be able to draw a line around what you are doing and say “we will change this but not that.” For this, it is very helpful if you can think like a programmer. This is a good programmer’s expertise — the interdependence and interfaces between parts. If you aren’t a programmer, have a programmer with you when you try to define chunks of work so you can be secure about the boundaries on the code side.

Deciding what to do

I try to lead every decision with user experience. What is the user-facing situation we want to change? Or if the motivation isn’t because of a user benefit, but a pure business reason — what is the impact on the user, and how can we align incentives so this at minimum makes sense to the user? This is critical.

The other thing is … often in software the thing we think we want to do isn’t actually the right thing. We have to imagine what we want, or stakeholders imagine what they want, and then it all sounds good — until you actually build it and try it. So it is critical to be skeptical of your own ideas and lead with design. Mock ups, stub prototypes, etc, that give you some first-hand experience of what it’s like to use the new thing.

Design & development process

How can design lead the process? On my teams designers go as far as they can to build real working templates against a mock back-end and then the programmers connect the dots behind the scenes. This way we have the maximum confidence about what we are building before investing programmer time.

Once the process is started, and programmers are implementing, we don’t bite off too much at once. We want to design one thing, implement it, and then see it in action. The design -> program -> review cycle is critical and it works best when it is a small and tight cycle.

Throughout the design -> program -> review cycle, it’s important to focus on flows not individual screens. No interface or piece of software is in a vacuum. People got to it from somewhere else, trying to do something. And after they do it, they go somewhere else. The more you can think of terms of sequences of action instead of static elements, the better. A flow is a better review target than an element or screen.

On my projects, programmers and designers work on the same code-base. Both have the app running locally on their machines. This is critical in my view.

One more point on development process. While design leads, they aren’t immune to feedback from development. If the programmers say something is hard or annoying, that should be a factor weighing in the design decision. It’s not a hierarchy with design purely on top. Rather it’s a path-dependent process, where the two alternate feedback, but it starts with design and the final evaluation is on the side of customer experience.

Communication and management

I like to create a Basecamp project for each iteration. I cluster the tasks around reviewable targets. By “reviewable target” I mean, if we checked off all these things on the list, it would bring us to a point where we can evaluate the result.

For example, if you had a list of “programming” todos and a list of “design” todos, you never know when you are at a point for review. But if on the other hand you had one todo list for “signup form”, and it needed both design and implementation, when the items are all checked you can load the signup form and evaluate whether the work was done well or not, and where to go next.

I’ve had good success with a daily status message, where each person posts at the end of the day anything important that they accomplished. It is async, so you don’t waste time on a status meeting. And it gives a sense of accomplishment/celebration at the end of the day.

“Done”

One of the best words you can internalize is “satisfice“ — in other words, “done enough” given a certain goal. There is no absolute measure of “done.” It’s up to you to decide, because all projects can go on forever. The best way to determine when you are done is to again lead with design, where the function of design is to reach a solution to a problem. When the problem is no longer a big enough problem to matter, you are done.

Like when you have a headache. If you don’t take enough painkiller, it doesn’t get better. But if you take too much, not only is the headache gone, but you’ve gone past that and you’re floating up in the clouds. It’s easy to keep improving on something past the point of customer value.

I hope this overview touches on the many sides of product management and gives you a sense of the major themes that lead to good results.

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.

—

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

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.