Four user observations shaped four design decisions. Each decision has a rejected alternative alongside it. One thing shipped and performed differently than expected.
GenWizard is an internal platform that helps delivery teams accelerate code analysis, document generation, and test automation. The Reverse Engineering archetype lets teams upload legacy codebases and receive structured documentation generated by a multi-agent AI pipeline.
I was the sole designer for the RE archetype — responsible for every screen from file upload through generated document output.
The previous version had been built by engineers for engineers. A twelve-step wizard with no re-entry path, no progress memory, and no status during a two-hour AI run.
In an informal round-zero test at the start of the project, I asked five delivery team members to complete a basic RE job. The results were immediate.
I attended four of eight contextual inquiry sessions and ran two independent usability testing rounds. Before those sessions I assumed the core problem was step count. After them, I wasn't sure step count was even in the top three.
I owned every screen from file upload through generated document output — interaction model, usability testing, design reviews, and engineering handoff.
The brief specified a streamlined wizard. Engineering had already scoped one. When I mapped the RE workflow against the re-entry finding from Session 4, a wizard would fail for the same reason the old one did: no memory, no context, no re-entry path.
The Advisor brief arrived with a design decision already embedded: full-screen modal. Engineering had scoped it. Observation 4 made the real problem clear: experienced users weren't struggling with the modal — they didn't know the Advisor existed at all.
The engineering spec said: checklist. When I reviewed the backend logic, I discovered the entire deliverables model had a hard prerequisite structure — none of which had ever been surfaced to users. A flat checklist would hide this entirely.
In 3 of 4 post-launch observation sessions, teams pulled up the graph at session start. One team called it "the brief." A planning artefact I hadn't designed for.
Decision 3 solved generation order. Decision 4 solved what came after: forty-three files in a flat archive with no navigation, no role labels, no starting point. Different team roles needed entirely different subsets — the flat download treated all forty-three as equivalent.
Seven screens that tell the story of one RE job: from the moment a user decides to run an analysis to the moment they have a structured, role-appropriate document library. Every screen is a decision I made — and most of them replace something that previously didn't exist at all.
The old platform had a single spinner with a 2-hour median wait and no indication of what was happening. This directly caused the "I have no idea if I did something wrong or if the system just broke" pattern from Session 2. The Initiate Run dashboard replaced it entirely — but this surface is separate from the dependency graph (Decision 3). Together, they close the loop on error blindness from both ends: before the run, and during it.
The Assembled Agents graph was the surface I designed to let users inspect and modify their agent network before running. Post-launch observation showed 4.1 minute median dwell — the highest of any surface in the platform. Users weren't just reviewing it before running — they were understanding their system through it. One team returned to it mid-run to cross-reference which agent was handling which step.
Before a user ever reaches the canvas or the agent graph, they land on a project page that organises their work across archetypes — SDLC, Reverse Engineering, Forward Engineering, and AMS. This entry-point screen was a key design decision: the archetype tab structure sets the mental model for everything downstream. Each application card surfaces two primary actions: Manage Deliverables and Analyse Application.
The two-step card (Manage Deliverables → Analyse Application) replaced the old linear wizard's first screen, which asked configuration questions before the user had uploaded any files. By making the dependency graph the mandatory first step, users arrive at analysis with a clear intent — and the system has the inputs it needs to run without silent failures.
Before any document can be generated, the platform analyses the uploaded codebase. The Analyse Application screen visualises this process as a four-column hierarchy: Application version → detected Languages → individual Code files → AI-generated Explanations. Each file is scored for extraction accuracy — 94% in this run.
This is what produces the "Code Explanation: Completed" node in the dependency graph. Users can see exactly which files were analysed, which languages were detected, and how confident the AI was about each extraction — information that was entirely invisible in the old wizard's single spinner.
Discovery showed users restarting entire runs because they had no idea whether a 2-hour AI job had processed their files correctly. The Analyse Application view surfaces the extraction results before any long-running generation begins. If accuracy is low on a critical file, teams can correct their upload and re-run — avoiding a wasted 2-hour wait on bad inputs.
The Manage Deliverables screen replaced the flat checklist of 7 deliverables with no ordering logic. The new graph makes dependency relationships explicit: Code Explanation must complete before Backlog (Feature / User Story) can begin; Backlog must complete before Test Case, Architecture, or Design Document. Users can only trigger deliverables the system is ready to produce.
Post-launch, 3 of 4 teams used this screen as a brief at session start — a usage pattern I didn't design for, and the clearest signal that the structure was doing real work.
Observation 03 from contextual inquiry was unambiguous: users didn't know what to do with a 43-file flat zip. The redesigned output experience replaces file-system navigation with a structured, hierarchical document viewer — accessible directly from the document canvas without leaving the platform.
The Summary screen confirms completion, surfaces the View Status path for users who want to inspect the agent run, and groups all output into two top-level categories: Documents and Knowledge Graph.
Two things that weren't possible in the original wizard: editing generated documents in-platform, and returning to a session that was interrupted. Both are solved here.
Observation 02 was a delivery team member who "came back Wednesday and literally couldn't find where I was." The left navigation's persistent activity structure — Inputs, Context, Select Agent Arc, Reverse Engineer, Summary — means re-entry is always one click from anywhere in the platform. The document canvas is the other half of that answer: documents open in an editable full-screen view with a rich text toolbar, so teams can annotate, refine, or update AI-generated content without switching tools.
The Assembled Agents screen supported three interaction modes: viewing the hierarchy, adding agents from the right panel, and configuring individual agents inline. Each was designed to feel like editing a document — not operating a pipeline configuration tool.
Each decision mapped to a named principle. Not decoration — these constraints actively shaped every tradeoff.
Evaluated across 2 usability testing rounds (5 participants each), product analytics (~40 users, 6 weeks post-launch), and 4 structured observation sessions. These are directional indicators, not proven causal outcomes at production scale.
