From Feedback to Decisions in Five Days
The back office where analysts review, comment on and publish use cases drafted by an AI agent
6 min
Atlas is an AI agent that drafts use cases for Liminal’s taxonomy. I was the only designer on its back office, where analysts generate, review, comment on, approve and publish them. It launched on 22 October. In the five days after, I turned 23 pieces of analyst feedback into 15 design decisions.
Industry
Market Intelligence, Cybersecurity & Digital Identity, B2B SaaS
Role
Product Designer (sole designer)
Project Duration
4 weeks (Sep–Oct 2026)
Focus
Human-in-the-loop Workflows
QA & Review Flows
Prompt-driven Prototyping
Design QA
→ The brief
A use case went from the agent's dashboard to a Google Doc, then to Airtable, then to the product, and was re-typed at each step. Editing a published use case wiped its product tags, which the analyst lead called “the re-scope blocker”. Developers had already started a new back office with little design input.
The agreed scope was small: a clean-up pass, not a rethink, because the fields were already right. The rules kept moving after that: who publishes, what a QA pass means, and how a change to a shared solution spreads.
The agreed scope was small: a clean-up pass, not a rethink, because the fields were already right. The rules kept moving after that: who publishes, what a QA pass means, and how a change to a shared solution spreads.
→ Research in one day
On 1 October I read the team's procedure, about 445 Asana tasks, about 20 internal docs and the staging build. Then I wrote a one-page brief: roles, pain points, where staging broke the design rules, and 14 open questions for the lead developer.
The brief also flagged asks that went beyond a clean-up, such as safe edits after publishing. Those came back later, in testing and after launch.
The brief also flagged asks that went beyond a clean-up, such as safe edits after publishing. Those came back later, in testing and after launch.
→ Decisions I reversed
Solutions & Map became a table. My first layout had three columns joined by connector lines. The analyst lead said analysts work row by row, so it became a requirement table with the diagram as a preview.
Drafts, Published and Runs became page tabs. My first call was one table with status presets. A front-end developer found them confusing, so I reversed it.
Warn, don't block. Unresolved comments and publishing without QA show a warning instead of stopping the analyst. Urgent fixes must not get stuck behind a rule, and analysts use open comments as task notes.
Drafts, Published and Runs became page tabs. My first call was one table with status presets. A front-end developer found them confusing, so I reversed it.
Warn, don't block. Unresolved comments and publishing without QA show a warning instead of stopping the analyst. Urgent fixes must not get stuck behind a rule, and analysts use open comments as task notes.
“Show first, then ask.”
→ Release blockers first, then usability
Before the release test I specced the three blockers: vertical publish, editing a published use case, and version history on real data. All three merged on 13 October, and Atlas went live on 22 October.
After launch the question changed from “can it ship?” to “can analysts use it every day?”. The analysts' feedback listed 23 items, mostly about comments, the QA hand-off, versions and notifications.
After launch the question changed from “can it ship?” to “can analysts use it every day?”. The analysts' feedback listed 23 items, mostly about comments, the QA hand-off, versions and notifications.
→ Five days, three batches
A 94-minute review with the lead developer gave a 48-row fix table. I sorted the 23 feedback items into design, roadmap, bugs and questions, and 29 prompts landed in two days.
Then a 69-minute walkthrough with the analyst lead: I demoed first and asked questions after. 15 decisions were recorded and landed the same day, among them QA verdicts (Approved, Approved with comments, Changes requested), comments that belong to a section instead of a version, a live generation timer, and a “Needs a look” table for every use case a shared change reaches.
Every landed change got a before/after image: 45 in three days, so analysts and developers could review without reading prompts or code.
Then a 69-minute walkthrough with the analyst lead: I demoed first and asked questions after. 15 decisions were recorded and landed the same day, among them QA verdicts (Approved, Approved with comments, Changes requested), comments that belong to a section instead of a version, a live generation timer, and a “Needs a look” table for every use case a shared change reaches.
Every landed change got a before/after image: 45 in three days, so analysts and developers could review without reading prompts or code.
→ The audit that told the truth
Instead of clicking through staging, I had an agent read the front-end and back-end code and compare every agreed design item with the code and the Jira tickets, row by row.
Of 36 items, 5 were built, 12 partly and 18 not at all, and 24 had no ticket for the missing part. It also found tickets that contradicted design decisions. That list became the hand-off for the lead developer.
Of 36 items, 5 were built, 12 partly and 18 not at all, and 24 had no ticket for the missing part. It also found tickets that contradicted design decisions. That list became the hand-off for the lead developer.
→ Results
Atlas V1 went live on 22 October with the three release blockers I specced, and most of the redesign held up in the post-launch review.
176 of 188 prompts landed and checked, 23 feedback items turned into 15 decisions in five days, 45 before/after callouts, and a 36-row audit as the developer hand-off.
176 of 188 prompts landed and checked, 23 feedback items turned into 15 decisions in five days, 45 before/after callouts, and a 36-row audit as the developer hand-off.
What I learned: keep the as-is and the proposal apart, and check tickets as part of design QA. A design that lives only in the prototype gets lost.
→ What I’d do differently
Book the real users first. No analyst from the team that uses Atlas every day joined the final test, and my slot in the approval demo fell through. I’d lock both in before setting the date.
Check tickets as part of design QA, from week one. The audit at the end found 24 agreed changes with no ticket. Checking every week would have caught them while there was still time to build.
Read the code before I answer. I told the analyst lead some missing steps were a bug. They were missing by design. A look at the code first would have saved a correction.
Check tickets as part of design QA, from week one. The audit at the end found 24 agreed changes with no ticket. Checking every week would have caught them while there was still time to build.
Read the code before I answer. I told the analyst lead some missing steps were a bug. They were missing by design. A look at the code first would have saved a correction.
