When your startup vision is big — a suite of apps used by hundreds of millions, funded by a couple rounds of financing — it’s easy to think of an App Store launch as a small step along that road. If you hear people claiming that they can build Instagram in a week, what they’re probably thinking is that they could assemble a prototype that approximates the idea. And, undoubtedly, a talented iOS dev working from the fully-formed idea of Instagram today could be feeding captured photo data through some CI filters, uploading it to a server, and pushing it to her social streams before the weekend. If there weren’t any stylish mobile photo-sharing apps out there and I’d had the foresight of that premise, I’d be off prototyping it right now.
Products with focused feature sets tend to seduce us into thinking that success is a matter of hacking on our idea for a week. The nature of mobile UIs makes this seem all the more reasonable. But strong implementations of good ideas always tend to feel within reach, and there are reasons that 900 million people aren’t using any number of Facebook competitors to manage their personal lives.
So: we could assemble our team to build and polish our vision, and if we’re lucky enough to have Instagram-in-a-week-caliber people, then maybe we’ll be able to get our own untested idea to market in a few months. Or we can try to test our assumptions with prototypes, knowing that if we build out the whole thing and then try to iterate, our v2 might mean starting from scratch. I’ll try to explain why we think this is usually the right approach for a startup.
Iterate with prototypes
Sketches, wireframes, design comps, and interactive prototypes are all steps in our process. None can assure that our idea will work in the end: carefully-crafted wireframes need re-thinking once we see them implemented with our designer’s graphics; beautifully rendered layer comps of a list-sorting UI seem perfect until we actually use it on a tablet. We can only hope to find the problems that will keep the project from succeeding.
Put another way, our goal with the prototype isn’t to prove-by-wireframe that the product will be just what users want. Instead, we’ll hypothesize about the ways in which the product will fail and try to find the potential failure points as quickly as possible so that we can work around them. Think of it as a loose relative to reductio ad absurdum: let’s try to convince ourselves that the product won’t work as we’ve designed it; if we can’t, then maybe we’re on to something.
We’ll either get to the right product a lot faster, or learn some important lessons and move on to the next idea. This is true even when we’re totally confident in a product idea. And it’s true whether we’re spending evenings hacking in a coffee shop or have millions in funding because if nothing else, failing slowly carries an opportunity cost. We prefer to uncover our misguided design assumptions, missing features, and broken interactions as soon as possible. We’re sculptors starting our implementations with sketches and clay.
Prototypes as user testing
As a developer, I lean heavily on interactive prototypes, which may or may not implement the designs from our creative team. It’s generally easy for us to build a quick mobile web demo, or a storyboarded iOS app, or even just a set of comped images with gesture recognizers to simulate a user experience.† Prototypes like these give us the opportunity to learn, relatively cheaply, that the idea isn't right — and to make needed changes early in the process.
The kinds of prototypes I’m hinting at here are for user experiences. We work from a set of user stories and use the prototype to improve them. Along the way, we discover that features we thought critical are marginal or unnecessary; we uncover functionality we didn’t know we needed; and we’ll almost certainly find a better way to design part of the interface.
Of course, UX is rarely the whole story. If you’re a technical entrepreneur, you’re already writing spike solutions, integration tests, or other proofs of your core concept. The good news, if it’s not obvious, is that these two kinds of prototypes can be built in parallel by different teams. There’s no reason we shouldn’t iterate on the interface of a multi-player mobile game at the same time we write our API integrations and test for network problems in target areas.
The faster you can find those failure points, the better
At a talk at Urban Airship last year, Eric Ries quipped that after months iterating on a product and only then discovering that not a single user was interested in downloading it, the only thing they needed to build was a marketing page with a download link that 404'd.
Start on that end of the spectrum: focus on the biggest questions first and build as little as possible. The next step is always a slightly more-realized product; the next step is just your next iteration.
† There are dozens of tools and techniques for prototyping, and perhaps I’ll talk about some of those in a future post.