37signals logo

This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Follow us on Twitter for more information on our products.


See more on our Job Board.

The Obvious, the Easy, and the Possible Jason F. Nov 29

32 comments Latest by Byron Ruth

Much of the tension in product development and interface design comes from trying to balance the obvious, the easy, and the possible. Figuring out which things go in which bucket is critical to fully understanding how to make something useful.

Shouldn’t everything be obvious? Unless you’re making a product that just does one thing – like a paperclip, for example – everything won’t be obvious. You have to make tough calls about what needs to be obvious, what should be easy, and what should be possible. The more things something (a product, a feature, a screen, etc) does, the more calls you have to make.

This isn’t the same as prioritizing things. High, medium, low priority doesn’t tell you enough about the problem. “What needs to be obvious?” is a better question to ask than “What’s high priority?” Further, priority doesn’t tell you anything about cost. And the first thing to internalize is that everything has a cost.

Making something obvious has a cost. You can’t make everything obvious because you have limited resources. I’m not talking money—although that may be part of it too. I’m primarily talking screen real estate, attention span, comprehension, etc.

Making something obvious is expensive because it often means you have to make a whole bunch of other things less obvious. Obvious dominates and only one thing can truly dominate at a time. It may be worth it to make that one thing completely obvious, but it’s still expensive.

Obvious is all about always. The thing(s) people do all the time, the always stuff, should be obvious. The core, the epicenter, the essence of the product should be obvious.

Beyond obvious, you’ll find easy. The things that should be easy are the things that people do frequently, but not always. It all depends on your product, and your customer, but when you build a product you should know the difference between the things people do all the time and the things they do often. This can be hard, and will often lead to the most internal debates, but it’s important to think deeply about the difference between always and often so you get this right.

And finally are the things that are possible. These are things people do sometimes. Rarely, even. So they don’t need to be front and center, but they need to be possible.

Possible is usually the trickiest category because the realistic list of things that should be possible will often be significantly longer than the list of things that should be obvious or easy. That means that some things on the possible list might be better off off the list completely. Instead of making them possible, maybe not making them at all is the right call.

Coming to know the difference between obvious, easy, and possible takes a lot of practice, deep thinking, critical analysis, and, often, debate. It’s a constant learning process. It helps you figure out what really matters.

But once you’re able to see the buckets clearly, and you begin to think about things in terms of obvious, easy, and possible instead of high, medium, and low priority, you’re on your way to building better products.

Nov 28 2011 Michael 13 comments Latest by kevin k.


We’re long overdue on thanking our friends at Uncommon for sending over these awesome iPhone cases. If you’re not familiar with Uncommon, they specialize in custom designed cases for the iPhone, iPod Touch and iPad. Check ‘em out!

Top-tier this David Nov 21

96 comments Latest by Bryan

If I hear one more Silicon Valley type gush over a computer science graduate from CMU, MIT, or Stanford, I’m going to puke. Yes, yes, I’m sure these are mighty dandy nice schools, but you’re letting the stench of superiority and shallow whiff of superficial judgement pollute my airways.

The fantastic thing about programmers is that we don’t have to give a fuck about where they were trained because we have something much better available: We can look at what they actually do! We don’t need the indirection of pedigree to guess at their skills, we can look at their code and know it.

Here’s a list of the top tier schools that helped shape the fine band of programmers we employ at 37signals:

  • Lawrence University
  • Rochester Institute of Technology
  • Brock University
  • Washtenaw Community College
  • California Institute of Technology
  • Copenhagen Business School
  • Brigham Young University

Nov 16 2011 Jamie 19 comments Latest by Michael

Inspiring stuff. Related SvN posts: The first step is to start and Four tips for learning how to program

Nov 15 2011 Ryan 4 comments Latest by jelbo

Designing a product is keeping five thousand things in your brain and fitting them all together in new and different ways to get what you want. And every day you discover something new that is a new problem or a new opportunity to fit these things together a little differently.

And it’s that process that is the magic.

Steve Jobs (via Daring Fireball)

Welcome Shaun and Emily! Joan Nov 10

13 comments Latest by Suhasini

A couple terrific people have joined our team recently: Shaun Hildner and Emily Wilder.

Jason wrote a little bit about him in Inc., so you might already know that Shaun joined us a little over a month ago as our new videographer. He made both the great logo animation and customer appreciation party video. Shaun is originally from Montana (also known in my area of the country as Western Real America) and now lives in Chicago. His application and demo reel really impressed everyone at 37signals and we’re very pleased to have him aboard.

If you’ve sent in a support ticket or checked out our Smiley ratings in the past few weeks, you might have noticed a new face. Emily Wilder has joined our Customer Support team, which means we are seven members strong and finally able to compete in water polo.

Emily was hired in an effort to replicate qualities from existing support team members: a redhead like Ann, a Northern California transplant to Austin like Merissa, and a passion for helping people like all of us. Emily told me her heroes are people she knows who manage to be brilliant while unfailingly kind, and her superpowers include the ability summon bagpipes with her mind and bake bread without a recipe.

You can follow Emily and Shaun on Twitter or help us welcome them here!

Nov 8 2011 Jason F. 29 comments Latest by Alonzo Katz


Fisher Price toy.

Nov 7 2011 Jason F. 36 comments Latest by John



Quick little UI feedback tip Jason F. Nov 04

19 comments Latest by Francesco Bertelli

Sometimes when I’m giving feedback on a UI, and I’m pointing out a spacing detail, I upload a little screenshot to Basecamp or Campfire to help make sure the feedback is clear.

I wanted to share a little tweak to the feedback which I think is ultimately more useful. In this example I’m pointing out that the space above and below an element is not equal (and I think it should be).

I used to do it like this:

Two lines. One line above the element (text, in this case) extending to the next element above it, and one line below the element extending to the next element below it. The length of the lines shows the different spacing. That works, but the difference – especially when we’re talking about small units of pixels – isn’t as clear as it could be.

Then I switched to doing it like this:

Blocks like this are easier to see than thin one pixels lines. This is an improvement. But it’s still not as clear as it could be because it’s not as easy to judge the comparative volume of a rectangle as it is a square. So…

This is how I do it now:

The same vertical distance is covered, but now, since both blocks are perfect squares, we have related horizontal distance which helps you see how much bigger the difference is.

Why not just say 24px vs 35px? Because I want to point out the physical difference, not the exact number of pixels. If we’re just talking numbers then it’s easy to assume 24px or 35px is right. But maybe the final size is 27px or 31px. I don’t want to get stuck on numbers when I provide feedback like this. The final number isn’t important as long as it’s the same (and it looks right).

I hope this was helpful.

Nov 4 2011 David 36 comments Latest by JjP


Evolution of a Logo Animation Shaun Nov 03

26 comments Latest by IT Rush

I suppose this is my first SvN post, so by way of an introduction I thought I’d share a bit about creating the animated 37signals logo.

When I first came on as “the video guy,” I wanted to think about how to brand 37signals’ wide variety of content with an interesting and unifying bumper. We hadn’t had to deal much with incorporating our logo into video, so it was time we gave it a bit of motion.

37signals is all about building things—from building a business to building software. I wanted the logo to “build” itself to reveal the design. 

I actually landed on the basic animation that would become the final product early on, but kept trying more and more complicated versions. I spent a week teaching myself new 3D software and countless hours tweaking every frame to get it just right, but as these things often go, we ended up back with a simple, clean design. The way the logo “builds” itself feels natural; it’s hard to imagine it moving any other way.

Not that it wasn’t worth it to challenge myself—I certainly enjoy learning new software and techniques, but it’s a good lesson to learn. More often than not, the simplest solution is often the best.

The chimes were a lucky coincidence. I needed some audio to give the animation a little more life. Using GarageBand and hitting four random keys on my keyboard, I came up with the chimes as a placeholder until someone with musical talent could get their ears on it. Like many things around here, it just worked—so we left it in the final version.

Here are a few of the different iterations we tossed around.

Nov 3 2011 Jason F. 12 comments Latest by Ebun

You break expectations by changing what someone’s already used to. You change expectations by giving them something new. Understanding the difference is key to product design.

Nov 1 2011 Ryan 11 comments Latest by Joe

Remember, a real engineer doesn’t want just a religion about how to solve the problem. Like ‘object-oriented’, or ‘functional’, or ‘imperative’, or ‘logic programming’. This piece of the problem wants to be a functional program. This piece of the program wants to be imperative. This piece wants to be object-oriented and guess what—this piece want to be logic-based. And they all want to work together usefully, because of the way the problem is structured.

First Round Winners: Basecamp Tell a Friend Contest Jamie Oct 31

8 comments Latest by Michael

We’re happy to announce the first round of winners in our Basecamp Tell a Friend Contest:

iPad Winners: Darren from Victoria, Australia uses Basecamp at all three of his businesses: Pro Blogger, Digital Photography School, and FeelGooder. JoAnne from Smithtown, NY uses Basecamp at Lighthaus Design, Inc. and Getting Real Health.

MacBook Air Winner: Michael from New Hope, PA is a Basecamp fan, best-selling author, professional speaker, and entrepreneur.

Tell your friends about Basecamp for a chance to win
We still have 9 more iPads, 2 MacBook Airs, and $5,000 cash to give away. Every friend that you sign up for Basecamp also gets $10 off their first month. Here’s how it works:

  • Sign up with your Basecamp account at https://tellafriend.37signals.com.
  • We’ll give you a special link that you can tweet, share on Facebook, or email to your friends.
  • Every person that signs up from your link for a paid Basecamp plan will get $10 off their first month.
  • Every person you sign up counts as a chance to win one of our prizes.

This contest ends on January 2, 2012. Sign up today and start saving your friends $10 off their first month.

Oct 28 2011 Jamis 7 comments Latest by Dain Miller

When a friend calls to me from the road
And slows his horse to a meaning walk,
I don’t stand still and look around
On all the hills I haven’t hoed,
And shout from where I am, What is it?
No, not as there is a time to talk.
I thrust my hoe in the mellow ground,
Blade-end up and five feet tall,
And plod: I go up to the stone wall
For a friendly visit.

Robert Frost, “A Time to Talk”

A little customer get together in Chicago Jason F. Oct 25

25 comments Latest by David Vaassen

Last week our whole company got together. We try to do this a few times a year. We fly everyone in and all spend a few days together in Chicago. We share what we’re working on, we talk, we debate, we review, we get some work done, and we have some fun.

Usually we reserve one of the nights to all go out to dinner together, but this time we decided to host some of our Chicago-based customers at a party at our office instead. We invited about 50 customers – some new, some old – and all hung out for a few hours. We met, exchanged ideas, fielded feature requests, and just got to know each other. Everyone had a great time. Thanks to everyone who came.

We put together a little video to share.

Special thanks to Steve Dale from Gyro, Jimmy Spencer Jr. from Love Without Agenda, Ray Hightower from Wisdom Group, Ben Greiner from Forget Computers, and Michael Carney from MWC Accounting for taking some extra time to be interviewed on camera.

Oct 25 2011 Jason F. 4 comments Latest by Martin Edic

And just as Steve loved ideas, and loved making stuff, he treated the process of creativity with a rare and a wonderful reverence. You see, I think he better than anyone understood that while ideas ultimately can be so powerful, they begin as fragile, barely formed thoughts, so easily missed, so easily compromised, so easily just squished.

Jonathan Ive at the Steve Jobs Tribute on the Apple campus. His talk starts around 47:17 right after Tim Cook introduces him.

Oct 20 2011 Jason Z. 13 comments Latest by Jay Cutler

Who is the star of your product? Do you want people to think your product is awesome, or would you rather they felt awesome about themselves because they used your product? Does the UI say “Look at how beautiful this app is” or “Look at how beautiful your content is”?

New in Highrise: LinkedIn profiles 37signals Oct 18

67 comments Latest by OnLooker

Today we’re introducing LinkedIn profiles in Highrise. You can now add LinkedIn URLs to your contacts to see their profiles in Highrise instantly. You’ll have easy access to all the specialties and qualifications listed in their LinkedIn profiles.

How to set it up

It’s simple: Just go to a contact, click the “Edit” link in the top right corner, then scroll down to the “Social media” section on the edit screen. Enter the person’s public LinkedIn profile URL and click save. Then you’ll see a “LinkedIn” tab at the top of their contact page. Click that link and you’ll have access to their LinkedIn profile.

To make the most of this feature you’ll need to have an account on LinkedIn. Highrise uses your LinkedIn account to grab the latest profile each time you view one of your contacts. This ensures the profile information you see is always up to date.

Integration with LinkedIn has been a popular customer request since we launched Highrise. We’re pleased to make it a reality today and we hope it makes Highrise more useful to you everyday.

Watch Ryan sketch and code a UI from scratch on PeepCode Ryan Oct 16

15 comments Latest by Grady Kelly

Last month the folks from PeepCode visited our office and asked to record my design process. Geoffrey told me not to prepare anything. He said he’d show up with a sample problem and simply record whatever I did with it. The result is two 75-minute videos (Part One, Part Two) that show my thought process step-by-step, starting with paper sketches and then moving on to HTML/CSS.

The hard thing about demonstrating design is the sample problem. The problem should be simple enough that the details don’t bog down the audience, but complicated enough that you run into real-life conflicts and constraints.

Fortunately Geoffrey picked a really good sample domain. He asked me to design a UI for picking the top five finishers out of 200 participants in a pro bicycling race. The task was rich and interesting enough that we spent the first 75 minutes purely sketching and analyzing the approach.

The first video, Part One, covers the sketching process. A lot of good material came out of this section, including:

  • How to tackle a UI problem by dividing it into tasks that each have a beginning, middle and end
  • How to use sketching as a response to uncertainty, and when to stop sketching and move on to HTML
  • How to focus on the most natural solution so that people will intuitively grasp a design
  • How to focus your design process on conflicts and friction points, attacking them one by one until the design works

This video also gave me a chance to explain the UI design process through an analogy to software testing. Kent Beck’s Test-Driven Development had a huge influence on me, and I’ve always had trouble explaining the connection. In both videos I continually refer to setting up “tests” — specific things in the design that aren’t working or aren’t resolved — and then design against those tests until they “pass” (that is, until the problem goes away). This loose analogy articulates that tricky and hard-to-pin-down process where a designer continually moves their focus among pieces of a problem and along the way settles conflicts step-by-step in a constructive sequence.

I think the process will be interesting to both designers and coders. Designers can compare the process to their own, while coders can use the analogies to software testing to see design as an extension of concepts they already know.

In the second video, Part Two, I take the sketches and ideas from the first session and build them out in HTML and CSS. Along the way I dip in and out of Photoshop, explaining the time and place for each tool.

Part Two especially focuses on getting quick results in the browser. I sketch out dom elements, give them classes to communicate their purpose, and gradually decorate them with inline styles until the design comes together in the browser.

I would prefer videos like this to be free. But Geoffrey had the idea to begin with and his PeepCode team did all the hard work. I just showed up one Friday morning for a couple hours of design practice. So if the material is useful to you I hope you’ll support their effort and buy the videos at $12/each.

Here are the links:

  1. PeepCode Play by Play: Ryan Singer Part One
  2. PeepCode Play by Play: Ryan Singer Part Two

There’s also a 10 minute preview on the Part One page.

I hope they’re useful!

Oct 15 2011 Jason F. 9 comments Latest by Website Design Las Vegas

Some designs are evil – you know they’re bad right away. Others are like love at first sight. And some you just need to live with for a while before making up your mind.

Fast and great support from the 37signals team 37signals Oct 13

21 comments Latest by Tyler

Our support team works hard every day to make our customers happy, and we’re always proud to show how great a job they do.

In addition to making customers happy, our fantastic team also answers questions fast. Across the last 500 new cases we’ve received during our normal hours, we’ve responded to 97% in less than hour, with the average case answered in 14 minutes and solved in 25 minutes.

Our team has been steadily improving at this too. Over the last few months, we’ve steadily cut down response times, all while maintaining or improving customer happiness.

Congratulations to Michael, Ann, Kristin, Merissa, Joan, and Chase!

Questions I ask when reviewing a design Jason F. Oct 11

30 comments Latest by Legion of Velour

I’ve been thinking more about how I review a design – both my own and someone else’s. So over the past couple days I’ve been writing down every question I’ve been asking when I look at a design-in-progress. Some of these I say out loud, some just go through my head, some are in person, others are posted to Basecamp or Campfire.

These are in no particular order, and I don’t ask all of them every time.

  • What does it say?
  • What does it mean?
  • Is what it says and what it means the same thing?
  • Do we want that?
  • Why do we need to say that here?
  • If you stopped reading here, what’s the message?
  • What’s the take away after 8 seconds?
  • How does this make you feel?
  • What’s down below?
  • How else can we say this?
  • What’s memorable about this?
  • What’s that for?
  • Who needs to know that?
  • Who needs to see that?
  • How does that change behavior?
  • What’s the payoff?
  • What does someone know now that they didn’t know before?
  • How does that work?
  • Why is that worth a click?
  • Is that worth scrolling?
  • What’s the simpler version of this?
  • Are we assuming too much?
  • Why that order?
  • Why would this make them choose that?
  • What does a more polished version of this look like?
  • Why would someone leave at this point?
  • What’s missing?
  • Why are we saying this twice?
  • Is it worth pulling attention away from that?
  • Does that make it clearer?
  • What’s the obvious next step?
  • How would someone know that?
  • Would it matter if someone missed that?
  • Does that make it easier or harder?
  • Would this be better as a sentence or a picture?
  • Where’s the verb?
  • Why is that there?
  • What matters here?
  • What would happen if we got rid of that?
  • Why isn’t that clear?
  • Why is this better?
  • How can we make this more obvious?
  • What happens when this expands?
  • If we got rid of this, does that still work?
  • Is it obvious what happens next?
  • What just happened?
  • Where’s the idea?
  • What problem is that solving?
  • How does this change someone’s mind?
  • What makes this a must have?

Why programs become territorial David Oct 11

35 comments Latest by Deltaplan

“Can you ask Sam about that? Stacker is his domain”, “I’d rather let Josh look at the router, he wrote it”, “Jon is better versed in associations, send it to him”.

The natural progression of programs is towards the territorial. When a programmer has weaved an intricate web of considerable complexity, others are loathe to enter his lair and he is loathe for them to do so.

This is despite the fact that we all agree that it’s bad for programs to become territorial. When only one or a few people know how to work on something, you get bottlenecks where progress is stunted until the master is ready. You risk the hit-by-a-bus factor where nobody knows how the system works if the master leaves. You ensure the annoyance of stakeholders who can’t understand why another minion can’t fix his urgent problem.

But this problem can’t be solved with a slogan. You can proclaim that “we shouldn’t have territorial parts of our program” until you turn blue, but nothing is going to change until you accept the cost of avoidance.

The first step of acceptance is to recognize that sending someone fresh in to fix a single issue in a complex part of the code is expensive. It’s going to take Pratik five to ten times the effort to fix a single issue in Stacker that it’s going to take Sam. And the odds are that even that is not enough to appreciate the internal coherency of the system, which means that the fix is likely to be a butcher’s job, and Sam will have to rewrite it afterwards anyway.

To broaden the base of knowledge, you’re going to have to let someone else not only spend considerable effort getting up to speed. Then you’re going to have them deal with more than just a quick fix. Let them deal with a raft of issues and let them spend the time of the original creator to learn it all.

To do all that, they can’t do anything else at the same time. That feature you want do is now going to be pushed a few days or a a week out. Until you’re ready to delay things you really want done, it’s fruitless to bemoan that parts of the code base territorial.

Oct 7 2011 David 588 answers Latest by Tybalt

The home button on the iPhone 4 stopped working properly for both Jason and I recently. Requiring hard presses or multiple tries to work. It appears that lots of people have this problem. Has it happened to you yet? Let’s track this.