Design & Development
The Ethos
Design and development is a conversation, not a handover. Nothing gets thrown over a wall. Designers and developers stay in the same conversation from the first alignment meeting all the way through to the merged Pull Request. Here is the process intended to maintain the conversation.
The Process at a Glance
Design ticket created
A Design ticket is created by PM as a Github Issue containing the scope and direction of the work. The scope can change as the design exploration begins and there are subsequent conversations with Engineering, PM and Design. The ticket should be a document of this.
Design Exploration
The designer explores and documents the solution, keeping the engineer and PM looped in as it develops in the Github Issue. This could be through paper prototypes, whiteboarding, AI prototypes or quick Figma ideas. It's all about communication.
Implementation kick off
This is a meeting with the designer and developer to align on what scope, catch any use cases and make sure communication is clear and transparent.
Developer Implementation
The developer inspects the finished design directly in Figma. tokens, sizing, and code snippets, layout and positioning.
PR and QA Review
The designer reviews the implementation on the Pull Request itself and signs off before it merges. A Design QA should generally happen for a piece of work that has gone through this process. There are other smaller items that do not require this process.
Completion
The PM determines whether an items is done or not. This mirrors the issue lifecycle described in Project Management: an issue may be marked Up Next when it is the pressing next item for someone, then moves through In Design → In Development → In Review → In Staging → Done. The stages on this page are what should actually be happening at each of those statuses.
1. Design Ticket Created
Before any design work begins, the designer, assigned engineer(s) and PM get together to understand the requirements and expectations of the work. This is what turns Todo into In Design.
| Who attends | Designer + Engineer(s) + PM |
| When | Before design work starts, triggered when an issue moves to In Design |
| What's decided | Scope, constraints, technical feasibility, edge cases, rough timeline |
The conversation should all be captured in the GitHub issue. Here is an example.
2. Design Exploration
With alignment in place, the designer explores potential solutions quickly. Information is kept general in Figma. A page will be created with the same name as the ticket in the project where the feature is located. For the example above here is the Design #39 Improve Golden Path Discovery corresponding Figma file.
A design should only be considered ready to build against once it's in the "complete" state described in Figma exploration.
3. Implementation kick off
For larger items of front-end work, when the designs have been approved (generally by the PM), there should be an implementation kick off meeting where the engineering and design discuss the proposal to ensure alignment and transparency. At this point the corresponding front-end ticket can be assigned.
- All design tickets live in the design GitHub repo
- All front end engineering tickets live in platform-frontend repo
4. Developer implementation
Once a design is ready to build, the developer should go straight to the source file rather than working from a screenshot or a verbal description. Figma's Dev Mode is how you read a design precisely. Here is our Design #39 Improve Golden Path Discovery example in dev mode.
Open the file in Dev Mode
Toggle Dev Mode in the top right of the Figma file (or press Shift + D). This switches the right-hand panel from design properties to developer-focused inspection.
Select a layer to inspect its tokens
Click any layer on the canvas. Dev Mode's Inspect panel shows the colour, spacing, and typography variables bound to that layer — the actual design tokens, not just their resolved values.
Read sizing and auto-layout
With a layer or frame selected, check its padding, gaps, and constraints in the Inspect panel to understand how it should behave when content changes or the viewport resizes.
Use the generated code snippet as a starting point
Dev Mode generates CSS (and other platform) snippets for the selected layer. Treat this as a useful first draft, not a drop-in implementation — it won't know about your component library or existing patterns.
Build against the Figma file as a living reference, checked against Dev Mode as you go. Designs can shift slightly as edge cases surface during build, and that's expected. It's up to design and engineering to clearly communicate to make sure these cases are covered.
5. PR and Design QA
Once the implementation is ready, the Pull Request itself becomes the last checkpoint in the conversation. Follow the general PR conventions for titles, descriptions and issue linking. When ready assign a designer for a review with these steps in mind:
- The developer marks the PR "Ready for Review" they are happy with the quality of the work on their development branch.
- The designer reviews the running build (or the attached screenshots/recording) against the Figma file, commenting directly on the PR.
- The developer addresses comments in the same thread, the same way they would for a code review.
- The designer ticks off sign-off once satisfied, clearing the way to merge.
Here are a couple of examples:
6. Completion
Once there is sign off from Design and reviews from other engineers, the item is completed and can be merged.