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

Evaluating a redesign

Jason Fried
Jason Fried wrote this on 14 comments

When evaluating a redesign, your first instinct is to compare the new design to the old design. But don’t do that.

The first step is to understand what you’re evaluating. If you just put the new design up against the old design, and compare the two, the old design will strongly influence your evaluation of the new design.

This is OK if nothing’s changed since the original design was launched. But it’s likely a lot has changed since then – especially if many months or years have passed.

Maybe there are new insights, maybe there’s new data, maybe there’s a new goal, maybe there’s a new hunch, or maybe there’s a whole new strategy at play. Maybe “make it readable” was important 3 years ago, while “help people see things they couldn’t see before” is more important today. Or maybe it’s both now.

But if the old design sets the tone about what’s important, then you may be losing out on an opportunity to make a significant leap forward. A design should never set the tone – ideas should set the tone. Ideas are independent of the design.

So, when evaluating a redesign you have to know what you’re looking for, not just what you’re looking at. How the new design compares to the old may be the least important thing to consider.

It’s a subtle thing, but it can make all the difference.

Behind the scenes: Designing the REMOTE book cover

Jamie wrote this on 13 comments

Many months ago Jason Fried asked me to think about a cover idea for REMOTE, a new book that he and David Heinemeier Hansson were writing.
I thought REWORK, their previous book, had an iconic cover. The sole image of crumpled paper alluded to “back to the drawing board.” It’s a great cover.

I decided early on to keep the main color scheme for the REMOTE cover: red, black, and white. I liked how the titles “REMOTE” and “REWORK” read like they’re part of a series. It made sense for them to have some relationship. I also wanted the book cover to be white. There was no meaning other than I wanted REMOTE to feel related but be visually different.
My first two covers were designed to be directly related to REWORK: title centered top with an image in the middle.

I also thought it’d be fun to try something similar in attitude to the crumpled paper.

During this time, I was reading a book by David Byrne called How Music Works. Like all (most?) designers, I’m always filing away graphics, signage, type I see every day into my brain somewhere. I appreciated the boldness of the cover design (still do).

Could I make REMOTE typography that communicates remote? I imagined an unplugged electrical cord. So, I drew and scanned one spelling out the word “Remote”.

Then I traced it in Adobe Illustrator and set type around it.

I still like this cover idea.

Then I thought about not alluding to any physical objects. Let’s not hold on to the crumpled paper. Let’s ditch cut neckties and electrical cords. Could I communicate “remote” with type in an abstract way?

The “O” in REMOTE had a lot of potential. The perfect circle “O” (set in Futura) could act as an anchor.

I uploaded that to Basecamp and 5 minutes later Jason Fried texts me: “You are a genius.” Actually, he didn’t say that. I can’t remember what he said because I don’t have his text anymore. He liked it.
We showed the cover to the publisher and they weren’t crazy about it. The publisher showed the cover to bookseller buyers and they didn’t like it. All the while, Jason and David kept pushing my cover design.

After a few tweaks and some uncertainty we had a cover for REMOTE. I’m honored that Jason and David advocated for my design. Thanks to Crown Business for going with the cover.
Pick up a copy of REMOTE if you don’t have it yet. I designed the cover.

Try, try again

Mig Reyes
Mig Reyes wrote this on 5 comments

I wonder how many people stop themselves short of making something new in fear of it failing.

Failure, sigh. It’s (still) overrated, and it’s given everyone the wrong lens to look at their craft. Why dissect post-mortem when we can imagine possibility? Why review mistakes when we can consider play?

The makers of our world would be better off mimicking scientists with their work. Harp on deliberate practice. Reinvent their processes daily. Share every discovery. And most importantly, try new things often.
All of a sudden punting on ideas—no matter how silly—seem like the real mistake. They’re lessons you didn’t learn, skills you didn’t exercise.
When everything’s an experiment, you shed the fear that comes with trying new things. And that sounds like a better way to grow and learn. Plus, no one has to even mention the f-word.

On Writing Interfaces Well

Jonas Downey
Jonas Downey wrote this on 28 comments

Interface designers like to talk shop about visual styling: colors, icons, type, gradients, shadows, spacing. If it can be tweaked in Photoshop, there’s probably a lengthy Twitter debate about it.

Aesthetics are debatable, but writing is essential. Peel away the layers of styling and you’ll be left with words. Writing is the meat of a design, and it’s one of the hardest things to get right.

So why don’t designers talk about writing more often? I think there are three reasons:

  1. It’s not sexy. 15 edits of a single sentence don’t make for a flashy portfolio piece (although I’d love to see more portfolios like that.)
  2. We’re all pretty bad at it. Writing is difficult, and most of us probably weren’t trained to do it well.
  3. We think people don’t read. Jakob Nielsen’s research showed that people don’t read on the web, and on average, they’ll read only 20% of the words on a page.

As a result, designers undervalue text. We cut copywriting back to the bare minimum. Sometimes we exclude important details to keep things short. We overload interfaces with obscure icons, invisible gestures, and no explanatory text at all. Instead of “writing” or “copy” we even call it something generic: “content.” The measly text we have left is often a low quality afterthought.

Who cares, right? People don’t read anyway. Well, maybe they don’t read because they know what they want, and this junky writing is a waste of their time. How can we improve?

Write better words, not less words.

Writing for interfaces isn’t just about brevity. Brevity is a luxury that you can occasionally get away with. It may take quite a few words to explain what’s happening, and that’s fine — a paragraph of clear instructions is better than a vague sentence. (Though a clear sentence is better than both of those.)

Here’s an example. I worked on the recurring events feature for the Basecamp calendar, so you can schedule an event that happens more than once. When you edit a recurring event, Basecamp asks what you intended to do. Did you want to change just that one event? Or subsequent events too? Maybe you didn’t know this event repeated, so you might be surprised at the question.

At first, I wrote a concise, robotic version of this dialog:

You're moving a repeating event. Which events to do you want to update?

* Only this event
* All events in the series
* Never mind

Good enough? Nope. What’s a “series”? What does any of this mean? Exactly what’s going to change? There’s no way to know. This text makes too many assumptions.

After a round of feedback, I tried a second version:

You're moving an event that repeats. Do you want to move all future versions?

* Move all future versions.
* Move this one only.
* Never mind, don't move anything.

This is a little better. Now we know that we’re only concerned with future versions. But this copy still feels repetitive and mechanical. After a bit more feedback, we ended here:

You're moving a repeating event. Do you want to move all future versions of this event too?

* Yes, move all future versions.
* No, just move this one and keep the others where they were.
* Never mind, don't move anything.

We added a lot of words! But now the choices are clear, and the tone of this text feels more natural and friendly.

Write for your friend.

Most of us learned to write in the Official Style, in which your message is mostly obfuscated by nouns, buzzwords, and other garbage. It’s the writing you’d use to meet the 1,000-words length requirement on a term paper.

That’s the opposite of how you should write copy for your website or app (or anything, really.) Instead, write like you’re talking to a friend who needs help. Be casual, positive, and encouraging. If you wouldn’t naturally say it out loud, it’s not right. Keep working until it feels natural.

Edit relentlessly.

Good writing is good editing. Remember that people will only read your words when they’re motivated, so make it worth their while. Say everything that needs to be said, but no more. Set a high standard for yourself — would you want to take the time to read this? Edit, edit, and edit again until you nail it.

We call this “wordsmithing,” and we do it a lot. Just look at some of Basecamp’s commits:

Quality writing is hard work that takes time, but it’s worth it. Accumulated across your entire website or app, consistently good writing will help reduce your users’ confusion, and your customer support burden to boot.

Forget about Jakob’s 20% rule. Make your writing 100% worth reading, and people will read it.

Design Decisions: Basecamp for iPhone iOS 7

Jason Z.
Jason Z. wrote this on 8 comments

Today iOS 7 arrived and along with it our freshly updated Basecamp for iPhone. Perhaps there were some existing apps that just worked on the beta releases of iOS 7 but Basecamp wasn’t among them. And while we knew some under-the-hood changes would be required to support the new system, we didn’t anticipate changes to the design or how much we’d like them.
Here’s a quick before and after look at what’s changed.

Navigation bar

Basecamp was already using a tinted stock navbar so updating to iOS 7’s aesthetic meant embracing the flatter look and borderless “Projects” button. Tinting the button green was a nice opportunity to add some personality and expand our already-in-use color for tap highlights. We weren’t happy with the default opacity and blur effects when scrolling content up under the navbar so we created a custom background image with a very small amount of translucency. It’s a similar but subtler effect.

Page stacking

Arguably the most unique part of Basecamp for iPhone is the page stacking navigation. As you tap through projects, new sheets stack on top of the one you were looking at before. Getting back to where you were is simply a matter of swiping the sheets off the top of the stack. It’s a unique and intrinsic part of Basecamp.

In the iOS 6 app stacked sheets overlapped the navigation bar but that design didn’t work with the way content now scrolls underneath the navbar and status bar in iOS 7. Updating the design so that sheets tucked under the navbar felt like a compromise at first glance but we’ve come to realize that the page stacking metaphor is still intact—with the added benefit that you can now access the project menu anytime and jump to another section without first dismissing the stack.


Proxima Nova is a strong part of Basecamp’s identity so there was no chance we were going to switch to iOS 7’s default Helvetica Neue, but that’s not to say we weren’t influenced by iOS 7’s lighter sensibilities. In general, the system seems to avoid multi-facet contrast by tending, for example, to rely on just type size or color when iOS 6 would have created contrast with size and color and weight. The lack of that heavy navbar, in particular, seemed to free us from the bolds we used on the project menu. Basecamp is improved by embracing these cues from the OS.

App icon

The new icon designs for Apple’s built-in apps might be the most discussed change in iOS 7. While we didn’t attempt to flatten the artwork or brighten the colors, we did enlarge Basecamp’s logo inside the icon bounds. The larger logo looks better inside the new rounded rectangle radius and feels more at scale with the built-in app icons—it just reads better. A very small change that makes Basecamp feel more at home on the new OS.

We’re still getting cozy with Apple’s newest OS, but right now everything feels fresh, light and new. The newly updated Basecamp for iPhone was released today alongside iOS 7. Be sure to get the latest version when you upgrade or when your shiny iPhone 5s/5c arrives on Friday!

Download on the App Store

What I cannot create, I do not understand.

Richard Feynman
Travis Jeffery on Jul 31 2013 2 comments

[On Apple’s integrated organizational structure]

Normally, in well-functioning markets, vertical integration is suboptimal. However, if transaction costs in the vertical chain outweigh the losses due the inefficiencies of being vertically integrated, then vertical integration could be the correct course of action.

Apple thinks the exact same way, but not about monetary cost; instead, the transaction costs they consider are the tax that modularization places on the user experience, and it is a cost they are not willing to bear.

A design has to start with some initial conditions, and then adapt to the boundary conditions – the conditions it encounters as it evolves. This can only happen through recursion, which is how our design achieves adaptive evolution and a much better “fit” with the problem. We might have a very good intuition of what the design has to embody – Steve Jobs, for instance, was famous for his intuition of the final qualities a design needed – but then large teams of people had to refine that initial vision and bring iterations to him to evaluate. He was setting the initial conditions (what he wanted the devices to be able to do for people), as they were adapting to the boundary conditions.

Michael Mehaffy and Nikos Salingaros in Unified Architectural Theory: Form, Language, Complexity. A companion to Christopher Alexander’s Nature of Order, Book 1

Designing App Store “screenshots”

Travis Jeffery
Travis Jeffery wrote this on 18 comments

Hey iOS developers, App Store “screenshots” don’t actually have to be screenshots and they can communicate more than just how your apps looks.

They can communicate:

  • Who you are, how hard you worked, and prerequisites to using your app…

  • Your app’s job…
  • How to use your app…

As an aside: keep in mind that these images will be seen outside of the App Store too, such as in Twitter cards…

What’s cool about these screenshots? They’re interesting—i.e. not boring lists! They communicate explicity, often using words. It’s cool seeing the apps from the perspective of being on a phone and in someone’s hand. They use colors outside of the typical app color pallete. They convince me that these apps will do the job. Most important, they convince me that the makers of these apps care.
The apps listed above, and other good examples:

Bad Rap

Jamie wrote this on 32 comments

I’m tired of hearing “Android seems cool, but the apps just don’t have that same polish as iOS ones.” Yes, there are duds on Google Play (their App Store). But there are duds in Apple’s App Store too. Here are some Android apps I’ve been using that feel “as good as iOS”

Google Music. Google Music’s All Access (their new all you can eat music subscription service) is really nice. I love how my uploaded music lives in the same Library as their store’s music. Radio feature is great. Search, of course, is pretty good too.

Flickr. They made a splash last week with their web app redesign. The new Android app design brings it up to the same level as their iOS app. It’s very nice.

Pocket Casts. When I’m not using Google Music I’m using Pocket Casts. If you like listening to Neil deGrasse Tyson’s voice, this is the app for you.

Press. I’m an RSS guy. I know that’s not cool anymore. I’m sad about Google Reader. I use Press every day to catch up on interesting stories across the web. Really nice app.

DashClock Widget. Android’s nice because you can run apps on the lock screen. DashClock gives me information without having to drill into apps.