Hey Matt, great questions.

1. There aren’t “typical” days at Basecamp, per se. It’s different for everyone that works here. Out of about 45 people in the company, only about 12 live in Chicago. For me in particular, I like to spend half my time at my favorite Chicago coffee shops, and the other half in our office. For tools, everyone has their own preferences for how they write code and design. I’d say most of the designers fire up Photoshop for image editing, Illustrator for illustrations, but nearly all of us work in a text/code editor and get our hands dirty with HTML and Sass sooner than later. Even our Customer Support team uses Terminal, Git and Markdown to update our help pages. We’re a really hands-on type of culture.

2. Regarding creative blocks, I never try to force an idea. If something isn’t coming to you, staring at your blank canvas won’t make it appear. So I take breaks. I may switch projects that only require tedious production types of tasks—or I may not work altogether. I’ll pull out a book, or my Kindle, and get my mind off code, design, and the problem I’ve been trying to solve. I think people feel bad when they aren’t working every second, and that seems a little crazy to me. Inspiration and motivation comes in waves for a lot of people—me especially. So when I don’t have it, I don’t force it. Tomorrow is another day.

3. My one piece of advice to beginners would be to dive right in to whatever it is you’re trying to learn. Basketball, the piano, or HTML. You can read about how to do something, but nothing will ever replace you actually getting in there, making mistakes, and trying all over again.

Howdy, Ruth!

Everyone in the company helps out the Support team, talking directly to our customers everyday. There’s so many great findings here alone.

And, at Basecamp, we’re users of our own products. We use Basecamp to keep track of the progress we’re making on making Basecamp better, everyday.

We feel the pains that other people do, we get frustrated by certain things others people feel, and enjoy things that other people do when using Basecamp. When you’re so close to the product—when you use it, see it, feel it everyday—you’re that much more inclined to do a better job on it. Our names and our work are all over this—let’s do the best job we can.

So we take our findings, and the findings of our customers, and give ourselves plenty of discussion points which lead to new design tests, new design ideas that we try often. Not all of the ideas we work on make it into the real world, and that’s okay with us, too. Not everything will be “great” design as you mentioned.

But we’ll never know what’s “great” design until we’ve explored tons iterations of designs and weeding out what’s “not great.”

Hey Victor,

I’d consider what you’re designing for.

• Browser
• Mobile device?
• Something else?

If you’re working mostly on browser-based pages at AOL, I think HTML and CSS is a great start. In fact, HTML and CSS is a bit of a low-risk gateway drug into getting comfortable with code, so I’m of the school that every designer should have some HTML and CSS under their belt.

Coming from Basecamp, it’s harder to recommend what prototyping tools to recommend in terms of native mobile apps—though there are plenty great tools out there. It’s part of our culture to dive right in and figure things out. Example: just a few years ago, Basecamp had never put out an iOS or Android app that was built in-house. That didn’t settle well with us, so we took it as an opportunity for any interested programmers and designers to jump right in. A few short years later, we have people at the company that are working on actual code bases for each app with skills they didn’t have prior.

But, that’s also not to say it’s up to you how “high fidelity” you want your output to be. I’ve seen incredible website and app interactions prototyped with Apple Keynote and Microsoft Powerpoint.

Jeff,

That article from 2008 is still fairly accurate to the team of now 9 designers at Basecamp in 2014. Some thoughts to further this, though.

The aesthetic of Basecamp Classic and our older apps were simpler, then. That means there wasn’t much need to use Photoshop to change a hundred boxes from light grey to dark grey when you can do one global change from #CCC to #333 and hit refresh.

Every designer writes HTML, CSS, and to many extents, Ruby and CoffeeScript Because these are our shared languages from designer to programmer and back again, we find it easier to work on the actual Basecamp codebase and collaborate using Basecamp and GitHub faster than sending raster images. In fact, working with programmers has helped all of the designers become better at code, and vice versa designers helping programmers have a keener eye for design. We really value teaching each other.

Working in code is easier for product design than marketing design. Because applications need to have a consistent visual language, re-inventing and exploring this isn’t as necessary. Great UI is consistent and familiar, so there’s no need to change these on users. So, I still whip out Illustrator and Photoshop to do rough tests and quick sketches for marketing related work. You can see how much I used Illustrator in the visual exploration and typography behind redesigning Signal v. Noise.

Hey Daan,

That’s a great question. First and foremost, please note that my answer comes from Basecamp’s perspective, and may not be indicative of other remote teams.

To start, all of Basecamp works remotely—even the 12 employees who live in Chicago out of the 45+ who work at the company. So to directly answer your question, our design teams do indeed work remotely—and we work together, and with other programmers in this way.

Our remote working setup is a bit like this: - We share work on real code bases on GitHub - We share process, progress, and visual decisions on Basecamp - We chat on Campfire everyday - We have individual conversations with Messages/Jabber

That’s really about it in terms of our communication tool set. Now, to further this.

At Basecamp, to be a designer—product and marketing—means you wear a few hats. - Designers write their own copy. - Designers write their own HTML and CSS. - Designers sketch and prototype interactions with CoffeeScript. - Designers craft the visuals and aesthetics.

Now, this doesn’t mean every designer at Basecamp offer the same exact skillsets. Quite the opposite! Jamie are relied on more for visual and graphic design and marketing, yet we both work on product features. The other designers may be better versed in native app code bases and UI designs, so we default to them to work on new features and new products. It’s a balance of skills with our ever-awesome design team, and we complement each other well.

But I’d be remiss to say that everyone in Basecamp is wildly talented, and inspire the hell out of me. You can meet them here: http://basecamp.com/team

No.

Hey Keaton,

Fun question, and one I think about pretty often.

Moving from Marketing design to Product design felt, at times, like changing careers. Marketing design is selling something you make. Product design is making something you sell.

There’s so many lessons learned, and I’m still learning everyday. Here’s a few off the top of my head.

• In Marketing design, I learned to spend a lot of time crafting stories and carrying a narrative. I worked a bit slower, and spend more time crafting words and visuals.
• In Product design, I learned to move quicker, try different iterations faster, and allow myself to have my work feel less precious. Product design isn’t about winning awards or being noticed, it’s about getting out of people’s way and doing the right thing as opposed to the most clever thing.
• Marketing design is “what do people want to know?”
• Product design is “what do people need to do?”

Of course, this is a huge topic with plenty of opinions, room for debates, and plenty more perspectives. But these were a few quick ones that come to mind.

Hey Thomas!

First and foremost, I love using GrubHub. Keep up the good work, because you guys keep my tummy full and happy.

I really loved working on The Distance because I had full control of the art direction and design process.

How it all started… - Jason Fried had long since wanted to start a new publication to celebrate long-standing businesses. So we decided to press on with this idea. - He asked if I wanted to run the show on the design side, and I gladly hopped on. - We hired a very talented journalist and writer in Wailin Wong to research, report, and write all of our stories.

About the first version… The first version of The Distance featured individual custom-art directed designs for every story. This was super fun, but super taxing. So much effort goes into designing unique layouts per story, it started to get a bit unwieldy. For me. I’m the one responsible not only for the visual design and art direction of each story and the site as a whole, but the code and development of the entire site, too! So I made a lot of work for myself up front.

Last week, we launched a brand new version. I’ve since redesigned The Distance to be more uniform, making it easier to hop to any story at any time. Visually, I wanted to lean more on the lovely work of our in-house illustrator, Nate Otto, and redesign the site so that it’s less about the visuals and more about Wailin’s writing. We’re really happy with the refined results.

On Editorial Design versus Product Design… Editorial design is one thing I was fortunate enough to study when I was a student. The careful consideration of space, typography, and an emphasis on the reading experience is really where Editorial design differs from Product design.

Editorial design wants to be read, consumed, and enjoyed. It screams, “Slow down. Read me!”

Product design wants to be used, and out of your way so you can focus on whatever task you have at hand. It whispers, “Hey, I’m here for you. Here’s where you want to go, I’ll be here if you need me.”

Both types of design if done well—like any great design—should actually go unnoticed.

Hey Oz,

Thanks for the nice note. I agree with the mentality of “just doing it,” for sure, there’s no replacement for experience. But…

In terms of how, which is a great question for everyone, I follow my motivation when I have it. Somedays, I’m not interested in doing work—or I just don’t have the energy. Other days, I can’t keep my hands off the keyboard. Here’s a couple of things I’ve noticed about myself when I work.

Work when others aren’t. The early mornings or late nights afford me distraction-free focus time. These are often my best, most productive times. Plus, it helps make me feel less guilty looking at Facebook at 12pm in the afternoon knowing I either did some good work early, or am ready for good work later in the night.

Work in unusual places. I like to work in other people’s offices, different cities, and coffee shops when I’m trying to explore new ideas. When my environment feels routine, I tend to feel stuck myself. One of my favorite aspects of working in a coffee shop is that I get the feeling of having coworkers, yet none of them know who I am, need to tap me on the shoulder to ask if I received that one email, etc.

Jonathan,

Good question. I really enjoy when I find moments of serendipity doing the work as opposed to looking for inspiration for the work.

In my classes I teach, I encourage every student to study great work that has come before them. Chew on it, figure out why they did what they did. I still do this, too. But I’m always asking two things:

• Why does it have to be this way?
• What if we did this weird thing instead?

So in a recent example, I worked on the Basecamp.com signup page. Here’s the dialogue to myself:

• What if this still illustration of the man moved instead?
• What if it was more fun, and he made funny faces on errors?
• Oh, also, what if I learned enough JavaScript to do this on my own?

And questions like why can’t I do this on my own? and why the hell does everyone squish their browser to see responsive design shaped projects like jQuery.wanker.js.

So, those moments of connection happen when I keep digging, keep asking questions, and connecting things that never seem relevant before.

Hey Mitch!

How fun, we’ve followed the same paths so far.

My best advice for someone in college getting ready for the workforce is to do the work you want to be doing now.

If you want to work on the web, do projects either personal or through school that help you fill your portfolio with web-based work.

Likewise, if you’d rather be doing logos and branding, make sure you do that kind of work and show a variety of it.

We get hired for what we’ve done, not what we want to do. So even if you don’t have opportunities to do “real” web work, invent some projects for yourself to get you started!

Kelly,

What a tough question. Some challenges we face:

• Staying relevant in a growing industry
• Keeping up-to-date on ever-changing technology
• Wondering where we go next

This is all so new to us, and I think it always will be. We should worry when we start to feel complacent with the things we’re doing. And that’s a blessing and a challenge.

Marcus,

Thanks so much, I’m glad you enjoyed the talk. You don’t need permission from anyone to break, hack, explore, and play on your personal projects.

Keep this in mind, because a lot of the skills, techniques and ideas I’ve learned in my career have come from personal projects. Best yet? I was hired at Threadless and 37signals because of the passion and dedication I put into so much of the personal projects—all while still doing a good job at my day-to-day.

People recognize effort and craft. If your currently employer doesn’t, it’s their loss. Because someday soon, someone else will.

Jarrod,

Thanks for the kind words.

It depends on the comfort-with-code level of the designer, but these days, I do believe every designer is working with code in the actual Basecamp code base. (On its own separate branch with Git, of course.)

HTML is the shared language between designer and programmer, so more often than not these HTML designs are in local copies of Basecamp running on all of our machines.

Designer: “Hey, I made a design update to the form when you enter to-dos.” Programmer: “Awesome! I’ll pull down your branch, review, hook it up, and pass it back.” Designer: “Thank you! Let‘s celebrate with pizza.”

Ruby,

I think everyone has a leg up if they know how to sell. This may be the first time I’ve ever quoted Mark Cuban, but I really do agree with him that, “If you know how to sell, you’ll never be unemployed.”

Keep in mind… - You’re selling yourself as a capable interaction designer - You’re selling your design work to a product manager or creative director to say “this is the right thing” - You’re selling your work to clients saying “we’re experts”

So yes, I think everyone—not just designers—should know about about marketing and selling!

CJ, great question.

I don’t think I’m an engineer or “developer” by any stretch. I’m very fortunate to work with really smart, talented, brilliant ones. I do think that having a foundation in front-end coding can only help designers working on the web today. At many companies—Basecamp included—it’s actually a requirement that you can code HTML and CSS if you’re a product designer.

To further this discussion, while I think it’s good for designers to know code, there are plenty of designers doing great work that don’t know a lick of code, and frankly aren’t interested in learning it. That’s okay, too!

Whenever I describe myself, I always say designer. HTML and CSS are just some of my design tools.

Wes, Happy Wednesday!

The design of my personal website is a product of my formal graphic design training. I didn’t try too many things. Secretly, I think working on projects about or for yourself is kind of the pits. It’s so hard to get through, and there are never any real deadlines.

So, I went with my gut. I called back on my traditional typographic training and tried to bring back the aesthetics of print back onto the web. Careful use of horizontal spacing, fine type treatments, and not a whole heck of a lot of color.

The web today starts to feel the same… - Huge, full-width lifestyle photos - Three-columns of text with an icon over it - Image left, text right, Image right, text left, repeat…

I just wanted to do something a little different, and being “a little” different just meant going back to something I was used to: traditional print.

My entire website is open sourced on GitHub, by the way.

Working at Basecamp (and Threadless) is totally different from my experience working in an agency environment.

On designers coming up with projects to work on versus fulfilling specific goals and feature requests… It’s a mix of both at Basecamp. Everyone—designer, programmer, support or otherwise—are always encouraged to try new things, invent fun projects for themselves, and make things that shake up our usual workflow. But of course, we have a responsibility of making Basecamp the app better every day. So we all try to make sure we’re doing the day-to-day “make Basecamp better” work while finding time for “it’d be awesome if we did this, too…” work.

On the process for designing… Our process is a little bit messy, a lotta bit exploratory, and by no means locked into place. We have about 9 different designers with different aesthetics, different ways of thinking, and different ways of starting (and finishing!) projects. What we share in common, though, is that we constantly try new/weird iterations of ideas and share every one of those. (On Basecamp, of course!)

Conversation may go a bit like: - Here’s the button this way… - Here’s the button this other way… - Here’s if we had a text link instead of a button… - Actually here’s this crazy illustration instead of text… - Here’s me making all of that super tiny and green… - Here’s me making all of that super huge and red… - I like this particular version the most, what do you think?

Sorry Ryan, Markdown looks busted here! Hope this helps, though.

Hey Greg, great to hear from you! Brooklyn Beta was such a good time, so many congratulations need to be sent to Cameron and Chris for what they were able to put together.

I’m not speaking any time soon, but totally open to it. I think this talk I gave at CreativeMornings may be one of my favorites.