You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy .

Signal vs. Noise: Design

Our Most Recent Posts on Design


I love Fantastical but missed having a quick way to find out today’s date, a feature the native iOS calendar app provides with a special app icon that changes each day. To work around this Fantastical offers a clever hack: an option to display the current date as a badge on the app icon.

Michael Berger on Mar 12 2013 20 comments

Since copywriting is interface design, you can do an awful lot of great design in a text editor. Don’t worry about where things will go, or how they will fit. Worry about explaining it clearly and then build the rest of the interface around that explanation.

Jason Fried on Mar 7 2013 15 comments

A loose rant on motivation and evaluation

Jason Fried
Jason Fried wrote this on 16 comments

In our industry, you’ll often hear people say things like “if someone can’t figure it out in 10 seconds then they’re gone.” Or “I checked out the site and I couldn’t figure out what they did so I left. Terrible design.” Or “if it takes more than a couple sentences to explain it then it’s not simple enough.” Or “too much to read!” Or “there are too many fields on this form!” Or “there are too many steps in this process.”

I’ve said some of these things in the past, so I understand the knee-jerk impulse that lead to these sorts of reactions.

However, something’s usually missing from these assessments of the situation: The actual customer’s motivation. How motivated is the customer to solve their problem? What are they here for?

If you’re just evaluating something purely on a design-principles basis, then it’s easy to be binary about it. Good, bad. Too slow, not clear enough, confusing, whatever.

But it’s lazy to evaluate things that way – and trust me, I know, I’ve been lazy about it in the past. I’ve just recently come to remember that you have to factor in motivation.

How motivated is the customer? If your motivation is to evaluate a design, how can you accurately comment on whether or not it’s good or bad unless you understand the customer’s motivation? Their motivation isn’t always to get in and get out as fast as possible.

Customers come to learn something, research something, consider something, buy something. If they are motivated, they may not mind spending five minutes reading. They want to read, they want to know. They’re OK investing their time to find something out if they really care about the answer.

For example, while a longer form – one that a designer might cringe at – might lead to fewer trial signups, it might also lead to higher-quality, more qualified leads. A longer form could weed out the people who are just poking around from the people who are really motivated to buy.

Is clearer better? Yes. Is brevity better? Not always. Is speed important? It depends. How much detail is required? Just enough? Should you make it easier for people to get better answers sooner? Yes. But that doesn’t mean every question demands a 10 second answer and that doesn’t mean every form needs to be three fields or less.


Graphic design is visual communication. Can you design a better graphic that communicates NYC “sugary beverage” law changes? (via Charles Go)


My green thumb is often challenged by the grocery store orchid. I never quite know how much water to give these things. So I was really happy to see this solution recently. The orchid comes with a cup! How much water? This much water. Nicely done.

Jason Fried on Mar 5 2013 11 comments

Learning Rails made me a better designer

Jonas Downey
Jonas Downey wrote this on 38 comments

At 37signals, our designers write code. Not just HTML and CSS — Ruby and JavaScript too. We can all get reasonably far implementing an idea before calling in a programmer for help.

I was lucky to get a crash course in Rails when production for the new Basecamp was kicking into high gear. But even after a year in the trenches, I wasn’t confident I was Doing It Right™. So last fall I took the Rails for Designers class at The Starter League. Obviously, the class helped me get better at programming. I wasn’t expecting it to transform my design process — yet that’s exactly what happened.

Before you can walk, you have to stand on your own feet.

An interface isn’t just a series of static screens pasted together. It’s a flow, with inputs and outputs. You can’t truly evaluate an interface until you can use it, and you can’t use it until you build it. Anything less than the real thing is a fuzzy approximation.

It’s fine to bring in a programmer when you’re confident that your idea is worth building, but what if you’re not so sure? Now you’ve used someone else’s time and mental energy to make something that might hit the dumpster. That stinks.

This hit home recently when we started working on a new app. Before, we’d make a static mockup or build a few working pieces and then call in a programmer assist. This time, we’ve been able to stay in the prototype phase much longer – almost 2 months – without having to use up a programmer’s time to test concepts and explore ideas. Basic programming knowledge lets us dance without a partner.

You don’t have to be a code master. I am most definitely not. If you can just make things functional, that’s enough to evaluate and a huge head start for a real programmer to make it great.

Are you a designer who learned to program? How did it change your process? Let’s hear it in the comments.

The Design Roulette

Ryan wrote this on 7 comments

There are sites, books, feeds, magazines, and movies about “design.” Thousands of people call themselves “designers.”
But have you noticed … “design” never means the same thing?
When I click on some “design” link, I feel like I’m spinning a roulette wheel. Will it be about:

  • Grids and Helvetica?
  • Typography?
  • How to balance trade-offs?
  • Applying engineering capability to a non-engineering problem?
  • Gradients?
  • Producing emotions?
  • Solving a business problem?
  • Posters?
  • Products?

I just saw a cool link on Hacker News.

Screenshot of the color picker

What is it?

  • An interesting implementation because it’s made in HTML5, not Flash.
  • A cool style because it doesn’t look like other pickers.
  • A novel solution to a problem because the large scale gives access to values you can’t reach in a traditional picker.
  • An emotional experience because the immersive colorfield evokes purple twilights and blue-yellow sunrises.

Design decisions: Projects on Basecamp for iPhone

Jason Z.
Jason Z. wrote this on 6 comments

Designing the mobile version of an existing app is about so much more than screen size.

The fundamental concept of the new Basecamp is this: a project on a single page. Projects resemble a nicely organized paper document with wide margins, familiar proportions and plenty of white-space. In a glance you can see what’s happened in the project, what’s left to be done, and any relevant files. You can almost imagine peeling the sheet off the screen and handing it to a co-worker to get them up to speed. It’s an iconic design.

We knew that this design would be instrumental in making Basecamp for iPhone feel like Basecamp so it’s no surprise that we attempted a very literal reproduction in an early version of the app.

It’s all here: the clean, white sheet topped with the project’s name followed by sections with snapshots of the latest Discussions, To-dos, Files, etc. A virtual clone in smaller package. We were pretty happy with this mini-me design for awhile, but the story doesn’t start here.


Reminder: Design is still about words

Mig Reyes
Mig Reyes wrote this on 31 comments

Click away from the pen tool…

Put down your Pantone book…

Stop rearranging your layers…

Close your stock texture folder…

Log out of your Dribbble…

And god dammit, hug your copywriter…

Designing for the web is still about words.