Building a shared language between design and code

Establishing the foundations

I started in Figma, using AI to help recreate foundations and reusable components from existing interface references. That provided a starting point for typography, colour, spacing, radii, form controls and common interaction patterns.

The generated foundations required review. I treated them as a working interpretation of the references, rather than a verified specification of the original product.

I used Claude Code to help build the foundations and reusable components before developing the prototype screens. My role was to direct the work, review the results and decide where the system needed to change.

Reuse before adding

Before implementing a screen, I worked through a simple sequence:

This made reuse a decision made before implementation. It also gave me a way to distinguish a missing component from a missing variant or an unclear content rule.

For example, a referral form needs more than fields and a submit button. It also needs validation feedback, a consent interaction and a confirmation state. A referral detail view needs a consistent relationship between its status, timeline and next action.

Connecting visual roles to product meaning

The foundations included colour primitives and semantic roles, along with typography, spacing and radii.

The important distinction was between a visual value and its purpose. A status colour cannot explain whether a case needs the agent’s attention. That meaning also needs a label, supporting copy and the right action.

As the prototype developed, I added missing components and semantic tokens instead of treating every screen difference as a one-off style.

The portfolio uses Archivo and a paper-and-forest palette. Those are the presentation styles for these case studies. They should not be mistaken for the prototype’s original token values.

When implementation reveals a design problem

One referral state showed that the client could not be reached. Its timeline also suggested that an adviser had already spoken to them.

Both messages could not describe the same moment.

I revised the timeline to communicate that contact was still being attempted, then updated the corresponding Figma screen. The correction aligned the status, progress language and next step across both environments.

This was a useful reminder that system consistency includes content and behaviour. A reusable timeline can still communicate the wrong thing if its completed states do not match the scenario.

Refining states and access

The work included clearer form validation, accessible names, contrast adjustments and reduced-motion support. I used labels alongside visual treatments so meaning did not depend on colour alone.

I also checked the coded experience at a 390px viewport in English and Arabic. The RTL variant made layout direction, mixed-language content and the relationship between labels and controls part of the design work.

These refinements are evidence of attention to access and interaction quality. They are not a claim of a comprehensive accessibility audit or validated Arabic localisation. Both would need further review before production.

The earnings progression was another example of state design. Estimated, payable and paid earnings needed different meanings, not simply different colours. The same applied to pending and available points.

Bringing implementation back into Figma

As the implemented experience developed, I recreated six key screens in Figma using the working library, adding missing components and semantic tokens where needed.

The workflow became a loop:

This was deliberate reconciliation across two environments. It was not an automated synchronisation pipeline.

Figma helped establish the visual foundations. The working prototype exposed questions about behaviour and content. Bringing those decisions back into Figma kept the design artefacts useful after implementation had moved forward.

What the project established

The project gave me a working set of components, screens and interactions that could be explored in design and code.

It did not establish adoption, engineering time saved or production performance. I did not measure those outcomes.

The strongest evidence is more concrete: reuse decisions made before implementation, a contradictory state corrected in both environments, and six screens brought back into Figma from the coded experience.

What I would improve next

I would document component responsibilities and state rules more explicitly, verify token mappings against the implementation and define a repeatable review process for changes in either environment.

I would also extend the accessibility review beyond the refinements made during prototyping and have Arabic-speaking users review substantive flows.

The lesson I would carry forward is that a design system should connect how an experience looks, behaves and communicates. Keeping that connection requires more than matching screenshots.