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

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 that I can imagine that 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 that 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 that 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 that a piece of the product is ready to review and mark ”done.” It feels great to know that 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.

I want to stress that 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 almost see territories on the map being conquered and resolved. 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 that checking off a set of contingencies means that 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.

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.