From complex data to
readable insights.

The company works with a material risk passport: a scientific model that evaluates the ethical and ecological risks of materials and technologies across dozens of indicators. That data existed only as raw spreadsheets, readable only by the scientists who had built them.

The PO / Scrum Master held the direction and owned the client relationship. My role was in researching, translating and designing.

I interviewed three scientists and engineers at the client offices in Paris. People who had built the model themselves and worked with it daily. You only understand what someone needs when you see how they work: which columns they ignore, where they tune out, how they reason about risks you don’t immediately grasp as a designer. Alongside the individual interviews I ran a focus group to understand how scientists and managers look at the same data differently. That tension turned out to be the core of the design problem. Then came stakeholder mapping, functional flow mapping and a HMW session with the whole team, so everyone had the same problem in mind before a single wireframe hit the table.

From paper sketches to low-fi wireframes in Miro, always aligned with the stories the PO had prioritised. Classic usability testing was not feasible because the domain knowledge is too specific. Instead we validated iteratively with stakeholders and key users per sprint. The final design was presented per sprint to both scientists and managers, each giving feedback from their own perspective. The final design got the green light from both groups and was fully implemented by the developers afterwards.

In the early phase of the project we did not yet have access to the client’s official design system. To be able to design and iterate quickly, we used an internal component kit as a temporary base: 30+ UI components we had built internally. That let us work in a realistic look and feel immediately without waiting for approval. Once we got access to the official design system, we migrated. Based on what we had learned, we made improved suggestions for components that better fit the specific needs of this platform. The final result was developed with the client’s official design system components, enriched with our insights from the design track.

1. 01

   Don’t over-simplify

   Complex processes are complex for a reason. My job was to make them understandable, not to hide them.

2. 02

   Validation without formal testing

   Not every project lends itself to usability tests. Iterative stakeholder sessions provide sound direction too.

3. 03

   Working inside a tight structure

   The PO set the course. My value was in filling that space with strong research and considered design.