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.

Mister Default

Here he is: our default profile picture. You may know him as “Generic Avatar”. He’s the picture you get when you create a new account and profile on Basecamp, Highrise, Backpack, and Campfire. Mr. Default is a standard guy. He’s found everywhere on the web (in variations): message boards, comments, activity streams.

He forces everyone to look like him regardless of gender, race, and physicality. He’s also very boring.

Time for a change

People don’t usually have a picture on hand to change the default avatar. What happens is none of the default pictures ever get changed. Basecamp looks boring when everyone is Mr. Default. Splashes of color and personality from peoples’ pictures bring life to a product.

We want your first experience with Basecamp Next to be colorful, welcoming, and friendly. First, we’ve improved the flow for replacing the default avatar. Additionally, we’ve improved the default profile pictures. Say goodbye to Mr. Default.

Literal Icons

Initially I thought about approaching the pictures like the game Monopoly. Everyone has a different icon much like the pieces in that board game: an iron, a thimble, a race car, etc. Here are some sketches from that session.

I had been experimenting with a painterly style for a different project, so I tried that with this literal icon imagery.

Jason Fried’s feedback: Having literal and distinct icons might cause people to want to switch one out with another, or not find a suitable match. Would we need to build an interface to “choose your default icon”? Too complicated. Maybe we should go abstract.

37signals Office Surface Textures

Another idea I had was to try our office surface textures. The 37signals office is made of so many great materials. Basecamp is basically our office. Perhaps it was worth a try.

Jason Fried’s feedback: We want people to see Basecamp as theirs not ours. This isn’t about 37signals. Who wants to be represented by cork? Also the imagery feels too masculine. Let’s go softer and more cheerful.

Abstract Paintings

I liked the painterly style of the first batch of icons. They were colorful and cheerful. What if I tried some abstract shapes and patterns?

Jason Fried’s feedback: These are closer. The patterns might be too distracting. Try shapes and lines like that one on the upper left.

Refining the Abstract Paintings

Concentrating on shapes instead of patterns was a big breakthrough. The shapes started to take on face-like features.

Jason Fried’s feedback: Loving these. These are great!

Jason Zimdars’ feedback: When I see these I think of cars. The headlights and grill make a face. I wonder how they’d look with a slight smile?

I’m very happy with the way these default profile pictures turned out. When someone creates a new Basecamp account they will be randomly assigned one of these custom painted pictures. As you’d expect, each picture can be easily swapped with their own personal photo.

The difference now is straight away, out of the box, Basecamp will have color, personality, and vibrancy as you start managing and completing your projects.

“If a customer asked you why, how would you answer?” This is a question I’ve been asking a lot lately. Why could be “why does it work this way?” or “why can’t I do that?” or some variation on that theme.

I think your answer to those questions is a great way to measure your product. Are you happy with your answers? Are they fair answers? Are they clear answers? Would you be happy with the answer if you were the one asking the question?

The goal isn’t to get to “Yes” on every answer. The goal is to listen to your answer and ask yourself what it really means about how you approach product development.

If the answer is something like “well, because it was too hard for us to make it work the way it should” or “because we couldn’t figure it out” or “because we didn’t spend the time to think about the problem thoroughly enough” or “we just didn’t feel like putting in the work to make this easy for you” it may be a red flag.

Now, sometimes those are just truthful answers. Every decision involves a sacrifice. You may have had to sacrifice some thoroughness here so you could be more thorough there. But when answers like that pile up it’s worth looking yourself in the mirror and ask why you’re satisfied with answers like that.

This approach is especially helpful during product development, prior to launch, when many things are still in flux. This is the moment when you should be asking these questions repeatedly. The more you ask, the more you have to consider, and ultimately the better decisions you’ll end up making.

We’ve been working on Basecamp Next since March 2011 and we’re getting close to the public release. The private beta is now in full swing.

Early iterations on the Projects screen

We thought it might be fun to share some of the early design explorations for one particular screen, the Projects screen. Basically, the projects screen is a list of your projects. You can create new projects there as well. We explored hundreds iterations of the screen – from small tweaks to fundamental shifts in the feature itself. Only a fraction of the explorations are shown in the video below.

What you’re seeing here are discarded ideas. But new ideas are often built on old ideas, so you may recognize some of the design concepts you see here in the actual final product.

Back when 37signals was consulting, we gradually weaned ourselves off of documentation. It’s normal practice in the design world to produce lots of artifacts. You see IA diagrams, flow charts, OmniGraffles, and all kinds of illustrations of what the final product will be. In the early 2000s we noticed that our clients only cared about the deliverable, so we dropped nearly all of the paperwork.

Since then we’ve often advised other companies to spend less time on paperwork artifacts and more time on real prototypes. But just saying that isn’t enough. How does a team that is accustomed to a heavy paper flow wean themselves off of it?

I used to think design teams made so many diagrams and documents because… well, they like that sort of thing. Now I’m suspecting there’s more to it.

A symptom of a bottleneck

I’m suspecting documentation is a symptom of something else: a bottleneck in the value chain. Think about it. Design ideas are perishable. They have to be acted on right after they appear, or they fade away. So what happens when your development process can’t absorb design ideas at the rate you produce them?

It looks like a dilemma. You either:

1. Produce design ideas at the pace of development (which is far slower, by definition of the bottleneck) or
2. Freeze ideas in the form of documents, diagrams and requirements until they are ready to be thawed and consumed later.

I suspect #2 is what happens in a lot of firms. The throughput from design to implementation in those places is so low that pacing design with development doesn’t seem feasible.

At 37signals we’re firmly in the #1 camp. Designs go from concept to HTML (often in-app) without any deliverables in-between, and then from HTML mock to fully implemented feature in Ruby or JavaScript again without intermediate artifacts.

Healthy pressures on design, programming and scope

Pacing design with development puts a few pressures on the company that we think are healthy.

First it means all the designers should be proficient enough with code to implement their ideas, at least statically.

Second, the programmers should have enough skill and leverage from their tools (an important factor) to produce meaningful work in short periods.

The third point concerns how we manage and define scope. In order for design, implementation, and review to all happen while the plate is still hot, each piece has to be small. If we bite off too much work at once, then design will go on too long before development can join in. When there’s too much to build at once, review becomes unfocused because the set of variables to evaluate is too large. So whether the project is small or large, we factor the scope into smaller component scopes, build them one at a time based on their dependencies to each other, and evaluate the results step by step using the app ourselves.

The ideal loop

The ideal loop is short enough that you can still feel the spark of your idea and you’re still curious to find out if the decision was right or not as you click through the implementation. You can’t fully judge a design until you’ve tried it in action. The clothes simply look different when they’re on. If there are too many changes to evaluate at once, we can’t tell which of the changes contribute to the improvement or regression and how those changes suggest future steps. Moving in one direction in one feedback cycle is easy. Moving in ten directions in the same cycle is too hard.

I hope this look at our process gives you a clearer picture than a bare statement like “documentation is bad.” Documentation may be necessary when your throughput is low, and that’s an opportunity to see documents not as charming deliverables but as warning signs of a deeper problem in your process.

Yesterday I spoke with a software company that is strongly motivated to improve their interface design. They asked me where good software UI designers come from and who could I recommend to help them out.

From my little bubble, I couldn’t think of anyone to recommend outright. I know some good folks who are already employed. But a “go to” consultant? Not really. A school with good curriculum to scout at? Couldn’t think of one of those either.

So I tweeted to a sizable circle on Twitter. In response, I got less than ten actionable leads. I figure it’s time to cast a wider net.

Who out there is doing great UI consulting for software businesses? Who is doing UI training? Where is the good UI curriculum?

If you know of somebody, help me out and post a comment here—preferably with a personal experience. Thanks.

When we needed a creative shop to help us with this year’s holiday gift, we turned to Scott Thomas and his crew at Simple.Honest.Work in Chicago. They did a fantastic job putting together the concept and building, printing, and assembling the final packages.

Shaun shot a behind-the-scenes film of the final stage of the project. Here’s how they put it all together:

We’re looking forward to getting some postcards.

A safe holiday season to everyone. Take care.

We’re working on something new over here. We’re stuck on the design for a certain screen. Over many months we’ve probably been through a dozen concepts with dozens of minor tweaks to those concepts.

In all this work, and all the usage, and all the trials, and all the tweaks, I’ve spotted a pattern. Things that look good at the end of the day often don’t look good the next morning.

The end of the day has a way of convincing you what you’ve done is good. The next morning has a way of telling the you truth.

And that’s fine. Design is a process of experimentation and elimination. You should be excited to have your mind changed and throw things away.

This isn’t news, of course. “Sleep on it” has been great advice since forever. But it’s been a good reminder that the next morning isn’t just a block on the calendar, it’s a great design tool in itself. Use it to your advantage.

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.

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.

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!

This weekend during the Ravenswood Art Walk, I visited Lorna’s Laces. They hand-dye yarns in some really beautiful color combinations. I took some photos to share, because sometimes it’s nice to look at pretty things!

Designers, how do you put colors together? Where do you find inspiration?

One of the best things about CSS is the cascade, itself. It can also be one of the worst things about CSS. Styles applied to an HTML element are automatically inherited by their children. Cascading is what allows web designers to set styles and keep them consistent throughout a website without repeating themselves. With a single line of CSS you can, for example, set the typeface that will be applied to every element on every page of your website:

body {
    font-family: Helvetica;
}

Because every element is a child of the body, those elements will inherit the font style unless that property is otherwise overridden with a more specific rule. That’s where things get tricky. We might want to use Helvetica throughout the website except in the sidebar, where we’ll use Georgia. To reset the font-family rule for the sidebar element we must write something like this:

body aside {
    font-family: Georgia;
}

This is how we write CSS. We set styles at the top level and then proceed to override the inherited rules with increasingly specific selectors. There are esoteric rules of inheritance built into the CSS cascade that let designers target elements by id, class, or by relative position in the document. Each time you reset a style using specificity, overriding that style on a subsequent child element requires an even more specific selector.

Within complex website designs this can begin to feel like an arms race. You add classes and containers to your mark-up and more elements to your selectors. As you add increasingly specific (and increasingly long) selectors it becomes equally difficult to override them later. This problem is compounded after the initial composition of the CSS is completed and you begin to edit, maintain, or add new styles later in the life of the website. Even in the most carefully composed stylesheet it can be difficult to completely grasp the overall scheme – especially if you’re coming in behind the original developer to make changes. The safe thing – we’ve all done it – is to write a very specific selector for any new styles so you’re certain yours take precedence. Each round a salvo in the specificity arms race.

So what can be done? We’ve been experimenting with a few techniques that we think make a big difference. There are three parts to this formula: compiled CSS, structured mark-up, and a neglected CSS selector.

I was just reading the Economist on my iPad at lunch, and I’ll be damned if that’s not one of the best-executed apps on the platform. I’m impressed over and over by how simple and perfect it is.

The experience is massively superior to print. No issues piling up, no guilt when you only read half an issue, nothing extra to stuff in your bag, new issues available to download the second they are released, and so on.

And the app doesn’t have any of the downsides of other magazine apps. The typography and layout and illustrations look beautiful and they exactly match the print magazine. It feels 100% like the real Economist, not a digital imitation. The app is lightning fast and just the tiniest amount of chrome frames the page for navigating.

I don’t get to say this often: it’s a perfect execution.

Tap an issue to read it.

The world this week.

Layouts just like the magazine.

Beautiful features stories.

Link: The Economist on the App Store.

I was an A/B test skeptic. Maybe we don’t want to be second-guessed. Maybe we don’t want to cater to the lowest common denominator. Designers are taught—explicitly and implicitly—to follow certain visual rules and the final design will work great. The whole A/B testing concept probably came from from “strategy analysts” or “MBAsses”. Anyway, now I’m a believer in A/B testing.

How I Learned to Stop Worrying and Love the Bomb
Designers, you’ve been in critiques where Clients, Art Directors, Creative Directors, Project Managers, Copywriters, Executive Assistants, and other Designers have picked apart your work. You listened with agony when they questioned your choice of this shade of red or this typeface. You winced when they said that photograph wasn’t “right”. Your vision is already changing based on a series of opinions!

Next time say, “I hear your concern about the shade of red. Why don’t we test that? I feel strongly about the color red, but it sounds like you need to be convinced it won’t affect X.”

Increasing our Signups through A/B Testing
A few weeks ago Noah and I talked about the testing we’ve been doing with the Highrise marketing site. Here’s a summary of the findings we posted:

37.5% more people signed up for Highrise with the Long Form design.

Jason Fried’s mantra while testing was: We need to test radically different things. We don’t know what works. Destroy all assumptions. We need to find what works and keep iterating—keep learning. (I’m paraphrasing here…) We tried out a radically different design with these results:

The Person Page was far shorter. There was less information about Highrise. However it had a 47% percent increase in paid signups than the Long Form design. Why exactly was the Person Page working? What might happen if we added more information to the bottom?

The crazy thing was when we added more information to the bottom of the Person Page it performed over 22% worse than the original design!

Changing People
Jocelyn from One Design—a Chicago design company—could also be the secret sauce to the effectiveness of the design. Her quote is direct and simple. She looks friendly and very non-techie and approachable.

I got in touch with more of our wonderful Highrise customers to see if some would be interested in posing for our homepage. Michael, an accountant at MWC Accounting; Will, a programmer at Tall Green Tree; John, founder of Revolution Management; Mari, owner of Foiled Cupcakes; and Brian, owner of Nutphree’s were gracious enough to have me interview them for the site.

I was curious to see if Jocelyn was the key to the winning design. Here’s how she fared:

Conclusions

• Big photos of smiling customers work
• A specific person didn’t quite matter among the set of people we tested

I hope you gained some insight from our series of behind the scenes articles. Please try to roll in A/B testing into your schedule! If you work in an internal Design Department then this is a no brainer. It’d be interesting to see Interactive Agencies add testing to the design process.

We’re still testing too. You may not notice such drastic changes to the Highrise site anymore, but trust me we’re tweaking and measuring behind the scenes. We’ll also be applying some of these findings to future marketing efforts. However, as Jason says, we will always test, improve, and learn. I want to be the first to come up with a design that beats our Person Page. Thanks for reading!

Please note: What works for us may not work for you. Please do your own testing. Your conversion rates may suffer if you copy us.

We’ve been testing design concepts at highrisehq.com since this past May. I want to share with you the different designs and their impact on Highrise paid signups (“conversions” for the jargon inclined).

We have assumptions about why some designs perform better than others. However we don’t know exactly why. Is it the color of the background? Is it the headline? We hope more iterative testing of the winners will help us get that information. If you have any theories please add them in the comments.

Note that designs that win for us may not necessarily win for you. I encourage you to do your own A/B testing. There are many tools online that make it easy to do.

The original page
The original design had served us well for the past year. Signups were going well, but we were worried that customers still couldn’t get the gist of what Highrise did and why they needed the product.

This page would be our baseline for the first round of A/B tests.

Long form sales letter
Ryan Singer posted a link to Visual Website Optimizer’s “Anatomy of long sales letter” blog post in our Campfire chat room one day. We were fascinated by this technique. If I remember correctly there was a heated debate about whether it would work for us.

We decided that in the amount of time we took to debate the technique we could have made an A/B test to prove it right or wrong. The original page had some long form sales letter techniques, but the copywriting wasn’t as strong as it could be.

Ryan and I worked together on the long form approach. Here’s what we came up with.

I’ve been a fan of interface and software designer Bret Victor’s work since Craig (one of our designers) tipped me off about him. Bret made a splash a while back with his Magic Ink paper. Now Fast Company has profiled him and his Kill Math series. “Kill Math” is all about using smartly designed interfaces to make math tangible and playful, something you can experience instead of just think about.

Have you ever tried multiplying roman numerals? It’s incredibly, ridiculously difficult. That’s why, before the 14th century, everyone thought that multiplication was an incredibly difficult concept, and only for the mathematical elite. Then arabic numerals came along, with their nice place values, and we discovered that even seven-year-olds can handle multiplication just fine. There was nothing difficult about the concept of multiplication—the problem was that numbers, at the time, had a bad user interface.

It’s a nice piece (I only wish it was longer) and Bret surely deserves your attention if you are a fan of innovative UI design.