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.
Initial import
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.
Judoed
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.
Lesson learned
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.
Josh Walsh
on 28 Aug 07I think all businesses have experienced similar problems at some point, if not routinely. Hindsight is always 20/20…. but the fine line comes when you’re waist high in a bad solution and make the jump to start over with a new approach. It takes guts.
Well Done.
Brian H
on 28 Aug 07Jason,
I got to hand it to you, the reason I keep coming to your blog, isn’t always because of the information in it, but how its presented. Now sometimes I disagree with your POV in some areas but, hey you’ll probably disagree with mine in others; its a wash.
What I really like is a company blog that’s professional when it needs to be and tells it like it is when it needs to. Case in point.
“So three weeks in we said what the fuck?”
I would love to see my company include that in their blog…wait a minute…oh yeah I forgot…i work in a company that believes in “traditional business” and a “real” company has no business with a blog.
Erik
on 28 Aug 07Love this post! Love the honesty, love the lesson learned, love the no-nonsense. This is why I keep reading this blog.
Carl Tashian
on 28 Aug 07hi Jason,
I hope you will take a moment to read a piece I wrote about importing vs. syncing when Highrise first came out:
http://www.tashian.com/carl/archives/2007/03/nsync.php
I’d love to hear your comments if you feel compelled.
random8r
on 28 Aug 07Hmm…
Judo already has a meaning!
It’s the gentle way… it’s supposed to be using your opponent’s force in a way where both people win. I say “supposed to be” because the more popular sport judo is very different from the other, lesser-known kind.
But I guess you’re meaning something which skilled martial artists use all the time, and is actually more appropriate to Ninjutsu than Judo: applying the minimum effort to gain the maximum effect.
As one shifts from being a student to being more skilled, one brings one’s circle of effort in, closer towards one’s spine: one takes the amount of physical effort required down, yet increases the amount of potential effect.
The same would be for writing software: using well written software and frameworks and languages that encourage re-use means less effort ongoing; as one gains more and more skill, one needs less and less to perform such large sweeping gestures to make one’s intended mark.
Ironically, at the seat of these “effortless efforts” is relaxation.
I recommend a book called “Cheng Hsin: The Principles of Effortless Power” by Peter Ralston.
Cool ;) Love ya’s. :) Julian.
random8r
on 28 Aug 07@Carl – Dude! Echoing my sentiments exactly when Highrise came out. Don’t want to crap on their parade.
This is a great app, and it does what it does really well, and now, it does Address Book syncronisation with Apple’s Address Book with that new Cocoa App of name which escapes me at present! (Pretty awesome).
However, what we’re stipulating is a shift in thinking. In fact, if you look at it, ALL address book apps assume that they’re the black box. What we need is a system of having all your contacts available from all the points where you need them. Your phone should have all your phone numbers in it, for example… but probably doesn’t really need all your email addresses in it unless it has that capability. Your computer probably doesn’t need all your phone numbers in it, really, unless you’re going to be sending those numbers to other people, or looking them up for reference because it’s easier, or using a stupid phone where your mobile isn’t present. Basically, the ideal we’re looking at is when the information you need is at the point you need it, or even better – when the things or people which need the information get the information when and where they need it.
This links in with (i don’t know if you saw this) the Identity 2.0 speech of some years ago (youtube or google for it, if you haven’t seen it) and it also ties in with infrastructure of the internet concerns.
Essentially, we have SO MUCH TECH. It’d be nice if all the information we want is always present whenever we need it, or at least got to us by the shortest possible route. So if I need to phone someone on my VoIP phone, why can’t my mobile tell my VoIP phone the phone number? It should be as simple as touching a finger-print sensor (or some auth device) on my phone, which goes through the next-gen internet, which would not be end-to-end but rather shortest-route, in this case, the mobile phone in your pocket, and grabs the phone numbers that you can call from this device, and displays them as possible, allowing you to search or browse as that device allows.
Anyway I digress… we’re in a SYNCING world now, a world which requires synchronisation, or preferably a higher level above that… one where there is only one true copy of the information, and it can cloned and fetched and expired to wherever it’s needed. It ties in with a good auth mechanism, because passwords are shit.
Meh anyway :)
Jared Goralnick
on 28 Aug 07Thanks for such a great post…and for building an Outlook importer.
MI
on 28 Aug 07Carl and random8r – Have you tried Plaxo? They support synchronization with a great number of applications, both desktop and on the web, Highrise included. It may do what you want.
Jeff Koke
on 28 Aug 07MI, Where can I synchronize Plaxo with Highrise? I use Plaxo to sync up my Address Book on my Mac, with Outlook on the PC, and LinkedIn, but I don’t see Highrise offered as a link point… It would make Highrise much more useful to me.
JF
on 28 Aug 07Jeff: Plaxo Labs likely has what you’re looking for. If you have any questions beyond that you’ll need to get in touch with Plaxo. I hope this helps.
Ryan
on 28 Aug 07Granted, this may be a ludicrous request, but I would love to see some design decisions around the actual code. After all, coding needs to be “designed” too, right?
The reason I say this is probably a ludicrous request, is because it almost fits into the “give an inch, want a mile” paradigm. With Rails itself, conferences, workshops, etc, one could argue that 37s has supplied enough code out there for people to see.
But it’d be cool to see the thinking pattern when considering or adding in a new feature.
Des Traynor
on 28 Aug 07It’s a very interesting post.
I like how you guys can openly admit you effectively over-engineered the solution. The “One True Importer”(tm) is exactly what most of us would have come up with.
The road to engineering hell is paved with with the thought that “CSV is an easy little format”.
If you were true academics you would have created an intermediate format that you convert all these other formats into. And then you could have had one true importer :)
Lar
on 28 Aug 07So, where’s the ACT 6.0 import at? I wish.
Margaret
on 29 Aug 07Good for you to be naked about your thinking and the problems that sometimes come from your philosophy. With this experience in mind, I hope you’ll hear the many requests for an import/migration tool between basecamp accounts.
It’s disappointing to me that a company so central to the evolution of the fast-moving web2 environment doesn’t allow its customers to merge/split basecamp data effortlessly. Isn’t the whole point of working on creative, collaborative projects together, to allow new companies and ideas to flourish or die, expand or contract, merge and divide, with nimbleness and ease?
I’m not suggesting letting people take their data and go (which you already allow)- I’m asking, and many are asking, to simply move projects between basecamp accounts.
Perhaps you’re wanting a third party dev to figure this migration tool out using the API? If so, please blog about this and invite them to the table. It’s a very real problem for our entities, and others, judging by the forum and other feedback.
Neil J. Squillante
on 30 Aug 07Just curious—how many people asked for import from a Web form on a landing page? That’s what we would need to switch from Salesforce.
Richie Mackay
on 31 Aug 07The truth is you do provide a CSV import. It just so happens that the CSV file must be formatted to the Outlook specification.
It might be worth highlighting that point on the site as it may not be immediately obvious to most people.
This discussion is closed.