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

Drawing Trouble

Nate Otto
Nate Otto wrote this on 13 comments

One of the fun aspects of illustrating for the new marketing site is getting assignments from Jamie, Jason, and Mig. One of my favorite briefs I got was “can you illustrate browser trouble?”

Upon getting art requests, I usually search to see if there’s a standardized image for the concept. In this case I didn’t find any imagery that rose to the level of iconic, or was particularly interesting or clear. I opted to start from scratch.

Hmmm, browser trouble

Broken windows, bugs, injuries, cracked screens, dizzy people? I drew a page of visual brainstorms and posted it on our Basecamp project.

Whoever assigns me a drawing—in this case, Jamie—reviews my explorations and then ask me to flesh out one of the directions. Jamie liked the guy with the computer head and suggested that there be a browser window with a frown face.

I drew up another page with color.

With that, Jamie got back to me with “Awesome.”

I waited to see how the image would be implemented. Working with the Basecamp design team is great for me because I’m not particularly strong in Photoshop or Illustrator—those guys are all ninjas. I like to draw, and that is how my time is spent most efficiently.

Usually I have no idea how the images are going to be used until they are implemented live on the website, which is fine by me. I like the surprise of finding a fully rendered web page with my drawings.

Hopefully it is a page you will never have to find.

Yelp's nice settings toggle

Jamie wrote this on 5 comments

Yelp updated their Privacy Policy so now businesses can get some insight on their customers. The nice thing is Yelp gives you a preview of how your information would appear to these businesses.

You can Change Privacy Settings to toggle between how much info you want to reveal. As a Yelp user I’m not passive in this. I’m given a choice. I thought this was a pretty cool interaction—a nicely done modal.

Join our team: We're hiring a product designer.

Jason Fried
Jason Fried wrote this on Discuss

We’re looking to add another product designer to our team! We don’t hire for this position often, so we really savor moments like these. We’re eagerly anticipating hearing from you.

Besides design, your job is to make an undeniably positive impact on our company, our culture, our products, and our customers. As long as you make your best effort, and you love to learn, we will do everything we can to support you creatively and help you do the best work of your life.

Product designers at Basecamp are always working on different things. You may be working on polishing up an existing feature, pitching and designing something brand new, or fundamentally rethinking how we do something. You could be working on the web or you could be exploring designs and interactions for a native mobile app. Projects at Basecamp always start with design, so you’ll constantly have the opportunity to lead us in new directions. Challenge us! Push us! Be original and show us the way!

Besides having great visual taste, talent, and the right sensibilities, you must write well-structured HTML/CSS. Basic Javascript or Rails skills are a plus, but not required. Experience designing for iOS and Android is also a plus. Great writing skills are required.

We are not looking for someone who’s already expert in everything they do. We’re looking for someone great who demonstrates the interest, drive, and desire to keep learning new things and continually get better.

At Basecamp you’ll be working with great people. Friendly, talented, original folks from dozens of cities around the world. The people who work here have a wide variety of interests and interesting life experiences. You’ll have a chance to learn from some of the best people you’ve ever met. And we’ll get to learn from you. We’d love for you be part of our patchwork.

Working as a product designer at Basecamp is a unique opportunity. We have a small team, so you won’t be one of dozens. You’ll be one of a few, so your impact will be felt inside and outside the company. You’ll be working on a product that is used by millions of people. You will help drive us in new directions. You’ll help us see things we haven’t seen before, consider things we’ve never considered before, and bring fresh perspective to our team. Brighten us up and put a big smile on our customers’ faces.

You love to write, too. You understand that copywriting is design. The words matter as much as the pixels. Great visuals with weak words are poor designs. You should care about how things are phrased as much as you care about how they look.

We’re open to hiring the best person no matter where they are. If you’re in Chicago we have an open desk for you in our office. But more than half of our company works remotely all over the world, so you’re welcome to be part of the team no matter where you live. If you do want to relocate to Chicago we’re open to that as well.

How to apply

Send relevant work samples, and anything else that will make you stand out, to Extra effort and personal touches will be looked upon favorably. Show us how much you want this job and not just any job. Please include [DESIGN] in the subject of the email.

It doesn’t matter where you went to school, or if you even graduated. It doesn’t matter if this is your first job or your fifth. Doing great work and being driven to improve yourself and everything you touch is what matters.

If we think you’ll be a good fit, we’ll be back in touch with step two of the application process.

Google Play Banner Design

Jamie wrote this on 3 comments

Apple provides a nice “Smart App Banner” hook for developers to promote their iOS apps from within their web apps. Unfortunately Google doesn’t have anything like this for the Play Store. Now that we have Basecamp for Android, we want to promote it to customers using Basecamp on their phone browsers.
Thanks to GitHub there are a few nice solutions:

These combine both iOS and Google Play designs which we didn’t really need. In the end we rolled our own solution, but I based the banner design on Vitaly Glibin’s Smart App Banner.

I uploaded a working version of the HTML to GitHub. Please feel free to use this design to promote your apps in Google Play. Thanks again to Vitaly’s Smart App Banner for the inspiration.
And if you’re an Android user get the Basecamp app on Google Play!


The 3 1/2” floppy disk as the go-to save icon gets a lot of play, but I don’t think enough attention is paid to the venerable trash can icon.

First of all, trash cans never looked like this while I was growing up in Denmark — I only knew what it was from American TV. Second, I don’t think there are any of these left even in the US.


Guess what these Google domain icons do. I’ll go first: Send a locksmith, Start a party, Call a handyman, Jump out the window, Put on your seatbelt, Use a lifeline, Start the machine.

The feature that almost wasn’t

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 9 comments

It took more than a year and three distinct attempts to get Google Docs in Basecamp ... and still, the damn thing almost didn’t get built. Why was it so hard?

We knew we needed it. Integration with Google Docs was a super-popular feature request, and usage in general is on the rise. Since Basecamp is a repository for everything project-related, it made sense to show the same love to Google Docs we show to any other type of file you can store in a Basecamp project.

Problem was, we don’t really use Google Docs ourselves. And we’re kind of notorious for scratching our own itch and not building shit we don’t need. It’s absolutely the exception that we would create a feature we didn’t plan on using. (For years, to-dos in Basecamp Classic didn’t have due dates, because we just work on things until they’re shippable. It wasn’t until enough customers hollered at us that we eventually added them.)

“We know tons of our customers use Google Docs; they have to,” says Jason Z. “Everybody’s using Google Docs. So we know it’s useful, we know people are asking for it all the time. There just comes a point where we have to figure it out.”

Shortly after launching the new Basecamp in March 2012, a small team explored what it would take to link to Google Docs from Basecamp. “We started with a little experiment to see whether the tools Google provides are enough to do basic integration,” said Jeremy, the programmer on that first spike. The goal was to be able to “pick a file from Google without having to commit to deep integration that changes the way Basecamp works.”

Google’s file picker made integrating with Google Docs easy, but rendered switching between accounts (if you’re signed in as one user and need to sign in as someone else) nigh on impossible. And we got hung up on what to do about permissions: Our choices seemed to be either allowing anyone who had the link to edit the document, or letting Google handle permissions and suffer the nasty flow and UI that resulted (more on that later).

With the account switching problem, our choices were to wait for Google to improve their tools, or scrap that and find some other way to integrate — i.e., roll up our sleeves and build our own picker. “That led to a waiting game,” Jeremy recalled: “if Google’s own tools got good enough that we could use them, then we’d have an easier time integrating.” So we punted.

Nearly a year later, a different group took a second look. While there still wasn’t a straightforward path for switching accounts, Javan experimented with a ton of different parameters and landed on treating authentication as a separate, first step to lead into the file picker, using Google’s JavaScript client.

What a Basecamp user sees before signing into Google
When a user is signed into a different Google account, they can sign out and choose which account to link to Basecamp.

Managing the two steps separately gave us the flexibility we needed to resolve the account switching issue, but the permissions demon was still rearing its ugly head. We punted again until we’d have more time to explore it.

Each time we felt like we were getting close, we’d reach the same stalemate. No one knew which of the two options for handling permissions was the lesser of two evils:

  1. Allow anyone with the link to view the document. This route would have meant sharing a Google Doc in Basecamp = changing its permissions so anyone with the link could view and change it. Other tools handle permissions this way; it makes things pretty easy and keeps the UI clean. But it creates a pretty gnarly security concern, in that there’s no way to revoke access later. People no longer employed at an organization might be removed from its Basecamp account, but still have access to proprietary information stored in Google Docs. Or users might share the link with outsiders who could then access and edit the document anonymously. No bueno.
  2. Let Google be the gatekeeper. When permissions are set within the Google account and Basecamp doesn’t mess with them, we get to wash our hands of security concerns. Convenient for us! But it passes this potential morass of access seeking and granting onto our users: The viewer has to be signed into Google, and they need permission to view the document to see the preview in Basecamp. If they don’t have permission, they can request it through Basecamp. They’ll then be directed to a Google page, and from there, the request is emailed to the Google Doc’s owner. When the owner grants access to the document, Google sends an automated email to the viewer with a link to view it. “A lot of us were feeling like this leads to a pretty crappy experience,” Javan says, “because you click on the doc and then you hit this brick wall.”
Step eleventy-bajillion-and-four in trying to preview a Google Doc in Basecamp that you haven’t been granted access to

“I was worried that people wouldn’t understand that, because I didn’t understand it,” recalls Ann from QA. “I did an experiment with the support team where I shared a Google Doc with them … I got all kinds of requests to view the document, because I hadn’t given them permission yet. I was afraid that oh my God, every customer was going to see that.” Adding a private file to a Basecamp project with 150 people on it might generate 150 email requests for access to the file. That was too big of a burden to pass along to customers.

The temptation was to punt a third time — only that was no longer an option. “We decided very clearly that if we don’t do it this time, if we don’t figure this out, we’re basically saying that Basecamp is not ever going to have this,” Jason Z. says. “Because why would we take a fourth attempt? That would be ridiculous.”

The pressure to “ship or get off the pot” led the team to explore other possibilities, like building a folder system that would copy Google Docs into a Basecamp project folder on Google Drive, or using’s Google Docs integration. We finally started to wonder whether the people who wanted Google Docs in Basecamp might already have the permissions thing dialed in. Jeremy chimed in at that point:

Companies switch to Google Apps from company Exchange email and central network fileservers. They “go Google.” Everyone at work is on Google, signed in, and has access to email, drive, calendar, contacts, etc. Google Apps recommends default sharing settings that are a lot like having a old-school central fileserver: newly created files are visible to others by default. There’s no sharing step or permissions-request dance: This is a golden path. It’s well-integrated and it’s the default when a company goes Google.

That perspective alleviated a lot of the trepidation we had about what users would see when they clicked on a Google Doc — the hope was that if people were already using Google Docs at work, they can probably already access all the links they need to be able to access by default. The access nightmare we envisioned wouldn’t occur if companies’ Google Apps admins were already setting up good defaults, the way Google recommends.

We still weren’t 100 percent convinced we had it right, but it felt good enough for v.1 — to be hands-off, and let the people who use it figure it out (with help, of course). “It’s funny how long the project went on, and in the end, it’s almost simpler than where we started,” Javan says. “But I guess that makes sense.”

“We made a bet on this permissions thing,” Jason Z. says. “We don’t use the feature, so we don’t know. We can’t anticipate what the pain points are going to be here.”

A month or so after shipping, it’s looking like we made the right bet. The majority of feedback has been of the thank-you-so-much-for-adding-this! variety. So far, 56 percent of users are logged into Google when trying to preview a document from within Basecamp, and of those, 91.5 percent already have access to the document they were trying to view. For how much concern there was over whether we were making the right call with permissions, it’s been super quiet. “We were really expecting more confusion, because we were confused,” Ann says. “The people who do use it know how to use it, and I guess we’ve fallen in with their expectations.”

“That’s a super important lesson just in product design in general,” Jason Z. concludes. “You can engineer all kinds of things, and they might be the wrong things if you don’t know. So it’s better to under-engineer and let the pain kind of bubble up organically, than to guess wrong.”

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.