fidelity

Day 19 of 30. A while back, when I was at Code for Canada, I had the good fortune to work with Luke Simcoe on a couple of blog posts and presentations - he was their Director of Communications at the time, and whenever someone brought something to him for review, he'd ask:

Do you want 5%, 60%, or 90% feedback on this?

5% feedback was the early-stage, this-is-the-roughest-sketch-of-an-idea stuff. Does the idea make sense? What other ideas does it spark? Have I picked a sensible structure? Can you see what this might become? Feedback here might change the whole direction of the other 95%.

60% feedback is much further along. You've done the work to assemble a first real draft, not just a proof-of-concept but something that resembles the finished product. Am I on track to achieve my goals with this? Do the pieces fit together? What's missing, unclear, or confusing?

90% feedback is get-to-the-finish-line feedback, the kind that turns something good into something great. What needs a last tweak or two? Are there ways to make it even better?

One thing about writing at speed, whether it's blog-post-a-day or NaNoWriMo, is that you never reach that 90% stage, much less the 100% stage. You have to get comfortable with 60% drafts, one day at a time. I used to be the sort of person who would find that deeply frustrating, like an itch you can't scratch, like constantly forcing yourself to put work that you knew wasn't finished out there.

Which implies, correctly, that I no longer think that way. I've realised that the work is never finished, not for anything of any real scope or complexity. Perhaps it was my first encounter with NaNoWriMo that wrung this mindset out of me. Perhaps it's the 15 years of professional work between then and now, where you seldom have the luxury of polishing your work to a fine sheen.

Far from being frustrating, I now find it exhilarating to get work out there early and often, to get that 5% - 60% - 90% feedback, to accept that my 60% may in fact be the 90+% my users were looking for.

In digital product teams, we talk about lo-fi and hi-fi prototyping. Lo-fi prototypes are the bare minimum to show an idea to users and stakeholders. It could be a Balsamiq wireframe, a Figma clickable prototype, even paper prototyping if you can get your users on-site (or come to them). Hi-fi prototypes often step into code: early versions of actual, working features.

Larger products have lots of features. Some might be getting polished to 90% or even 100%. Some might be built into hi-fi prototypes to get that 60% feedback. Some might be still in the idea and sketch phase, and need that 5% feedback from user research so they can proceed to lo-fi prototyping.

Often you'll have a mix of features, all being worked at different fidelities - and the work doesn't always split along dev / design / product lines! In fact, from what I've seen, the outcome is often better when dev, design, and product engage at all fidelities. Some features will call for technical discovery at the 5% stage: maybe they rely on a key integration point, or they have performance and scalability concerns, or the business logic is unusually thorny. Some features need holistic design thinking, or attention to product details, to get from 90% to 100%: maybe they have multiple user groups involved, or complex interactions, or precise wording needed to guide the user.

So as a member of that team, you'll be more valuable if you're comfortable working across the fidelity spectrum. As a lead engineer, I might be writing technical specs one day, building a proof-of-concept to unblock the team the next, helping polish a nearly-finished feature the next, and so on. If you've never worked at the 5% stage before, seek out opportunities to try. If you struggle to get from 90% to 100%, ask around: how do other engineers (or designers, or PMs) motivate themselves in that phase? If you don't often get 60% feedback, try to get it on your next feature or project.