Most of the posts in our Design Decisions series have been about visual design. Why is this pixel here, why is that button there, why does this read like that?
In this installment we want to share some of the thinking behind the execution of a specific feature. It’s not so much about the visual design as it is about the functional design.
When we launched Highrise we offered vCard and Basecamp import. You could upload a single vCard with many people, or many vCards with individual people. And if you had a Basecamp account you could pull all the people you created in Basecamp over to your Highrise account.
But that’s wasn’t enough. Well, it was enough for an initial launch. Hundreds of thousands of contacts were imported over the next few weeks. The options we offered were working for plenty, but requests for additional import options began to pile up.
Hearing without listening
This is where we got lost. We heard, but we didn’t listen. We heard “I need to import from…” and lumped all the “froms” into a single pile. Some people wanted to import from Outlook, some from Excel, others from apps that spit out data in CSV (comma separated values) format, and others from other generic CSV sources. So we thought, ok, let’s kill all these birds with one stone and build a generic CSV import tool. Upload your file, match up the fields, and we’ll take care of the rest. That should be easy, right?
What we missed
Here’s what we missed: In a statistical romp, the number of people who wanted to import from Outlook trounced the number of people who wanted to import from other CSV sources. But we didn’t listen to that. We just heard “import from CSV” and we set off to build the generic CSV import tool, cause, ya know, it should be easy, right?
Well, it turned out not to be very easy at all. It was easy enough to get clean data in, but when people sent us sample data it was pretty dirty. Some was encoded wrong, some wasn’t encoded at all. Some was quoted correctly, some was all scrambled up. Some had the same number of columns per row, some was variable. It was a total mess. Not an impossible mess to deal with, but maybe not one worth the effort right now.
Three weeks was two weeks too long
So three weeks in we said what the fuck? Why is this taking so long? Why aren’t we done yet? And it turned out we weren’t done because we hadn’t listened. We didn’t chop the big problem into smaller, more prioritized problems. We didn’t Judo it.
What we should have done
What we should have done was first build an Outlook importer. That was the biggest pain point for the most people. It was our customer’s top priority and it should have been ours as well. Focusing on a single file format removed 95% of the uncertainty. We knew the column names, we knew the file structure, we knew what to expect. When you know how the parts fit together it makes it much easier to build something. You can add value quicker. Maybe not all the potential value, but most of it for most people. That’s a quick win.
And so that’s what we did. We put on the brakes, turned the wheel, and pointed our efforts at an Outlook-only importer. It took about a week, we launched it, and we made a lot of people very happy very quickly.
Then we looked at the next most popular import request. It turned out to be ACT 9!. So we grabbed some sample ACT 9! export files, mapped the format, and launched ACT 9! import next.
Listen, don’t just hear. And don’t lump a bunch of related small problems together—it just makes one big problem. One big problem requires one big solution, and big solutions take a long time (and often don’t go right). You’re better off chopping big lumps of problems into smaller chunks until you’re able to knock them off one at a time. Add value sooner by solving the highest-priority/smallest-problem first. Then move on to the next one. And then the next one. This way you can provide a long chain of value, one link at a time.