369 HERTZ · CREATIVE TECHNOLOGY STUDIORECORD 002 / APPROACH
Research, design, and code stay in one thread.
Handoffs lose reasoning. The person who watched your expert users misread a screen is the person who writes the fix.
RESEARCH · DESIGN · TEST · MERGE
01 · THE SHAPE OF AN ENGAGEMENT
Phases overlap by design: code starts before research ends. Weeks below are typical for a mid-sized project. The studio carries the work, drawing in specialist research and engineering contractors under the same terms when an engagement needs them.
WKS 1–3
Research, with your expert users
Sessions in the systems they actually run. Walkthroughs with your engineers to learn the real data model. We map where technical state is most likely to be misread, and that map sets the priorities.
WKS 3–7
Design, failure cases first
Flows and components designed against real technical state: empty, partial, degraded, and conflicting states before the happy path. Prototypes are built in code early, inside your design system where one exists.
CONTINUOUS
Test, before it ships
An experimentation practice, not a review meeting: design decisions are tested with users against realistic fixtures; on critical reads we measure error rates. Decisions carry evidence, and the evidence is documented.
WKS 6–12
Build and merge
Most engagements run to code: production React and TypeScript, opened as pull requests into your repository and reviewed by your engineers like any other contribution. The engagement ends with a pairing handover. SEE A WORKING EXAMPLE
A diagnostic is a two-week engagement: stakeholder interviews, a review of consent and permission flows, a front-end audit covering accessibility and performance, and a prioritized roadmap with effort estimates.
02 · IN YOUR REPO, UNDER YOUR RULES
Our code should be indistinguishable from your best code.
We work inside your stack and conventions: no parallel codebase, no framework of the week, nothing your team didn't agree to own.
- YOUR CONVENTIONS01Lint rules, folder structure, naming, review etiquette: adopted, not negotiated.
- TYPESCRIPT, STRICT02Typed against your real API contracts. No any escapes.
- TESTED03Unit and interaction tests ship with every component, runnable in your CI.
- ACCESSIBLE04WCAG 2.2 AA verified per component: states, focus order, reduced motion.
- NO SURPRISE DEPENDENCIES05New packages only with your team's sign-off. Your bundle, your budget.
- REVIEWED BY YOU06Pull requests reviewed by your engineers. Rejection is feedback.
03 · THE BOUNDARY
A layer boundary, not a format one: we work in research, design, and front-end engineering, whatever form the output takes. It also keeps our security surface small (see Security & Privacy).
WE WORK IN
- User research, findings, and audits
- Interface design: components, flows, screens
- Prototypes, specs, and design files
- Design system code and tokens
- Front-end engineering, through code merged into your repo
STAYS WITH YOUR TEAM
- Back-end services and APIs
- Infrastructure and deployment
- Data storage and processing
- Decisions only your team can make
- Production data: we never hold it
04 · THREE WAYS IN
TWO WEEKS01
Diagnostic
A structured read of one product area: where users misread state, what it costs, and a prioritized plan. Most engagements start here.
START WITH A 30-MINUTE CALLTYPICALLY 6–12 WEEKS02
Project
A flow or product area taken end to end on the phases above, through to merged production code when the work should ship.
ONGOING03
Retainer
Embedded design-engineering capacity for teams whose interface risk never stops moving. Same practices, standing cadence.