How You’re Being Manipulated By Software

(And what you can do about it)

The Book of Life (1898)

There’s a term we use in software design called the happy path. It describes a best-case scenario, in which customers use a product exactly as intended, without bumping into any edge cases or uncommon problems. This includes the interface you see when you sign up, setup steps you have to complete, and so on.

For software designers, a happy path is also an extremely powerful psychological tool that allows us to control people’s behavior and direct them to do whatever we want.

If that sounds surprising—and slightly terrifying—think about how many times you’ve blown past a lengthy software license agreement and clicked the Agree button without looking.

Were you thinking deeply about what you were doing?

Probably not. And you’re not alone! Research shows that humans have a natural aversion to decision making. As Smashing Magazine describes it, people simply don’t like to make choices unless they have to:

Making an explicit decision requires effort, after all. Time, thought and consideration are often required to determine the best choice. It turns out that people are remarkably sensitive (and averse) to the amount of effort that making a choice demands.

And therein lies the trouble.


If you pay close attention, you’ll notice something else about software happy paths. Like a tell in a poker game, they subtly reveal a company’s underlying motives.

Since designers know you’ll probably avoid making difficult decisions, they take advantage of your passivity and coax you into doing anything they want.

For example, if you’ve ever installed the Facebook Messenger app, you were likely encouraged to continuously upload all of your phone’s contacts to the service. This is framed as a way to help you text people quickly.

Look at that screen for a moment. There’s no opt out button! You can only choose OK or Learn More.

And who wants to Learn More when they’re signing up for a chat app? Almost nobody.

I’m guessing at least 80% of Facebook’s users just tap OK and move along immediately. There’s even a little animated arrow encouraging you to tap OK, in case you momentarily considered doing something else.

But let’s say you’re among the 20% that happens to pick the Learn More button. You’ll get a cutesy second screen:

This screen finally has an opt-out button, in plain text, buried underneath some repetitive copywriting that vaguely implies you’re wrong for questioning any of this.


What’s more, Facebook’s designers neglected to mention a rather important detail: continuously uploading your contacts helps them collect a ton of data about people who aren’t even on Facebook.

Tapping that OK button is a trivially small decision. It takes just one minuscule tap of your finger. It’s done in less than a second.

But the impact is quite large indeed! You’re implicitly agreeing to send Facebook little bits of info about everyone you know. Now imagine the network effects when you multiply that by the millions or billions of users who also tapped OK in the blink of an eye.

This little happy path is feeding a massive data beast, which probably has details about almost everyone on Earth. And Facebook had ample space — two separate screens! — in which to mention anything about this.

So why didn’t they?

Because endless growth and data collection is the foundation of their business, and that necessitates doing gross invasive things to their users.

They need you to feed the beast, and they certainly don’t want you to think about it. So they use cartoon animals and sneaky happy paths to make sure you stay blissfully ignorant.


Now, of course happy path design also happens at companies that don’t have any nefarious hidden intentions.

When you sign up for Basecamp, we don’t trick you, coax you, or collect any more information than we need to get your account working properly.

However, we’re also a for-profit software company, and business performance is one of our considerations when we design our interfaces. When you sign up for Basecamp, we encourage you to take actions that give you the best chance of having success, and (hopefully) becoming a paying customer.

The difference is, our approach is fully above board. If you have success with Basecamp, your life gets a little easier, and we earn a new paying customer. We promise to support you and protect your data. You pay us for that. Cool for everybody.


Using software is inherently a handshake agreement between you and the service provider. It’s not unlike paying for a physical service.

The problem is, many of the dominant software makers are abusing your handshake in increasingly dastardly ways. They treat their customers like sitting ducks — just a bunch of dumb animals waiting to be harvested. And when growth slows, they resort to deceptive and creepy tactics to keep the trend lines pointing skyward.

So what can we do, as consumers?

First, keep your eye out for sneaky manipulation, especially when you’re first signing up for a service. If you’re asked to share personal information or forced to commit to something that makes you feel uncomfortable, you’re probably being used.

Second, slow down and thoroughly consider the choices you’re making. You’ll end up discovering weird, surprising things about services that you thought were harmless.

Third, be wary of any “free” software platforms. Sure, you’re not giving those companies any money directly. Instead, you’re giving them something else they’ll use to get money — your attention, your time, your personal information—all things that are arguably more valuable than money.

And finally, pay for software! When you pay real money to software creators, you’re supporting them, and they’ll support you in return.

More and more independent software makers are standing up and defending users against data misuse and manipulation. Recently, Feedbin significantly altered their tech to protect their users from being tracked by the likes of Facebook or Twitter. That’s a great example, and there are many others like it.

Vote with your wallet, and support the people who really do have your back.

Introducing Boosts: an all-new way to show your support in Basecamp

We gave up on Likes and invented a totally new form of tiny communication.

If there’s one thing you can’t avoid on the Internet, it’s Likes. They’re in nearly every software platform where people post photos or write text messages.


Sometimes Likes are called Faves, Hearts, Reactions, Claps, or something else, but the basic idea is the same: they’re a small, quick way to express your feelings about something, usually accompanied by a count of other people who had that same feeling.

Until today, we had exactly this sort of feature in Basecamp 3. We called it Applause. If you liked a post, you’d clap for it. Everyone who clapped was shown in a row.

Basecamp’s applause feature.

This was fine, of course—it worked just like all the other Likes.

But a couple months ago, we started thinking more deeply about this pattern, and we noticed it has a lot of insidious problems.

  1. Likes are vague, especially in a professional setting. Let’s say your boss liked someone else’s post, and not yours. You might start questioning what happened. Was she just busy and not paying full attention to everything? Or did she do that intentionally? What does it all mean!? There’s no way to know, because there’s not enough information — just a bunch of digital grunting.
  2. Likes are obligatory. How many times have you felt obligated to SMASH THE LIKE BUTTON because you didn’t want to seem like a jerk, or because everyone else was liking something? There’s a subtle peer pressure and herd mentality hiding behind those thumbs up.
  3. Likes are vanity metrics. Whenever you post something to a social network, do you obsessively check to see how it was received? That’s because those little Like counts are a drug for your brain: you get a dopamine rush by observing your own mini-popularity contest. It’s a psychological trick to keep you coming back for more.
  4. Likes are thoughtless. Has there ever been a more mindless form of communication than merely tapping a button? Liking something requires almost no effort or consideration whatsoever. Here’s what you’re really saying: “Thank you for spending your precious time posting this. In return, I have clicked a button. It took me less than one second. Bye.”
  5. Likes are canned. In most apps you have to pick from a predefined set of acceptable symbols (or in Basecamp’s case, just clapping.) That’s not great for addressing the infinite range of nuanced human emotions, and it’s also totally impersonal. Why should some software company decide which 3 emotions you’re allowed to have?

Now, it’s not all bad. There are some good things about Likes too:

  1. Sharing support for others is wonderful. We want to encourage that, of course!
  2. It’s nice to respond to something without making a fuss. You might not have much to say, but you still want to let someone know you appreciated their ideas. Notifying a bunch of other people on a thread merely to say “good job!” is overkill.
  3. It’s helpful to know that people saw your posts. When you see that 10 people liked your post, you’ll know they received it and thought about it (at least a little.)

With all of these ideas in mind, we went back to the drawing board and came up with a fresh new approach that’s never been done before. We’re calling it Boosts, and it’s way better than all of those crummy digital grunts.

Here’s how you boost something in Basecamp.

In various places in Basecamp, you’ll see a new rocket icon:

Boost button!

Click that, and it’ll morph into a small text field.

A field in which to boost

You’ll notice there are no predetermined options or smiley face buttons to choose from. That’s on purpose. You have to make it up yourself!

Add some emoji or write a tiny text note, up to 16 characters max. Then click the green check mark to save your boost (or the red X to cancel.)

You can add more than one boost if you want, and they’ll collect into a little bundle like so:

Boosting twice

Your boosts won’t notify anyone other than the original poster. So if you’re on a comment thread with 10 other people and you boost Dave, only Dave will get a notification about it. This is in contrast to comments, which send a notification to everyone on the thread. So if you just want to say “Great job!” or “I agree” or “👍”, but you don’t want to bug everyone with a notification, boosts are best!

If you messed up making a boost, click on it and a trash icon will appear. Click the trash to delete it. (If you’re an admin, you can delete anyone’s boosts in the same way.)

Deleting a boost

After a lot of people have boosted someone, you’ll see a sweet block of small supportive comments, where everyone’s message is totally unique! There are no vanity counts or anything like that.

Here’s how it looked when I announced that we’d be launching Boosts:

A block o’ boosts

Other times, boosts work like a silly mini-conversation.

lol juice boosts

When you’ve received some boosts, you’ll get notified about them every 3 hours as long as there’s something new to report—otherwise Basecamp won’t notify you.


Why every 3 hours? We think it’s the perfect amount of time: infrequent enough that you won’t be bombarded about little responses, but frequent enough that you won’t miss anything for too long.

When you click on that notification, you’ll see all your boosts, ordered by date:


You can also unsubscribe from the boosts notifications, if you prefer. Just hit the button in the top-right corner of the page above.


What happened to applause?

Applause is no more (it’s been replaced by Boosts.) But old posts that had applause will still show it—those claps have simply been turned into boosts instead.

Clap Boosts.

So that’s Boosts — we hope you like them! (Pun intended)

We’ve been using boosts for over a month, and we’ve found them to be a much richer form of communication than our primitive old applause system. They’re far more contextual, freeform, and creative: perfect for posting short, thoughtful responses.

After a few days, you’ll notice you won’t feel obligated to boost something unless you genuinely have something to say. Boosts are far less susceptible to vague interpretations, since every little boost is unique to the conversation at hand. And with no buttons to smash, there’s no more mindless button smashing!

Give boosts a try and let us know what you think. We’d love to hear from you on Twitter or in the comments on this post.

🚀🚀🚀


New to Basecamp and want to see what it’s all about? Sign up for a 30 day free trial over yonder.

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 best visual description of a company I’ve ever seen

Can you describe your company this concisely?

Back in 2010, I saw Andrew Mason give a talk at Startup School that included a slide that really blew my mind. The slide wasn’t about Groupon (Andrew’s company), it was about Meetup.com.

Andrew heard Scott Heiferman (CEO of Meetup.com) describe the initial version of Meetup.com as a matrix of cities and interests. He put it in spreadsheet format and here’s how it came out:


It doesn’t matter how many rows or columns — it works at all scales. It’s such a simple representation of what is ultimately a simple idea (meeting up with people in your city who share a similar interest), but it could just as easily been diagrammed in a complex way.

I’ve come back to this slide over and over for inspiration when thinking about new concepts or product ideas. It’s a great exercise in clarity. Can I boil down the idea into something as simple as a column and a row?


Today, Meetup was acquired by WeWork.

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.

Are you Sure?

Considerate software doesn’t second-guess.


I was Twittering away the other day, and Prettier came across my feed. Prettier turns the conceptual moorings of lint on their head. Instead of “Well, actually”-ing you when you make a commit and forcing you to fix whatever pedantic issues it’s squawking about, it just… fixes them.

As you can guess, I have an uneasy relationship with lint. I value what lint brings to the table, but I don’t like my tools saying, “You need to do x before I’ll do what you want.” Who’s serving who here? You’re a hammer. Swing.

This is a niche example of software behaving inconsiderately. A common example takes the form of three words guaranteed to upend the user / tool power dynamic with every invocation: “are you sure?”

It seems like an innocuous enough question to ask before you complete an action on their behalf, but think about how it would play out in real life.

Person A: “I’ve got my hands full with all this stuff. Mind opening the door?”

Person B: “Are you sure you want to open the door?”

Person A: “Uh, yeah. I wouldn’t have asked if I wasn’t.”

Person B: “OK, I’ll open the door.”

Person A: “Great, can you close it after me? I don’t want the dog to get out.”

Person B: “Are you sure you want me to close the door?”

Person A: “I really fucking hate you right now.”

You’d never do this in real life, but it happens all the time in software. Alan Cooper nails exactly what’s wrong with this question in his seminal book, About Face:

Interactive products should stand by their convictions. If we tell the computer to discard a file, it shouldn’t ask, “Are you sure?” Of course we’re sure; otherwise, we wouldn’t have asked. It shouldn’t second-guess us or itself.

On the other hand, if the computer has any suspicion that we might be wrong (which is always), it should anticipate our changing our minds by being prepared to undelete the file upon our request.

How often have you clicked the Print button and then gone to get a cup of coffee, only to return to find a fearful dialog box quivering in the middle of the screen, asking, “Are you sure you want to print?” This insecurity is infuriating and the antithesis of considerate human behavior.— Alan Cooper

Self-confidence is one dimension of Cooper’s core design principle: Software should behave like a considerate human being.

What are some of the other dimensions that make a human (and software) considerate? They use common sense, don’t ask a bunch of unnecessary questions, keep you informed, help you avoid awkward mistakes, fail gracefully, anticipate the needs of others, and are preceptive and conscientious.

If you’re trying to make considerate software, don’t ask your user if they’re sure. Assume they’re competent humans who mean what they intend. If the action is potentially destructive, give them a way to gracefully recover if they change their mind (undo/redo, archive states, auto-save drafts, etc).

If you’ve fallen into the “Are you sure?” trap, well, welcome to the club. I certainly have, and so have a bunch of others. Sometimes you don’t realize you’re doing something inconsiderate, and sometimes time and money dictate other choices.

But next time you find yourself reaching for that question, take a step back and think about what you’re trying to accomplish. Do you really need to ask the user that? Is there another approach you could take that would be more considerate? If so, take it. You’ll be rewarded with more satisfied customers for your effort.

What is someone going to stop doing when they start using your product?

Stop using a key, start pressing a button

When you’re building a new product, you’re often thinking about all the new things people are going to be able to do with it. Now they can do this, now they can do that. Exciting!

But there’s a better question to ask: What are people going to stop doing once they start using your product?

What does your product replace? What are they switching from? How did they do the job before your product came along?

Habit, momentum, familiarity, anxiety of the unknown — these are incredibly hard bonds to break. When you try to sell someone something, you have to overcome those bonds. You have to break the grip of that gravity.

So, when you’re thinking about your product, think about what it replaces, not just what it offers. What are you asking people to leave behind when they move forward with you? How hard will that be for them? How can you help them overcome everything that’s tugging them in the opposite direction?

Slow, Smooth, Fast, Effective


A mantra I apply to product design

“Slow is smooth, and smooth is fast” is a common mantra in marksmanship. The kernel of wisdom being: Don’t rush, make your actions count, and you’ll come out ahead.

It’s inspired a mantra that I apply to product design:

Slow Smooth Fast Effective

Thinking slowly about the problem provides the insight and context needed to solve it holistically. Step back, and take a deep breath. Understand your true target. It’s probably not the first thing that caught your eye.

Acting smoothly means that your movements aren’t wasted. Once you’ve identified the true target, your actions can be efficient, and focused. You hit your target with accuracy.

Moving fast is a byproduct of accuracy. Missing your target creates unnecessary waste, forcing you to recalibrate, reload, and resight. Only after you’ve hit your target can you move on to the next one. Accuracy is fast.

Effectiveness is the byproduct of speed and accuracy. If you hit your targets smoothly and quickly, you’ve become an effective marksman.

Notice that each step builds upon the previous one: You must go slowly and smoothly before you can be fast and effective.

Focus on being slow and smooth, and the rest will follow.


If you’d like to embrace a calmer, more thoughtful way to work, check out Basecamp 3. It’s the saner way to manage projects and communicate company-wide.