Heads up! This page uses features your browser doesn't support. Try a modern browser like Firefox or Chrome for the best experience.

Cartoon. A figure stands next to another figure seated at a desk. The standing figure with hands on hips asks: So, how's the project coming? The seated figure looks nervously to a whiteboard covered in a mess of sticky notes labeled: To-Do. A thought bubble says: Ugh, how do I explain?

As the team gets oriented, they start to discover and track the tasks they need to do to build the project. It’s important at this early phase that they don’t create a master plan of parts that should come together in the 11th hour. If the team completes a lot of tasks but there’s no “one thing” to click on and try out, it’s hard to feel progress. A team can do a lot of work but feel insecure because they don’t have anything real to show for it yet. Lots of things are done but nothing is really done.

Instead they should aim to make something tangible and demoable early—in the first week or so. That requires integrating vertically on one small piece of the project instead of chipping away at the horizontal layers.

Integrating in one place

We can think of projects in two layers: front-end and back-end, design and code. While technically speaking there are more layers than this, these two are the primary integration challenge in most projects.

Suppose the project starts with a lot of design. The team could design a variety of screens and even implement them as templates or views. But until they’re wired to a backend, nothing does anything. The work remains hypothetical and speculative.

Illustration depicting the front-end and back-end as two discs lying flat. The front-end disc floats above and parallel to the back-end disc. The front-end disc is marked with dotted line boundaries and the regions inside the boundaries have checkmarks, suggesting surface area that is completed. Nothing is marked on the back-end disc below. At the right a label says: Nothing works.

Same with the backend. A lot of tasks could be checked off, but without any UI—what can you do with it? How do you judge if the work on a specific piece of business logic is really right without interacting with it?

Another illustration of the front and back end discs. This time the back-end disc also has surface area marked out as completed, but it doesn't line up the completed areas on the front end disc above. The illustration again is labeled: Nothing works.

What we want instead is to pick off a specific piece of the project to integrate on. Then when that’s done, the team has something tangible that they’ve proven to work (or not work and reconsider). Anyone can click through the interaction and see if the feature does what it should and if what it does is what they want.

Illustration showing the two discs lying directly on each other. One area is marked on the front-end disc and dotted lines coming down indicate the exact same area is also marked on the back end disc. This common area on both is shaded and marked complete. At the right, a label says: Something works!

Case study: Clients in projects

We built a feature in Basecamp 3 that allowed service firms to invite clients to their projects and share chosen documents, messages, or to-do lists with them. The concept, defined in the pitch, had a variety of moving parts:

The team had one designer and one programmer. After they got oriented and familiar with how the existing code worked, the designer chose the visibility toggle as the best place to integrate first. This was the most central piece of UI in the project. It’s the one that would appear in demo videos and the interaction customers would use most.

The designer didn’t make a pixel-perfect mockup. Instead, he experimented with different affordances and placements in the app’s HTML templates. Should the toggle be two radio buttons, a checkbox, or a custom button that changes state?

Meanwhile, the programmer wasn’t waiting around. He had enough guidance from the pitch to start spiking the access model.

As soon as the designer felt confident in the basic direction of the UI, he pinged the programmer and showed him the stubbed toggle. Stepping away from the access problem for a bit, the programmer wired the toggle enough so that it would appear on all the supported content types, change state when clicked, and save its state in the database.

At this point, the toggle didn’t actually change the visibility of the content. But it worked from the service firm’s point of view. The designer could click it, feel it, and judge how well it worked with live data on a staging server.

There was still more design work to do on the toggle. But the programmer didn’t need to be involved anymore. With the affordance wired up, the designer could continue to experiment with copy, placement, color, mobile view rendering, and more. Meanwhile, the programmer could get back to the access model or whatever else was most important to tackle next.

About three days after the start of the project, the designer demoed the working toggle to a manager. Their conversation led to a few more tweaks and then they were able to call the toggle “done.” One important piece of the project was designed, implemented, demoed, and settled. The team felt good about showing tangible progress. And the team and management both felt confidence in the project by seeing a working piece. By clicking through a core interaction early, they were able to validate that what they hoped would make sense in theory did indeed look right and make sense in practice.

This short example illustrates a few points about how the teams integrate over short periods to finish one piece of the project at a time.

Programmers don’t need to wait

Because the important moving parts were already defined in the shaping process, programmers don’t need to sit idle waiting for design when the project starts. There’s enough direction in the pitch for them to start working on back-end problems from the start. They won’t be able to take a piece of functionality to completion without knowing where it leads on the front-end, but there should be enough information in the pitch to inform foundational modeling decisions.

Affordances before pixel-perfect screens

Programmers don’t need a pixel-perfect design to start implementing. All they need are endpoints: input elements, buttons, places where stored data should appear. These affordances are the core of a user interface design.

Questions about font, color, spacing, and layout can be resolved after the raw affordances are in place and hooked up in code. Copywriting, basic affordances, and some wiring are all we need to try a live working version in the browser or on the device. Then we can answer the fundamental questions early: Does it make sense? Is it understandable? Does it do what we want?

That means the first interface a designer gives to a programmer can look very basic, like the example below. It’s more like a breadboard than a visual design or a polished mock-up.

Screenshot of a web browser. Some form fields, labels, and headers present an interface, but there is no navigation around them or visual styling. They float on a white field and are themselves very unstyled.

This screenshot is from a registration app for multi-day courses. The designer made it in HTML by hand. There’s barely any style — just enough visual hierarchy to feel confident that the layout is usable and amenable to future layers of styling.

While the design looks simple, a lot of decisions are reflected in it.

Visual styling is important in the end product, not in the early stages. The biggest uncertainties are about whether it will work, whether it will make sense, how long it’ll take to implement, etc. After the elements are wired up, they can be rearranged, restyled, and repainted without impacting the integration work that came before.

Program just enough for the next step

The same is true for back-end work. It doesn’t have to be all or nothing. Sometimes a designer just needs some scaffolding—a couple fields that save data or some code to navigate from one stubbed screen to another. Other times she needs to populate a variable in the template with a collection of real data so she can iterate on different displays (rows, columns, media boxes, etc) to find the best design.

The early back-end work can be strategically patchy. There might be a controller to render templates but no model. Or a controller and bits of a model with mock data but no support for creating or updating the data. Screens that aren’t wired yet could at least be connected with routes for navigating between them.

The point is to create a spirit of prototyping and piecewise enablement among the designers and programmers. Take turns layering in UI, code, and styling to the app. Step by step, click through the real working feature-in-progress to judge how it’s coming and what to do next.

Pick where to start

There are three criteria to think about when picking first piece to build and integrate.

First, it should be core. The Visibility Toggle was central to the “Clients in Projects” concept. Without it, the other work wouldn’t mean anything. Contrast that with a more peripheral aspect of the project, like the ability to rename a Client. Both are “required,” but one is more central and important to prove out first.

Second, it should be small. If the first piece of work isn’t small enough, there isn’t much benefit to carving it off. The point is to finish something meaningful in a few days and build momentum—to have something real to click on that establishes confidence. Figuring out how to implement Client Access was very core, but it wasn’t small. The programmer picked it first since it was so important, but it wasn’t the first integration priority for programming and design.

Third, it should be novel. If two parts of the project are both central and small, prefer the one that you’ve never done before. In the case study feature, the UI for adding clients to the project was largely the same as UI that already existed to add regular users. Starting on that would have moved the project forward, but it wouldn’t have eliminated much uncertainty. Starting with the Visibility Toggle boosted everyone’s confidence early because it proved a novel idea was going to work.

We built Basecamp to execute the techniques in this book. It puts all our project communication, task management, and documentation in one place where designers and programmers work seamlessly together. See How to Implement the Shape Up Method in Basecamp.