C-MORE PRODUCT WORK

The platform has three kinds of user and they want opposite things: a buyer managing thousands of suppliers, a supplier answering questionnaires about itself, and an auditor checking whether any of it can be trusted. An AI agent sits underneath, reading uploaded documents and proposing answers. The loop for every ticket was the same: • Read the ticket, then write down every way the sentence could be read, and ask rather than pick one and report it as finished • Build it as a self-contained HTML prototype with a state switcher, so a reviewer can jump straight to the empty case, the volume case and the failure case • Verify in a real headless browser (bounding boxes, contrast, whether the control actually exists on screen) and report pass counts, not impressions • Rebuild the approved screens in Figma on the existing components, so the handover carries the team's own tokens rather than my copy of them The volume case is the one that kept paying off. Almost every defect worth finding showed up at 17 items, not at 3.

A super admin lands on the platform responsible for thousands of suppliers, and the old entry point was a list. A list does not tell you where to start. The redesign opens with a single sentence of state, how many of your suppliers need attention and that everything else is on track, followed by a filter card that doubles as the way into the list. The status distribution underneath is not decoration: each row is a filter, so "633 expired documents" is a click, not a number to write down and go looking for. The list itself stays collapsed until you search or filter. Showing five thousand rows by default answers a question nobody asked, and it buries the four counters that actually route the day's work.

Clicking a supplier used to mean a full page navigation and a trip back. Most of the time the question is small (what is this company's score, who is the contact, which questionnaires are outstanding) so the answer arrives in a side panel over the list, with the full page one click further on for the times it is not. The panel content went through several rounds of subtraction. Role came out because a company can have several users with different roles and one cell cannot honestly say which. Registration date and next renewal went in, because both were being looked up elsewhere to answer "is this current?"

A third role joined the product: an auditor who checks a questionnaire someone else already answered, partly with AI help. Their question is not "what is the answer" but "where did this answer come from, and did a human overrule the machine?" So every answer carries one label from a fixed set (high confidence, medium confidence, manual, manually approved) and where a person changed what the AI proposed, the row says so in plain language: who changed it, when, what the AI had said, struck through, and what it says now. The banner at the top counts those categories and doubles as the filter, so the review can start with the highest-signal group, the answers a user overrode while the AI was confident. The scope of this ticket got smaller as it went, and correctly. My first pass rebuilt the screen; the feedback was that the focus is the labels and nothing else should differ, so the final version is the team's existing questionnaire with the label vocabulary corrected in place.

Suppliers upload documents; the agent reads them and answers questions from them. Delete a document and the answers it supported quietly go stale, which nobody could see, because the delete was a plain confirm dialog. The warning now names the blast radius before anything happens: this file is the evidence behind six answers, here is every one of them with its current confidence label, and removing it means the agent answers those six again from whatever evidence remains. The confirm button carries the count rather than the word "Delete", so the last thing you read is what you are actually about to do. The volume case sets the shape. At seventeen of seventeen questions the list scrolls inside the dialog while the summary line and the buttons stay put. And when nothing cites the file, no warning appears at all, because a dialog that fires on every delete teaches people to click through it.

Users can re-run the agent after adding documents. The unscoped version was a single button that could silently overwrite an answer a person had written by hand, the one class of answer the machine has no business replacing without being asked. The re-run is now scoped by answer class rather than by question. You choose which categories the agent is allowed to replace (manual, low confidence, medium, high, manually approved) and unanswered questions are permanently included and shown as such, because there is nothing to protect there and pretending it is a choice adds a decision for no reason. Underneath, the selection resolves to one sentence with real numbers: the agent will run for 14 questions, made of 3 unanswered plus 5 low confidence plus 6 medium. The button repeats the count. Nobody has to hold the arithmetic in their head to know what they authorised.

Certificates expire, and the platform needs the date. The agent can read most of them; it cannot read all of them. A scanned report, a spreadsheet, a licence with the expiry field left blank. Rather than hide that behind a progress bar, the flow surfaces it as a step of its own between analysing and extracting. Documents the agent resolved sit in one group with the sentence it actually read from the file and the page it came from, confirmable in bulk. Documents it could not resolve sit in a second group, each with the reason it failed and a date field, plus an explicit "this document has no expiry date", because for a code of ethics no date is the correct answer and not a gap. The two groups share one card, one table and one place in the flow. What changes between them is the source line and the action, so the screen never reads as two features bolted together.

The dashboard project was one long argument about a model. The ticket queue was the opposite: many small decisions, fast, against a design system I did not own and a codebase I could not see. What carried across all of them: • A one-line ticket has more than one reading. Enumerate them, act on one, say which, and hand the rest back to whoever wrote it • Design the volume case first. The three-item version of any screen is always fine and always lies • Warnings that fire every time train people to dismiss them, so warn only when there is something to lose, and name what it is • When the ask is a copy change, change the copy. A rebuild that is technically better is still the wrong deliverable • Build on the team's own components, so handover is a diff rather than a translation