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.
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.
One of my favorite career stories is this one from Michael Beirut:
I designed little magazines when I was in the third and fourth grades, and I made logos for my friends’ bands when I was in the seventh grade. I could do hand lettering, and if someone wanted an animal in the logo, I could do that; if someone needed a poster for the school play, I could do that, too.
All along, I had no idea that what I was doing was called graphic design. I lived in the middle of nowhere at a time when no one knew anything about something like graphic design.
By accident, I happened to find a book in my high school library…it was called Aim for a Job in Graphic Design/Art. I opened the book up, and it was like receiving an instruction manual for my future career: it was all right there. I was about 15 at the time, and I thought, “This is what I want to do.”
This bears repeating: one of the world’s preeminent graphic designers didn’t know graphic design was a thing — let alone a job you could get paid for — until high school.
He knew what the idea of graphic design was, and he even knew how to do it. But he didn’t know what to call it.
Perhaps the biggest obstacle to gaining skills in a given domain is knowing the right words. Being a beginner is intimidating because you don’t speak the same language as experts, who have often forgotten what it’s like to be a beginner.
If you’ve ever had to talk to a car mechanic, you know how it feels. In the immortal words of George Costanza:
Of course [car mechanics] are trying to screw you! They can make up anything, and nobody knows! “Why, you need a new Johnson Rod in here.” Ohh…a Johnson Rod…Yeah, well, better put one of those on!
Here’s another example. Millions of people use iPhones, but they don’t know the official names for all the interface widgets and the underlying stuff that makes them work. It doesn’t affect their ability to use an iPhone, because the iPhone is well-designed.
I went to Twitter, then hit the thing that said “Notifications”, and a new screen came in, then I saw some messages, and it stopped working.
By contrast, an iOS developer knows the domain words, so they can be more precise:
The customer opened the Twitter app, then selected the Notifications Tab in the Tab Bar. The Notifications Table Viewrendered for a moment but then the app crashed. The issue might be the Notifications View Controller or some malformed data in one of the notifications.
In product design, this is related to User Experience (UX). Part of a UX designer’s job is making sure a product’s internal language is either hidden away, or translated into common words that users can understand and interact with. If you don’t do this, you might end up with this kind of thing.
A customer support rep’s job is the opposite: they translate customer-speak into domain words so a specific problem can be resolved — especially in the case of a bug report that gets passed along to developers.
Here’s one last example. I’ve been an obsessive music fan for most of my life, but I’ve never formally studied it, so I don’t know the terminology. Check out this video of Jeremy Leaird-Koch building an electronic song from scratch on an OP-1. (Jump to 1:25 or so.) Be sure to watch the subtitles.
If you make it through the whole video, you’ll see a ton of expert language:
Ambient poly lead
I’ve put in 30+ years of music listening, and these phrases might as well be in a foreign tongue.
So it’s not enough to have exposure to the outer surface of a domain. If you want to level up your understanding, you have to be willing to feel ignorant for a while and study it in depth, until you find your sea legs and pick up a handful of those all-important words. There’s no magic to it. This willingness, and a lot of practice, is all that separates the experts from the beginners.
Once you’ve learned a bit of lingo, you’ll find that the words help you ask questions. The questions help you learn how things interact. When you know how things interact, you can start understanding the system as a whole. And pretty soon, you’re an expert too.
As experts who’ve put in the time, then, how can we make things more approachable for beginners? Wouldn’t it be nice if we could simply eliminate all jargon and special words? Then we’d have no problem, right?
Well, then we’d have a new problem: we’d have no way to talk to each other! Any sufficiently complex system needs names for its component parts— otherwise there’s no way to talk in detail about the system. So eliminating internal complexity isn’t always possible or even desirable. Still, there are a few things we can do to help.
Use plain words instead of fancy words.
For example, if you’re a programmer modeling a message sent by a client, call it ClientMessage instead of ExternalActorSubmissionContent.
Give abstractions familiar names, so they seem less foreign.
In Basecamp 3, we called group chats Campfires and direct messages Pings. They’re still abstractions that users have to learn, but at least they’re helpful names—a little descriptive and a little less intimidating.
Listen to how beginners talk about the problem, and inherit their language.
We did this recently by noticing our customers called Basecamp projects “Basecamps.” They’d say, “Oh, I made a Basecamp for that.” So we ran with it and called Basecamps Basecamps instead of Projects.
If you’re in the privileged position of being an expert at something, don’t forget what it felt like to be a beginner. Let those battle scars inform how you communicate, and choose your words with intention. If you need a reminder of how it feels to be a newbie, just pick yourself up an OP-1 and let me know how that ambient poly lead turns out!
We worked hard to make Basecamp 3 the clearest and friendliest version we’ve ever written. Check it out and see more examples over at basecamp.com.
This year, 2015, marked the 20th anniversary of the first time I stuck some HTML on a server and put it out for the world to see. (Sorry about that one, world.)
Twenty years! Twenty years is a long time to do anything, especially in tech. Given how fast things churn, it’s rather unbelievable that I’m still gainfully employed to write HTML for anything at all in 2015.
I’ve been reflecting on this recently, as the web’s future keeps sounding rather bleak. It seems that nary a week passes without someone predicting the end of the open web as we know it. Perhaps understandably so — at a glance, the web appears to be suffering a death by a thousand cuts.
Let’s recap a few of the most common arguments for why the web is totally screwed.
Corporations and governments are encroaching on the open web and trying to control it from all sides (bandwidth, access, content, etc.)
Social media sites are sucking up most of the traffic and attention. In the process, they’ve become stand-in replacements for the entire Internet (think AOL 2.0.) This has the side effect of turning smaller individual websites into irrelevant sideshows.
User-hostile advertising practices are degrading user experience on the web to an alarming extent.
Native apps provide a better and friendlier alternative to traditional websites-in-browsers. As native apps continue to mature, they’ll gradually eat the web with specialized UI for every situation — which means you’ll never need to access the web directly in a browser anymore. This will turn the web into a content delivery mechanism (i.e. HTTP requests) rather than an endpoint for users to interact with directly.
Web designers and developers are overusing slick copycat layouts, styling, and template tools. This makes web production easier and trendy looking, but at the expense of individuality and substance, leading us into a bleak dystopian future where web UI becomes the software equivalent of suburban tract housing.
Publishing platforms like Medium are piggybacking off independent writers’ content while offering relatively little differentiation or authorship credit in exchange. These platforms are gathering all the small-time folks under a few large umbrellas, thereby reaping most of the financial benefit while hammering more nails in the coffins of traditional independent blogs.
Alright, so wow. That all sounds pretty terrible, doesn’t it?
A lot of those things are true. The times are certainly changing, as they always do. We web folk should keep thinking seriously about this, lest we become the old crusty janitors left to turn out the lights.
But hold on. Forget about all those problems for a moment, foreboding as they may seem. Is there anything good happening now? How about:
Despite their repeated attempts, big corporations haven’t killed the open web — at least not yet!
Small mom and pop independents now have access to massive audiences that used to be impossible to come by. Whether your business is writing, art, or anything else, it’s easier than ever to get yourself out there and make a living or solve new interesting problems with the web. Kickstarter, Medium, and Etsy are incredible platforms for the little guy.
Web tech is as sophisticated, diverse, and powerful as it’s ever been. (Granted, we’re abusing it for bandwidth-munching ads and gratuitous effects — but that’s on us. We can stop. We should stop. Please, stop.)
Native apps haven’t eaten the web either. Native is fantastic and powerful and lovely, but you know who still has websites? Facebook. Instagram. Whatsapp. Medium. These are enormous services, some of which even launched as native-only and then added web versions later, because the web as a platform is still too important and universally applicable to ignore.
We — the small, independent weirdos — still have the power to meaningfully contribute to the web and change it for the better.
So where does that leave us?
First of all, let’s chill out for a minute. Maybe the naysayers are right and we’re all doomed, but the web is still alive and kicking right now.
Secondly, let’s reflect on our missteps and start walking back the most egregious abuses of slick tech and bad UX we’ve willingly let slide the past few years. Ad blocking on iOS is forcing the issue — but it’s rather sad that we let it be forced in the first place.
Let’s make the web weird again!
Twenty years ago the web was super weird. No one had any clue what this thing was about or how it worked, so we were trying everything. Sites were badly organized, ugly, strange. Some were loosely organized communities. Some were just text. Even the best produced sites had the feeling of being held together by duct tape and straws.
Now to be clear, I’m not nostalgic for that time at all. Making websites sucked. Nothing worked well. The tech was painfully slow and limiting in every imaginable dimension. I don’t want to go back.
But the one thing the web had then, and which it has lost a lot since, was the sense of rampant experimentation. The feeling that it was fine not to have everything figured out or perfectly polished before letting people see it. That we were all in this bizarre human experiment together.
If we want the web to keep thriving, we have to start letting ourselves experiment (and fail) more. The web still has a low barrier to entry and the biggest possible audience. That’s an incredible thing.
So c’mon everybody. Let’s mess this place up again! Get weird! It’ll be better for it!
Recently I did a little side project to improve the website for a non-profit animal shelter in our town. The existing site was an outdated Microsoft FrontPage menagerie, so basically anything I did would be a big improvement.
I spent around 20 minutes creating a simple design in HTML, and then several hours editing, rewriting, and refining the copy. In the end, I reduced a scattershot 25-page website down to about 8 focused pages written in a friendly tone.
My next instinct was to apply our great modern web toolset to the site. Let’s add a static site generator or a CMS! Let’s add Sass and a grid system! Let’s do more fashionable things!
Then I started looking at those tools critically. A static site generator usually requires knowing Markdown and esoteric commands and configuration. A typical CMS will need setup, logins, security patches, templates, and maintenance. Even hosted CMSes have a lot of cognitive overhead, and the content is trapped away inside someone else’s system.
These are tools made by geeks, for geeks. Why do we need a CMS for an 8-page site? And for that matter, why even bother with Sass? Regular old CSS can do the job just fine.
Who knows who will take over the site in the future. I’ll hang with it for a while, but someday someone else might have to work on it. It would surely be easier to do that with 8 simple, straightforward HTML files than with some custom WordPress installation that’s several versions out of date. So what if I have to repeat the navigation markup 8 separate times? It’s not that hard. We used to do it for much larger sites!
Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?
As builders, we like tools and tech because they’re interesting and new, and we enjoy mastering them. But when you think about the people we’re building for, the reality is usually the opposite. They need simple designs, clear writing, less tech, and fewer abstractions. They want to get stray animals adopted, not fuss around with website stuff.
Remember when the web was damn simple? It still can be. It’s up to us to make it that way.