Decision-grade blueprints · Part 4 of 4
Seen, out of scope
Design precisely and you see more than you were asked to. Staying silent doesn't work, and neither does quietly delivering it. A list does.
This is one of four articles on decision-grade blueprints: pictures of AI products good enough to base decisions on, before anything is built.
Week two of three. Victor is testing the new review screen, clicks on “diploma can't be compared automatically” and says in passing: “Foreign diplomas, I always give those to Hilde. She knows.” Hilde retires in two months.
It isn't the only thing you notice halfway through an assignment like this. The monthly report for management counts candidates as “not suitable”, even when the system simply couldn't read their CV. A candidate like Marek gets no explanation he understands, while the law can give him the right to one for decisions like these. And the demo the sales team shows to clients promises features that aren't in any quote.
None of those four belongs to the screen you were asked to design. All four determine whether that screen will work.
Careful design always surfaces more than the brief covers, so the method needs an answer for the rest.
Two reflexes that don't work
There are two obvious answers, and both are wrong.
Stay silent. It isn't in the brief, so it's not your concern. That's commercially defensible and humanly understandable, especially when the budget is already tight. But the client pays for it later, with interest. The missing process surfaces after launch, when Hilde has already left and the first Polish welder has been waiting three weeks for an answer. The report only becomes suspect once someone has based a decision on it. And whoever saw it but said nothing loses the trust the whole collaboration rested on.
Quietly deliver it. You see it, you can do it, so you throw it in. That feels helpful, and in the moment it is. But the work falls outside the budget and eats into the margin. Next time, it's expected. And the client doesn't see it as extra, because it was never named as extra.
Quiet delivery has one more drawback, and it's the biggest. Sell vaguely, and afterwards anything can be tucked under that vagueness as if it went without saying. That cuts both ways: the supplier delivers more than was paid for, the client expects more than was bought. After a while, nobody knows exactly what was agreed, and everyone is sure the other side remembers it wrong.
The third way: a list
In my work, every delivery includes a fixed section with a simple title: Seen, out of scope. A list of what I noticed but didn't work out.
The case in this series is fictional: an illustrative design, not a validated system. The people, the company and the data don't exist.
Seen, out of scope
Noticed during discovery, not worked out. What is blocking doesn't wait for the delivery. The rest you decide line by line, with an owner and a date.
- 01Decision needed
No process for assessing foreign diplomas
seen in: review screen, welding certificate row
Every “incomplete” on a diploma becomes a task without an owner; candidates wait
Process design, ±1 weekmostly work for BE People itself
decides: BE People, operations · by 20/11
- 02Decision needed
The monthly report counts unreadable CVs as “not suitable”
seen in: reporting, definition of status
Management steers on a figure that is wrong, possibly skewed by language
±3 days of designbefore the reporting is built
decides: BE People, management · by 20/11
- 03Blocking
No explanation the candidate understands
seen in: email module, rejections
A matter of accessibility and trust; under the AI Act, decisions like these can carry a right to a clear explanation
±1 week of designlegal check by your lawyer
Assess first: already reported on 28/10
BE People, lawyer · by 13/11
- 04Improvement
The sales demo shows features that aren't in the quote
seen in: ChainConstruct demo, 14/10
Clients expect more than they buy
½ daya demo with clearly marked phases
decides: BE People, sales · by 4/12
Outside the current assignment. What isn't blocking, I work out, you do yourselves, or you take to another party. The rough order is indicative and validated by delivery first; a quote only follows after that.
Reported on 6 November. Anyone who later asks why something is wrong will find here when it was seen.
Four things make a list like this useful.
It sets priorities. Not everything can wait. Anything blocking, such as a safety, privacy or compliance problem, doesn't wait for the delivery; it goes straight to whoever makes the call. What needs a decision gets an owner and a date. An improvement can wait.
It's specific. Not “there are still a few compliance points to look at”, but exactly what is missing and where you saw it.
It explains why. The person reading the list often isn't the one working with it every day. A director has to understand in one sentence what the risk or the opportunity is, without knowing the whole project.
It gives a rough order of magnitude, without committing anyone. An order of magnitude makes prioritising possible. It isn't a quote, and it's no more certain than what's known at that point; delivery validates it before anything is promised. It doesn't say who should carry it out, but it does say who decides and by when. Sometimes the honest answer is that the client is best placed to solve it.
Yes, it's commercial too
Every line on that list is a potential follow-up project, and I say so to the client.
But the list belongs to the client, not to me. With each line that isn't blocking, they can do three things. Ask me to work it out. Solve it themselves. Or take the list to another party. All three are good outcomes, because in each case a problem that would otherwise have stayed invisible gets dealt with.
That may sound naive. In my experience, it's the opposite. A client who's given the choice knows what they've got in you, and has little reason to shop around. A client who senses an invoice behind every remark starts to distrust every remark, including the valid ones.
The list has a second, less visible benefit: it records what was and wasn't delivered.
If someone later asks why the report doesn't add up, the answer is a date: seen on that day, reported in that delivery, deliberately left out at the time. That protects client and supplier alike.
Why this belongs at the front
When a designer joins only once the product is under construction, Seen, out of scope is at its most painful: nearly every line means rework.
At the start of a project, the same list is worth the most, for three reasons.
It helps decide what gets built, and sometimes whether. A blueprint showing that half the decisions require a human who isn't there isn't a failed blueprint. It's a cheap way to discover that the product needs to be different, or that the organisation first needs something else.
It sharpens quotes. If you know a process for foreign diplomas is missing, you can plan for it, or deliberately leave it out of the first version. What you know up front, you can quote for, instead of arguing about it as extra work later.
It brings hidden problems into the open. Much of what ends up on the list, someone at the client already knew. Hilde knew about the diplomas. It just wasn't written down anywhere. A picture that looks like the real product makes it something you can talk about, because everyone looks at it together and sees the same question.
The series as a whole
Four articles, one idea: a picture of an AI product is only useful if it shows what the system will really do. That accuracy lives in small decisions about whether a human can trust, check and correct the system, and the hardest of them are about uncertainty. Whoever looks this closely sees more than was asked for, and that deserves to be named.
Recruitment is the example in this series, not the boundary. The same questions come up with an agent that interprets regulations, or a vision system that isn't sure about a defect.
Nobody can be certain in advance. If they could, you'd have a script that only needed executing. A blueprint gets you as close to that script as possible.
Why I work this way
I didn't develop this way of working because I thought designers should do more. It grew out of questions I kept running into while designing, questions that should really have been answered already.
What began as a personal habit became a method: making a product visible before the most important decisions become expensive or irreversible. For now, I call it a decision-grade blueprint.
It doesn't need a designer who knows all the answers. It needs one who recognises the questions, knows where they belong, and makes sure the answers add up to one product that works.
That leaves one question. If designing earlier and more precisely helps decide what we build, what we'd better not build and what we need to figure out first, why does design still so often only get its turn after those decisions have been made?
I made that question my way of working. It really shouldn't be an exceptional one.
