With the launch of Basecamp Mobile just a couple of weeks behind us, we wanted to take a look back at some of the design decisions we made along the way.

One of the first challenges was simply how to take the Basecamp design and make it work on a much smaller screen. It needed to look like Basecamp and be familiar to people who have been using the desktop version for years. We wanted it to perform like a native app but we didn’t want it to look like one, it was far more important that it looked like Basecamp. This was a big factor in the decision to avoid using one of the existing mobile Javascript UI frameworks.

Early inspiration: iOS

For the earliest mock-ups it was easy to rely on the excellent UI conventions of the iPhone; most of us are iPhone users at 37signals (as are many of our customers), we did a lot of testing on the devices, and frankly the UI is very good. It was a great place to start. That meant the first version had an iOS-like navigation bar at the top of the screen with the title of the screen in the center. A button on the left navigated up one level in the hierarchy (backward). A button on the right worked in the context of the current screen. This was pretty much stock from the iOS Human Interface Guidelines. Here is one of the very first screenshots of Basecamp Mobile:

First look at Basecamp Mobile

This early mock-up was just static HTML. We used the iPhone SDK simulator even at this stage to make it seem as real as possible.

Finding our own way

We continued with this design for some time but a few problems kept coming up. We’d used the item type instead of it’s title in the navigation bar because titles can be very long. So now we had two bars that both titled the screen, but in different ways. And even using all that space it still wasn’t clear where you were. Where does the back button go? Which project is this list in?

Header variations

After a few more iterations we knew something wasn’t right. We were trying too hard to squeeze our app into a navigation idea that wasn’t the right fit.

Starting over

Right about this time I happened to be in Chicago so I sat down with Ryan and Jason Fried to brainstorm some new ideas. We were sure that the iOS style navigation bar wasn’t going to work. We had to be able to show a lot more information than it was capable of—especially since titles were often much longer than the available space offered (usually just a word or two). Here are the pieces that needed to be included:

  1. Back button
  2. Title of the screen or item
  3. Name of the project
  4. Context actions (Add and Edit)
  5. Account theme (header color)

I went immediately to work quickly sketching a single header with more dense information.

Quick sketches
Several paper and Photoshop sketches

After we agreed on a direction from the sketches, I began impleming the new ideas into our app mock-up so we could click through it on our phones. A few iterations later we had something. The new direction was more clear and managed to look more like the desktop version of Basecamp.

A new direction

I left Chicago with a better navigation concept in place but there were several things that still bothered me. The header was different on every screen; different height, different buttons, different hierarchy, and just plain awkward looking in some cases. It took up more space. The buttons varied in size and location from screen to screen. The entire header needed to be tighter, more structured, and give us the flexibility to label the buttons as we needed without it looking bad.

Starting over again

When I got back to my home office I took another look at it. I felt like we’d found the right problem but that the solution had still eluded us. One idea was to let the header be just that, headings for the current view. We could comfortably show the project, company, and screen title without having to squeeze in buttons if we move them to their own bar.

The result was a action bar fixed at the bottom of the screen closer to where physical buttons appear on the phone hardware. The buttons loosely tied to the back, add and edit actions added some visual interest and the colors helped tie similar actions together between screens. There were some nice improvements here: The back button was always in the same place; the header was more complete and less crowded. There were also some new problems: The bottom bar was going to be difficult to implement, technically, and the colored buttons were visually overwhelming.

Action bar concept

I shared this concept with the rest of the team, who confirmed what I was thinking. But I had another idea that I was working on at the same time. This idea had two major elements: a large (thumb-sized) back button that was clear and in the same place on every screen; a tab bar that split the screen between its actions.

Tabs concept

This finally felt right. It was clearer, had more visual style, and the tabs managed to unite the header and content area. Plus, they visually recalled the tabs in the desktop Basecamp design. The new design managed to break out of the iPhone mold while feeling even more like Basecamp. With a little polish we had a winner.

Final design
The final design in several color themes”

Final thoughts

I can’t say enough how important it is to let the process of design take your project where it will. We couldn’t have predicted how this app would look when it started. Nor would the app be as strong if we’d locked down the design after the first version. Continuing to think about your design as it gets more real helps give you clarity and lets you confirm or reject your earlier ideas. As you go from sketches to mock-ups to prototype to real data and conditions the solution solidifies naturally. Each step reveals surprises and new problems. We hope this look at the decisions we made helps you to look at your own design process with fresh eyes. We’d love to hear about your process.