EN
Back to site

Case study · Large-scale systems · Client confidential

When one source becomes the foundation for many products.

The portal had far too many pages to design one by one, and the system behind it had to hold up for editors who rely on it all day. So I didn’t start with screens. I built one token library and let both products grow out of it.

Part oneProcess

Before the first screen, I mapped the whole project.

I didn’t open Figma first. I read the requirements until I could explain them to someone else, ran workshops with the institutions whose data ends up on the portal and worked out who needs what. The decisions below came out of that, and they shaped everything that follows.

  1. 01Research

    Citizens, municipalities, researchers and editors want different things from the same page. I wrote down who needs what.

  2. 02Workshops

    I ran workshops with the institutions behind the data. The sticky notes showed what each of them really needs, and where they all agree.

  3. 03Analysis

    I went through the requirements line by line and compared similar portals, to see what already works and what nobody has solved yet.

  4. 04Mapping

    Then I mapped every area, every page and the system that publishes all of it.

  5. 05Decisions

    Four decisions came out of it. I wrote them down early, and they lasted to the end.

    One shell for every page
    Editors change content, the system protects layout
    Tokens before screens
    One library for the portal and the central system

  6. 06System

    Everything else on this page grew out of those four.

    Portal kitPart two
    Central systemPart three
    LibraryPart four

Part twoThe portal kit

The portal is built from parts that repeat on every page.

Nobody opens a portal to admire its components. People come for a number, a document or a deadline. These are the pieces that get them there, rebuilt here from the prototype with names and data changed.

01Data display

Every number shows its direction and its source.

A number without a source is just a rumour. Every value on the portal says where it comes from, when it was last updated and whether it went up or down, with an arrow and a sign, not only a colour.

02Charts

One data card serves every measurement.

Particles, gases, temperature and pollen matter to different people, but on the portal they share one card: a title, a period, tabs, a chart and a short table. Once you can read one, you can read all of them.

03Navigation

The shell stays the same whether it is open or folded.

The sidebar keeps the same items, icons and counters whether it is open or folded, and the top bar keeps search, the assistant, language and settings in the same order on every page. People shouldn’t have to look for the navigation.

04Notifications

Messages follow one calm pattern.

A small coloured tile says what kind of message it is, a dot says it is new, and one link clears everything. The same row works in the notification panel and in the inbox, so I only had to design it once.

05Forms and controls

Every input behaves the way people expect it to.

Fields, selects, checkboxes, switches and steppers share one height, one radius and one focus ring. An air quality alert and a page of accessibility settings are built from exactly the same parts.

06Cards and lists

Cards and lists are assembled from the same few pieces.

An icon tile with a title, an empty state with one clear action, a list of links. These few pieces repeat all over the portal, so a new section is mostly a matter of picking the right ones.

Part threeCentral system

A central system runs behind the whole portal.

Everything people see on the portal is written, checked and published here, by editors who work in it every day. It uses the same tokens as the portal, but it is built for speed and control, not for first impressions.

01Access

Security is visible, not hidden in settings.

Editors sign in with a second factor, see when their password expires and know when the session will close. It sounds strict, but this is official content, and people relax when they can see the rules instead of guessing them.

02Workflow

Every piece of content shows where it is in the workflow.

Draft, editorial review, legal review, scheduled, published. The same statuses, colours and counts show up in the list, in the editor and in notifications, so nobody has to ask in a chat where an article is.

03Roles and permissions

Permissions read like a table, not a maze.

Who can create, edit, approve or publish what fits on one screen. The administrator role can’t be deleted by accident, and a privileged role asks for a second confirmation. Both rules exist because somewhere, someone once locked everyone out.

04Site tree

The site tree decides where every page lives.

Editors move pages in the tree, pick a template and decide where a page appears in the navigation. Menus and breadcrumbs follow on their own, so one change doesn’t turn into five.

05Audit trail

Every change leaves a trace people can read.

Who changed what and when is written down in plain language. With official content that isn’t a nice extra, it’s the first thing anyone asks for when something goes wrong.

Part fourThe library

Everything above settles into one library for this domain.

My design library existed before this project. What this project added is the library set up for this domain: shadcn/ui with its own tokens, themes and patterns, written down once and used by both products.

01Token registry

Every token has a name that says what it is for.

Components never ask for orange or grey. They ask for --primary or --muted-foreground, and the registry says what each name is for. That one habit is what makes the next two sections possible.

02Colour tokens

Three themes, one set of names.

Light, dark and high contrast change only the values behind the names. The components don’t even notice, which is the whole point, and the reason accessibility here isn’t a separate project.

03Elevation

Depth follows a few clear steps.

A small set of shadows, each with one job, from cards up to dialogs. When someone asks for a new one, it usually means the layout has a different problem.

04Components

Buttons, chips and cards share one anatomy.

Everything you can press has the same height, radius and focus ring, and every card has the same three zones. It is boring on purpose, because boring is what lets people move fast.

05CRUD layout

One layout serves every list in both products.

A header with actions, filters, a table, pagination and an edit panel on the side. Content, users, media and datasets all use it, in the portal and in the central system.

06Typeface

One typeface, four sizes that do the work.

Google Sans in four sizes with fixed line heights. Nobody picks a size by eye, so the hierarchy holds on every page, even the ones I never designed myself.

LEARN
The library also lives on its own, as a place to learn.Next to the products, the library runs as a separate instance with tokens, components, examples and rules. Someone new can open it on day one and start working without waiting for me to explain.
PDF
And at the top of it all, a whitepaper.One document explains the thinking behind the whole thing: why there is one source, how tokens are named, how the library grows and how a new product starts from it.

OutcomeWhere it stands

The project was specified and approved by the client.

Every part of it is written out in full. Development is estimated at eleven months, and the design took about three. The portal spans a great many pages and even more components, and whole sections exist as ready-made blocks, so someone new can put a page together without starting from a blank screen.

What comes nextScaling

This foundation can grow into whatever comes next.

Because everything starts from one source, the next step doesn’t start from zero, whether that is the central system, a mobile app, more teams using the library or something nobody has asked for yet.

One source of truth

  1. 2026 · Now

    Web applicationThe public portal, built from the kit and the tokens.

  2. Now

    Central systemThe system behind the portal, on the same components.

  3. Next

    Mobile scalingThe same tokens, adapted to how phones work.

  4. Source of truth

    Shared libraryThe source every product draws from.

  5. Later

    A new solutionWhatever comes next, starting from the same source.

The system was built to outlive this project.

That was the real goal from the start. Products change, teams change, and the portal will look different in five years. The decisions underneath should still make sense.