Skip to content
Rodney Zieck
All work

PANGEA portal

PANGEA is Gasunie's IT programme for the energy transition. From March 2023 to December 2024 I was the UX designer in a multidisciplinary scrum team in its Informeren cluster. The assignment: bring a scattered set of tools and systems, used by companies that operate on Gasunie's gas network, together in one portal.

Client
Gasunie, via Sogeti
Role
UX designer
Year
2023–2024
Methods
User interviews, Personas, Wireframing in Figma, Task-based usability testing, Hand-off to Storybook
Tools
Figma, Storybook
Site
Client portal, not public
From separate tools to one portalSix separate tool windows on the left connect through a research step to a single portal on the right, laid out with navigation, a task list and detail panels.4 personas, 8 test tasksSeparate toolsOne portal
The portal is a Gasunie client system and isn't shown. This drawing shows the shape of the project: separate tools, the research in between, one portal.
embedded in the scrum team
2 years
personas built from user interviews
4
task scenarios in every test session
8

The brief

The people using these tools know their domain well. What slowed them down was the tooling: finishing one piece of work meant moving between several systems, each with its own logic and vocabulary.

So the design question was about consolidation. How do you give expert users one place, and one mental model, for work that used to be spread across many?

Process

I ran the work in two rounds of widening and narrowing, first on the problem and then on the solution, following the Double Diamond.

DiscoverThe problem spaceDefineThe problem itselfDevelopThe solution spaceDeliverThe solution

  1. 1Discover

    I interviewed end users of the functions the portal would take over, and stakeholders across the Informeren cluster. The same pattern came up in almost every conversation. People lost time switching between tools to finish a single task. They knew the domain; what they couldn't keep track of was which screen lived where.

  2. 2Define

    I turned the interviews into four personas, each with a different relationship to the work. That changed the brief. The team had been thinking of the portal as an information layer on top of the existing systems. After the personas, we treated it as the place where the work itself gets done.

  3. 3Develop

    I designed wireframes in Figma in short cycles with the team and tested every round with real users. Each session used the same eight task scenarios, based on work participants actually do. Every session ended with a concrete list: a label people misread, a flow that branched the wrong way, a button nobody understood. I changed the designs and tested again.

  4. 4Deliver

    Engineers built the designs as components in the team's Storybook, which became the source of truth for what exists in production. Figma held the spec, Storybook the implementation. The portal kept developing after my assignment ended in December 2024.

Decisions

Testing tasks instead of collecting opinions

Walking people through a feature and asking what they think mostly produces opinions. Instead, every participant got the same eight realistic tasks and I watched them work. Findings changed from ‘I like this’ to ‘I couldn't find that’, and because everyone did the same tasks, I could compare results from one round to the next.

Storybook as the hand-off

Long hand-off documents tend to go unread. We skipped them. Each design went from Figma straight into Storybook, where engineers built it as a production component. With the spec in Figma and the implementation in Storybook, there was little room for the two to drift apart.

Removing a button instead of relabelling it

In one scenario, participants hesitated at a button whose label didn't say what it did. The obvious fix was a better label. Rewatching the sessions showed something else: participants already reached the same result through other paths on that screen. I removed the button. The screen got simpler and nobody missed it.

What I took away

Most of the UX work on this project happened before the first wireframe: understanding how people's tools fitted together and where they got lost. In a domain this complex, the screens are the visible end of that work.

Testing with the same tasks every round is the habit I took with me. It turns usability testing from a mood check into something you can measure against the previous sprint.