KMD Elements. Making design part of how the team delivered.
A national infrastructure project under real time pressure, where design could easily end up as an afterthought. I was one of four designers embedded in a large team that moved fast.
The problem: a component library nobody used as intended
KMD built Elements for a consortium of Danish energy infrastructure providers, with high government focus. The library behind it was rarely used as intended, didn't fit real needs and had no clear owner.
My part: the bridge between the client and the design team
Four designers, each on our own flows. As the only Danish-speaking designer, I bridged the client and a multinational design team. My focus was the edit flows and the date-time picker, shaped with the other designers and the product owners. I documented components where people worked: Storybook for interaction, the wiki for behaviour.
Desk research and interviews with product owners and architects.
From designers only to the whole organisation. Documentation standardised across components and people.
Interaction in Storybook, behaviour and implementation in a wiki, translated into Danish.
Walkthroughs with developers and product owners, and guidance on extending components.
The work: patterns that hold across every flow
The edit flows look simple, but they carry conditional logic, locked data and versions. Every entity follows the same steps: details, application period, preview. I annotated each one, so developers could see the behaviour, not just the layout.
The one sharp proof: relative time you can read
Settlement needs dates that recalculate, like "9:30 on the 2nd work day, 5 months after the start of the previous year". No standard picker can express that.
I treated the component as a grammar, not a picker. Each step is a short, constrained sentence, and steps chain. Try it.
A working rebuild for this portfolio, from my designs and the component sheet. Simplified: work days skip weekends, not public holidays.
How I measured this
There are no outcome numbers for this case. The numbers above show scale and effort, and here is what each part rests on.
Three rounds with real users
Tested on scenarios from actual settlement work. Users lost track of what a chained definition would compute. The fix was a live summary that reads the definition back in plain language.
What I saw, not what we measured
Scoping got more structured, and delivery faster and more predictable. Tight timelines left little room for classic research, so decisions rested on heuristics and product owners as domain proxies.
Looking back: shipping now and building to last pull against each other
The date-time picker became the working example for the wider design system overhaul. Next time I'd bring real users in earlier, so fewer decisions rest on proxies.