An Ode to Experimental Design

If you search the Internet to learn about A/B testing, you’ll find scads of articles bursting with tips for cranking your business performance into the stratosphere.

You’ll get blazing hot secrets like…

BOOST YOUR CONVERSION RATE BY 300% WITH THIS TINY TWEAK

and…

DESTROY YOUR COMPETITION USING A STATISTICALLY SIGNIFICANT SHADE OF BLUE

…and it just keeps going like that, into an overenthusiastic pit of armchair psychology and semi-authoritative pseudoscience.


As the gurus tell it, A/B testing is like Vegas slots: plunk some crap into a machine, score a handful of 🍒🍒🍒s, and voilà, Easy Bake Revenue!

With a pitch like that, who could resist? It sounds so simple. If you don’t do it, you’re obviously a fool who’s leaving money on the table.

Welp, I have a couple of hard truths for ya:

  1. It’s not as easy as it sounds, and those big gains aren’t such a sure thing.
  2. Setting out to dramatically boost some arbitrary metric (signups, conversions, revenue, whatever) is exactly the wrong way to approach a design problem.

How do I know this?

I spent most of last year testing dozens of conversion-related design ideas in Basecamp, and I found that the JACKED UP PERFORMANCE aspect is the least interesting part of the process, by far.

The most interesting part is how it can change your thinking. Testing is a ticket to ride. It energizes your adventurous spirit, introduces you to uncharted territory, and lands you in cool places you never expected to go.

Here’s what I learned, and why I’ve come to love doing experimental design.


Testing turns your designs into trash.

After running tests for a while, you’ll find yourself throwing away mountains of design work for just a handful of meaningful improvements.

Do that enough, and you’ll notice something: Maybe design isn’t such a special endeavor after all!

The truth is…a lot of design is ephemeral, malleable, disposable…garbage.

Anything you make today merely represents one moment in time. Maybe it’s your best idea now, but it’s not necessarily the best idea you’ll have in another two days or two months.

Testing makes this painfully obvious on a shorter time scale. You’ll soon become less emotionally invested in your precious creations, and more focused on the problems you care about.

Testing strengthens your gusto.

I don’t know about you, but it took me years to build up the confidence to make hard design decisions. I still struggle with it sometimes.

You have to succeed and fail a lot. You have to take criticism a lot. And you have to trust your gut and keep at it, day after day.

Experimentation is a great way to build that muscle. It’s an opportunity to try things you aren’t completely sure about, and gives you a sweet little safety net for failures.

Testing makes you thoughtful.

It can be tempting to do experiments like the lottery: throw a bunch of random shit at the wall and then declare victory when one thing performed best by random chance.

You might get lucky a few times that way, but it’s a terrible long-term approach. Without some overarching vision, you’ll be left with a gnarly mess of test results born from guesses, and no clear plan for what to do next.

The better way, of course, is to start with good ideas! Do some research, come up with educated hypotheses and concepts you believe in, then build and test them to verify your thinking instead of defining it.

Testing destroys perfectionism.

It’s so freeing to ship a bare-bones version of an idea because it’s “just a test” that you’ll either improve or throw away when it’s done.

If you thought that same design had to stick around permanently, you’d probably never launch it with a lot of known flaws or incomplete parts. You’d want to fix up every last detail and make everything perfect first.

Amazingly, those rough, imperfect tests often outperform the supposedly perfected version you already had in place. When you see that, you’ll realize your outsized attention to detail might not matter as much as you thought.

A license for imperfection is an extremely useful defense against Fussy Designer disease. We should all be vaccinated early and often.

Testing builds empathy.

This sounds counterintuitive: running an experiment is mostly a pragmatic and statistical kind of thing. How is that related to empathy?

It’s related because you’re forced to learn what happens when real human people interact with your work. Your choices all have directly measurable effects, so you can’t hide behind bullshitty designerspeak or vague justifications when the data shows you’re just flat wrong.

That means you have to get outside your insular designer bubble, stop thinking of people as numbers, and get in their shoes a bit.

When you do that, the business boosts you want will happen as a natural side effect of continually tuning your product to serve your customers’ real-life situations. Making things clearer or more efficient for your customers always pays off.

Testing helps you make space.

One tough challenge in UI design is making physical space for new things you want to do. There’s only so much room on a screen!

You might have ideas that require injecting steps into an existing UI flow, adding more screens, revising a visual hierarchy, or rearranging certain navigational elements.

Doing stuff like that is a gamble. You might be confident that your new version is better in some way, but are you sure your improvements are worth the extra steps or added complexity?

Testing lets you dip your toes in the water. You can run a short experiment and see if you’re busting your business before committing to a direction.

Testing tells the truth.

The truth is weird. Sometimes common sense wins out. Sometimes a wild idea succeeds. Sometimes a version you hated performs the best. Sometimes your favorite design turns out to be a total stinker.

Where else in the design world can you get opinion-free feedback like this? There are no Art Directors or Product Managers or App Store reviewers telling you what they think is right. It’s real human nature telling you what’s right!

It’s a fascinating, powerful, bizarre reality.


Do you use testing as part of your design process, and NOT just for improving some Haha Business metrics? I’d love to hear about that. Drop me a comment below or holler on Twitter.

The Basecamp 3 refresh is here!

Last month, we shared a sneak peek at some major design improvements we’ve been cooking up for Basecamp 3. Today’s the day — you’ll see those changes in your Basecamp account right now!

There are countless little tweaks and improvements throughout the entire app, but here’s quick recap of the most important new stuff.

High-level Changes

The examples we showed in the preview still stand: improved navigation, colors, and typography, better use of space on desktop screens, and more consistent placement for buttons, headers, and menus. These changes apply everywhere.



A few examples: Message Board, To-dos, and Docs & Files

New Comments Design

Comments got a big upgrade. We wanted to give comments their own identity and charm, while reducing the metadata noise that had built up around the actual writing. They’re friendly and easier to read, too.

Comments get a big bold header, simple shapes, and an all-around cleanup.

New Options Menus

There’s a slick new design for the ••• options menus that appear on every page. We consolidated all page options into these menus, so now there’s just one consistent home for all the actions you can take, rather than having various buttons and links scattered in several different places. Note: Edit and Bookmark have been moved in here too.


New Breadcrumbs Shortcuts

We built on the breadcrumbs navigation in a couple ways.

First, there’s a new and improved quick-jump button, so you can easily hop between any of the tools in a project. (The project’s name used to to pop up this menu, but now the name is a simple link, just like the rest.)

Second, now you can click anywhere on the white “back sheet” to go back up one level—or click it multiple times to go back multiple levels.

Click the four-squares button to get the jump menu shortcut, and click the backsheet to go up one or more levels.

Unified Buttons and Themes

Buttons got a lovely facelift (they’re all round now) and they’ve been themed to match whatever custom color theme you’ve picked. We also sprinkled the theme color on a variety of other elements.

The red theme.

Tidier Message Composing

Posting a message in Basecamp is an important moment, and it should feel GOOD. We simplified the message categories picker, cleaned up the new-message screen, and gave you more space to breathe—and write.

Ahhh, sweet sweet space.

Updated Design for Clientside

If you use Clientside, you’ll notice a few changes. Now there’s a big button at the top of the project to access the Clientside (this replaces the old tabs). The Clientside is now on a white sheet, and message threads are updated too.



New Clientside design

Plus…So…Much…Other…Stuff…

Those are just the biggest changes. There’s a lot more than we can list here—so go forth and explore it!

We’re just getting started

We think the refreshed Basecamp 3 is more cohesive, modern, and sophisticated, but still friendly and familiar too. We hope you enjoy the changes as much as we do.

And this is only the beginning. These updates set the stage for a ton of additional improvements we’re planning to make, so keep an eye out for those coming soon. It’s gonna be a great 2018.

Thanks and much ❤️ from all of us at Basecamp!

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.

https://basecamp.com/svn

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!

UX AND UI, WHY OH WHY

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:


https://twitter.com/princessyalonie/status/841441040410255361

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.

https://twitter.com/aniakans/status/836962274803920898

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:

🚨️ YOUR SOFTWARE EXISTS TO HELP PEOPLE! 🚨

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:

compliments.dk

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.

Craigslist

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.

Facebook

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 basecamp.com.

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.