The Magic of Low Fidelity


Recently, I was working with a client, designing an application for them. We worked for a few months, from concepts, to sketches, to high-fidelity wireframes, which were then transformed into detailed requirements documents, to hand off to an internal development team. The process (for a relatively simple application) took about 6 months, 2.5 of which were design, the rest, translation into formal requirements.

Safe process, right? Ensure you’ve got all the Ts crossed, and Is dotted, making sure you can accurately estimate development resources, and plan accordingly, so you can sync other functions of the business (marketing, support) with the plan.

Makes sense.

Until it doesn’t.

This formal process of prepping high-fidelity documentation for product development is generally the go-to approach for enterprise teams. But it has problems. For all the safety in this extensive documentation comes some real risk for the product:

Products Aren’t Snapshots

Putting together formal documentation and requirements for a product takes a long time. Months, sometimes close to a year. In that time, so many things change. You learn the market better, the market changes, your strategy changes. With that documentation so meticulously prepared, you end up locked into a strategy that made sense months ago, but is now less relevant.

Formality Squelches Creativity

Your product team are your greatest source of creative solutions when building your product (duh). Your designers, developers, marketers, salespeople and all the others working around the product are the engine that drive things, and their collaboration can create huge leaps in the product experience.

Formally documented products remove this creativity. A carefully documented screen or interaction becomes a tightly scoped instruction to a developer, who might see a more interesting way of solving the problem, but is hamstrung by the process.

That powerful creative force that you’ve got in your product team is effectively neutered, likely replaced by rounds of compromise by committee. The product ends up being safe and mediocre, not innovating and game-changing. Not what you set out to create, was it?

The Sunk Cost Fallacy Kills

When you spend months documenting a product, meticulously designing every detail, you’re investing scads of time into that process. Every minute you invest becomes a sunk cost - time invested that you don’t want to waste. As a result, ideas that are invalidated later in the design (or even development) process are harder and harder to revise. Sure, that feature looks less important now, but we spent so much time designing it, we can’t just drop it.

This is the sunk cost fallacy, and it sinks a lot of products (pun definitely intended). When you invest a lot of time or money into something, it becomes harder emotionally to kick it to the curb. You want to ride it out as long as possible, even against your best judgement. You launch, it fails, and the blame game starts.

When you build products, you have to be willing to get rid of stuff mercilessly. Else, you end up with a Frankenproduct that no one loves.

Low Fidelity To The Rescue

While it’s not always appropriate, taking a lower fidelity approach is often faster, lower risk, and helps to engage more creative resources on your team. An idea for a new features isn’t meticulously detailed, it’s drawn out roughly on a whiteboard in 30 minutes, in collaboration with design and dev (and marketing? and support?), and then each party is sent off to apply their interpretation and magic to it. If you are hiring the right people, this allows them more creativity to make magic when actually building it, taking the solution far past that design-by-committee approach that is too often used.

Designing informally like this also eliminates (or at least vastly reduces) the sunk cost fallacy effect. You spend 30 minutes before lunch whiteboarding and brainstorming, and by the end of the week, that feature is out in the world. Didn’t work well? Kill it or revise it. Because less time was invested in detailing it out, there’s less attachment to that particular solution, allowing you the freedom to get to the correct solution faster.

The point is, when you build products, you almost always build them wrong. Everyone does. The only way to get to the right product is through cycles and cycles of iteration. You can either make quick mistakes, or make long mistakes. At the end of the day, it’s about the money and time you’re burning. Dollars per mistake (as a function of time) is a good metric for seeing how efficient you are at getting to the right solution.

Next time you need to build something, stop and take it to a whiteboard, and see if that’s enough. I bet you’ll be surprised.

Related Posts

Announcement: The Most Exciting Thing I've Done

Today, I'm announcing the most exciting project I've been involved with. It's called CrowdSync, and it helps to automate paperwork, communication and logistics when dealing with groups of people. Read on for why this is so big.

How to Post to Private Slack Channels from Zapier

If you automate posting to Slack via Zapier, you might need to post to a private channel. It's not entirely obvious how to do it, but actually pretty damn easy.

Sharing is the Currency of the Web

You consume free content all day on the web. The best way to pay back the people creating it? Share it.

Why You Should Blog More (Data)

When you stop blogging, people stop coming. Simple enough. Here's the proof.

Using a Linter Will Make You a Better Dev

Using a linter while you write code won't only make your code better formatted, it'll make you a better programmer.

Everyone Is Self Employed

The idea that you're not self-employed if you work fulltime somewhere is wrong. EVERYONE is self-employed.

The Real Reason to Learn to Code

Not everyone needs to be a programmer, but learning a little bit of coding can help in a lot of different areas.

Review: Keto Diet

I recently gave the Keto (Ketogenic) Diet a try. Suffice to say...it works.

You Don't Need to Get it All Correct Immediately

Too many people wait on shit to be perfect. Get it close, leave out some stuff, and set yourself up to quickly iterate.

Using Foundation 6 in Angular 4 (or 2)

How to use Foundation for Sites 6 in Angular 4 (or any version 2+)