Web App Masters: Backstage at 37signals

by April 28, 2010

At the UIE Web App Masters Tour in Minneapolis MN, 37signals founder, Jason Fried described how 37signals solves design problems and collaborates by showing four days worth of chat transcripts about an ongoing redesign project at the company.

  • The overview screen in the 37signals application Basecamp has been around for four years. 37signals tried to redesign it once and got a lot of pushback for their users, so they pulled back. That was quite uncharacteristic for them so Jason hopes they never need to do that again.
  • Before deciding to redesign the Basecamp overview screen, 37signals gathered feedback from a survey over a couple months. In the survey, people said they do not have a good feel for what is going on in their projects. When looking at customer surveys, 37signals does not implement product ideas from users but instead tries to get an understanding of the problems people are having.
  • The current Basecamp overview page is a listing of what happened on a project per day. Everything is organized by day: to-dos, comments, files upload, etc. It’s all useful data but it is hard to get a sense of what happened in a summary view. Things are grouped by time and not type. This was the impetus for the redesign and all the direction the team was given to get started.

Insights from the 37signals Process

  • 37signals does not use documentation, schematics, or traditional user testing. They try to design the real thing right away and iterate until they get what they want.
  • It’s important for a manager or creative director to know what is important at any given time. Up front, you need to provide feedback on the big picture not on the details. Once you are going in the right direction, then it is time to focus on the details.
  • It’s very easy to get stuck on things that don’t matter. Don’t do it. Try to get the big picture ideas in place first then work through the rest.
  • Instead of talking too much about feedback, one of the best ways to respond to a design is with another design. This response could just be a simple sketch. Working back and forth with pictures helps to remove misinterpretation. If you spend too much time talking about something, you need an image to ground the conversation.
  • When you redesign something, you don’t have to change everything. What is the least amount you can change in a design to have the biggest effective difference? Look for small but impactful changes.
  • Typically, 37signals does not try to change 15-20 things at once. They make one change and upload a new screen shot to discuss. This allows them to control everything but the one thing they are changing. When you make multiple changes at a time, it is hard to see what worked and what didn’t. Better to go one thing at a time. When people go away for a week and work on stuff that does not matter, that’s time lost.
  • Don’t base the design on something you can’t do. If you can’t build something now –remove it from the design.
  • Always try to use real information in your designs. Use real numbers, data, and names so you can think through the way a design will support actual content. A variety of data can help work through potential issues.
  • At first you are in the excited phase with a new design. But then you get used to it and start to look at it critically again. This is ok –it helps bring up additional issues.
  • If you build things for other people, you are judging everything by proxy. “will other people like this?”. Solving your own problems allows you to effectively judge them. Design for yourself if you can.
  • 37signals prefers to kick off projects with loose requirements because they are not smart enough to know exactly how things will go. Allowing the project to evolve yields more insights as things progress.
  • 37signals currently has 3 teams: 2 programmers, 1 designer. Each team breaks up and reforms every two months. They always divide work into two week increments. Even big initiatives can be broken down into smaller tasks.