The Magic of Low Fidelity

Sep 28, 20174 minute read

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.

Justin Davis is a hacker and user experience designer, and co-founder of CrowdSync. He's an expert in UX, product design and product development. He's also pretty legit at throwing JavaScript around.