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

Jonas Downey

About Jonas Downey

On a molecular level, Jonas is mostly pancakes and caffeine.

It's OK not to use tools

Jonas Downey
Jonas Downey wrote this on 54 comments

Recently I did a little side project to improve the website for a non-profit animal shelter in our town. The existing site was an outdated Microsoft FrontPage menagerie, so basically anything I did would be a big improvement.

I spent around 20 minutes creating a simple design in HTML, and then several hours editing, rewriting, and refining the copy. In the end, I reduced a scattershot 25-page website down to about 8 focused pages written in a friendly tone.

My next instinct was to apply our great modern web toolset to the site. Let’s add a static site generator or a CMS! Let’s add Sass and a grid system! Let’s do more fashionable things!

Then I started looking at those tools critically. A static site generator usually requires knowing Markdown and esoteric commands and configuration. A typical CMS will need setup, logins, security patches, templates, and maintenance. Even hosted CMSes have a lot of cognitive overhead, and the content is trapped away inside someone else’s system.

These are tools made by geeks, for geeks. Why do we need a CMS for an 8-page site? And for that matter, why even bother with Sass? Regular old CSS can do the job just fine.

Who knows who will take over the site in the future. I’ll hang with it for a while, but someday someone else might have to work on it. It would surely be easier to do that with 8 simple, straightforward HTML files than with some custom WordPress installation that’s several versions out of date. So what if I have to repeat the navigation markup 8 separate times? It’s not that hard. We used to do it for much larger sites!

Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?

As builders, we like tools and tech because they’re interesting and new, and we enjoy mastering them. But when you think about the people we’re building for, the reality is usually the opposite. They need simple designs, clear writing, less tech, and fewer abstractions. They want to get stray animals adopted, not fuss around with website stuff.

Remember when the web was damn simple? It still can be. It’s up to us to make it that way.

Basecamp goes back to basics

Jonas Downey
Jonas Downey wrote this on 11 comments

If there’s one thing everyone can agree on, it’s that computers and user interfaces peaked in the 1980s. Everything was clear and simple, without all of our modern annoyances like portability, color, touchscreens, and the Internet.

With that in mind, we took a long, hard look at Basecamp. We asked questions like:

  • Is Basecamp as simple as it can be?
  • Should we make Basecamp less colorful?
  • What if Basecamp was stored on 800kb floppy disks?
  • When is Knight Rider starting?

So today, after months of work, we’re excited to announce that Basecamp is going back to basics. We’ve rolled out an update to all our users that’s available right now. Just visit Basecamp in your web browser, and type the code dogcow to get a sneak preview of our new direction. We think you’re going to love it.

Basecamp’s new system requirements:

  • Macintosh System 6 or higher
  • 512kb of RAM
  • 800kb floppy disk drive
  • 1200bps dial-up modem (recommended)

P.S. refresh your browser to exit the preview.

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.

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.

Lessons in creativity and joy at XOXO

Jonas Downey
Jonas Downey wrote this on 4 comments

Last week, a small crew of 37signals folk headed to Portland for the XOXO festival. It was a high-speed joyride of creative spirit, and it might have permanently changed my outlook on making stuff. Here are a few of the morsels that will stick with me for a while.

Ignore cynicism. Do what you want, and love doing it.

The Internet appears to run on cynicism. Twitter is a complaint delivery protocol, and comment threads are polluted with meaningless grammar fights and nitpicky personal attacks. It’s hard not to be distracted and consumed by the blustering.

But somehow, at XOXO, everyone was cheerful. They showed beautiful things. They had fun. They were friendly. No judgement. It was a breath of fresh, caffeinated air.

The talks blurred into a DIY instruction manual for following your bliss. Every speaker shared the same recurring tale of overcoming self-doubt, failure, financial obstacles, and technical challenges to do something they could believe in (and you can do it, too!)

It was a much-needed reminder that the lifeblood of the Internet is still made up of respectful people who are wide-eyed and fiercely passionate about their work.

Work with people you admire, and spend some real, quality time with them.

I’m so fortunate to work with great people. But we’re busy, we don’t all live close to each other, and we don’t have a lot of time to hang out.

XOXO had so much fringe social time that even a bunch of introverts like us couldn’t avoid talking to each other. The social events were invaluable — I kept wishing more of our company was there too. It was team-building, fun-style. When your job is to make things together, your work will be better when you have fun together. Make time for it.

Conference events shouldn’t be be short and formal.

Andy Baio and Andy McMillan could teach a course in throwing a good event. In short: allow your attendees plenty of room to breathe. Don’t pack in tons of simultaneous sessions in a generic hotel. Give people an experience. Give them free time. Give them good food and loads of coffee in a weird place.

Look at other types of art, as much as possible.

Web design has a bad reputation for being stylistically trendy and same-looking. Some guy does a parallax scrolling site, and now your boss wants you to add that to your corporate PR website for some reason. Glossy buttons, Gaussian Noise, linen texture, new things that look fake-old, then back to minimalism and flat colors as a reaction to the glossy noisy textured fake-old stuff.

Turns out, there is a ton of inspiring work being done…in every other genre that isn’t web design! XOXO highlighted so much good work, and almost none of it was on the web. Movies, games, illustration, industrial design, comics, it was all diverse and interesting. Time and again, the web was just a way to deliver or sell it — the means, not the end.

So, get out of your chair and look at the world for a while. Then go make something new.

Exploring ideas in the pursuit of clarity

Jonas Downey
Jonas Downey wrote this on 11 comments

In my six months as a signal, I’ve worked with Jason F. on numerous design explorations for the new Basecamp. These sessions are always fun, and a few of them helped transform difficult problems into the UI you’re using in the final product. (One famously tricky one was the new Projects screen.) Our design process isn’t formal, but we’re fast and methodical. We scope most of our work into a week or two.

One of our recent explorations was a UI for adding groups or departments inside a company — such as the Marketing and HR groups inside Acme Widgets. This turned out to be a great example of how an exploration can produce an entirely different result than you originally expected.

Step 1: Define the problem and propose solutions

To start, we meet to talk about the problem, and sketch ideas. We each suggest some concepts and review them, trying to poke holes in our reasoning or spot any early showstoppers. This usually takes less than 30 minutes.

Step 2: Pick the ideas that are most likely to succeed

For this exploration, we had several ideas, but two stood out: a straightforward A-Z list, and a more visual circle-themed version.

Circle sketch