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

Signal vs. Noise: Design

Our Most Recent Posts on Design

Behind the scenes: From Herding Cats to Finishing a Project Together

Jamie
Jamie wrote this on 4 comments

Nate Otto and I made a new Basecamp homepage illustration based on a vector drawing I made in Adobe Illustrator. Initially I didn’t intend it to be hand drawn. I thought I’d refine the vector drawing. Somewhere in the middle it turned into “herding cats”. In the end the spirit of the concept was intact, but the result very different from what I’d envisioned.
Here’s how we got to the final idea: Basecamp helps you wrangle people with different roles, responsibilities, and objectives toward a common goal: Finishing a project together.

First pass: Basecamp is a central hub. All the things going into it are like train lines.

Train lines are pretty boring. What if it was about herding cats? Lemme put some vector cat heads on there.
The vector style doesn’t fit with the rest of the site. I work with Nate on the idea of Basecamp as being the ultimate “cat herder”. Give the cats some human accessories…
Jason Fried is concerned that “herding cats” may come across as insulting. The idea of herding cats may be lost on some potential customers. Maybe we should just be clear.
Final: Let’s add all the people involved in the process.


This process took about one day of back and forth (in Basecamp) between me and Nate. So, that’s how we made the illustration for the idea: Basecamp helps you wrangle people with different roles, responsibilities, and objectives toward a common goal: Finishing a project together.

Solo

Nate Otto
Nate Otto wrote this on 6 comments


About five years ago I consciously willed an art career into existence. At that point I had been working a social services job for about five years. I initially took the job because it wasn’t specifically art related. It was a job I could feel good about — helping people with disabilities — but it wouldn’t tap my creative juices. I had learned many years before when I got a job doing graphic design that being creative at work drained my creative life bars during my down time. This social services job would leave me with enough creative energy to work on my art when I got home, but in reality that wasn’t really happening. Furthermore, the job itself was becoming a frustrating dead end. I had learned that working in a large organization with seven direct bosses wasn’t an environment in which I would thrive. What would my next move be? I was grown up and competent. I felt as though I could do pretty much anything.

Continued…

Are we making it better?

David
David wrote this on 5 comments

A common approach to problem solving is to consider it binary. Either you’ve fixed the issue or you haven’t. Some problems fit that domain well: Either the calculator returns 2 on 1 + 1 or it doesn’t. There really isn’t much of a middle ground.

But many problems in product development aren’t like that. They’re far more hazy. Solving a problem in 100% of the cases for 100% of the people might very well not even be possible. So thinking of such problems as binary flips is not only futile, but harmful.

A better way to think of hazy problems, like “how easy is it to get started with Basecamp?” or “is the query interface for Active Record as readable as can be?”, is to focus on mere progress instead: Are we making it better?

That’s such a disarming question to pose of new initiatives. No longer does an idea have to contend with being The Solution, it simply has to contend with making things better.

It makes it so much easier to find consensus that way. Everyone sits with their own idea of The Solution, but most people can agree whether A is better than B, when both of those states are real.

Compare the concrete, make it better.

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.)

Basecamp is hiring another Marketing Designer

Mig Reyes
Mig Reyes wrote this on Discuss

We’re looking to hire a Designer to join us at Basecamp to work on all sorts of fun, meaningful marketing projects. The last time we hired for this role was when I joined in 2012. The last time before that? It was Jamie in 2008. We don’t often have openings for design positions like this, so we’re really excited to bring someone new to the team.

Note: This is primarily a senior-level graphic design position. Applications were due on February 6, 2015. Thanks to everyone who applied!

Designers at Basecamp are a fun bunch, and we all do a bit of everything. We’re not just setting type, picking Pantone colors, or pushing pixels in Photoshop. In addition to graphic design, designers at Basecamp write tight copy, plan the user experience for marketing pages and apps, and craft the HTML and CSS to bring it all together. We don’t think this makes you a unicorn, or a ninja, or a rockstar. We just think it makes you a well-rounded designer. You may not have all these skills yet, but you’re looking for a place to learn and hone them.
Designers that work on marketing at Basecamp aren’t afraid to sell. Whether it’s getting your coworkers to buy in on a direction you’ve designed, or writing copy that makes it clear why customers should choose Basecamp, you don’t shy away from the role of marketing: selling something worthwhile.

If you were a marketing-focused Designer at Basecamp, here’s some of the work you might have done:

When the new version of the Basecamp app launched, you would have lead the charge on designing a new Help site while teaching the Support team how to write the documentation for it.

When we changed from 37signals to Basecamp, you would have worked on the brand new marketing site for our exciting company change.

You would have suggested that the new name change, along with all of our new coworkers we hired in the last couple of years, warranted fresh business cards. So you made them.

You believed in supporting businesses who have lasted for generations, so you volunteered to design The Distance.

You would have found your own design’s shortcomings and months later, redesigned The Distance to make it faster to update and easier to read.

Over time and if you were feeling adventurous, you’d dive into the world of product design to add useful features including Annual Billing and storage upgrades, because making customers happy and having a positive impact on revenue is a win-win.

You’d go on to create beautiful letter-pressed invoices, because our customers deserve the best in every instance we get to talk to them.

On a whim, you’d swoop in to help Dan and Merissa make t-shirts to hand out at the latest conference we’re sponsoring. Heck, you’d even think of other great conferences and initiatives we should be sponsoring, too.

You’d give our Support team fun ways to write personal notes to customers.

You’d help plan and design the materials that went into Basecamp sponsoring the Pitchfork Music Festival. Dressing up like a camper is both silly and optional. But we’re all fun here, so you wouldn’t have thought it was weird to do so.

Some work you might do once you get here:

You’ll look at billboards like this and ask, “if Basecamp took out a billboard, what would ours say?”

You’ll encounter beautiful wall murals like this and offer, “if donut shops can have great branding and advertising, why can’t Basecamp?”

You’ll also help us make Basecamp.com feel alive and relevant, you’ll learn the ropes of A/B testing and experiment with new designs often for our marketing sites, you’ll craft email campaigns about Basecamp that people actually want to sign up for, and you might even share everything you’ve learned on this blog.

And if you didn’t like anything I just shared with you above, you’d step in to find out ways to do things better and lead with real designs you make and put out into the world.

You’ll have some of the most talented, smart, and funny people all around the world to help you do this work.

If you’re working on a new Basecamp.com landing page and have a question about trends in Basecamp signups, Noah can offer plenty of insights. If you’re curious about what our customers actually want, the entire Support team can give you a top-three list of requests at the drop of a hat. If you think a campaign at Basecamp needs great photography and video to tell your story, our video producer Shaun can be right by your side to film and shoot. We think everyone here is awesome, and we’d love to see you on the Basecamp Team page with us.

About you

You might live in Chicago, and that’s great. But we work remotely, so we’ll give you a fair shake no matter where you live. We want to know that you’ve done this kind of work before. Whether you’re coming from a big tech company or a small mom-and-pop agency, your resume and pedigree don’t matter nearly as much as the real world work you’ve put out in the world.
You may have a copy of Bringhurst’s The Elements of Typographic Style laying next to your copy of Dan Ariely’s Predictably Irrational. You may also have a stack of design, marketing, and advertising books you’re just dying for us to check out, too.
You have a love for writing, an interest in selling, a soft spot for art, and a fascination with technology. We’re hoping you also have completely unrelated hobbies that will make us love you even more.

Ready to apply?

At Basecamp, we have a long standing history of favoring candidates who put in extra effort in their applications. Whether that’s a video of you introducing yourself or making us a custom website—that’s all up to you. We want to know if you’re qualified, a good fit, and most importantly, you want this job and not just any job.
When you’re ready, shoot an email to me at mig_at_basecamp_dot_com with your design portfolio and anything extra you’d like to send along. I’ll share everyone’s applications with the team. When we’ve narrowed down our list of candidates, we’ll reach out to you.
If this sounds like you, I’m encouraging you to apply. If this isn’t you and sounds like someone you know, please pass the word along for us!
Happy Friday!

Design Discussions: Having fun with Basecamp business cards

Mig Reyes
Mig Reyes wrote this on 3 comments

I’m a sucker for “behind the scenes” articles on how other people made design decisions. They’re usually accompanied with neatly packaged lessons for everyone to walk away with.

Designing—especially during the early exploration phases—is anything but neat. There’s plenty of debates, countless iterations, and drive-by critiques.
I’m starting a new series here on Signal v. Noise called “Design Discussions.” Every so often, I’ll take a page out of our company Basecamp account and share the entire discussion behind a design project we’ve done. They’ll be raw and unedited. They might be full of insight, or they might be incredibly boring and expose the weirdness and silliness of each of our coworkers. That’s fine, too!
Either way, I won’t overly explain the reasoning behind what we were doing, nor will I share a top-ten list of things you should try in your own project. You’ll get an uncut backstage pass to the conversations that took our projects from A to B.
So, let’s start with something we had fun with. Around this time last year, we were Becoming Basecamp. With so many employees, it was high time for us to have a new identity, and that included business cards. (Chances for free lunches via fishbowl drawings, as I like to see it.)
If you happen to come across one of us happy Basecampers, be sure to ask for our card. They look like this.

Designing and illustrating the cards took a day. You can see how quickly other folks in the company chimed in to help me try new ideas throughout the day. The full-sized screen capture of the design discussion follows. Click-to-enlarge it to 100% if you’re on a desktop.

Continued…
Request an Invite | Cloudpipes.png

Playful touch spotted on the Cloudpipes invite request page. They keep a list of companies they like and show a little thumbs-up whenever someone signs up from one of those domains!

Michael Berger on Jan 13 2015 1 comment

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?

Google shows you a good time

Jason Fried
Jason Fried wrote this on 9 comments

I ordered something from overseas and checked the tracking number to see when I might receive the shipment. The results looked like this:

Since the page wasn’t in English, and Google knew I was an English speaker, Google offered to translate it for me:

So I did. Then it looked like this:

The special part… Check out the time column. They “translated” 24-hour time into 12-hour time. They knew I was in the US and that’s our preference for displaying time. So they didn’t only translate the words into English, they went the extra step and translated the time format to match expectations. They certainly didn’t have to do that, but I definitely noticed that they did.

Delightful attention to detail, and thorough definition of translation. Well done.