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

Signal v. Noise: Design

Our Most Recent Posts on Design

Basecamp HQ Mural

Nate Otto
Nate Otto wrote this on 6 comments

When I painted a mural on the wall of the first 37signals office back in ‘99, or 2000, I didn’t have a camera phone in my pocket. That’s why I took pictures of the wall with a disposable camera. If back then I was the competent human being I am now, I would have gotten those pictures developed, but I was an idiot then, and I have no documentation of that mural. I remember that it had monsters in it. I was into painting monsters.

About a month ago I completed a new mural in the front entrance hallway of the Basecamp Headquarters. Luckily I have a camera on the thing I browse Facebook with, and I keep it in my pocket. I was on a black and white abstract cityscape kick when I pitched the idea to Jason and Michael Berger. Jason had some ideas but gave me the license to do whatever I wanted. Doing whatever I want is what I do best. I’m really proud of the results, and grateful for the opportunity. I’ve done several murals, but this one might be my favorite. It was Jason’s idea to go around the corner.

I put a few Easter eggs in there. It says Basecamp. It also says 37signals and Spinfree. There is something that looks like a ruby on some rails. Jason didn’t want it to be too Basecamp specific, and I agreed with that, so those things are all somewhat hidden.

By the way, I love doing murals, and I especially love doing them in offices. It gives me a chance to soak up a company’s culture for a few days or a week while I work, and tech companies always have snacks. I’m down to fly to Germany (or wherever) and do a mural in your office. Basecamp is a fifteen minute bike ride from my house, I’m already familiar with the culture and the people, and I have a fob, so this was a fun one. Say the word and I’ll paint the whole place!


Building Basecamp 3: Mobile Prototypes

Jason Z.
Jason Z. wrote this on 8 comments

Interactive prototyping was essential to designing Basecamp 3 for iOS and Android. In this article we’ll look at how we chose a prototyping tool and take a peek at a few of our prototypes.

At Basecamp design happens through iteration. We don’t make highly-polished comps but instead work right in Basecamp’s code making hundreds (even thousands!) of tiny revisions until the design is just right. We can then see and click the work-in-progress design just like our customers will the finished product. We’ve done it this way for years—our workflow and development stack are highly optimized for it.

When designing Basecamp’s mobile apps it was a completely different story. Even for the simplest of changes the difference between refreshing a web browser and building an app to a device (or simulator) is orders of magnitude slower. It’s worse when you consider that making even seemingly minor visual changes to iOS or Android designs in native code can take much more time than you might expect. Over the course of a day that time adds up. All told, we had to find a better way.

Basecamp 3 mobile wizard

Solution: interactive prototypes

We knew right off that static Photoshop mock-ups weren’t going to cut it. We wanted to see and touch our designs on real devices. It was tempting to simply make prototypes in HTML, CSS and JavaScript—tools we’re very familiar with—but it turns out they’re a poor fit for the kinds of designs we wanted to try. Simple things that are essentially free in native code can be difficult or quirky in web browsers. For example, full-screen transitions or fixed navigation bars.

So we set out to find a prototyping tool that met these requirements:

  1. Fast. Above all a suitable tool had to be faster and easier than putting something together in native code or even HTML/CSS. It was equally important that the round-trip was short between making changes, previewing them, and making further tweaks.
  2. Real devices. We wanted to see and touch designs on real devices, desktop emulation alone wouldn’t cut it.
  3. Shareable. Prototypes would serve two purposes: Quickly sharing work-in-progress designs for critique and sharing the final, high-fidelity reference designs with our programmers.
  4. Cross-platform. We’re all developing on Macs but it was important that any tool worth considering would be suitable for prototyping both iOS and Android app designs.

We looked at a ton of tools and put several through their paces including Quartz Composer w/Origami, Form, Pixate, and Briefs before settling on Framer.

N.B., We evaluated these tools nearly one year ago at the beginning of Basecamp 3’s mobile development so some of the reasons we choose Framer over the others may no longer be true. In fact, Quartz Composer was my favorite tool to use—the springy-band UI is unique and super-fun—but it lacked on-device preview at the time, a deal-breaker for us that has since been corrected. What I hope you’ll find interesting in this article is how Framer met our requirements and what we learned about those requirements after we had been using it regularly


“Sometimes you just have to see it”

Conor Muirhead
Conor Muirhead wrote this on 2 comments

“Sometimes you just have to see it to get a feel for it”

^ That’s what Jason said to me yesterday right after he pushed some tweaks to a design we’ve been ping ponging on this week.

When I read that I found myself nodding my head and thinking, “ain’t that the truth”. Now, if only I’d learned that lesson a few years ago.

You see, not long ago I used to spend a lot of time and energy pushing back on ideas. I think I must have seen myself as some sort of Design Guardian or something. I know, stupid, right? In that (ridiculous) role I seemed to think it was my job to protect the product from “bad” ideas. Only problem is, how did I know if an idea was “bad” or not?

One of my teammates would usually suggest an idea, I’d imagine it in my mind, and then (unfortunately all too often) I’d explain why it would never work. I bet I missed out on a lot of great ideas doing that, probably some good friendships too :(.

It gets worse though. When shutting down an idea without giving it a chance to be seen, I miss out in at least three ways:

  1. The idea could be fantastic once I saw it, used it and felt it.
  2. While trying it out, I may stumble into another, even better idea.
  3. I’m stifling my teammates, and discouraging them from jumping in and helping.

All three of those kinda suck.

Nobody Wants a Design Guardian.

I’ve learned that I’m not a guardian, and that I never should have tried to be one. The team didn’t hire me because they thought I’d be a great guard. No, they hired me to try things, to experiment, to build stuff, and to find out what worked.

The Good News

Here’s the good news though: it’s usually easy to try out an idea enough to actually see it, use it, and feel it. In fact, I think in the past I’ve wasted more time bickering than I ever spent just finding out!

So, the next time an idea comes your way, give it a chance. Try building or prototyping it, seeing how it actually feels. You’ll be done faster than you could even argue about it!

What’s more important: An extra gig of RAM or 3D Touch?

David wrote this on 3 comments

The hardware engineering and software coordination behind 3D Touch in the iPhone 6S is impressive. It’s such an Apple feature. Executed with exquisite diligence because they control the whole stack. Marvelous.

But you know what, it’s not my favorite feature of the 6S. That honor belongs to the low-tech, behind-the-curve addition of an extra gigabyte of RAM. Something that probably cost Apple just a few extra dollars per phone and almost no engineering prowess. (Compare that to the probably hundreds of millions in revised tooling, advanced development, and more needed for 3D Touch.)

Doubling the RAM means apps aren’t constantly being swapped in and out. Which means switching between them is super fast more of the time. Which in turn makes the whole phone feel much better over the course of a day.

It’s been repeated ad nauseam, but it’s still so hard to internalize for most product people: Speed is a feature.

Usually, it’s one of the most important features. Yet it’s also one of the hardest to get right. Chiefly because every other feature is generally at war with speed. Any excess CPU cycles are quickly captured by new, advanced, and ultimately slowing features. Extra cycles are like a surplus government budget: The constituency is going to have a thousand ideas for how to spend it.

It’s not easy to get this balance just so. You have to be fast at what people want and expect. Being the fastest phone running iOS5 or Window OS isn’t going to get you any business.

Comparing this RAM apple and that 3D Touch orange, though, is also a worthwhile reminder that good product design doesn’t deal in distinct categories. It’s all a fruit salad! Customers just want it to be delicious and nutritious.

A rallying cry for the Weird Wild Web

Jonas Downey
Jonas Downey wrote this on 2 comments

This year, 2015, marked the 20th anniversary of the first time I stuck some HTML on a server and put it out for the world to see. (Sorry about that one, world.)

Twenty years! Twenty years is a long time to do anything, especially in tech. Given how fast things churn, it’s rather unbelievable that I’m still gainfully employed to write HTML for anything at all in 2015.

I’ve been reflecting on this recently, as the web’s future keeps sounding rather bleak. It seems that nary a week passes without someone predicting the end of the open web as we know it. Perhaps understandably so — at a glance, the web appears to be suffering a death by a thousand cuts.

Let’s recap a few of the most common arguments for why the web is totally screwed.


Cargo Culting

Nathan Kontny
Nathan Kontny wrote this on Discuss

I've been exploring Medium as a new channel for my writing. It's a pretty place to read and share my thoughts – though still written on Draft :) – and getting more and more popular. Yesterday I shared a post: Poison, which received some nice traffic and shares. A couple people began to comment. And that's where I started getting confused.

There's a comment, what Medium calls a "response", but it's not the full comment. In fact, I have to click Read More just to get to the meat of it. When I read the comment and wanted to respond, that even was a new affair, encouraging me to Publish or go Full Screen:


Work in Progress

Nathan Kontny
Nathan Kontny wrote this on 7 comments

Jason and I have now done 18 live chats we've published on YouTube and SoundCloud and we still like each other! :) Just to be transparent, it hasn't been a piece of cake. It's a whole new environment for us to figure out. Not just how to get subscribers. But things like picking topics. Staying interesting. Even things like lighting. Barking dogs. Poor internet connections. Sleeping in-laws. But it's a constant reminder how much work goes into any product. There's always a new challenge or opportunity to learn to get better. It's never done. It's a "Work in Progress". And waiting for perfect is a sure way to fail to get anywhere. Here are some of my favorites of the episodes we've done so far:


Putting on the shipping goggles

Jason Fried
Jason Fried wrote this on 5 comments

One of the biggest challenges of shipping a product is knowing when to put on the shipping goggles.

The shipping goggles make you less sensitive to little nits and scrapes and things that might be able to be a little bit better, but really don’t need to be right now. Stuff that we could tweak, but really shouldn’t be grabbing our attention given all the other high value bits we need to hit.

It’s sort of like squinting – you lose the detail, but you can still see the overall big picture shape, form, and function. Your peripheral vision shrinks, but the center is still bright. Knowing when to squint is a good thing to know.

It’s not that the details don’t matter. They do, but details aren’t fixed – they’re relative. And of course any time you talk about details mattering, you’re speaking in very broad generalizations. Some matter, some don’t. Some never matter, some matter later, but not now. And some really matter now and can’t wait for later. Like everything, there are varying degrees.

Part of training yourself to ship is to recognize what details are really worth nitpicking and when. There are no hard and fast rules here – it just takes judgement and experience. These are skills that build over time. Once you’ve been around it for a while you tend to improve your sensitivity to what’s worth doing before you ship and what can wait until later.

And BTW, nitpicking may be construed as a pejorative, but I don’t believe it is. Nitpicking is a valuable skill, as long you deploy it at the right time for the right reasons. One of the penalties of nitpicking at the wrong time is that nitpicking often attracts a crowd. Someone nitpicks this which is an invitation for someone else to nitpick that. And before you know it, half a dozen people are spending time discussing tiny details that really don’t demand that level of attention.

Again, there are no facts around when it’s worth nitpicking and what’s worth nitpicking – I’m only speaking to the awareness how situations unfold.

We can all get better at this. I’ve been shipping stuff for years, but I still have to get better at recognizing the right moments to bring up certain things. I definitely fall into the trap of spending time making changes to things in the 11th hour that are really perfectly fine and can be addressed later if necessary. I absolutely find myself regretting going down a rabbit hole that really didn’t need to be investigated. I still find myself distracting others with change requests or suggestions that really didn’t need to cloud their vision and sap their attention. It’s hard!!

As we close in on a big launch ourselves, I’m reminded of how important it is to keep time and place and impact in mind when bringing small things up. Again, it’s not that they aren’t important, it’s that they may not be important now. Everything has a cost and the cost of breaking attention goes up during crunch time.

Extra Drawings for The Distance

Nate Otto
Nate Otto wrote this on 1 comment

Last year I shared some extra drawings I made for the Basecamp marketing site that for a variety of reasons never went live or were seen by anyone outside of Basecamp. There have also been many drawings for The Distance that have never seen the light of day until now.

For just over a year, The Distance was dedicated to longform articles about long standing businesses. Under the editorship of Wailin and the art direction of Mig, I made a header illustration for each article and a building drawing that served as the footer. In recent months, The Distance has morphed into a podcast. I still illustrate the cover for each issue, but the header illustration is no longer needed. I like to tell people that I illustrate a podcast, and then I wait to see their reaction. There were a few issues that were both a podcast and a longform article. Here are some of the extra drawings made for those articles and then a link to each corresponding podcast. I’m also hoping to show some of the collaborative process and how we use Basecamp together as a team.

World’s Largest Laundromat

The finished header looked like this. I got a creative brief from Mig with some of the concepts of the story that he wanted to see in the header, and he also shared some visual inspiration, including some anthropomorphic washers and an animated gif of spiraling bubbles. The theme that I latched onto was that this is the world’s largest laundromat, so I knew I wanted to draw a big washing machine. The first image I drew was of a washer amidst a field of bubbles, but that didn’t read well and it didn’t really say anything.

I tried another one with a washing machine looming large on a street with residential buildings. Drawing buildings is my jam so I was playing to my strengths here, and I thought it worked conceptually. I shared it on Basecamp and…

I was ecstatic that they liked the drawing, and that the header came together so quickly. As you will see, it doesn’t always happen that way. I colored in the drawing and that became the final image. I had some time and I was still thinking about washing machine people, so I made the additional drawing of a washer with a top hat!

Ideal Box Company

The final header looks like this.

This article is about a box company that makes a lot of point of purchase displays. I kicked off the to-do with a drawing.

Wailin shared a copy of the story then and she broke down some of the key points and themes. She also shared a few ideas for me to try. I did this drawing but I knew that it didn’t hit on many of the themes (even though I initially tried to champion it).

Mig then chipped in with a winning idea followed by some other points, but I latched on to his origami concept.

Even though I’m relatively inexperienced in editorial illustration, that doesn’t always stop me from being overly opinionated about their purpose. I ranted about that on the thread a little bit. Artists are the worst. In the end Mig is usually right.

Victory Auto Wreckers

The final header looks like this.

I got a copy of the story and some thematic ideas from Wailin: the afterlife of a car; use every part of the animal; from junkyard to recycling center; and new commercial. That gave me enough to sketch out some ideas.

Mig liked that idea but he wanted to see it more dense with car parts.

Mig wasn’t sure about the car in 3D space, so he wanted me to try one flat but with more parts.

I drew up this, and it evolved into the final image.