How we achieve “simple design” for Basecamp and HEY

Yesterday I got an email asking how we achieve simple designs for Basecamp and HEY, so I hastily tweeted a screenshot of my answer, and a lot of people responded to it. A few folks pointed out that my screenshot was illegible for blind users, so I’m reposting it here in full text, with a bit of additional commentary below.


At a high level it boils down to a handful of foundational principles that affect the decisions we make:

  1. Always choosing clarity over being slick or fancy. Internally we call this “Fisher Price” design. We aim to make the UI totally obvious and self explanatory, by keeping individual screens simple, showing only one focused thing at a time, and so on. Good product design eliminates the need for an instruction manual!
  2. Preferring good copywriting, and taking the time and space to explain things with words, instead of making minimalist UIs with lots of unlabeled buttons, etc. (Although we’re still guilty of having a few of those.)
  3. Prioritizing respectful interfaces that don’t overwhelm or try to nag the user into certain behaviors. We intentionally don’t include things like notification counts/badges, 3-column designs, and such unless we absolutely can’t avoid them. We don’t like the idea of having “sticky” interfaces—we want our customers to use our products to get the job done, and then go do something else. That makes the whole design approach more peaceful in general.
  4. Having a strong editorial sensibility, and knowing when to split complex concepts into simpler individual parts. This one is more of an art than a science, but we have a good instinct for breaking down problems until they can be easily understood in simple UI flows.

There’s one other thing that’s important for simple design. It’s not merely a matter of having clear or basic-looking interfaces. (It’s easy to make a simple UI that doesn’t really do much.)

The magic combo is having simple interfaces paired with powerful capabilities below the surface. HEY looks simple, and it’s straightforward to use, but it’s backed by some deeply considered opinions, logic, and machinery that empowers people who use it to be better at email than they were before—and with less effort! The interface itself is simple, but the thinking and the system behind it is extremely complex. The product is valuable because it saves people time and anxiety dealing with the terrible email mess that they had just learned to live with.

For more on this line of thinking, we highly recommend Kathy Sierra’s Badass: Making Users Awesome.

(P.S. many thanks to @waynedixon and @redcrew for calling me out on the inaccessible screenshot tweet. Appreciate that.)

6 thoughts on “How we achieve “simple design” for Basecamp and HEY

  1. This is a very interesting way to make people think you’re HEY UI is superior to other offerings.

  2. Thanks a lot for a deep thought that goes behind the design of “hey.com.”

    I really liked “Always choosing clarity over being slick or fancy.”

    Could you pls suggest some more good resources to improve the design thinking to make the product extremely useful as per JTBD and yet super simple?

  3. Funny, I also called it “Fisher-Price design” to myself. I also imagined that was a by-product of more Basecamp employees having little children and thus that were more exposed to real-life Fisher-Price UIs 😛

    I also love the “Always choosing clarity over being slick or fancy.”. What I didn’t understand is what’s wrong with 3-column designs, too cluttered?

  4. Not trying to be a downer here, but to ask a sincere question. I love how you do most things at Basecamp, but the design of your tools is the reason I don’t use them. I want to use tools that are as beautiful as they are easy to use. The way your apps scream at me with garish colors distracts me from what I think is most important – the content.

    Is this something you consciously do and have thoughts about, or do I just have very different taste from you?

  5. Reading the second point I’m curious, what do you think about the saying “users don’t read”? Do you attempt to make UI self-explanatory if you were to remove the text, or use a different language? Maybe some of your users don’t understand English that well :).

Comments are closed.