The screen matches Figma. The work still disappears.
Someone fills in an expense claim, attaches a receipt and moves to the review screen. They go back to correct the date. The form is blank, and the receipt is gone.
The screens look right, but someone using them has to do their work twice. Design and engineering need a shared understanding of the experience they are trying to improve.
Korium in this storyMemory + Code + Skills + WorkflowsAn illustrative story, not a customer result. No customer is depicted.
Follow the work01What keeps happening
The handoff shows what to build, but loses what has to keep working.
Your UX team watched people lose their progress when correcting a claim. The redesign lets them move back from review without losing the draft or its attachment.
The Figma screens show the fields, the receipt and the back button. The ticket links to the design, but the reason for preserving the draft sits in a research note and a review conversation.
A developer or coding assistant implements each screen correctly in isolation. When the review screen sends someone back, the form is created again with empty values, and the next design review rediscovers a problem the team already understood.
- Research shows lost progress
- Design agrees to preserve the draft
- Implementation follows the screens without the reason
- Review finds the same broken interaction
02Where we would start
We’d start with the moment between the screens.
We’d walk through creating a claim, reviewing it, going back and correcting it. What must survive that journey, which design records the decision and how will the team check the built version?
The first thing to preserve is a testable agreement: returning to edit keeps the draft fields and receipt, and saving the correction updates the review. That is more useful to the next person than another instruction to follow Figma.
03What Korium would keep
Keep the interaction, the reason and the design reference together.
A connected assistant could save the agreed behavior in Korium, without storing someone’s receipt or expense details:
“In the claim flow, going back from review to edit must preserve the draft fields and attachment. Research found that losing progress made people repeat work. After a correction, review must show the updated value; a change to the screens or state handling must preserve this behavior unless the team explicitly revises the decision.”
Source: The de-identified research finding, the approved Figma flow and design-review decision, and the ticket’s agreed acceptance checks.
04The next person, the next task
The developer gets a behavior to preserve, not just a picture to match.
Before changing the claim flow, the assistant retrieves the decision and opens the current design reference. Korium:code helps locate the draft-state, back-navigation and review-update functions at the indexed commit, which the assistant verifies against the current checkout.
An interaction-testing skill guides the checks across screens, while a workflow carries the agreed behavior through implementation and review. Now the question is whether a person can correct the date and keep their work, not whether two screenshots look alike.
A plan based on the saved explanation
- Create a draft with a test attachment, move to review and return to edit; check that the work remains.
- Correct the date and verify that review shows the change without losing the other fields or attachment.
- Check the built interaction with the designer and developer, including keyboard navigation, focus and error handling.
05Memory + Code + Skills + Workflows
Which parts of Korium help here?
Memory keeps the reason behind the interaction. Code locates what implements it, skills guide the design and testing checks, and a workflow carries the agreement through review and saves the result.
- MemoryKorium:mem
Keep why returning to edit must preserve the work.
Korium:mem keeps the research finding, the draft-preservation decision and references to the approved design and acceptance checks. A new developer can retrieve the reason without replaying the design meeting or storing private claim details.
- CodeKorium:code
Find the state and navigation code behind the screens.
Korium:code points to named symbols and locations in the indexed commit so the assistant can inspect the current implementation. It indexes code symbols, not Figma screens; the design reference belongs with the decision in memory and is opened in its own tool.
- SkillsKorium:skills
Check the behavior as carefully as the appearance.
We’d adapt skills for your design system, interaction tests and accessibility review. Those instructions guide checks such as preserving a draft, updating the review screen and managing focus when someone returns to a field.
- WorkflowsKorium:workflows
Keep the agreement intact from design review to tested software.
The workflow would read the decision and current design, locate the code, use the implementation and testing skills, and prepare the result for design and engineering review. After acceptance, it would save what changed, what was tested and which requirements still apply.
06What the team can do next
The next design review can tackle the next improvement.
When the team accepts the fix, save the implementation decision and the tests that checked draft preservation. Keep them connected to the research and design reference so the next change has an explanation, not just a test that nobody understands.
If a later design changes how editing works, the team can deliberately revise the requirement and record why. The next coding assistant can distinguish a screen that has been replaced from a behavior people still depend on.
Once that interaction works, the designer and developer can try the next improvement together instead of passing the same defect back and forth. The person making a claim can correct one date and carry on. New team members can learn why preserving that work matters from the decision and its test.
How we would check whether it helped
- Check whether reviews test the full interaction as well as the appearance of each screen.
- Ask whether designers and developers can spend reviews improving the flow rather than repeating an earlier agreement.
- Ask people using the updated flow whether they can make a correction without repeating their work.
One problem. A useful place to start.
Bring the interaction that keeps bouncing between design and development.
We’d take one flow, follow the decision from research and Figma into the implementation, and agree what a working result looks like. Then we’d put that explanation and those checks where the next person or coding assistant can use them.