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.

The special recipe for DELIGHT

Jonas Downey
Jonas Downey wrote this on 5 comments

Delight is a word interaction designers have been throwing around for the past couple of years. Some people think it’s an overblown buzzword, while others believe it’s a subject worthy of an entire conference.

One part of “designing delight” is about turning otherwise mundane tasks into funny or interesting moments. On the UI side, this might include adding thoughtful animations, cutesy or clever copywriting, and perhaps tossing in a few surprises on top.

These surface-level treatments help make a product seem more human and less computery, which is surely a good thing to do whether you define it as delight or not. At Basecamp, we try to bake this sort of thinking right into our usual design process, rather than calling it out as a specific ideal.

But there’s another, deeper kind of delight. For this post I’ll call it DELIGHT. Here’s an example.

I recently moved my sizable photo library to Google Photos, for a variety of boring reasons: it syncs with Google Drive, storage space is generous, sharing albums is easy, it doesn’t mess with my existing file structure, and searching is miles ahead of competing services. Sure enough, it all works very well — currently besting Apple’s or Dropbox’s offerings.

I was already satisfied, and then Google Photos did something I didn’t expect. When I synced my tens of thousands of photos, the Google Photos “Assistant” bot worked behind the scenes to breathe new life into them, by automatically compiling them into animations, stories, and collages. The stories and collages were roughly what you’d expect a computer to achieve when laying out photos: a fine enough job, but not too mind-blowing.

It was the animation idea that knocked my socks off.

As any parent of a young child (who just WON’T SIT STILL) can tell you, you often need to take 30 photos in a row to get one good one. So we do that a lot. This means our photo libraries are cluttered with countless batches of photos, most of which are basically blurry garbage. Who has the time to go through all of them to find that one perfect gem? Definitely not parents of young children!

Google’s engineers realized this, so they transformed all that garbage into something great.

Now that, right there, is DELIGHT.

Not only did this feature make amazing use of all those junky photos I haven’t looked at in years, it did so automatically. Google Photos just made my entire library much better without my intervention.

This feature has been around for a couple of years, but it doesn’t show off its true power until you backload your 10 years’ worth of stuff. And before now, backloading all your stuff sounded rather unappealing since the Photos feature was deeply intertwined with a big social network.

It took Google a long time to find the special recipe — that perfect combination of features, capabilities, and surprises — to get DELIGHT. To make it happen, they needed to mix cheap storage, tons of processing power, robust file syncing, plus a healthy dose of smart thinking and a willingness to decouple Photos from its social networking parent.

Now, DELIGHT isn’t really about the software itself. Seeing photos of your kid from 3 years ago in a brand new way is sentimental and emotional. It just so happens that the software helped make those emotions happen. I love my kid, not the software, but now I’m certainly more endeared to the software and the people who created it.

This is what product design is about. Finding the special recipe for DELIGHT. Making people badasses by giving them new superpowers they couldn’t have achieved on their own. Everything else along the way — the animations, the copywriting, the tech, etc. — is just supporting material for the main act.

37 pieces of life-changing business advice you'll have to see to believe

Jonas Downey
Jonas Downey wrote this on 17 comments

We write a lot of thoughtful stuff here on Signal v. Noise, but we noticed our headline writing hasn’t kept up with current trends. So, we’ve started revising all our past posts — you won’t believe what happens next!

  1. You might have thought design was about pictures, but what it’s really about will surprise you
  2. How to ease any situation by doing something unexpected in 5 minutes
  3. Unleash your creative potential by getting the truth in this unlikely place
  4. Find out why this billionaire just won’t make up his mind
  5. Watch out for these 7 dirty words that are totally NSFW
  6. You won’t believe what this brash young upstart thinks about his career
  7. Amazing! We found a way to make your life easier by avoiding something you thought was important
  8. There are lots of ways to get started, but the first step will shock you
  9. Don’t miss: This one simple trick will save you time and professional embarrassment
  10. Meet the person who just can’t stand what you’re writing
  11. Check out this hot commodity that’s even harder to get than the next iPhone
  12. How noisy is your office? If it’s louder than this, you’re doing it wrong
  13. This guy thinks it’s super fun to argue with everyone
  14. You need this revolutionary space-saving trick that’ll change everything
  15. Fortune Telling! This unbelievable product predicted the future, here’s how they did it
  16. Here’s a shortcut to make your wildest dreams come true right away
  17. Confused, anxious, or happy? We’ll tell you how you’re supposed to feel at a new job
  18. The worst thing that can happen in Vegas is way worse than you thought
  19. It only took these 3 charts to make this man happy
  20. This trendsetter convinced all her friends to wear the same shirt, here’s her wild story
  21. Health Alert: A common personality trait might be hurting your mind and body
  22. Meet the successful CEO who puts all his faith in one thing. It’s not what you think!
  23. This crazy company convinced everyone to do shit work. Here’s what happened next
  24. Pop Quiz: Do you have to love what you do? Come find out
  25. Call the cops? These people just won’t go away no matter what
  26. We found the easiest way to get famous people to talk to you
  27. When the whole world is speeding up, this man slows down. Does he have turtle DNA? Yes? He might! Or not?
  28. Vanishing! This classic animation trick disappears before your very eyes. Look now before you miss it
  29. 6 reasons you should throw your suit and tie in the trash right now
  30. Ouch! We found out how much surgery really costs (and you’d better hope that weird abdominal pain goes away on its own)
  31. 3 awesome ways to get people to speak words out loud using their mouth holes
  32. Which M&M flavor is the world’s best? We tried them all so you don’t have to
  33. In a race to the finish, these designers started throwing stuff out the window…then this happened
  34. These businesses didn’t go out of business. Or did they? Read this for the answer
  35. This marketing email has a funny detail (WARNING: can’t be unseen)
  36. 3 really disturbing examples of bullshit apologies that will make your skin crawl
  37. Spoiler Alert! This is what happens when Kenny Loggins and a semiaquatic animal get involved in a presidential campaign

Asking why

Jonas Downey
Jonas Downey wrote this on 7 comments

Last week I asked a question on Twitter: If you have a personal website, why do you have it?

Some people used their site as a hub that collects their online identities. Others liked to fiddle with web tech or writing. Several treated it as a showcase for their professional work, to possibly get a job. Everyone else, it seems, didn’t have a reason aside from a general feeling of obligation.

I think that last group indicates a sea change. In the early days of the web, your site was a big part of your identity. It was one of the best places to share information, prove your geek mettle, and make a little network of fellow weirdos. In 2015, we have a million other ways to do that, so a personal site feels left over from a bygone era — a tiny island adrift in a vast ocean of apps, status updates, and clickbait headlines.

And so, its purpose has become even more vague. People don’t know what a personal site is for anymore, so they go through the motions. They put the same things everyone else puts on there. A giant photo of a city. Something that says “Hi, I’m Dave.” Fancy scrolling effects. A bunch of social media icons. An unintelligible skills chart. A quickly neglected blog.

All these choices are based on assumptions. First, the assumption that you even need a website. Second, that a website looks a certain way and has this usual kind of stuff on it. And third, that some anonymous group of users will stumble upon it and be interested in it.

As an industry, we have this problem a lot. We do things because that’s how everyone else does things. We assume that what’s popular must be good, so we don’t ask questions…we just do it! Even if we’re not that into it.

This is also why you see countless corporate websites that look exactly the same and automatically generated hipster logos. It’s much easier to assume an existing pattern works and reapply it than to dig in and find a deeper understanding of the real problem you’re trying to solve.

But shortcuts like this rarely lead anywhere new or interesting. Why replicate what hundreds or thousands of people already did? The best you can achieve is as good as everyone else. That makes you forgettable.

There’s a simple solution: ask why you’re doing something, and don’t bother getting started until you have a clear answer. This applies to any situation, but in this particular example…

Why should this website exist?

That question leads to more specific questions…

  • What am I trying to get out of this?
  • What’s unique about my story?
  • Do I have anything to say?
  • Why would someone look at this?
  • Why do I want them to look at it?
  • What do those visitors really need to know?
  • What should they do next?

When you work outwards from why, you unlock all sorts of revelations that aren’t about obligatory features or popular trends. You might find that those scrolling effects and skills charts have nothing to do with your story and the outcome you want. Maybe you’ll uncover a parade of new ideas dying to see the light of day. Or you’ll decide your site is just for your own experimentation, and that’s OK too.

If you find no strong reasons for a project to exist, all the better! Kick it to the curb and free yourself to spend time on something else.

Strategies for getting feedback (and not hating it)

Jonas Downey
Jonas Downey wrote this on 7 comments

Recently my team has been working on core improvements for Basecamp. We planned to move quickly on a range of projects, and we wanted to make sure everyone at the company stayed in the loop. Plus, our company is full of smart folks who know the product inside and out, and we were hoping to use that hive mind to our advantage.

That’s easy when you have 5 or 10 people, but it’s challenging with 45. We had to share a lot of info and avoid pestering everyone in the process, so we began experimenting with a few new ways of working. Some of ‘em worked, others…kind of worked. Here are a handful of the strategies we tried the hard way.

Make screencasts for easier reviews.

No matter how many times you’ve done it, asking people for feedback is a harrowing ordeal. They’re busy working on something else, and you’re requesting their precious time and attention.

We wondered: what’s the most effortless way to communicate what we’re working on? Long written messages or storyboards take a lot of time to wade through. So instead of that, we started making 3-5 minute screencast demo videos for each project-in-progress. We share these videos with everyone at the company and ask them to comment. They’re friendly and easy to watch.

In each demo, we talk about the motivation behind the project and what we’re trying to accomplish. We explain how our solution addresses those things. We also mention weak spots or details we’re not sure about.

Here’s an example:

These videos helped quell broad questions like “why are we even doing this?” because they demonstrate that we’ve thought through the big picture stuff. As a result, the criticism we receive is more specific and actionable.

Sidenote: if you do this, you’ll have to get comfortable recording screencasts. After about 5 of them, you get the hang of it. The first step is accepting that yes, your voice is weird, and your face is kind of weird too, and wow, you’re not good at this at all, are you?

Work in the open.

A few years ago, Ryan wrote about designing in the open. We took that to its logical extreme and left our work wide open for anyone in the company to see at any time. That meant having our ongoing projects (in Basecamp) visible to everyone, and sending out weekly status updates about our work in progress. We call these heartbeats.

For feedback purposes, the heartbeats proved more successful than the open project. The open project is like a dirty workroom — people feel bad wandering in and criticizing what you’re doing while you’re doing it. (Plus we’re a remote company, so the workroom is full of people who aren’t wearing pants.)

That said, it’s still nice to let people peek if they’re curious about what’s going on. It also leaves a chance for the occasional helpful comment you might not have expected.

Seek out people who have different perspectives.

Getting the truth isn’t always as easy as mass-emailing people. You might actually have to talk to them. Sorry, fellow introverts!

We’ve made a concerted effort to chat with people outside our immediate development team, like our customer support people, data analyst, QA folks, and anyone else in the company who might look at the problem from a different angle. Sometimes they don’t speak up on their own, but if you reach out personally, they’ll almost certainly mention things you never considered.

Decode vague comments.

How many times have you heard (or said) stuff like this?

"This one looks more readable." 
"I like how this one is clean and simple." 
"This version makes your eyes jump to the important part of the page." 
"This seems like it’s the most usable." 
"This solution might be too noisy." 

This feedback isn’t necessarily bad, it’s just incomplete. Words like clean, usable, and noisy don’t have much meaning. They roughly suggest something about hierarchy, contrast, and spacing.

When we get feedback like that, we dig deeper and ask for clarification. If something looks more readable, why? What about the design is better? More whitespace? Typeface pairings?

Once you unravel the real issues, you’ll know which direction to go. You’ll also get better at offering suggestions to others. Instead of saying, “hey this design looks bad and weird,” you’ll say, “this doesn’t fit in well with our usual styling.” Details like that give your colleague a hint about what they need to improve.

Emotionally separate yourself from your work during critiques.

If you’re working on a project you care about, you’re invested. Sharing your work puts your ass on the line, and hearing a negative reaction will sting. (Admittedly, it’s even harder in front of the whole company. Your ass is on all the lines.)

But the only way to make something great is to recognize that it might not be great yet. Your goal is to find the best solution, not to measure your personal self-worth by it.

Furthermore, most people are reluctant to tell you what they really think. Got negative feedback? Cool! You just succeeded at finding the truth. That’s a win in itself.

When it’s time to share and evaluate what you’ve done, try to put your emotions and sweat equity aside. If you can manage this, you’ll be able to debate the ideas logically instead of emotionally.

When nobody responds, you probably haven’t nailed it.

We noticed that people rally around an obviously good or bad solution. If a solution is strong, you’ll hear about a few minor nitpicks, usually interspersed with an excessive quantity of happy emojis. If it’s clearly bad, a few honest folks will call it out (with not so many emojis.)

When the team is indecisive, or worse—silent—there might be bigger underlying issues at stake. The best way to move forward is to get the whole team together and air it out. Get on the phone, or Skype, or have a meeting and chat in person.

We did this with a project that wasn’t going so well. We were creatively stuck, but we’d been trying to work through it individually. When we reconvened as a group, everyone had a chance to voice their concerns and agree on what to do next.

Make the call.

What happens when everyone disagrees? You might have multiple viable ways to proceed and no definitive answer on any of them.

Now it’s up to you to weigh everything you heard. How much time do you have left to make changes? Which solution do you feel strongly about? Does someone else feel strongly when you don’t? Is there a compromise version, or another option you haven’t considered yet?

The answers here are always different, but one thing remains the same: it’s up to you. It’s tempting to pawn off these decisions to other people, or wait for a consensus to appear, but it’s better to choose a direction than to keep spinning your wheels trying to please the group. Making the call has the side effect of drawing out people who were on the fence — if it’s the wrong call for some reason, they’ll speak up before it’s too late!

Don’t be embarrassed when things don’t work out.

Not every project is an immediate success…or even an eventual success. Out of our last 10 projects, 2 didn’t go smoothly. The first one shipped after we took a break and regrouped. We shelved the second one entirely, because we tried numerous approaches and there was no clear path forward.

Admitting defeat doesn’t feel great, but it’s far better than trudging ahead with a design that simply isn’t working. Who wants to ship and support something like that?

Return the favor.

Try offering thoughtful critiques of others’ work. Be kind, honest, and specific. It’s surprisingly difficult to do!

If you’ve been in the game for a while, mentor the younguns. Help them improve and share the feedback love. Teach them to screencast so they’ll get used to their weird voices and faces too (eventually.)

Why you should share your dirty work

Jonas Downey
Jonas Downey wrote this on 13 comments

When you look at most designers’ portfolios, you usually see beautiful, polished work — finished products with plenty of spit and shine.

Those examples are great for showing off your talents and the culmination of your hard work, but the final product is only a small percentage of your total effort. It just represents your last decisions that made the cut.

In reality, most projects are ugly and messy. There are piles of half-baked explorations and heated arguments left behind the scenes. That’s why the shipped version of a design can seem obvious in retrospect — you threw out all the confusing stuff along the way!

Most of this dirty work ends up in the trash or unseen, and that’s too bad. We should all show our dirty work more often, because it’s documentation of the real work. It explains your thought process and gives critical backstory to the final version. (By the way: having that backstory also makes it easier for employers to hire you. Sometimes it’s much more valuable than the end result.)

We’ve been doing this for years in our Design Decisions posts. In that spirit, here’s a bit of our recent Basecamp dirt. This is what it’s really like to make the doughnuts!

Example 1: Should we show a button or not?

Sometimes small things are unexpectedly controversial. When we worked on Archiving Discussions, we had a running debate about whether we should expose the [Archive] button on discussions all the time, or keep it hidden away in a “bulk archiving” mode.

Archiving is an occasional use feature, so we were concerned about making it too prominent. For a while, we even planned to hide the button behind a keyboard shortcut and make it a secret power user thing.

Finally, we all agreed that there was no harm in showing the button. It didn’t get in the way or make the Discussions page noisy — it made it useful.

Example 2: Writing a single link

There wasn’t much design work needed for multiple-file downloads, yet we fiddled with this link text profusely. We even changed it in production after we shipped the feature.

Example 3: Fixing an edge case

Working on a big product like Basecamp means there’s an edge case practically everywhere you look. When we added moving a single to-do, we had to accommodate what happens if there are no destinations to move to. Most people won’t ever encounter this state, but it has to exist for those who do.

Example 4: How should we show attachments?

One of the bigger challenges with attaching files to to-dos was deciding whether we should show each file’s thumbnail next to the to-do itself. To-dos already have a lot of UI chrome, so we wanted to tread lightly. We tried big thumbnails and tiny ones.

After several debates, we decided that big thumbnails were too intrusive, and small ones were too tiny to be useful. So we axed them and opted to show a paperclip icon instead.

Example 5: Basic grammar

There’s often a conflict between proper English and what wording can be programmed to fit a variety of conditions in software. This is why you see computers making silly mistakes like 1 to-dos added successfully. Carefully working around these situations is almost an art in itself. There’s always a push and pull between what you want to say, and what you can reasonably do without excessive conditional code.

During design for making templates from existing projects we included an option to remove to-do assignments in bulk. We had to try several times to find a version that was clear enough and didn’t violate basic English grammar in some way.

So there you have it — those are just a few of our recent examples! What stuff have you made recently that’s itching to see the light of day?

Writing-first Design

Jonas Downey
Jonas Downey wrote this on 10 comments

A quick way to measure a designer’s maturity is to watch what they do at the beginning of a project. Inexperienced designers are often smitten by the allure of new tools and quick results, so they’ll jump in to Photoshop or Sketch and start messing with layouts and style explorations. Seasoned designers know this can be distracting, so they might start by doing research or drawing in a paper sketchbook instead.

Sketching is great, but before I start sketching, I start writing. Writing first has lots of advantages, regardless of the project you’re working on. Here are a few examples.

Example 1: You’re making a simple website, and your client doesn’t have any copy yet.

Great! Here’s an opportunity to write it. Skip the lorem ipsum and start telling your client’s story. What’s special about this client? What problems are they trying to solve by having this website? How can you explain those ideas to people who visit the site? And why should the site’s visitors care?

Answering these questions requires you to gain understanding. You can’t write anything without knowing your subject. You’ll be forced to learn a lot about the client’s business, their history, and their audience. Having this information will clarify your vision for the overall project.

Example 2: You’re making a website, and the client gave you copy to start with.

Great! Don’t design anything yet. Put on your editor’s hat and think critically. Is the text arranged correctly? Does it have the right tone of voice? Is it too long or too short? Is it suitable for the web? Can you chop it up into separate pages and keep it coherent? What’s still missing?

Chances are, this handed-over writing might be lousy. Be honest and propose copy changes before you get much deeper into the design. Don’t be afraid to do a rewrite — treat writing as part of the design, not just an element on the page.

Example 3: You’re making an app or interface elements.

In that case, you’re likely designing affordances — communicating actions the user can take. These might take the form of explanatory copy, prompts, buttons, labels, error messages, etc.

Great! Hop into a text editor. Write out as many variations as you can. It’s easy to mock basic UI in text, like this:

Are you sure you want to delete that file?
[ Yes, I’m sure ] [ Never mind ]
Deleting this file will remove it permanently. Are you sure?
[ Yes, delete it ] [ No, cancel ]

And don’t be afraid to have a little fun with it:

That file will disappear completely and never be found. Carry on?
[ Indeed, ashes to ashes and so forth ] [ No, I can’t let go ]

Example 4: You’re making a graphics-heavy poster that has almost no writing at all.

Great! Write down what you think you’re trying to accomplish. Spend 5 or 10 minutes on it. The notes are entirely to help you clear your head and figure out what to do.

Putting writing first improves your chances of success in the final product. It’s good practice, and it makes the rest of your job easier.

Now, what does the overall creative process look like? I’ve found it works well like this:

  • Spend time writing until you’re happy with the first draft.
  • Sketch visual ideas on paper.
  • Open your software tool of choice and explore aesthetics: colors, type, imagery, and style.
  • Put it all together and try different layouts and arrangements.
  • Continue editing once you see everything in context.

Obviously that exact order is not always right for every project. There’s no right way to do things! But following this general process helps guarantee you’re putting horses before carts and staying on the right road.

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.