Robbins Analytics.

HOW DID I DO THIS? / A BUILD PROCESS, WITH EVIDENCE

Specify. Test.
Own the result.

AI tools generated the implementation. Aaron framed the business problem, specified the work and compared two working builds, then refined the selected output through repeated review and verification.

  • Start with a specification: Define the intended behavior and acceptance checks.
  • Refine through review: Direct a change, check the result and repeat until ready.
  1. Frame
  2. Specify
  3. Build twice
  4. Compare
  5. Refine
  6. Check

This project is a static decision playbook. No operational data, ingestion engine or production release is demonstrated.

01 / TURN INTENT INTO A HANDOFF

A build starts before
the code.

The business question came first: a successful sync can hide missing evidence. Two independently developed plans were critiqued and integrated, then deliberately reduced to a lightweight playbook.

How the plan became buildable

The same stage prompt went to both platforms. Different cards show their outputs—not different instructions. Consolidation and scope revision came afterward.

  1. 01

    Separate ideation

    Two independent starting points

    SAME PROMPT → BOTH PLATFORMSDevelop an independent plan for the same business problem.

    Codex output

    A platform-neutral plan for the five decisions.

    Claude Code output

    A repository-grounded plan for the same five decisions.

  2. 02

    Cross-critique

    Each model challenges the other

    SAME PROMPT → BOTH PLATFORMSRead the other platform’s plan and provide a strong critique.

    Codex critique

    Findings on evidence boundaries, retries, history and scope.

    Claude Code critique

    Findings on exposure, past actions and independent expectations.

  3. 03

    Update

    Each author revises its own plan

    SAME PROMPT → BOTH PLATFORMSRead the critique, evaluate it, and update the original plan.

    Codex revised plan

    Evaluate findings and record the revisions.

    Claude Code revised plan

    Evaluate findings and record the revisions.

  4. 04

    Integration

    Each adopts stronger ideas

    SAME PROMPT → BOTH PLATFORMSEvaluate the revised other plan and integrate its stronger approaches.

    Codex integrated plan

    Selected Claude approaches incorporated into the Codex plan.

    Claude Code integrated plan

    Selected Codex approaches incorporated into the Claude plan.

  5. 05

    Final build plan

    Consolidate the two integrated plans

    One consolidated plan

    Compare the integrated plans with text metrics and a 40-criterion rubric, then combine the stronger approaches. This plan still described a data build.

  6. 06

    Revised build plan

    Change the scope to fit the goal

    Lightweight plan v2

    Aaron specifies a quick, no-data playbook. The revised plan carries the decision safeguards into content and prepares the URS, FRS, SRS and implementation handoff.

URS / INTENDED USE

What must the reader be able to do?

12 user requirements connect the business problem to decisions, journeys and scope. Intended use anchors acceptance.

FRS / BEHAVIOR

What should the interface do?

20 functional requirements cover guides, scenarios, navigation, history, download and print.

SRS / IMPLEMENTATION

What makes the handoff concrete?

14 system requirements define files, identifiers, browser behavior and progressive enhancement.

What else went into the implementation package?
  • Complete copy, three scenarios, five templates and five bounded primary-source references.
  • Inherited UI/UX standards, a traceability register and 30 original acceptance cases.
  • Written implementation and verification prompts, with input file identities.

The purpose was to reduce inference for a lower-cost implementation model. No measured token-cost saving is claimed.

02 / COMPARE WORKING RESULTS

The MVP made the choice
visible.

Codex and Claude Code produced separate first working examples from the same handoff. Aaron compared the rendered results and chose Codex as the better foundation for the intended experience.

CODEX / INITIAL MVP

The selected starting point

An editorial opening, compact decision cards and a strong visual hierarchy.

Open full build ↗
CLAUDE CODE / INITIAL MVP

The alternative considered

A working interpretation of the same brief, with different type, layout and emphasis.

Open full build ↗

Scroll inside either preview to explore the preserved initial build, including its guides, scenarios and templates. Use Full-screen view for more space, or Open full build for a separate browser tab. These local copies preserve the original files; their responsive layouts adapt to the preview width.

Chosen for refinement. Not treated as finished.

The preferred design still had review findings and needed substantial usability work. Visual preference did not replace verification, and this comparison is not a controlled model benchmark.

03 / DIRECTION AFTER SELECTION

A stronger first output
still needs judgment.

A preserved visual v1 kept the baseline intact. The selected Codex output then went through user-directed v2 refinements, driven by actual screens and interactions.

FROM MVP TO FINAL DELIVERABLE

Start with the MVP. Improve the current version until it is ready.

START / ONCE

Review the MVP

Find friction in a working screen.

THE FLYWHEEL

Change. Check. Review the current result.

  1. Direct a change

    Make the next adjustment explicit.

  2. Check the result

    Render and exercise the affected behavior.

Review the current result → direct the next change

Each check informs the next change. Repeat while further refinement is needed.

When the result is ready to accept

ENDPOINT

Final deliverable

The refined, checked result is accepted. The loop stops.

WHAT CHANGED THROUGH THE LOOP

  1. Put the business case first

    Expansion, the evidence gap and business consequences moved ahead of the five operating decisions.

  2. Replace text density with structure

    Decision diagrams, sequential stages and genuine parallel lanes made the operating logic easier to follow.

  3. Make the visual language mean something

    Evidence states reuse labeled colors and icons. Color is tied to supportability, not added arbitrarily.

  4. Make the templates usable

    35 fields gained prompts and examples. Tables gained pinned names and headers, with a frozen first column only when needed.

  5. Remove reading friction

    Contextual navigation, section-bound sticky controls and attached subheads keep the reader oriented.

THE OUTCOME

And this is the result.

The selected MVP became a business-first playbook through the review, change and check cycle. View the results below.

Refined v2 opening with business-first framing, a persistent reading index and three issue cards.
The refined playbook: the initial design became a business-first reading experience through explicit user feedback. Explore the actual v2 playbook ↗

04 / KEEP CLAIMS TIED TO CHECKS

Show what passed.
Name what did not run.

Builder reports were followed by independent review, targeted correction and a final UI/UX pass. Their evidence serves different purposes; a self-report is not an independent test.

22

Recorded UI/UX checks passed

Responsive layouts, keyboard behavior, scenario history, contrast sampling, navigation, tables, reduced motion, content fallback and download checks.

2

Manual checks remain unrun

Actual 200% browser zoom, and native print pagination with return-state restoration. Constrained reflow and print-media inspection passed separately.

What did the final pass actually correct?
  • Small diagram and caption text was raised to the 12px floor.
  • The skip link now transfers keyboard focus into the main content.
  • Sideways-scroll hints appear only when the table actually overflows.

The original 30 functional acceptance cases were not all rerun. No WCAG certification, complete security audit or production data validation is claimed.

Aaron declared the playbook complete with these limits visible. The process view is a local addition; no new publication has been performed.

05 / THE CONTRIBUTION

The useful answer is
the method.

Human decisions

Problem framing, scope, intended use, comparison of alternatives, visual direction, trade-offs and acceptance.

AI-assisted production

Plans, critiques, research synthesis, specifications, code generation, targeted fixes and documented checks.

A business question became an inspectable specification, two working alternatives, a deliberate choice and a refined, checked result. That is the work left out by simply naming the tools.

Inspired by pairing requirements with verification. This lightweight process is not a regulated validation lifecycle or proof of a production data platform.

Explore the completed playbook ↗

Initial MVP