The Art of the Low Fidelity Prototype

This  post was about to be titled “Why Business Requirements are going to be obsolete” but that became secondary to the value of prototyping.  Writing detailed functional business requirements are almost a thing of the past, and you will see why low fidelity prototypes are replacing them as the vehicle for delivering lean and rapid throw-away software.

So what are low fidelity prototypes anyway?

There’s nothing more demoralizing to a product team then sweating out a product for months only to see it discarded within seconds. Thanks to Agile and the lean UX movement, product releases are intended to cycle through waste and optimize value without having to invest months on product development.  While medium to high fidelity prototypes are 80% functional and resemble the Alpha, low fidelity prototypes are crude, grey scale mockups that are clickable, yet still feel like a functional product.

Apple’s ANPP (Apple New Product Process) always starts with design and is meant for creating and testing hundreds of releases.  Every one of their products starts with design, without anything written. The basis for this is that investing design and development hours without stakeholders involvement, is wasteful, makes no economic sense, nor does it effectively guide the product towards success.

From requirements-centric to prototyping as a way of getting buy-in.

I recently accepted a 6 month contract at a Fortune 100 London based company, with the task of conveying how fund managers can sell millions of pounds of mutual funds using nothing more than an iPhone app. I had to rapidly interview and collect all requirements and build something they would accept in less than 90 days.  Their last vendor failed because they delivered a binder of requirements that were not read, nor understood.

Knowing enough about Photoshop to be dangerous, and coupling that with thoughtful UX principles and a prototype creation tool, I cobbled together a functioning clickable iPhone app to get into their hands.  While they didn’t love it at first, I was able to get an incredible amount of feedback putting me in a position to deliver a quick iteration that allowed the business stakeholders to buy-in and rally around.

Written functional business requirements are often very ineffective.

Anyone involved with the development of an app, back-end software, or any kind of start-up knows that building products are done in a traditional linear pattern — conceptualization, definition, and development.  Whether you’re building an Android app or an accounting system, you’ve probably experienced the pain and anguish in writing requirements or reading them. Yes, they are that bad but the good news is they’ve almost completely gone obsolete, in favor of functional prototypes.

Before I get into the reasons why prototypes are so effective,  let’s look at the shortcomings of business requirements, (also knows as requirements documents).

As a long-time product guy and software engineer with a “4″ in front of my age, I’ve written more requirements documents than I care to think about. It’s just the way it worked. It was a hand-off artifact, a milestone deliverable which is to produce often binders of written requirements. There are even dozens of requirement apps just to help write them.  Dev shops and larger companies are still writing them because they’ve accepted failure as a typical outcome of development. Over 45% of products fail because of customer rejection, or non adoption.

Let me give you a few key reasons why written requirements will never survive on their own, especially when trying to socialize and attain buy-in.

#1. Business requirements documents take too long to write.  Even with over 58% of development going Agile, writing a requirements document and getting buy-in can take months. Not just in writing time, but the time it takes to get your audience to read them, comment on them, and iterate. The market or the business needs change in parallel and what has been written becomes out of date.

#2. Misunderstanding leads to building the wrong product.  Perception of requirements become everything when you’re dealing with translating the written word into a visual, tangible thing. Try and write a document what the Mona Lisa looks like. In my own experience, I’ve seen accepted requirements docs turn into something that wasn’t asked for. The cost of building a wrong product can go into the millions depending on size, and almost guaranteed will result in failure.

#3. Stakeholders will flat out refuse to read them, and simply wait for the finished product.  Nobody is going to disagree that executives (who are usually the stakeholders) are short on time, I dare to say short attention spans, and usually won’t agree to read through a requirements document for hours. If you’re sharing an elevator with the CEO of your company and you have 90 seconds to convey and explain what you’re working on, would you rather say, “Hey Dave, let me show you this 200 page document explaining the new auto buying app.” or “Hey Dave, check out this app I’ve been working on.”

So why are low fidelity prototypes so successful?

1. It’s now an expectation by the customer. Executives and stakeholders are cozying up to rapid and lean product delivery, so they expect to have something to “play with” almost immediately.  Not having a demo or a prototype to won’t help your cause in getting buy-in. Even if there are a few broken links or bugs, they will get over it knowing it’s a low fidelity prototype. Any feedback is good feedback. Once you keep iterating, they’ll soon forget about the buggy older version.

2. A picture’s worth 1,000 words.  If a picture is worth 1,000 words, a functioning prototype with behavior, latency and functionality, is worth 1m words. Something that can elicit feedback and emotion, whether bad or good, is so important in aligning a stakeholders perception with the delivery of the provider.

3. The availability of prototyping software.   With the onslaught of online and offline prototyping tools available, and in some instances completely free, there’s no excuse to not providing a prototype. I personally learned how to use Invision and had a prototype within 48 hours of signing up for an account. (Full disclosure, I have no connections with this company)

4. Flipping on the light bulb.  There’s nothing better than that “oh sh%t” moment. I was recently demonstrating an iPhone app to a group of fund managers and one of them was so engaged, he was embarrassed because he didn’t know if the prototype was a real app. He just flat out proclaimed, “i want this, when can I download this?”. Not to mention it’s an amazing feeling to know you’re providing value, but it gives the product more momentum and spirit.

5. People now have shorter attention spans than goldfish.
In a recent study by the Canadian media consumption, human attention spans have dropped from 12 seconds to 8 seconds, now lower than goldfish.  In our world of twitter feeds and emoticons, we read less and want more quicker. Add to that, executives are hyper focused on margins and eliminating waste. With the precious commodity of time, don’t even think of expecting an executive to read your 200 page binder of requirements. Hand them your smartphone with the app and you’ll have more luck.

To sum this all up, while many of you are shaking your heads with the notion of replacing requirements with a prototype, consider this.  When your customer or the person who’s writing the check gets it and is onboard, it’s not just the greenlight for the product, but your selling yourself, and promoting your brand as someone who can understand, convey and ultimately deliver a product to the next level.

Leave a Reply

Your email address will not be published. Required fields are marked *