From design to production code in P4 DAM

How I build and hand over features

01 · Gather context with the product owner

I start by understanding the problem and clarifying what the feature needs to do. My product owner and I built a system that turns feedback from our repository and directly from users into Markdown files.

These give Claude relevant product context before I start designing or building.

02 · Prototype and refine together

I usually build an HTML prototype so we can try the interactions early. A small group, typically one developer, one product manager and me, reviews it together.

I gather feedback and iterate quickly. Working with a prototype makes it easier to discuss how the feature behaves and agree on what needs to change.

03 · Document the states for wider review

Once we’re happy with the prototype, I use a Claude skill to create specifications and visual snapshots of its interface states. I share these with the wider team for feedback before implementation.

The first version missed some states. Developer feedback helped me improve the skill’s instructions, and the example below covers six lighting and background states from the 3D viewer.

04 · Build directly in production code

I bring the prototype, documentation and feedback into Claude Code. Using my agents and workflows, I implement the feature in the product, checking the interactions and correcting the generated code as I go.

This lets me take on implementation work and gives developers less UI to build from scratch.

05 · Hand over for developer sign-off

I share the code through GitHub for review, alongside the specifications, snapshots and CLAUDE.md context.

Developers can inspect the implementation and try the behaviour themselves. They flag changes before signing off and integrating the feature. They reported that the revised handovers made the work significantly easier to follow.

Example feature: the 3D viewer

The viewer lets people inspect 3D models and materials inside P4 DAM. I designed and built lighting controls that let reviewers see an asset under different conditions while keeping it in view.

Keep the controls beside the model

The existing viewer used a grey or single-colour background. I added selectable HDRI lighting environments so reviewers could inspect how light affected a model’s shape and materials.

I also moved the settings from a corner icon into a panel that could stay open, move and resize. Reviewers could adjust the lighting while continuing to inspect the asset.

Claude initially created a modal gallery for choosing environments. Its larger previews were useful, but the modal interrupted that inspection. I replaced it with small previews inside the settings panel so reviewers could change the lighting and immediately see its effect.

Make the generated UI fit the product

Claude’s output needed checking against the existing interface. It had used one-off pixel values and custom colours, so I replaced these with the product’s established Tailwind classes and adjusted the spacing and corner radius.

What I would do differently

I would involve developers earlier in defining the specification and snapshot templates. Release pressures limited that collaboration at the start, and I made assumptions about the detail they needed.

Reviewing one early handover together would have exposed the missing states before I reused the format across features.