AI/ML
August 20, 2026
In Part 1, I argued that prompting is the easy half of AI skill, the half that improves on its own, and that the hard half is output literacy: the ability to evaluate what these tools give back. I also argued that for designers it isn't a new competency at all. It's critique, applied to a new kind of output, at a volume that forces us to write down criteria we used to carry in our heads.
I ended with a story about an internal audit tool my team built that produced clean, confident, partially wrong findings, and a grading rubric whose math didn't reconcile.
All of that was caught in review. Here's what happens when there is no review.
When Nobody Downstream Catches It
At Relevate Health, we've sharpened around two pillars: Point-of-Learning and Point-of-Clinical-Decision. Both are output literacy problems, at different altitudes. Point of Learning asks healthcare professionals to absorb and act on information, so if AI participates anywhere in producing it, and increasingly it does, then somebody has to be the human who checks, and that person needs craft and the time to use it. Point of Clinical Decision is sharper still. We build into the EHR workflow, at the moment a clinician is weighing a treatment or connecting a patient to support. That user is under real time pressure and isn't thinking about model limitations, they're thinking about the person in front of them.
And there's a finding that should sit uncomfortably with anyone designing for that moment. A study in the Journal of Marketing, replicated across six samples from undergraduates to a nationally representative U.S. panel, found that lower conceptual knowledge of AI predicted higher receptivity to using it — an effect that held even after controlling for general attitudes toward technology. The authors landed on awe as the explanation: the less someone understands how the thing works, the more readily they trust what it says.
Plenty of the clinicians we design for are already using these tools, some of them enthusiastically: summarizing literature, drafting notes, working AI into workflows nobody built for it. I don't read that as a counterargument. It's the condition the research describes. Adoption is moving faster than evaluation, and it's moving fastest among people whose expertise is medicine rather than machine learning. Confidence with the tool and the ability to audit what it produces are separate things, and in a clinical setting the gap between them isn't an inconvenience.
So verification can't be their responsibility, whether the user is cautious or all-in. It has to be built into what we hand them.
Which is where defining "good" stops being a craft exercise and becomes an obligation. In most industries the judging criteria are about quality. In ours, some of them are about safety. Whether a claim is on-label. Whether a mechanism is stated correctly. Whether the guidance a clinician sees at 4pm on a Thursday is something we could defend to someone who asks. Those are the criteria, and writing them down is design work nobody else in the process is positioned to do.
A generated deck with a wrong number is embarrassing. A clinical touchpoint with a wrong number is something else entirely. That gap is the whole reason this matters more in our industry than in most.
The Objection
There's an objection to all of this, and it's a good one. If I'm asking people to verify before they ship, aren't I asking them to be less fearless than I said we should be in April?
No. And the reason is the thing I most want to get across here.
I shared a post recently that I keep coming back to. Its argument was that the imperfect thing you release beats the perfect thing you hide, and, pointedly, that this failure belongs to designers more than to anyone else. We hold the messy version back. We tell ourselves one more pass will get it ready. Then someone ships the rougher idea and takes the lead. The author's own admission was the part that stung: a product sitting unreleased for a year, not because it wasn't good enough, but because of a quiet voice asking who he was to put it out at all.
I recognized that immediately. Most designers will.
But look at what kind of failure that actually is. It's a fear of being seen, which has nothing to do with a fear of being wrong. If anything it's the failure of someone whose standards are too intact.
The opposite failure looks nothing like it. That one ships constantly and confidently, without much sense of what's in the output. Not hiding at all. Not checking either.
These are two different failure modes pointing in opposite directions, and a team can suffer from both at once, usually in different people and occasionally in the same person on different days. Neither one is cured by the other. Telling a perfectionist to slow down and verify makes them worse. Telling a naive power user to ship faster makes them dangerous.
What separates them is a distinction I'd been sloppy about myself: imperfect is not the same as wrong.
Imperfect is a scoping decision. Rough edges, unfinished states, a prototype that proves the idea and nothing else. Release that. Release it early and let it be ugly. That's the post's point and it's correct.
Wrong is a different category. A dosage that doesn't exist, a mechanism described backwards, a claim nobody can source. That isn't imperfection, it's a defect, and speed doesn't make it acceptable.
Output literacy is exactly the skill that tells you which one you're holding, which is why it makes you faster rather than slower. Without it you get two options and both are bad: ship blind and hope, or check everything with equal suspicion and grind to a stop. That second one deserves naming, because it's the trap our discipline actually falls into. Verifying indiscriminately is the perfect thing you hide, wearing the costume of diligence. With output literacy you triage. You know which three claims have to be right and which twelve don't matter yet. Then you release.
The audit tool from Part 1 is a fair example of both halves. We didn't wait for it to be perfect. The version we learned the most from was rough, and building it rough is how we found the rubric problem at all. But the contrast ratios and the scoring math weren't rough edges. They were the part that had to be right before anything left the building. Knowing which was which is the whole skill.
April's list was a set of commitments. Most of them have since turned into habits, which is the only real test a commitment ever gets.
So this isn't a new promise. It's the name for something we already do, and naming it is what lets us do it deliberately rather than by instinct:
Output literacy is a discipline we practice, and something we design for in what we ship. For myself: know where the stakes are, and check accordingly. For my team: keep verification a visible, respected part of the work rather than something people do quietly at midnight. And in our products: build the affordances that let people see what they're trusting.
We're better at it than we were in April, and we'll be better again by the fall, because it's a practice rather than a policy. You don't install output literacy. You build it the way you built every other kind of judgment on your team, one caught mistake at a time.
Prompting is how we talk to these tools. Craft is how we judge what they say back. Output literacy is just the name for craft doing that job.
I said in April that the risk of standing still is greater than the risk of trying something new. I still believe it. Release the imperfect thing. Just know which part of it had to be right.
References
Tully, S. M., C. Longoni, and G. Appel. "Lower Artificial Intelligence Literacy Predicts Greater AI Receptivity." Journal of Marketing 89, no. 5 (2025): 1–20. https://doi.org/10.1177/00222429251314491
Elman, Adam. "The Core Skill of Design in the AI Era: Critique." Nielsen Norman Group, June 12, 2026. https://www.nngroup.com/articles/ai-era-critique/
Harris, Buddy. "Craft in the Age of Intelligence." Relevate Health Blog, April 2, 2026. https://www.relevatehealth.com/blogs/craft-in-the-age-of-intelligence
Attribution note: the line "the imperfect thing you release beats the perfect thing you hide" is quoted from a LinkedIn post by Jibril AI. The post's broader subject is a specific public company's product decisions and share price; this piece takes only the argument about designers and perfectionism and does not reference that company. Recommend keeping it that way.