A fine line exists between spelling out company culture and inadvertently engraving it as policy.

Culture offers your staff the company blog’s “publish” button 24/7 so that they can write when their own iron is hot. Policy forces topics and a posting schedule to chip away at the company marketing quota.
Culture inspires your programmers to discover typographic rhythm and scale in their free time. Policy puts a “lunch and learn with designers” meeting on your calendar at 12:00 PM.
Culture nurtures pet projects so that they grow into everyday company tools. Policy steals 20% of your staff’s work hours to gamble on forced research and development.
Culture does. Policy says.
Culture encourages. Policy requires.
Culture empowers. Policy mandates.
Culture simply happens—it isn’t created.

Since its launch, the all new Basecamp hadn’t had a dedicated Help site that was actually, well… helpful. Last month, the Support team and I changed all of that.

The previous, crusty excuse of a Help page we had for Basecamp was:

• A list of answers to questions no one was asking
• A dead end that didn’t encourage discovery
• A mystery to our Support team because they couldn’t update it

It needed an upgrade. It needed a rewrite and redesign. It needed to put power back in the Support team’s hands.

Click away from the pen tool…

Put down your Pantone book…

Stop rearranging your layers…

Close your stock texture folder…

Log out of your Dribbble…

And god dammit, hug your copywriter…

Designing for the web is still about words.

As an ad-agency refugee, I’ve struggled with my fair share of design debates with copywriters, project managers, clients, and everyone in between.

Maybe you’ve been there, too. The copywriter you’re paired with doesn’t think the marketing page you’re working on “feels right yet.” (As it turns out, the tone of voice is just off.)
In dramatic fashion, your client thinks the design you just presented is “way off base.” (You just happened to use a color they absolutely detest.)
It’s been five years since I’ve had a client meeting, yet the road blocks of vague feedback still come back to haunt me within the programmer to designer relationship.
The other day, Nick and I were debating the look and feel of shared code snippets. Or, so I thought…

Last month we launched the redesign of our blog. During the process, we wanted to make it feel distinctly ours with a visual nod to its very name—signals and noise.

I wanted our blog to feel special, aesthetically unique, but not gaudy. I took a quick survey of our blog structure and found a great area for opportunity to explore style: our post categories. From design, programming, business, support, writing, to sysadmin, anyone from our team can categorize a post they write.

To give each post an identity, I riffed on these category themes. From there, the obvious presented itself: try illustrating waveforms to harken back to “signals and noise.” Although I had a focus on illustrating, I still started with words, and more specifically, questions to myself.

What does “writing” look like?

So, with Illustrator fired up, I started generating waveforms that would wear the identity of “design,” “programming” and so on. It quickly became an exercise in shape, color, and line densities. The process was fun, and the results were full of surprises.

Since the day The Starter League opened their doors, people from all over the world have traveled to Chicago to learn how to program web apps.

It didn’t take long before design-focused classes made their way into the curriculum. In Carolyn’s class, people learn how to research and shape great user experiences. Shay’s class takes those experiences and turns them into something tangible for the web. Now we’re thinking there’s room for even more. Today, we’re excited to announce the next addition to the growing list of design offerings at The Starter League.

We’ve been sharing our process and company values on Signal vs. Noise since 1999. It’s where we’ve planted the seeds for Getting Real and REWORK. And for many readers, it’s their first taste of 37signals. Yet, we haven’t given the look and feel any serious attention since 2005.

So I decided to tackle a much-needed redesign. In planning the overhaul, I wanted to focus on creating a beautiful, clear, focused reading experience.

Designing Outward

“Blog” has such a temporary, read-and-forget tone to it. On SvN, we take our time writing and editing every article. So rather than treating this like a “blog,” I shifted the mindset to that of a tenured publication. So, the entire redesign process started with typesetting the post, and designing outward.

Instead of poring over other blogs, I spent a week studying books, magazines, and of course, Bringhurst. Capturing the right feel for body text was step one—it sets the tone from here on out.

Perhaps it’s me, but there’s something about 13px sans-serif faces on the web that feels like “my Rails app just spit this out of a database.” I want you to read articles, not text rendered on a screen. Kepler, set at a comfortable size, wound up being a beautiful serif that added the touch of humanity I was looking for. Setting the headlines in Acta added to the look I was going for, and Freight Sans wound up being a great sans-serif pairing.

After a flurry of scrapped ideas and illustrations that may never see the light of day, I survived my first month designing at 37signals.

Joining the team in the heat of relaunching our flagship product, it comes as no surprise that everything has been hands-on and fast-paced.

My first week

• Monday → New computer day. (13” MacBook Air + Thunderbolt Display)
• Tuesday → Remove my Git and Ruby training wheels with Trevor.
• Wednesday → Screenshare with JZ, brush up on SCSS and CoffeeScript.
• Thursday → Redesign SvN for mobile. Commit code. Beer.

A typical day