Gasunie · via Sogeti
PANGEA · Informeren cluster.
A two-year UX-design assignment on PANGEA, Gasunie's IT/Energy Transition Program. The portal consolidated a set of separate tools and systems into one place, used by the businesses operating on Gasunie's energy network. Worked end-to-end as the UX-designer in a multidisciplinary scrum team: from user interviews and four personas, through Figma wireframes and task-based usability testing, into designs the engineering team implemented in Storybook.
/ at a glance
What I owned.
- 01Owned the UX track for a portal inside PANGEA, Gasunie's IT/Energy Transition Program.
- 02Built 4 personas from interviews with the actual end users of the function.
- 03Designed wireframes in Figma, validated through usability testing with users running 8 realistic task scenarios.
- 04Designs flowed from Figma to the engineering team's Storybook component library.
01 / problem
The brief.
PANGEA is Gasunie's IT program for the energy transition. The Informeren cluster needed a portal that could pull together a fragmented set of tools and systems into one usable surface. The users, operators of businesses on Gasunie's energy network, were doing complex domain work, but doing it across multiple disconnected tools. The UX challenge was consolidation: one portal, one mental model, one place to do the work that previously lived everywhere.
02 / process
Double Diamond.
The classic British Design Council framework, used across Dutch public-sector design. Two phases of diverge-then-converge: first on the problem, then on the solution.
01 / Discover
The problem space
02 / Define
The problem itself
03 / Develop
The solution space
04 / Deliver
The solution itself
01 / Discover
Started in listening mode. Interviewed the actual end users of the function the portal would serve, plus internal stakeholders across the Informeren cluster. The recurring pattern: users were spending real time hopping between tools to complete a single piece of work. They knew the domain. They didn't know which screen lived where.
02 / Define
Synthesised the interviews into four working personas, each with a distinct relationship to the work the portal would carry. Reframed the brief from 'inform the user' to 'consolidate the user's tools into one calm surface'. That reframe set the rest of the project's direction: the portal stopped being a new information layer on top of existing systems and started being the place where the work actually happened.
03 / Develop
Designed wireframes in Figma in tight cycles with the scrum team. Validated each wave of designs against real users through usability testing, with participants walking through eight realistic task scenarios per session, the kind of work they would actually do in the portal. Each session produced a concrete list of adjustments: a label that misread, a flow that branched wrong, a button whose purpose wasn't clear. Rewrote, retested, moved on.
04 / Deliver
Designs flowed from Figma into the engineering team's Storybook, where they were implemented as the production component library. That kept the boundary clean: Figma was the design spec, Storybook was the source of truth for engineering. The portal continued to develop after my assignment ended in December 2024.
03 / decisions
Forks in the road.
The interesting part of any UX track is what got picked, what got rejected, and why. Here are the ones that mattered.
/ decision 01
Task-based usability testing, not feature walkthroughs
Most usability tests walk users through a feature and ask 'what do you think?'. We did the opposite: gave each participant eight realistic task scenarios and watched them work. The findings stopped being 'I like this' and started being 'I couldn't find that'. Honest in a way that opinions never are, and reproducible across sessions because every participant tried the same eight things.
/ decision 02
Figma to Storybook, not Figma to a doc
Engineers don't read design documents. They read code. We targeted Storybook as the destination for every component design instead of a long handoff write-up. The engineering team implemented each design directly into Storybook, which became the shared source of truth for what existed in production. My deliverable was the Figma spec; theirs was the Storybook implementation. The seam between the two stayed thin.
/ decision 03
Remove the button if there's another path to it
One scenario exposed a button whose label didn't clearly say what it did. The obvious fix was to rewrite the label. The less obvious move came from rewatching the session: users were already reaching the same outcome through other paths in the interface, just by working naturally with the rest of the screen. So I removed the button instead of relabelling it. Less surface area, less confusion, same coverage. Sometimes the right UX answer is to make the design smaller, not clearer.
Where it landed.
Four personas, task-based usability sessions across the assignment, two years of UX-design embedded in a scrum team on PANGEA. Designs flowed cleanly from Figma into the engineering team's Storybook for production implementation. The portal continued to develop after my assignment ended.
/ reflection
What this taught me.
The biggest lesson from this assignment was how much UX work happens before the first wireframe. The consolidation problem, the user's tooling reality, the moment-to-moment confusion, that was the project. The screens were the visible part. In a high-complexity domain the design challenge is rarely about pixels. It is about lifting the user's perspective into rooms where the user does not sit. Task-based usability testing was the discipline that kept the design honest, scenario after scenario.