Move Slowly and Fix Things

Ruminations on the heavy weight of software design in the 21st century.

Synoptic Table of Physiognomic Traits

Recently I took a monthlong sabbatical from my job as a designer at Basecamp. (Basecamp is an incredible company that gives us a paid month off every 3 years.)

When you take 30 days away from work, you have a lot of time and headspace that’s normally used up. Inevitably you start to reflect on your life.

And so, I pondered what the hell I’m doing with mine. What does it mean to be a software designer in 2018, compared to when I first began my weird career in the early 2000s?

The answer is weighing on me.

As software continues to invade our lives in surreptitious ways, the social and ethical implications are increasingly significant.

Our work is HEAVY and it’s getting heavier all the time. I think a lot of designers haven’t deeply considered this, and they don’t appreciate the real-life effects of the work they’re doing.

Here’s a little example. About 10 years ago, Twitter looked like so:

Twitter circa 2007

How cute was that? If you weren’t paying attention back then, Twitter was kind of a joke. It was a silly viral app where people wrote about their dog or their ham sandwich.

Today, things are a wee bit different. Twitter is now the megaphone for the leader of the free world, who uses it to broadcast his every whim. It’s also the world’s best source for real-time news, and it’s full of terrible abuse problems.

That’s a massive sea change! And it all happened in only 10 years.

Do you think the creators of that little 2007 status-sharing concept had any clue this is where they’d end up, just a decade later?

Seems like they didn’t:

People can’t decide whether Twitter is the next YouTube, or the digital equivalent of a hula hoop. To those who think it’s frivolous, Evan Williams responds: “Whoever said that things have to be useful?”

Twitter: Is Brevity The Next Big Thing? (Newsweek, April 2007)

Considering these shallow beginnings, is it any surprise that Twitter has continually struggled at running a massive, serious global communications platform, which now affects the world order?

That’s not what they originally built. It grew into a Frankenstein’s monster, and now they’re not quite sure how to handle it.

I’m not picking on Twitter in particular, but its trajectory illustrates a systemic problem.

Designers and programmers are great at inventing software. We obsess over every aspect of that process: the tech we use, our methodology, the way it looks, and how it performs.

Unfortunately we’re not nearly as obsessed with what happens after that, when people integrate our products into the real world. They use our stuff and it takes on a life of its own. Then we move on to making the next thing. We’re builders, not sociologists.

This approach wasn’t a problem when apps were mostly isolated tools people used to manage spreadsheets or send emails. Small products with small impacts.

But now most software is so much more than that. It listens to us. It goes everywhere we go. It tracks everything we do. It has our fingerprints. Our heart rate. Our money. Our location. Our face. It’s the primary way we communicate our thoughts and feelings to our friends and family.

It’s deeply personal and ingrained into every aspect of our lives. It commands our gaze more and more every day.

We’ve rapidly ceded an enormous amount of trust to software, under the hazy guise of forward progress and personal convenience. And since software is constantly evolving—one small point release at a time—each new breach of trust or privacy feels relatively small and easy to justify.

Oh, they’ll just have my location. 
Oh, they’ll just have my identity. 
Oh, they’ll just have an always-on microphone in the room.

Most software products are owned and operated by corporations, whose business interests often contradict their users’ interests. Even small, harmless-looking apps might be harvesting data about you and selling it.

And that’s not even counting the army of machine learning bots that will soon be unleashed to make decisions for us.

It all sounds like an Orwellian dystopia when you write it out like this, but this is not fiction. It’s the real truth.

A scene from WALL-E, or the actual software industry in 2018?

See what I mean by HEAVY? Is this what we signed up for, when we embarked on a career in tech?

15 years ago, it was a slightly different story. The Internet was a nascent and bizarre wild west, and it had an egalitarian vibe. It was exciting and aspirational — you’d get paid to make cool things in a fast-moving industry, paired with the hippie notion that design can change the world.

Well, that motto was right on the money. There’s just one part we forgot: change can have a dark side too.

If you’re a designer, ask yourself this question…

Is your work helpful or harmful?

You might have optimistically deluded yourself into believing it’s always helpful because you’re a nice person, and design is a noble-seeming endeavor, and you have good intentions.

But let’s be brutally honest for a minute.

If you’re designing sticky features that are meant to maximize the time people spend using your product instead of doing something else in their life, is that helpful?

If you’re trying to desperately inflate the number of people on your platform so you can report corporate growth to your shareholders, is that helpful?

If your business model depends on using dark patterns or deceptive marketing to con users into clicking on advertising, is that helpful?

If you’re trying to replace meaningful human culture with automated tech, is that helpful?

If your business collects and sells personal data about people, is that helpful?

If your company is striving to dominate an industry by any means necessary, is that helpful?

If you do those things…

Are you even a Designer at all?

Or are you a glorified Huckster—a puffed-up propaganda artist with a fancy job title in an open-plan office?

Whether we choose to recognize it or not, designers have both the authority and the responsibility to prevent our products from becoming needlessly invasive, addictive, dishonest, or harmful. We can continue to pretend this is someone else’s job, but it’s not. It’s our job.

We’re the first line of defense to protect people’s privacy, safety, and sanity. In many, many cases we’re failing at that right now.

If the past 20 years of tech represent the Move Fast and Break Things era, now it’s time to slow down and take stock of what’s broken.

At Basecamp, we’re leading the charge by running an unusually supportive company, pushing back on ugly practices in the industry, and giving a shit about our customers. We design our product to improve people’s work, and to stop their work from spilling over into their personal lives. We intentionally leave out features that might keep people hooked on Basecamp all day, in favor of giving them peace and freedom from constant interruptions. And we skip doing promotional things that might grow the business, if they feel gross and violate our values.

We know we have a big responsibility on our hands, and we take it seriously.

You should too. The world needs as much care and conscience as we can muster. Defend your users against anti-patterns and shady business practices. Raise your hand and object to harmful design ideas. Call out bad stuff when you see it. Thoughtfully reflect on what you’re sending out into the world every day.

The stakes are high and they’ll keep getting higher. Grab those sociology and ethics textbooks and get to work.

If you like this post, hit the 👏 below or send me a message about your ham sandwich on Twitter.

The Unnecessary Fragmentation of Design Jobs

Photo by Sanwal Deen

Hey there, tech designer person. Have you noticed the increasing number of vague specializations we’ve invented for ourselves?

Here are a few I grabbed from a job board 10 minutes ago.

UX Designer
UX/UI Designer
UI Designer
Graphic Designer (UX & UI focus)
Visual Designer
Digital Designer
Product Designer
Presentation Designer
Front End Designer
Web Designer

Bleh. What’s the difference between UX and UX/UI and UI? Isn’t Product also UX/UI? Isn’t a Front End a UI? What’s a Graphic Designer with UX & UI Focus? And isn’t all of this Visual/Digital design?

For an outsider, the differences are extremely subtle. I’ve been talking to a lot of industry newcomers lately, and they’re almost unanimously confused. They’re struggling to gain the right experience and make portfolios to match our foggy job definitions.

Even worse, the companies hiring seem equally puzzled. One designer told me he took a UX job at a startup, and then his new boss asked him to explain what UX is about — after he had already been hired to do it!


This must be happening because everyone can barely keep up with the demand for design work. Companies are racing to fill seats and execute hastily-defined design processes without bothering to question if it’s all necessary for their particular business.

If your company does that, you might find yourself in a game of Designer Hot Potato like this one:

  • Bob’s good at customer research, so he’s on UX. He’ll make some personas and get a bunch of post-it notes on the wall right away.
  • Then we’ll get everyone together to look at the post-its and move them around.
  • Then we’ll write down ideas and ask Natalie to make wireframes. She’s our UX/UI person.
  • Then she’ll hand those over to Beth, our UI designer, who’s good at turning wireframes into a high fidelity UI mockup.
  • Then Beth will hand that over to Steven, our Front End person, to make a prototype.
  • Then we’ll try it to figure out what we did wrong, and check back with Bob on the post-its again. TO THE POST-ITS!!!

This is surely good for 3M’s office supplies revenue, but as a creative process it sounds painful to me.

I’ve never had a job quite like that.

Before I joined Basecamp, I was always a lone wolf — the only designery person at a small business or government org—so I had to figure everything out myself. I had to talk to people, learn about the problems they were having, come up with ideas, create a good-looking solution, write words, and build the UI piece of the final product.

It was tough, and it took years of practice to become competent at any of it. But I loved the diversity of the work and the exciting potential for new discoveries.

Recently John Maeda’s Design in Tech Report for 2017 suggested a name for my kind of role: Computational Designer.

These computational designers exist in a hazy middle ground — not quite pure engineers, not quite pure designers — but their hybrid status is increasingly attractive to technology companies. …The most successful designers will be those who can work with intangible materials — code, words, and voice. 
(via WIRED)

I dig this idea, but I don’t think we even need the word “Computational.” I think the software industry has been overthinking this, and what John describes is just Design.

Design (with a capital D)

I believe Design requires a holistic grasp of problems, potential, and materials.

If you’re only focused on examining problems, you’re not empowered to dream up the proper solutions.

If you’re only dreaming up what you could do, you’re not close enough to the ground-level truth.

If you’re only working on the nitty gritty implementation, you know about the what but not a lot about the why.

A capital-D Designer is comfortable working organically across all of that, without needing to slice it up into separate little steps and responsibilities.

This is possible in the real world

That’s exactly how we work at Basecamp. We skip most of the formal process stuff, and our Designers do everything: writing, visuals, code, project management, whatever it takes.

We’re living proof that this approach works well. We support hundreds of thousands of customers, plus multiple platforms and products, with a design team of 10 people.

We pull that off specifically because we don’t assign one designer to UX, and another to UI, and another to writing, and another to code.

Think this sounds too hard? Like there’s no way you could possibly be good at all of that?

Take a step back for a second. We’re only talking about making software.

Yes it’s hard…but in the grand scheme of things it’s not THAT hard.

If you’re not convinced, take a look at Art. Lebedev Studio:

Founded in Moscow in 1995, Art. Lebedev Studio is the only design company in the world offering product design, city and environmental design, graphic design, websites, interfaces, packaging, typeface design, custom patterns and book publishing under one roof.

Damn, that’s a lot of stuff! Projects across mediums, genres, industries, you name it. No artificial limits on anything. Inventing things using whatever materials and means necessary.

Some of Art Lebedev’s recent work

And that’s not even a new idea. Now look at master Designer Raymond Loewy, born in 1893:

Raymond Loewy (November 5, 1893 —July 14, 1986) was an industrial designer who achieved fame for the magnitude of his design efforts across a variety of industries.

Among his designs were the Shell, Exxon, TWA and BP logos, the Greyhound bus, the Coca-Cola bottle, the Lucky Strike package, Coldspot refrigerators, Studebaker cars, and the Air Force One airplane. He was involved with numerous railroad and locomotive designs. His career spanned seven decades.

Some of Raymond’s logos

A seven decade career making not just logos and products, but planes, trains, and automobiles too! Here’s Raymond, by the way:

Raymond Loewy, one hell of a cool Designer.

So if Art Lebedev’s shop can do all that, and Raymond Loewy could do what he did, why are we so insufferably particular about boxing ourselves into tiny little specialties just to make websites and apps?

Imagine if we stopped doing that, and tossed out our process assumptions and self-defeating arguments about what should be one person’s responsibility versus someone else’s.

Maybe we could all gain that magical holistic understanding, and grow to become Computational Designers. Or even just Designers.

You can make it happen

If you like this notion, try treating your career like your most important project. Be curious and restless. Aim to be constantly learning and trying new stuff without limits. Find a company or a work environment that lets you take a shot at everything you want to do (they’re out there!)…or invent your own little niche if you can’t find that.

This may not be the easiest career path to travel. It’s almost certainly not. But I guarantee you’ll enjoy the ride—especially since you’ve designed it yourself.

Hat tip to Jason Fried for turning me on to Raymond Loewy’s work. And a second hat tip to Dustin SenosOut of Office Hours project—such a fantastic idea that’s connected me with many wonderful young designers.

If you liked this post, hit the ❤️ below or let me know on Twitter.

How to launch software changes without pissing people off

Go the extra mile to avoid interruptions and protect your customers’ time.

Software designers and developers are all about NEW. We like to experiment with far-out ideas and make shiny things. Our livelihood depends on it.

We’re so addicted to NEW that sometimes it clouds our judgment. We love NEW and everyone else should too, so we force heavy-handed product changes onto our customers without much explanation.

And if they didn’t want that? Or if they got needlessly interrupted by it?…Shhh…we’re not so interested in those problems.

Dislike Facebook’s redesign? Deal with it! Confused by the newest Windows updates? Oh well! Missing some features in the new Final Cut? Too bad, they’re gone forever!

It’s no surprise that these sorts of changes are comically unpopular:

Developers get away with this anyway because we wield all the power. We can push a button and instantly transform an experience for millions of people in one shot.

Imagine if that kind of thing happened in the real world. Let’s say this was your living room:

And one day it suddenly became like this:

You wouldn’t be cool with that at all. You’d be totally freaked out!

What!? Where are all my books? What is all this creepy stuff? Whose head is that? Are those antlers?

That’s exactly what we do to our customers all the time. No wonder they’re always ranting on Twitter.

Why do we make disruptive changes?

There are a few reasons developers decide to steamroll NEW stuff.

  • It’s hard for us to keep legacy tech around. It’s easier to put everyone on the newest iteration and maintain only that.
  • It’s hard for us to make transitions elegant. A redesigned screen or feature might be jarring, but it takes extra care to ease people into the change.
  • It’s hard for us to balance business interests and our users’ needs. Sometimes we need to make a big move to stay relevant in the market or help the bottom line, so we drop a bombshell update on the world — continuity be damned.

Notice a theme there? It’s hard for us. Our laziness or time constraints take over, so we pass the buck.

How we can do better

Not all changes are massively disruptive, so we just need a strategy for identifying the ones that are, and then handle them properly.

Here’s how we do it at Basecamp.

Make only additive updates and improvements.

Taking away a feature is a surefire way to upset your customers. Even if it’s something small or innocuous, you can guarantee someone depended heavily on that one thing you took away.

The solution? Don’t take things away (if you can possibly avoid it.)

Thoughtfully adding stuff is great. Who wouldn’t want more for their money?

It’s also fine to improve rough spots. Make the same features look better, work better, or get the job done faster. Nobody’s going to be bothered by that.

The don’t-remove-stuff philosophy has a strategic upside, too. If you can’t take anything away, you’ll be more conscientious about what you put in.

Take extra care when making a disruptive change.

Sometimes you have a big idea that makes your product better, but switching over will be bumpy for your existing users. In that case it’s worth the additional effort to smooth things out, even if it means extending your development budget to build transition-related features.

We did this last year when we launched some big changes in Basecamp 3. We spent a few extra weeks making a settings screen for the new features we were introducing, so we wouldn’t be shoving them down our customers’ throats. The new stuff was turned off by default, so people could opt in if they wanted to, rather than having to opt out of something they didn’t want.

Basecamp’s new HQ and Teams features defaulted to OFF for existing customers.

Whatever extra time you spend doing this is a drop in the bucket compared to the exponentially greater time your customers might have wasted out of confusion or frustration.

Don’t bother pre-announcing changes.

You might think it’d be helpful to warn everyone before a big launch, like…

In three weeks, this website will be totally unrecognizable. You’ll have to figure everything out from scratch, but we think the new one is nicer. Enjoy!

…but what good does that do? Maybe the advance notice dulls the shock, but the customer can’t act on this information. They have to wait to be interrupted again later by the actual change.

This only prolongs the anxiety, with very little upside. It’s better to focus energy on the transition instead—make it so smooth that there’s no need for a pre-announcement.

Explain what’s different.

It’s bad enough to be forced into an update you didn’t agree to, but it’s even worse if you have no idea what happened or why things changed.

Make sure you have a way to introduce and explain what’s new when you launch, either via in-app announcements, a mailing list, a blog, or whatever method you have to communicate with customers.

People may not like the changes, but at least they won’t be blindsided. It’s the courteous thing to do.

Basecamp’s iOS app tells you whenever there’s new stuff.

Split distinct major versions and keep them around forever.

When we’ve collected enough new ideas to constitute a major rethink of Basecamp (this usually takes years), we create a whole new version from scratch. The previous versions live on in perpetuity in maintenance mode.

That means even there’s no disruption for people who are happily using a previous version. We incur the maintenance time and costs to keep it all running, and they keep paying us like they always did.

This might not work for some products, but it’s worked wonderfully for ours. Our customers get to keep using the version they like for as long as they want, with no pressure to do anything else. They can migrate to the newer version on their own timeline. Or not.

Perhaps best of all, we’re free to make a sweet NEW Basecamp every few years, with no legacy constraints holding us back. We can take risks and make big leaps forward.

You’ll be glad you did

Working through these issues might not be the most fun and exciting part of your job, but it makes a big difference in how people perceive your product, your service, and your company as a whole.

A few people will always complain about any change you make. That’s life. But these approaches will help keep your support load lower and your customers happier.

Any other ideas for making smooth product changes? Let me know in the comments. We learned most of this stuff the hard way, but we’re always looking for other smart approaches.

And if you liked this NEW post, please hit the ❤️ below or holler over on Twitter.

The Underappreciated Value of Incremental Design

There’s no such thing as a boring product update.

The Convair Model 118 Flying Car.

Apple announced iPhone 7 this week, and without missing a beat, the tech press decried it as dull. Tech pundits seem to have this same argument cued up every time Apple launches something that’s not game-changing innovation. I think they’re totally missing the point.

There are two ways to update an existing product:

  1. Make a brand new version that’s unlike everything before it.
  2. Improve it by simplifying it, making it more powerful, or adding new capabilities.

You can’t do #1 all the time. It’s just not possible. It’s a testament to Apple’s design prowess that they’ve pulled off #1 so many times, the public now expects it as a matter of routine.

Furthermore, making brand new versions all the time isn’t even necessarily good for customers. The iPhone is a stable, mature product that’s wildly popular and used by a massive number of people. Changing it dramatically every year is going to piss people off. Do you always want to relearn how your phone works every time you upgrade it? Do you always want to suffer the inevitable flaws and unforeseen bugs that arise when new moonshot stuff is launched at scale for the first time?

Sure you do, if you’re a tech reporter! But not if you’re a non-tech-obsessed human person who just wants to text their friends and check Facebook. If you’re that person, stability is a virtue, not a downside.

More importantly, there’s a critical aspect to these seemingly “mundane” product updates that people in the peanut gallery are missing:

Incremental updates help stack the deck for a big-splash release in the future.

When you have an existing product and you do want to make a big change to it, you can do that two ways:

  1. Bite the bullet, and launch it all at once in a massive blowout release that shocks everybody.
  2. Spread the changes out over a couple of releases that get you to the same end goal, but that aren’t as individually shocking to your customers.

In the case of iPhone 7, I believe the removal of the headphone jack is a tell that they’re doing the latter. I think whatever is coming after iPhone 7 depended on reclaiming that headphone jack space for something else. Every tiny bit of space matters!

By killing the jack in this release, they’re freeing themselves up to make a bigger move next. They knew everyone would whine and vent about that detail now. That means the next BIG launch won’t be marred by discussion about headphone jacks, because we’ll all have gotten over it by then. (People have a surprisingly short-term memory for the very strong opinions they held even a year earlier.)

The bottom line is, people get excited about changes and shiny new things, but they also hate changes — especially when they’re disruptive or different in ways that don’t seem to be a clear improvement over the old ways.

So, launching an update to an existing product is a difficult balancing act between these two extremes. Sometimes the big splash is fully warranted, but the rest of the time it’s best to be conservative and incremental. Apple’s carefully orchestrated release cadence is the perfect example of this, much to the chagrin of the overeager tech press.

Product releases are part of a larger long-term strategy, and they only make sense when you know the full picture. Only Apple knows theirs, but I’d bet on something big next time around. I suspect we won’t be “bored” for much longer!

Over at Basecamp, we dabble in big splashes and incremental changes. See both in action in the all-new (and constantly improved) Basecamp 3.

If you liked this post, please hit the ❤️ below, or holler at me over on the Twitters!

The Art of Designing With Heart

How to make useful, friendly software for real people.

One of the things I love about making software is that it’s a deeply mental exercise, chock full of heady processes, abstractions, and interconnected pathways.

You can fill your brain with the practical nuts and bolts side of it—research, strategy, prototyping, programming, UI, operations, and more. Lots more.

And if that’s not enough? Indulge yourself in metrics and performance. Every last detail can be tested, quantified and optimized to the fullest. Get high on KPIs and keep your eyes on your ROI!

The problem is…with so much to think about, and so many logistics to obsess over, it’s easy to forget the reason you’re doing any of this in the first place:


Designers usually call this notion User Experience or Empathy. I think those names stink. They’re buzzwordy and vague enough to mean different things in different contexts.

I think we should call it what it really is: Designing With Heart.

This isn’t something that’s the responsibility of one specific team in your company, or one step in a process that you can check off. It’s a core value that informs every decision you make.

Here’s what that means in practice.

At the other end of all your strategy and metrics and tech, there are real people. Living, breathing people — who are busy dealing with their weird life, arguing with their kids, trying to figure out what’s for dinner.

When you build software, you’re painstakingly inventing a machine that stands in your place, feigns sentience, and interacts with these people on your behalf so they can accomplish something meaningful.

Your software is not just a bunch of code and UI you smushed together. It’s also a compilation of your best ideas, your best intentions, your desire to help others, your compassion, your feelings, your soul.

Your software is YOU.

(That is, if you believe in the art of it. And you should, if you give a damn about doing it right.)

When you see things in this light, you’ll notice that a lot of software is dull and lifeless.

Consider your bank’s website, or your insurance company’s billing system. They’re probably cold and impersonal. That’s because the designers treated their job as a mechanical sequence: they took a set of requirements, invented imaginary personas, wrote user stories, and sprinted their way through the work until the requirements were met. All head, no heart.

Capital One’s “sign in” page.

Now, you might think it’s fine for a bank site to be plain and transactional. After all, banking is literally a set of transactions.

But compare that to the experience you’d have with a nice bank teller (if you can still remember what that was like.) The teller smiles at you, asks how your day is going, double-checks that your math is right, offers to help with something you might have forgotten, and gives you a lollipop! 🍭

That’s a transaction with a bit of heart.

OK, so let’s say we want our software to take the place of the bank teller. That means it should ideally provide the same humane, helpful service that they did. But how?

One option is to anthropomorphize the interface and stick some personality into it, which results in UI that’s funny, folksy, clever, sarcastic, or cartoonish.

Poncho the sassy weathercat sends you messages that say “Zzz Zzzzzzz” and “Purrrrrrrrrrrrr.”

I think this only works in small doses, because humans have a low tolerance for bullshit. Unless you’re really good at it, jokey and cutesy stuff gets irritating quickly. That’s even worse than just being mechanical, because it’s a waste of time. It’s usually better to cut to the chase.

So if mechanical is bad, and excess personality is also bad…Then what’s good?

The sweet spot is right in the middle. Good software is friendly, casual, approachable — but also serious, gracious, and respectful. Just like a pleasant real-life experience you’d have at a local business.

Achieving this sounds difficult (it is) but there’s an easy trick that helps a lot.

When you’re designing something, imagine you’re sitting in a room, helping a real person with the task at hand. What would you say to them? How would you explain this screen or feature? What advice would you give? What would you tell them to do next?

Say the answers out loud, and then write down what you said. Now you’re 80% of the way there!

If you were helping someone in person, you wouldn’t be austere or formal. You wouldn’t use buzzwords or jargon or business-speak. You also wouldn’t drop HOT SARCASTIC JOKE BOMBS on them and distract them with goofy asides. You’d watch what they do, see where they get stuck, and walk them through it. You’d speak from the heart.

This common sense technique helps you see the forest for the trees. If you struggle to explain something out loud, it’s probably not clear enough. That insight leads you to ask questions like…

  • Can we make this interface simpler or more direct?
  • Can we reduce or eliminate the choices someone has to make?
  • Are we using natural, casual language to explain things fully?
  • Is this design respectful of a person’s time and attention?
  • Is this something I would personally enjoy using?
  • Did we take any shortcuts that benefit US instead of THEM?
  • Did we make any incorrect assumptions?

Now your design will inevitably end up clearer and friendlier. That makes your customers happier and more efficient, so they can stop fiddling with software and get back to dinner with their argumentative kids.

That should be the underlying motivation for your work. Not tech, not styling, not stats, and not money. Helping people comes first. The rest follows.

Designing With Heart doesn’t just apply to making a product, either. It can also guide your marketing, advertising, and sales work.

For example, let’s say you want to increase the number of paying customers for your product. (Who doesn’t?) That’s a business-first problem, not a people-first problem.

If you only think business-first, you might blast out canned promotional emails, or show “BUY NOW” callouts all over the place, or interrupt key workflows with interstitial popup ads.

The Wall Street Journal asks you to buy before you’ve even arrived.

These techniques may well be useful for increasing raw business performance, but they can be annoying and smarmy to customers. That’s the opposite of what we want. So how do we reconcile the difference?

Easy: think about people again!

There’s nothing inherently bad about clearly communicating the value of your product, making it easier to buy it, spreading your message to new audiences, or even asking for referrals or reviews — as long as you do so in a way that’s considerate, honest, and at the right moment.

Don’t interrupt people when they’re in the middle of something, nag them incessantly, or hard-sell them into doing what you want. If you ask for a favor, make it worth their time by thoughtfully explaining why you need their help, and perhaps offering an incentive in trade.

Follow this approach and your promotional efforts won’t just benefit you, they’ll benefit people too.

There’s one more thing you can do to Design With Heart: don’t be afraid to reveal yourself.

People develop emotional connections to other people—not machines.

When your customers can see who’s behind the curtain, and when you speak to them with honesty and authenticity, they’ll be more likely to identify with your message and approach.

Nate Kontny’s Highrise updates always have a personal touch.

If you built something because you fundamentally care about helping people, and you intend to have their back…say it! Put your name on it, tell your story, show your face, and stand behind your work. Share your real personality rather than trying to graft a fake one onto an inanimate program.

Your customers will respond in kind — and that’s the most rewarding thing of all. 💞

Curious for more examples? Check out these ideas put into practice inside Basecamp 3. And if you ❤️ this post about ❤️, please hit the ❤️ button below or give me a shout on Twitter.

Why we need paid family leave in the U.S.

When you have a newborn baby, your home life descends into temporary chaos. There’s crying and messes and strange liquids everywhere, plus doctor appointments, grocery store runs, and endless laundry. And that’s not all: new moms need lots of support and ample time to recover.

But since Americans keep prioritizing EXTREME PRODUCTIVITY and individualism over everything else, most working parents don’t have time to get their lives in order. We’re expected to get back to the grind right away.

Don’t like it? Too bad. Stick that baby in a daycare, choke down a few painkillers, slap on a fake smile, and numb your way through the whole mess. You’ll see the kid on the weekends. It’s the American way!

Truth be told…the American way is fucked. This is what really happens when you go back to work so soon:

  • You’re a distracted, tired employee who’s running on fumes and whose mind is elsewhere.
  • You’re fighting with your partner because you’re overwhelmed trying to balance too much at once.
  • You’re missing precious time with your new child. At this early age they change every 20 minutes. You want to be there for that, and they need you to be there.

I know these things from experience. I had no parental leave when my daughter was born 7 years ago. I took a couple weeks of vacation and went back to work, leaving my wife alone with an especially feisty newborn. We slogged through it, but we suffered the fallout for a long time after that.

And I still had it relatively easy! At least I had some paid vacation time to use, and we could afford to have my wife stay home. Lower income families don’t have those options. If you’re earning hourly wages and living paycheck to paycheck, think you’ll skip getting paid when you suddenly have another person to care for?

These days, I’m so fortunate to work for a forward-thinking company with a generous parental leave policy. When my son was born in April, I was given 6 weeks of paid time off—a rare benefit for a father in the U.S.

Having that time allowed me to relax and focus entirely on my family. Being dad was my full-time job when it was needed most. I could do all the laundry, calm the crying, and help my wife get rest.

The family leave experience

I missed about a month of work, and everything kept on running without me. We put a couple of my projects on hold. It was fine.

Basecamp paid me my usual salary, but even more than that, they gave me a priceless gift: dedicated time with my new son. That experience endeared me to the company more than just about anything else they could do. In return, I came back to work feeling enthusiastic instead of worn out and stressed.

Now, of course paid leave is wonderful for an employee, but how about for a business? Why should a company pay workers not to work? It’s already expensive to pay for health insurance and other employee benefits.

That’s a fair argument, but forcing zombified employees back to work doesn’t make their problems magically go away. It just causes extra stress and burnout. That results in higher turnover. And turnover is even more expensive! Research shows many businesses save money overall with a paid family leave policy due to reduced turnover rates.

Whether a national solution for parental leave in the U.S. involves a cultural shift, government action, private sector changes, or some combination of all three, I hope I’ve helped shine a little light on the truth.

If you’re an American worker, look for jobs that have supportive family policies. (They’re hard to find right now, but they do exist.)

It’s worth the effort. You won’t remember yet another month you spent at work, but you’ll never forget the beginning of your child’s life.

And if you care about this issue like I do, keep talking about it! Call your representatives. Talk to your boss. Let’s help change it for everyone and make this post obsolete.

Basecamp is an amazing company with great benefits. We don’t hire new people all that often, but sometimes we do—keep an eye out! Give me a holler here or on Twitter if you have any thoughts about this.

Why I love ugly, messy interfaces — and you probably do too

Illustration by Nate Otto

Beautiful. Fresh. Clean. Simple. Minimal. These words have been dominating design discourse for a while now. In case you’ve managed to miss them, check out this review of portfolio websites over on Creativebloq. The word beautiful is used 6 times, and simple 11 times. In one article.

Designers use these words to describe their values, goals, and results. They plaster their portfolios and resumés with them. Non-designers use them too. They’re everywhere.

If you’ve hitched a ride on this wagon, you might have a website that looks something like this:

Lovely designs like this have become so commonplace that beautiful and clean are almost baseline constraints for new projects. It’s like every designer had the same Pinterest coffeeshop fever dream, and decided the whole world had to become lifestyle-chic.

And that makes sense, really! Everyone likes easily digestible things that look bright and stylish. Nobody wants ugly, messy stuff.

Or do they?

Here’s some ugly design that’s unbeatable.


Here’s some cluttered design that’s quite popular.

Adobe Photoshop CC

Here’s some complex design that 1.5 billion people use every month.


So…wait. If beautiful, fresh, clean, and simple are so important, why hasn’t someone upended all of these products with something nicer? It’s not for a lack of trying. There are countless simpler, better-looking Craigslist and Photoshop competitors, for example.

The answer is that these products do an incredible job of solving their users’ problems, and their complex interfaces are a key reason for their success.

Let’s say your goal is to make a global peer-to-peer commerce network. That’s a big, complicated project to tackle.

You could attempt to reduce your solution down to a minimal version, cutting out features and reducing density in the name of beauty and simplicity. Here’s a Craigslist redesign concept like that. (Designers sure hate Craigslist, don’t they? Has any other site had more unsolicited redesigns?)

Craigslist redesign concept by Aurélien SALOMON.

Or, you might decide that you really can’t cut features, because it’s more important to nail every use case you care about. (Remember, you have to support a huge number of scenarios to reach table stakes for this project.) Now beauty and simplicity are instantly a much lower priority. Making something useful comes first.

For another example, think of Photoshop. How many graphic designers who idolize Swiss Style also use Photoshop every day? Probably most of them. Yet Photoshop’s UI is the antithesis of minimal — it has more nasty junk drawers than your parents’ unkempt basement. It doesn’t matter at all, because people don’t come to Photoshop for inspirational UI. They use it to get the job done.

In other words, sometimes this isn’t so great:

When this is what you really need:

Now, obviously I’m not suggesting you should go clutter up your design work, or make it look crappy on purpose. I’m also not suggesting that the examples above couldn’t be improved.

My point is: there is no single right way to do things. There’s no reason to assume that having a lot of links or text on a page, or a dense UI, or a sparse aesthetic is fundamentally bad — those might be fine choices for the problem at hand. Especially if it’s a big, hairy problem.

Products that solve big, hairy problems are life savers. I love using these products because they work so damn well. Sure they’re kind of a sprawling mess. That’s exactly why they work!

We needn’t all pray at the beautiful minimalist design altar. Design doesn’t have to be precious. Toss out your assumptions and build what works best.

We made Basecamp to be one of those life saving, big hairy problem solvers. Check it out now at

This post was adapted from a talk I gave at University of Illinois Webcon.

You Aren’t Gonna Need to Design It

A short tale of building what matters and skipping the rest.

We just started a new email campaign at Basecamp, and it’s something we’ve never tried before. It’s a sequence of three automated emails that we send to new customers who fit a certain criteria. In these emails, we ask if the customer needs help getting started, and what they were hoping to do with Basecamp.

We originally thought of this project as a marketing exercise, but so far it’s giving us insights that reach way beyond marketing.

One thing that’s special about this campaign is that the messages are sent directly from me (and a couple of other folks), and we’re personally responding to anyone who writes us back. The replies go straight into our real inboxes — not into our company’s support help desk or some no-reply black hole. This is a ton of work to maintain, but we’re learning a lot and developing new relationships with people.

While we were setting up the nuts and bolts for the campaign, we got stuck on a tricky detail. We wanted the automatic sequence of emails to immediately stop if a customer replies, because it would be weird if we sent more canned messages after personally interacting with someone.

Tom asked me how it should work…

There was no obvious way for us to stop the sequence automatically. We probably could have devised some fancy system with an administrative interface to handle it, but would it be worth it? At that point we had no idea what was going to happen with the campaign as a whole.

How many replies would we get? Would this unsubscribe issue be a serious problem or just a minor issue? Was the overall campaign any good, or would we stop it after 3 days because it was performing poorly? There was no way to know.

In cases like this, you can either anticipate all the likely possibilities and build lots of things to insure yourself against potentially bad situations, or you can ship what you’ve got, wing it, and be prepared to make changes as you go.

As is our style, we ran with the latter…and it was completely fine! Most people leave our original email quoted below when they reply. Then we click the Unsubscribe link for them. That’s it. It’s lo-fi and works in 99% of cases. If the quoted email isn’t there, Tom programmatically unsubscribes the person by hand. We have to do that a couple of times per week. No biggie at all.

So this is YAGNI in practice. You might be familiar with YAGNI as a programming-specific concept, but I think it’s just as applicable—if not more so!—on the design side.

Design is often a matter of diving headfirst into an unknown abyss, and preparing to modify your thinking based on what you learn. When you’re doing that, there’s no sense in trying to protect yourself from bumps along the way. The bumps are the whole point of the exercise.

It’s certainly prudent to have an escape button handy so you can shut everything down if your world quickly descends into utter chaos. But otherwise, get ready, strap yourself in, and go for it! That’s the only way to find out what happens next.

Knowing the words is half the battle

One of my favorite career stories is this one from Michael Beirut:

I designed little magazines when I was in the third and fourth grades, and I made logos for my friends’ bands when I was in the seventh grade. I could do hand lettering, and if someone wanted an animal in the logo, I could do that; if someone needed a poster for the school play, I could do that, too.

All along, I had no idea that what I was doing was called graphic design. I lived in the middle of nowhere at a time when no one knew anything about something like graphic design.

By accident, I happened to find a book in my high school library…it was called Aim for a Job in Graphic Design/Art. I opened the book up, and it was like receiving an instruction manual for my future career: it was all right there. I was about 15 at the time, and I thought, “This is what I want to do.”

This bears repeating: one of the world’s preeminent graphic designers didn’t know graphic design was a thing — let alone a job you could get paid for — until high school.

He knew what the idea of graphic design was, and he even knew how to do it. But he didn’t know what to call it.

Perhaps the biggest obstacle to gaining skills in a given domain is knowing the right words. Being a beginner is intimidating because you don’t speak the same language as experts, who have often forgotten what it’s like to be a beginner.

If you’ve ever had to talk to a car mechanic, you know how it feels. In the immortal words of George Costanza:

Of course [car mechanics] are trying to screw you! They can make up anything, and nobody knows! “Why, you need a new Johnson Rod in here.” Ohh…a Johnson Rod…Yeah, well, better put one of those on!

Here’s another example. Millions of people use iPhones, but they don’t know the official names for all the interface widgets and the underlying stuff that makes them work. It doesn’t affect their ability to use an iPhone, because the iPhone is well-designed.


I went to Twitter, then hit the thing that said “Notifications”, and a new screen came in, then I saw some messages, and it stopped working.

By contrast, an iOS developer knows the domain words, so they can be more precise:


The customer opened the Twitter app, then selected the Notifications Tab in the Tab Bar. The Notifications Table View rendered for a moment but then the app crashed. The issue might be the Notifications View Controller or some malformed data in one of the notifications.

In product design, this is related to User Experience (UX). Part of a UX designer’s job is making sure a product’s internal language is either hidden away, or translated into common words that users can understand and interact with. If you don’t do this, you might end up with this kind of thing.

A customer support rep’s job is the opposite: they translate customer-speak into domain words so a specific problem can be resolved — especially in the case of a bug report that gets passed along to developers.

Here’s one last example. I’ve been an obsessive music fan for most of my life, but I’ve never formally studied it, so I don’t know the terminology. Check out this video of Jeremy Leaird-Koch building an electronic song from scratch on an OP-1. (Jump to 1:25 or so.) Be sure to watch the subtitles.

If you make it through the whole video, you’ll see a ton of expert language:

  • Sequencing
  • Swing
  • Delay
  • Kit
  • Wubbing
  • Phasing
  • Filters
  • Ambient poly lead
  • Modulation
  • Envelope sharpening
  • Arp (arpeggio)

I’ve put in 30+ years of music listening, and these phrases might as well be in a foreign tongue.

So it’s not enough to have exposure to the outer surface of a domain. If you want to level up your understanding, you have to be willing to feel ignorant for a while and study it in depth, until you find your sea legs and pick up a handful of those all-important words. There’s no magic to it. This willingness, and a lot of practice, is all that separates the experts from the beginners.

Once you’ve learned a bit of lingo, you’ll find that the words help you ask questions. The questions help you learn how things interact. When you know how things interact, you can start understanding the system as a whole. And pretty soon, you’re an expert too.

As experts who’ve put in the time, then, how can we make things more approachable for beginners? Wouldn’t it be nice if we could simply eliminate all jargon and special words? Then we’d have no problem, right?

Well, then we’d have a new problem: we’d have no way to talk to each other! Any sufficiently complex system needs names for its component parts— otherwise there’s no way to talk in detail about the system. So eliminating internal complexity isn’t always possible or even desirable. Still, there are a few things we can do to help.

Use plain words instead of fancy words.

For example, if you’re a programmer modeling a message sent by a client, call it ClientMessage instead of ExternalActorSubmissionContent.

Give abstractions familiar names, so they seem less foreign.

In Basecamp 3, we called group chats Campfires and direct messages Pings. They’re still abstractions that users have to learn, but at least they’re helpful names—a little descriptive and a little less intimidating.

Listen to how beginners talk about the problem, and inherit their language.

We did this recently by noticing our customers called Basecamp projects “Basecamps.” They’d say, “Oh, I made a Basecamp for that.” So we ran with it and called Basecamps Basecamps instead of Projects.

Don’t assume simple words are adequately clear.

Trying to be too simple or succinct is usually worse than being clear and verbose. This is why people are confused about what food is “healthy.” Even though healthy is a simple word, it’s an unclear way to define food.

If you’re in the privileged position of being an expert at something, don’t forget what it felt like to be a beginner. Let those battle scars inform how you communicate, and choose your words with intention. If you need a reminder of how it feels to be a newbie, just pick yourself up an OP-1 and let me know how that ambient poly lead turns out!

We worked hard to make Basecamp 3 the clearest and friendliest version we’ve ever written. Check it out and see more examples over at

A rallying cry for the Weird Wild Web

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.

  1. Corporations and governments are encroaching on the open web and trying to control it from all sides (bandwidth, access, content, etc.)
  2. Social media sites are sucking up most of the traffic and attention. In the process, they’ve become stand-in replacements for the entire Internet (think AOL 2.0.) This has the side effect of turning smaller individual websites into irrelevant sideshows.
  3. User-hostile advertising practices are degrading user experience on the web to an alarming extent.
  4. Native apps provide a better and friendlier alternative to traditional websites-in-browsers. As native apps continue to mature, they’ll gradually eat the web with specialized UI for every situation — which means you’ll never need to access the web directly in a browser anymore. This will turn the web into a content delivery mechanism (i.e. HTTP requests) rather than an endpoint for users to interact with directly.
  5. Web designers and developers are overusing slick copycat layouts, styling, and template tools. This makes web production easier and trendy looking, but at the expense of individuality and substance, leading us into a bleak dystopian future where web UI becomes the software equivalent of suburban tract housing.
  6. Publishing platforms like Medium are piggybacking off independent writers’ content while offering relatively little differentiation or authorship credit in exchange. These platforms are gathering all the small-time folks under a few large umbrellas, thereby reaping most of the financial benefit while hammering more nails in the coffins of traditional independent blogs.

Alright, so wow. That all sounds pretty terrible, doesn’t it?

A lot of those things are true. The times are certainly changing, as they always do. We web folk should keep thinking seriously about this, lest we become the old crusty janitors left to turn out the lights.

But hold on. Forget about all those problems for a moment, foreboding as they may seem. Is there anything good happening now? How about:

  1. Despite their repeated attempts, big corporations haven’t killed the open web — at least not yet!
  2. Small mom and pop independents now have access to massive audiences that used to be impossible to come by. Whether your business is writing, art, or anything else, it’s easier than ever to get yourself out there and make a living or solve new interesting problems with the web. Kickstarter, Medium, and Etsy are incredible platforms for the little guy.
  3. Web tech is as sophisticated, diverse, and powerful as it’s ever been. (Granted, we’re abusing it for bandwidth-munching ads and gratuitous effects — but that’s on us. We can stop. We should stop. Please, stop.)
  4. Native apps haven’t eaten the web either. Native is fantastic and powerful and lovely, but you know who still has websites? Facebook. Instagram. Whatsapp. Medium. These are enormous services, some of which even launched as native-only and then added web versions later, because the web as a platform is still too important and universally applicable to ignore.
  5. We — the small, independent weirdos — still have the power to meaningfully contribute to the web and change it for the better.

So where does that leave us?

First of all, let’s chill out for a minute. Maybe the naysayers are right and we’re all doomed, but the web is still alive and kicking right now.

Secondly, let’s reflect on our missteps and start walking back the most egregious abuses of slick tech and bad UX we’ve willingly let slide the past few years. Ad blocking on iOS is forcing the issue — but it’s rather sad that we let it be forced in the first place.

And finally…

Let’s make the web weird again!

Twenty years ago the web was super weird. No one had any clue what this thing was about or how it worked, so we were trying everything. Sites were badly organized, ugly, strange. Some were loosely organized communities. Some were just text. Even the best produced sites had the feeling of being held together by duct tape and straws.

Now to be clear, I’m not nostalgic for that time at all. Making websites sucked. Nothing worked well. The tech was painfully slow and limiting in every imaginable dimension. I don’t want to go back.

But the one thing the web had then, and which it has lost a lot since, was the sense of rampant experimentation. The feeling that it was fine not to have everything figured out or perfectly polished before letting people see it. That we were all in this bizarre human experiment together.

If we want the web to keep thriving, we have to start letting ourselves experiment (and fail) more. The web still has a low barrier to entry and the biggest possible audience. That’s an incredible thing.

So c’mon everybody. Let’s mess this place up again! Get weird! It’ll be better for it!