Much of the tension in product development and interface design comes from trying to balance the obvious, the easy, and the possible. Figuring out which things go in which bucket is critical to fully understanding how to make something useful.
Shouldn’t everything be obvious? Unless you’re making a product that just does one thing — like a paperclip, for example — everything won’t be obvious. You have to make tough calls about what needs to be obvious, what should be easy, and what should be possible. The more things something (a product, a feature, a screen, etc) does, the more calls you have to make.
This isn’t the same as prioritizing things. High, medium, low priority doesn’t tell you enough about the problem. “What needs to be obvious?” is a better question to ask than “What’s high priority?” Further, priority doesn’t tell you anything about cost. And the first thing to internalize is that everything has a cost.
Making something obvious has a cost. You can’t make everything obvious because you have limited resources. I’m not talking money — although that may be part of it too. I’m primarily talking screen real estate, attention span, comprehension, etc.
Making something obvious is expensive because it often means you have to make a whole bunch of other things less obvious. Obvious dominates and only one thing can truly dominate at a time. It may be worth it to make that one thing completely obvious, but it’s still expensive.
Obvious is all about always. The thing(s) people do all the time, the always stuff, should be obvious. The core, the epicenter, the essence of the product should be obvious.
Beyond obvious, you’ll find easy. The things that should be easy are the things that people do frequently, but not always. It all depends on your product, and your customer, but when you build a product you should know the difference between the things people do all the time and the things they do often. This can be hard, and will often lead to the most internal debates, but it’s important to think deeply about the difference between always and often so you get this right.
And finally are the things that are possible. These are things people do sometimes. Rarely, even. So they don’t need to be front and center, but they need to be possible.
Possible is usually the trickiest category because the realistic list of things that should be possible will often be significantly longer than the list of things that should be obvious or easy. That means that some things on the possible list might be better off off the list completely. Instead of making them possible, maybe not making them at all is the right call.
Coming to know the difference between obvious, easy, and possible takes a lot of practice, deep thinking, critical analysis, and, often, debate. It’s a constant learning process. It helps you figure out what really matters.
But once you’re able to see the buckets clearly, and you begin to think about things in terms of obvious, easy, and possible instead of high, medium, and low priority, you’re on your way to building better products.
The hardware engineering and software coordination behind 3D Touch in the iPhone 6S is impressive. It’s such an Apple feature. Executed with exquisite diligence because they control the whole stack. Marvelous.
But you know what, it’s not my favorite feature of the 6S. That honor belongs to the low-tech, behind-the-curve addition of an extra gigabyte of RAM. Something that probably cost Apple just a few extra dollars per phone and almost no engineering prowess. (Compare that to the probably hundreds of millions in revised tooling, advanced development, and more needed for 3D Touch.)
Doubling the RAM means apps aren’t constantly being swapped in and out. Which means switching between them is super fast more of the time. Which in turn makes the whole phone feel much better over the course of a day.
It’s been repeated ad nauseam, but it’s still so hard to internalize for most product people: Speed is a feature.
Usually, it’s one of the most important features. Yet it’s also one of the hardest to get right. Chiefly because every other feature is generally at war with speed. Any excess CPU cycles are quickly captured by new, advanced, and ultimately slowing features. Extra cycles are like a surplus government budget: The constituency is going to have a thousand ideas for how to spend it.
It’s not easy to get this balance just so. You have to be fast at what people want and expect. Being the fastest phone running iOS5 or Window OS isn’t going to get you any business.
Comparing this RAM apple and that 3D Touch orange, though, is also a worthwhile reminder that good product design doesn’t deal in distinct categories. It’s all a fruit salad! Customers just want it to be delicious and nutritious.
Software makers are obsessed with new. And of course we are, that’s our job: making more, newer, better! But as a lot, we’d be well-served to remember this affliction is generally not shared by our users and customers.
Sure, some people love upgrading to the latest version the minute it lands. It’s also a lot easier when it’s a personal device, like an iPhone, where the focus isn’t purely productivity.
But remember all those companies holding on to IE6 for their dear life? That’s the other side of ‘upgrading fun’. Disrupting workflow, processes, and institutional knowledge because the damn fax machine won’t send the important contract until the firmware is upgraded. What possible utility could a firmware upgrade to the fax machine provide that’s worth keeping a document from sending?
It’s ok not to LOVE, LOVE all software
It’s so easy to get self-righteous about IE6 laggards and the fax machine that cries for a firmware upgrade, but they’re two sides of the same coin.
For some of our customers, Basecamp is an appliance. It does the job, and it does it well, but they don’t have to LOVE, LOVE, LOVE IT to be happy customers. I’m at peace with that.
Clearly the person who came up with “sunset” as a euphemism for kicking people off their service was not at peace. Whether the reason was a shiny new version or simply losing interest in maintaining legacy, “sunset” encapsulates all the misconceptions software makers have about why their users upgrade.
It’s not beautiful to lose access to your data. And no, that gobbledegook XML or JSON export doesn’t help anything. It’s not beautiful to have a trusted tool or service ripped from your hands because the maker found it an inconvenience to keep it around. It’s nasty, it’s annoying, and apologizing for ANY INCONVENIENCE THIS MIGHT CAUSE is just a further slap in the face.
No more sunsets at Basecamp, ever
So Basecamp 3 is not going to sunset anything. Not the current version of Basecamp, not the classic, original version of Basecamp. Either of those work well for you? Awesome! Please keep using them until the end of the internet! We’ll make sure they’re fast, secure, and always available.
But, but, but isn’t that expensive? Isn’t that hard? What about security? What about legacy code bases? Yes, what about it? Taking care of customers — even if they’re not interested in upgrading on our schedule — is what we do here. Cost of business, as they say.
At launch, Basecamp 3 is not going to have all the same features as previous versions, so some existing customers may well just want to continue with whatever version they’re on. That’s great! All the new, exciting features will still be there when (or if) they choose to upgrade.
For those existing customers who do want to upgrade, we’re going to roll out the red carpet: Big discount on a new trial, and we’ll store your old Basecamp data in the existing versions for free, forever, as long as you’re a paying customer of the latest.
It’s really not rocket science. People like change on their own schedule, they detest it when forced according to someone else’s. That’s just human nature, and it’s rarely good business to fight it.
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!
When collaborating with others — especially when designers and programmers are part of the mix — watch out for these dirty four letter words:
They are especially dangerous when you string them together. How many times have you said or heard something like this:
“We really need it. If we don’t we can’t make the customer happy. Wouldn’t it be easy if we just did it like that? Can you try it real fast?”
Of course they aren’t always bad. Sometimes they can do some good. But seeing them too often should raise a red flag. Be careful when you use them, be careful when you hear them. They can really get you into trouble.
Remember the Flip camera? From its premiere in 2006 until the business was sold to Cisco in 2009, the little video recorder was killing it. Lavish praise, booming sales, flying high. And then cell phones got good enough at recording video, and that was the end of that.
If you disregard the acquisition proceeds, was Flip a terrible business? Well, that depends: Were they taking profits along the way?
There’s no natural law that states all products and services must endure forever and always. Some companies are glorious sprints, others are slugging marathons. Both can work, but the former is especially sensitive to making money along the way.
The problem is that everyone thinks they’re going to run a spectacular marathon in technology these days. There’s no amount too great to be invested in future growth, because the future is infinite, and you’d be a fool not to capture as much of that as you possibly can.
But what if the time allotted to your capture looks more like Flip? What if your product is going to have a great, booming run, but not for the next 30 years, just the next five?
Case studies: Dropbox and Evernote
Two companies come to mind when I think of Flip: Evernote and Dropbox. Both have had tremendous success with users, both were seen and perceived themselves as “long-term sure bets”, and both are starting to look a lot less shiny these days.
Both Evernote and Dropbox are facing increasing indifference from customers and competition from simply Good Enough features in someone else’s more complete offering. “You’re a feature, not a product”, as Steve Jobs famously dismissed Dropbox (see The case against Dropbox and Evernote, The First Dead Unicorn for but two deeper analyses).
I bet you that neither heeded the lessons of Flip. I bet you that both thought they were going to be around forever, so no amount of investment in the future would be too great. I bet you that even the mere suggestion that they should be taking profits during their first, seven fat years of prosperity would have been laughed out of the boardrooms.
Don’t put it all on growth
A lot of business administration is about managing risk. Thinking about how things might pan out if you’re not as clever as you think you are, or as lucky forever as you currently seem.
Yes, investing in growth when you got a good thing going is smart. But so is thinking that you might currently be enjoying the very best years of the business, not just “the beginning of an amazing journey”.
The smart choice is making sure you win in both cases. Don’t just keep putting it all on red and rolling. Eventually, everyone’s luck or skill runs out, and then it’s awfully nice if the entire time spent playing wasn’t all for nothing.
We’ve always felt strongly that we should share our lessons in business and technology with the world, and that includes both our successes and our failures. We’ve written about some great successes: how we’ve improved support response time, sped up applications, and improved reliability. Today I want to share an experience that wasn’t a success.
This is the story of how we made a change to the Basecamp.com site that ended up costing us millions of dollars, how we found our way back from that, and what we learned in the process.
This story starts back in February 2014 when we officially became Basecamp the company. This was a major change — a rebranding, the discontinuation of some products, the sale or spinoff of others, and more. As part of that process, we decided to redesign basecamp.com (our “marketing site”) to reflect that it was not only the home of Basecamp the product but also Basecamp the company.
The result was a fairly dramatic change, both in content and visual style. The redesign extended well beyond just the landing home page (you can browse the archived version before and after we became Basecamp), but the most noticeable change was to the main page, which you can see below.
One very significant change here was that we removed the signup form from the homepage. This wasn’t necessarily the most considered decision; we hadn’t done extensive research or testing recently on the role of the number of steps required to signup for a Basecamp trial. Over the years, we’ve long debated the value of a fast signup (which might bring in more people initially) vs. a well considered signup (which might have fewer initial signups but still retain all of the committed people who would ultimately become paying customers), but as far as I’m aware, we didn’t explicitly decide that we wanted to go for a slower signup. It was one of the many decisions that we made in the course of “Becoming Basecamp”.
We didn’t A/B test this new marketing site initially for a variety of reasons: we were too busy to prepare dramatically different variations, we wanted to present a consistent image at this time of big change, and we liked what we had come up with.
Immediately after we changed the marketing site I noticed that conversion rate had fallen on the marketing site; a smaller portion of people visiting basecamp.com were signing up to try Basecamp than had been before we changed the site. This wasn’t an unexpected effect: we had more traffic coming to basecamp.com because we were redirecting visitors from 37signals.com and we picked up some tech press coverage and traffic from other low-converting sources, so a smaller portion of people signing up wasn’t initially concerning. In the immediate aftermath of Becoming Basecamp, the absolute number of signups held steady, which fit with our expectation as well.
In the first couple of months after we changed the marketing site, signups trended lower than they had at the start of the year. This, too, wasn’t a hugely concerning event by itself: our biggest signup month is always January, and things slow down through late summer and then pick back up again in the fall. Because demand for Basecamp is driven in part by normal cycles within small businesses (many of which start new projects at the start of the calendar year), there’s a fairly strong seasonality to new signups.
It took a while to conclude that the decline in signups we saw through the summer of 2014 was more than normal seasonality. When things didn’t pick back up in the fall, it was clear that there was something else going on. In an internal writeup of our 2014 performance, I wrote:
Things didn’t improve through the first half of 2015, and we discussed it intermittently without making any major changes. Finally, in July we launched an A/B test that brought a signup form back onto the homepage, with immediate and dramatic results: signups increased by 16% in the with-signup-form group compared to the group without. The net impact upon finishing the test and rolling out the change to 100% of traffic was clearly visible:
We’re of course thrilled to have this performance back: at our scale, this sort of improvement is worth millions of dollars in revenue. The period of degraded performance was in no way threatening our livelihood (2014 was our highest revenue year ever, and 2015 is on track to beat it), but it certainly hurt.
Where did we go wrong and what can we learn?
There’s an obvious lesson here: in the specific context of Basecamp at the moment, we get more net paying customers when we make it as easy as possible for people to get started. The marketing site for the new version of Basecamp we’ll be launching soon will include a signup form on the homepage, but this is just the surface level learning from this experience.
The deeper lessons are really about process, and there are two key things that I hope we take away from this experience:
1. We don’t know what will work. We didn’t A/B test this change, which meant it took a long time to notice what happened. An A/B test of the new marketing site vs. old, conducted back in February 2014, would likely have caught the lower performance of the redesign within a couple of weeks. In an A/B test, you hold many external factors constant — the same seasonality effects apply, you can send the same mix of sources to each variation, etc. This lets you draw a more direct connection between what you are changing (the design, and more specifically the number of steps in the signup flow) and signup rates.
Because we didn’t test the redesign, we were limited to making longitudinal comparisons to see how the new marketing site compared to the old. With seasonality and other external effects (for example, when you rename your company and discontinue some products), it’s really hard to identify which of the many things that contribute to the ultimate number of signups we see had what impact, so it took us a while to nail down exactly what was happening.
It’s easy to decide not to test a change — you’re busy, you just know it will be better, you don’t want to risk the confusion that’s always possible anything you’re running a split test. In the future, it will be easy for us to justify spending the time and effort to test a marketing site redesign thoroughly in the future — we’ve learned the hard way what can happen if you don’t do that.
While we’re unlikely to make exactly this same mistake again, it’s worth considering where else we might be making a similar mistake that we aren’t even aware of. Are there areas of the product where we make untested assumptions that might have a big impact either on us as a business or on our customers success at using Basecamp? Can we test our beliefs in a quantifiable way?
2. We didn’t communicate effectively. Because we’re such a small company, many of the decisions about things like where to put the signup form are made by individuals or very small groups without a lot of broader discussion. In this case, that discussion might have brought up the risk associated with removing the signup form from the homepage, and we might have made a different decision back in 2014.
We also failed to take action quickly once we knew what was going on: over six months passed between when we clearly identified the problem and when we took action to address it.
We’re a very project-driven company: we tend to focus on a limited set of things at any given time and work on those very actively. In the time between the redesign and now we’ve collectively worked on a lot of different projects. We launched The Distance, added many new features to Basecamp, worked on many behind-the-scenes projects, and have been hard at work on the next version of Basecamp coming out soon. We also shifted a designer who had been working on things like our marketing site to work on Android, and we explored a bunch of new marketing ideas around advertising, sponsorship, etc.
All of this led to us just not spending a lot of time thinking about our marketing site, and that’s reflected in the pace of testing and refinement that it’s seen. We conducted only 1/3rd as many A/B tests in 2014 as the year before, and made significantly fewer commits to the marketing site’s repository. This all helps to explain why we were so slow to act: with no ongoing project working on the marketing site, we just weren’t spending any time thinking or talking about it.
As a data analyst, I could have done more, too — I knew that we should have A/B tested the redesign when we did it, and I knew that we needed to try bringing back the signup form months before we actually ran a test. In both cases, I either didn’t find the opportunity to make my case or didn’t do it vociferously enough to change the outcome. In hindsight I certainly wish I’d banged the table more loudly.
These were certainly painful and expensive lessons to learn, and we’re fortunate that the fundamentals of our business are strong enough that this wasn’t anywhere near an existential crisis. We’ll be a better company as a result of having gone through this, and hopefully we won’t make the same or similar mistakes in the future.
Many writers and publishers are freakingout after Apple opened Safari to ad blockers in iOS9. Ad blockers have been around for a long time, but the fear is that this is the move that will take the concept mainstream.
That fear appears well justified. The App Store’s charts have been dominated by ad blockers since the release of iOS9 last week. Currently, the #1 paid app is Crystal, an ad blocker, and so is #3, Purify. Clearly some pent up demand.
Another data point is the following poll from The Verge. It was setup with an almost satirically over-the-top slant, and yet readers pummeled them:
It is difficult to get a man to understand something, when his salary depends on his not understanding it — Upton Sinclair
The prevailing response from the media business to this challenge is hysteria: The World Of Journalism As We Known It Is About To End.
But I think more than a little empathy is in order. The natural response to having your livelihood threatened is universally to FREAK OUT. It doesn’t matter if you’re a French farmer or cabbie or if you’re an internet writer or publisher.
I say to you that the VCR is to the American film producer and the American public as the Boston strangler is to the woman home alone… The investment of hundreds of millions of dollars each year to produce quality programs to theaters and television will surely decline.
Consumers are going to stop going to movie theaters, or they’ll skip over commercials on broadcasts, and the entire industry is doomed! Ring familiar?
Fast forward to 2014: The movie industry just set another revenue record. Despite VHS, despite torrents, despite Chinese bootlegs.
But the movie and TV industry has indeed made great changes since 1982. Customers wanted to enjoy movies and TV shows without commercials. From their home. On demand. And when the industry woke up to the futility of first blaming, then suing their customer base, they found a big market just waiting to pay for their creative output (oh, and the public never did stop going to the cinema either).
Another parallel is the music industry. MP3s and Napster caused similar consternation in the early 2000s (and the cassette player before that). Nobody was going to put out music anymore in this new world of flippant piracy!
Yet here, unlike the movie business, there actually was shrinkage of the overall market. From 2002 to 2014, the US music industry went from $25 billion to $15 billion.
So one story of better than ever results, another story of shrinking results. Such is the nature of business! If you believe that you’re somehow morally entitled to an ever-increasing industry pie, reality is going to be a merciless teacher.
The lesson to take away from disruption, beside that it’s better when it happens to other people, is not “everything is going to turn out as well as today or better”. Rather, it’s that fighting what consumers want is a losing battle. Blaming them or shaming them doesn’t work. Those are merely stalling tactics — a way to cope with the pressure and anxiety of not knowing what tomorrow is going to look like, or whether you’re still going to have the same job you do now.
The sooner you stop fighting the present, the sooner you can get to work on figuring out the future.
People are spending more time reading online than ever. If the written media business can only see a dichotomy between “we must have privacy-invasive trackers along with bandwidth-hogging and overlaying full-size ads” and “death”, they’re just not looking hard enough. But that’s okay: YOU’RE FREAKING OUT. It’ll pass, or at least recede, and you will come to your senses.
The pendulum had swung too far. Publishers had abdicated far too much responsibility for the user experience and privacy concerns of their readers for too long. The ad pushers grabbed that opening and cranked the nasty to 11. There was bound to be a reaction. This is it.
It’s a soothing story to blame Apple, pin them with a motive of treating journalists and publishers like collateral damage in a war against Google. But there’s an easier answer: It’s simply better for Apple’s customers!
(Remember reader mode in Safari? Hiding all the ads, reformatting the text? Same motivation, no complaints from the industry because it still loaded the ads, so even if readers never saw them, they still counted.)
Anyway, the proof is in the App Store chart pudding! Customers are flocking to pay for a solution that restores some sanity to their mobile browsing experience.
You can cry about it, you can stomp your feet, you can call Apple and readers mean names, but the ice cream isn’t going back on top of your cone. Take a few weeks to grieve, then get on with the mission of figuring out how the written word carries on without shoving intrusive ads down readers’ throats.
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.