Making Design Review Part of the Application
Developing a practical design method that moves from standalone concepts to review tools inside the working app, keeping alternatives, screen maps, notes and checks close to the implementation.
- role
- Design Process Lead / AI-Assisted Prototyping
- duration
- September 2026 – present
- stack
- ReactTanStack RouterTanStack StartTypeScriptViteAgent SkillsGit
- tags
- design-processproduct-designprototypingAI-assisteddeveloper-experience
Key outcomes
4 outcomes · in progress- Developed a component-based workbench for comparing concepts and reviewing connected screens
- Carried review tools into the Treasury Console as a reusable development and staging package
- Added route-derived screen maps, viewport previews, pinned notes and checks to the review workflow
- Collected the method, templates and lessons in a reusable design-skill library
The Problem with Another Mockup
AI made it much easier for me to produce a working design. It also made it easy to produce another one, and another, until the designs themselves became a system to maintain.
A single HTML file worked well for discussing one page or interaction. It became harder to use for a connected application: shared navigation drifted, the same component existed in several places, and reviewing a flow meant moving between files. Once the real application existed, rebuilding its screens in a separate design app created another source of drift.
I needed a way to keep designing as a project grew, with enough structure to compare alternatives and enough connection to the implementation that the design work remained useful.
The Workbench
The first answer was a small component-based workbench. A shell provides navigation and review controls; a manifest describes the screens or concepts; shared parts are implemented once. Each concept has a place for its design notes.
That gives a reviewer more than a picture. They can move between related screens, inspect a design at different widths, switch themes, and compare ideas in a consistent frame. A screen map makes the scope visible, including unfinished areas.
I developed the approach through website concepts and application designs. My role was to define what the review needed to make possible, direct the iterations, and turn recurring corrections into reusable instructions and tooling.
Reviewing the App That Exists
The next step came from a useful challenge in working with Ben: if a screen already exists in the app, why reproduce it somewhere else to review it?
The Treasury Console now mounts a reusable review-mode package inside the application for development and staging. The app keeps its routes, components, and data layer. Review mode adds tools around them.
The floating menu made that review layer tangible. One row lets me move among areas and inspect the structure of the work; another keeps the controls for the screen I am reviewing in one place. The example below shows the kind of navigation and organization I want close at hand while designing.
| Tool | Review question it supports |
|---|---|
| Screen and navigation maps | What exists, how is it organized, and what is still missing? |
| Width previews | What happens when this actual screen is viewed on a smaller device? |
| Forced loading, empty and error states | Have we designed the situations beyond the ideal populated screen? |
| Proposed-version support | How could a changed screen be compared with the built version? |
| Pinned notes and a notes backlog | What needs attention, where is it, and what happened to the feedback? |
| Design-system views and self-checks | Are the components, tokens, contrast and layout behaving as intended? |
The screen map is derived from the app’s routes, so it does not need a second manually maintained inventory. Proposed variants and forced states need the app’s integration points; a control in the review bar does not implement those states by itself.
The review tooling is intended to be excluded from production builds, with an explicit build check. That boundary makes room for experimentation without turning design controls into customer-facing features.
A Method for Choosing the Right Form
The form of the work depends on what I need to review. A Markdown note is a good place to capture a question, a decision, or the first structure of an idea. When the question is about layout, hierarchy, or interaction, I need something I can see and move through. A polished document can come later; it is rarely the best place for me to work out the design.
I distinguish three visual situations:
- One visual question: a small HTML study can be enough to decide a layout or interaction.
- A new site or connected concept: a standalone workbench provides structure while the design is taking shape.
- An existing application: review the real screens and develop proposals alongside them, using the application’s own components where possible.
Feedback does not always need a separate document. A note pinned to the screen keeps a question beside the thing it concerns; a broader decision belongs in the project’s working record. The method includes how that feedback is recorded, how unfinished work is labeled, and how a decision becomes an implementation change. AI helps build the variations and carry decisions into files; I direct the work and review whether the result serves the user.
Current Status
The workbench and review-mode package exist, and the Treasury Console uses the integrated approach. Reusable templates and design skills capture the lessons. A related implementation is being explored in the Snyder website’s own framework.
This is still an evolving method. I have not measured a reduction in delivery time or claimed adoption across every project. What I have built is a way to keep design, review, and implementation close together as the work moves from a first concept into a real application.