How this kind of project comes together

Stage 1

Understand the need and the people

Start with a needs analysis^* rather than with code. Identify who the experience is for, what they need to accomplish, where and how they will use it, accessibility needs, device conditions, organizational constraints, and what success means.

Conduct a needs analysis before designing or building. Separate known facts, assumptions, unknowns, and AI inferences. Ask only the questions that could materially change the solution. Do not build yet.

Stage 2

Turn the need into a project frame

Create a project/build brief^* that defines purpose, audience, project type, major tasks, scope, non-goals, constraints, success measures, and the desired first deliverable. Add acceptance criteria^* so “done” has a concrete meaning.

Using the approved needs analysis, create a concise project brief. Identify unresolved decisions and risks. Recommend the architecture and first representative deliverable; do not build the full system yet.

Stage 3

Establish the visual, content, and interaction rules

Define the design system^*, content style guide^*, typography, colors, spacing, interaction states, accessibility expectations, and what is Locked, Controlled, Flexible, or Approval Required. Record approved names in a project style & component guide^*.

Before scaling, define typography, colors, spacing, interaction states, accessibility requirements, voice/tone, and reusable component rules. Classify each rule as Locked, Controlled, Flexible, or Approval Required.

See the related project style rule^†

Stage 4

Design the information architecture and source of truth

Organize the experience so people can reach information quickly. Decide the hierarchy, section indexes, cross-links, search behavior, and a durable source of truth^*. Keep content separate from presentation where practical.

Recommend an information architecture that lets a first-time user reach useful information within about three choices. Keep one source of truth for resource content and surface it through multiple relevant paths.

Stage 5

Name reusable blocks and components before multiplying them

Create approved blocks/components^*, a component library^*, and stable names^*. A card^*, for example, is a contained information unit; a block/section can contain several cards.

Identify repeated layout patterns and turn them into reusable named components before creating many instances. Use approved components unless a new pattern is explicitly authorized.

See the related project style rule^†

Stage 6

Prototype one representative experience

Use prototype first, scale second^*. If structure is uncertain, a wireframe^* may help; if a working version is cheap to change, build one representative implementation and stress-test it before scaling.

Build one representative implementation with realistic content and edge cases. Test the pattern before generating the remaining pages or cards. Do not scale until the baseline is approved.

Stage 7

Review independently, then synthesize

Run specialist reviews and first-time-user simulations. A multi-agent review panel^* can include User Experience, User Interface/visual design, accessibility, content, technical quality, and security perspectives. Synthetic users^* are useful for finding likely friction, but their results are hypotheses—not real human usability evidence.

Have specialist reviewers evaluate independently before synthesis. Record issue, severity, confidence, and evidence. Then run diverse synthetic first-time-user task walkthroughs. Treat simulated-user findings as hypotheses, not human-participant evidence.

Stage 8

Implement the approved changes in the working project

Once the design is approved, tell AI to implement/apply the changes^* in the working project. This is different from deploying^*. Set the authority boundary clearly so AI does not commit, push, publish, or deploy unless authorized.

Implement the approved changes in the current project files. Run the appropriate checks and report what changed. Do not commit, push, publish, or deploy without approval.

Stage 9

Verify behavior, accessibility, responsiveness, and security

Do not confuse generated with verified. Use generated → implemented → tested → verified → approved → deployed^* as separate states, and define a Definition of Done^*.

Verify the implementation against the acceptance criteria and Definition of Done. Check supported viewports, keyboard behavior, accessibility, links, error states, security boundaries, secrets, and regressions. Report evidence, not just “done.”

Stage 10

Deploy only after approval

After verification and approval, deploy^* the approved build to its target environment. Confirm production configuration, domains, protected secret bindings, logs, and rollback options. A credential is not safe merely because code is called “server-side”; verify how the value is stored, who can access it, and that it cannot reach browser/client code.

Prepare the approved build for production. Before deployment, confirm production configuration, secrets, domain/HTTPS behavior, monitoring, and rollback. Deploy only after those checks pass.

Stage 11

Maintain a recoverable project

Keep the project portable and reversible. Use version control, a checkpoint^*, handoff notes, and clear records of decisions. Update the shared style/component guide when a new approved pattern is introduced.

Before a substantial change, create a checkpoint and identify the rollback path. After approval, update the handoff and style/component guide if the project vocabulary or approved patterns changed.

See the related project style rule^†