From complex data to
readable insights.
For one of Europe’s largest energy companies (name under NDA), I delivered an end-to-end research and design track as UX Designer at Octoo. The goal: turn raw, scientific risk data into something understandable and usable for two completely different user groups, scientists and non-scientists.
- SECTOR
- Energy · Europe
- MY ROLE
- UX Designer @ Octoo
- TYPE
- Consultancy
- APPROACH
- Agile / Scrum
Data nobody could read
The client works with a material risk passport, a scientific model that maps the ethical and ecological risks of materials and technologies. From wind turbines to raw materials, each evaluated on dozens of indicators via complex scientific formulas. That data already existed. But only as raw spreadsheets, readable only by the scientists who had built them. The result? Ethical decisions about materials were being made by people who simply couldn’t interpret the underlying data. And even the scientists couldn’t experiment fluently, because an interactive system was missing entirely.
Working in a cross-functional team
We ran this project entirely in Agile/Scrum. The structure and direction of the project were carried by the Scrum Master / Product Owner. He kept the rhythm, guarded priorities and owned the client relationship. My role as UX Designer was focused inside that frame: researching, translating and designing, always in alignment with the team.
Research on site, in Paris
The discovery phase took place at the client’s offices in Paris. I interviewed three scientists and engineers, the people who had built the model and worked with it daily. The PO organised access and guarded the scope; I prepared the sessions and ran them. You only understand what people really need 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 organised a focus group to understand how the two user groups, scientists and non-scientists, look at the same data differently. That tension was the core of the design problem.
Stakeholder interviews, flows & How Might We
Together with the PO I organised sessions with everyone involved: managers, planners, supervisors and operators. Each role has different needs, different language and different thresholds. I mapped the roles and their relationships as a foundation for every follow-up decision, a shared reference document for the whole team. Then I mapped the full work process visually, from raw materials in to finished product out. Not as an abstract schema, but as a shared reference document for the Scrum team. Every usability problem I then rewrote as an open HMW question, after which we used Crazy 8's and a 10-minute design challenge to find solutions. I did this exercise with the whole team, not as a soloist.
Enterprise users expect training, even when the screen is user-friendly. That expectation had to set the tone of our design approach: not remove it, but guide it smartly. I shared this insight with the PO and the team as a frame for the rest of the project.
From paper sketches to tested low-fi prototypes
I almost always start on paper. Not because it’s required, but because it slows down thinking in the right way: you draw solutions, not visuals. Then I moved to Miro for low-fidelity wireframes, mapped to the stories the PO had prioritised. The focus of the wireframes was on efficiency and process logic, not aesthetics. The operator at the spice-mixing post has little time, works with gloves, and has context you as a designer don’t always see. That asks for designs that put the task front and centre, not the interface.
Low-fidelity first
Test fast and gather feedback before we invest in details. Involve key users the moment there’s something to show, even if it’s still rough.
Dev alignment per sprint
Every iteration discussed with front-end developers. Technical constraints became design constraints, not blockers, but frames to work within smartly.
Documentation for traceability
Changes documented with reasoning. In an enterprise context, decisions need to be traceable, also for stakeholders who weren’t in every session.
Systemic thinking
One screen impacts dozens of others. Every choice was checked against the whole, not just the one flow we built that sprint.
Testing on the shop floor, not in a meeting room
We tested in two rounds: first low-fidelity prototypes, then high-fidelity screens. Always with real users, always in context. The PO coordinated access to the shop floor and guarded the scope; I prepared the sessions, moderated them and translated findings into design actions. A usability test in a lab is one thing. Observing Alya try to complete the flow while a batch of spices is waiting is another.
Efficiency
Can users do their tasks faster than with the old tools? Where do they lose time?
Clarity
Do they understand what to do without explanation? Where do they hesitate or ask for confirmation?
Process logic
Does the digital flow match their mental model? That can only be validated on site.
I let users carry out tasks that simulated their real work. No briefing in advance, no steering during. I observed where they got stuck, hesitated or made mistakes and noted it as factually as possible. A short debrief afterwards uncovered the reason behind the behaviour. After the tests I translated the findings into concrete recommendations, ranked by impact, in alignment with the PO for the next sprint.
“Thanks to the new screens I’ll be able to work so much better. I can’t wait for them to be developed.”
Building a foundation, not solving screen by screen
The real challenge wasn’t improving one module, but laying a foundation on which all current and future applications could rest. That asked for a design system that was usable for both designers and developers. The strategic choice to build such a system was made together with the PO; my contribution was in the execution and implementation.
Component kit with 30+ UI components
Built on an existing Octoo component kit as a foundation. Components ready to use, consistent and scalable. Thanks to the existing kit, we saved the client weeks of work and a lot of frustration.
Component playground for developers
A central place where all UI components were stored, documented and tested. Developers could work in it independently. Design and development from the same source, no translation loss.
Visual tokens
Colour, typography, grid and spacing defined as a shared language for designers and developers. Colour as a carrier of meaning, not decoration.
UX patterns
First patterns for navigation, forms and feedback worked out as reusable building blocks, applicable across all applications.
The design system was not the end product, it was the infrastructure that let everyone work faster and better. That is exactly the kind of impact you aim for in an enterprise environment.
What this project taught me
- 01
Don’t over-simplify
Complex business processes are complex for a reason. My job wasn’t to remove that, but to make it understandable for the people who work with it every day. That is a fundamentally different posture.
- 02
Research and design are not sequential steps
In this project they ran through each other. Every test session brought new questions. Discovery didn’t end after the first sprint, it stayed a living reference.
- 03
Make insights visible to non-designers
At least as important as the design itself. I learned to communicate with developers, POs and managers in a way that convinces without patronising: clear documentation, concrete recommendations, and the courage to take a stance.
- 04
Working inside a tight structure
The PO and Scrum Master set the direction. My value was in filling that space with strong research and considered design. Not in setting the course, but in walking it with craft.
- 05
AI as a co-pilot, not a designer
I used AI for clustering research data, summarising findings and drafting interview guides. The insights, judgements and design decisions stayed human work, grounded in data, not gut feeling.
