Client portal: zero to one
Customers phoned their forwarder for every status check. Research decided, one data point at a time, what they should be allowed to see.
Web
B2B
AI process
Logistics
Role
Design Lead
Timeline
2026 - currently
Status
In development, pre-launch
Reach
4 languages 2 brands
Methods
Research Plan User Interviews Desk Research Competitor Benchmarking JTBD Mapping Hi-fi Prototype Design System UX Writing Localisation Motion Design AI in Design Process
Outcome
4 wks
kickoff to first dev-ready module
4
languages from day one
2
brands, switchable live in prototype and Figma
13
packaged workflows in git a second designer can pull
The portal dashboard — editorial type, quiet body text, monospace numerals in the data tables.
Overview
The company's sixth product — and the first one I ran fully through the way I work now.
In June 2026 the company asked for a portal for their own customers, the firms that order the transport. I led it end to end: research, scope, design system, dev handoff.
It is also the first product I ran fully through the way I work now. I keep a versioned knowledge base the tools read before producing anything: four years of meeting notes, a domain glossary, a decision log with the reasons attached. My methods are written down as skills — small packaged workflows in git a second designer can pull. When a tool does not exist I build it, including a Figma plugin that generates our brand typography maps.
Problem
Every status check was a phone call — and the after-hours hotline couldn’t find the order by the only number the customer had.
To check a status, get a transport document, or chase an invoice, customers called or emailed their forwarder. The after-hours hotline searched by truck number — but the customer does not have the truck number, they have their own reference numbers, which the hotline could not search by.
New EU tachograph rules added pressure: automotive customers started treating live tracking and reliable ETAs as a sales requirement.
This was also the company’s first external product, which raised the bar more than any feature decision did: four languages from day one, full responsive range with no data on what screens customers use, and a separate application with its own replicated database.
The orders list, filtered by the customer's own reference number. The after-hours hotline could only search by truck number.
Research
Two weeks, three sources — and the three rounds disagreed with each other, which is where the value was.
My vault has interview notes, usability tests and shadowing sessions going back to 2022. What changed in 2026 is what happens after the room: clustering a wall of post-its used to eat hours, and a teardown of seven competitor portals used to be a week of solo work. The mechanical half of synthesis got cheap, so the same two weeks bought more of the part that needs a person.
Week one produced a research plan, a screener and separate interview guides for internal proxies and real customers. Recordings became structured reports with verbatim quotes, and the synthesis fed a jobs-to-be-done map where every kickoff hypothesis got a verdict: confirmed, reframed, killed, or new.
Two jobs came out of the verdicts that nobody had predicted — find my order by my own numbers, and push statuses into my own system — and one planned MVP pillar died: invoices, which both customers independently called a non-problem. AI did not sit in the room; I moderated every session, and every claim in the synthesis traces to a quote I checked against the recording.
Three research rounds, three answers on how much the customer should see
Key decisions
Four decisions: one about data, one about scope, two about how the work itself gets done.
Decision 01 · Transparency
Three sources, three answers on transparency — so we drew the line per data point
The hardest design problem was not a screen. We drew the line separately for each piece of data:
Two of those rows reverse decisions the team made at kickoff — ”delays: yes” and ”GPS: default on”. The research flipped both, and six more rows went the same way, one data point at a time. Every row sits in the PRD’s decision log with a date, a rationale and a link to the meeting or interview behind it.
Why
The validated job is to react in time — rebook the crane, warn your own customer. That job needs live statuses; it doesn't need route logic, margins, or a price-trend chart handed to a negotiating counterparty.
Trade-off
GPS — the single most-requested feature — ships default-off, grantable per transport or per customer agreement. It flipped to default-off precisely because customers wanted it so badly: making location a per-customer business decision kept the forwarders’ trust and gave sales something concrete to offer.
Decision 02 · Scope
The MVP shrank twice — and the least glamorous item in the backlog came in
Invoices went out and account management came in — the least glamorous item in the backlog, but without it no customer can log in. A design review then narrowed the MVP to dashboard and orders.
On accounts: one customer asked for a single shared login for her whole team. We said no to the shared account — no audit trail, no way to revoke one person — but kept the need behind it: organization-level access where the team sees everything, individual logins by email plus one-time code, no passwords.
Why
Without account management no customer can log in. The glamour of a feature has nothing to do with whether it gates the product.
Trade-off
The on-time-performance metric was cut as too edge-casey to define honestly by the deadline — but the TMS started logging status data immediately, so the metric will have history when it ships later. One question stayed open as the main pre-dev blocker (one email, two legal entities) — flagged to be solved during the build, not patched after.
Decision 03 · Process
Design starts in code, not in canvas — and the brief became a tool
The brief became a tool. Research conclusions, hard boundaries, brand rules and MVP scope live in one written design brief, updated after each decision meeting. Any design session, mine or the AI’s, starts from the same source of truth instead of from memory.
The first working version was a clickable prototype generated from that brief and the design tokens: full MVP flow, four languages, both brands. The client review that narrowed the MVP happened on clickable screens, not slideware. Then into Figma for the token and component layer, back to code for refinement, and back again.
Figma got automated where it deserved it. Brand and language live in variable modes: sixteen brand variables, 109 string keys, and the only hardcoded text is data. When the dashboard header changed in August, that one decision touched 25 outgoing frames and 19 new nodes across breakpoints, brands and languages — plus the library, the dev doc and the coded prototype — in one reviewed pass.
Copy in four languages, measured against written tone rules per language, reviewed by native speakers inside the company. Login strings were measured against the narrowest mobile column: the French title wraps to two lines, the longest German string clears its column by one pixel.
Four places AI stays out: the interview room, because the follow-up question that was not in the guide is the research; deciding what is true, because the verdict on each finding is mine, checked against recordings; the final visual call; and anything client-facing.
Why
It's a loop, not a handoff: whichever medium answers the current question faster is the one I work in.
Trade-off
Fast generation produces unrequested things at the same speed as requested ones. Ax export all orders might be a cheap and fast line in the prototype, but is a whole new requirements and what-ifs debate with the dev team. And then it gets rejected, because we need to ship MVP version ASAP. A time of conversations we will never get back.
Decision 04 · Craft
The saved time went into the layer that usually dies in planning
On the portal, for the first time, there was room. The mechanical work — variant grids, string binding, breakpoint propagation, handoff writing — was not consuming the calendar, so the saved time went into the layer that usually dies in planning:
A deliberate visual identity instead of default SaaS: large display headings, quiet body text, generous whitespace, monospace numerals in the data tables. The design investment goes into tokens, typography, detail and motion, not into reinventing primitives.
A motion layer designed on purpose: transitions and micro-interactions built in the code prototype, where motion can be felt and iterated, then carried into the spec. Loading states got designed shimmer, not an afterthought spinner, with prefers-reduced-motion respected.
Two brands that feel intentional, not one theme with swapped hexes: separate accent ramps, wordmarks and on-accent behavior, switchable live in the prototype and in Figma.
None of this was a stakeholder requirement. It is the work I have always wanted the time to do in operational software.
Why
In operational software, time, budget, and deadline collide on every project — and motion, micro-interactions, and brand expression are always what gets cut first. Not because anyone thinks they don't matter; they're just never the priority.
Outcome
Same designer, same client, same domain. This time the research, the decision log, the handoffs and the motion layer were all full-size.
Dashboard and login are dev-ready with full handoffs, and development is underway on the separate application. Several hundred customer firms will be invited at launch. The success criterion is that the largest of them log in and stop calling.
Whether the after-hours calls drop is a number I will have after launch. The portal logs what is needed to answer that from day one.
The dashboard at 1440, 768 and 375 px. Dashboard and login are dev-ready with full handoffs; development is underway on the separate application.
Reflection
Do not skip wireframes phase
I thought since we have a live prototype so fast, we could skip the wireframes phase and just go straight to the design review.
Little did I know, that wouldn't make things any faster. Unfortunately, somewhere along the way the product requirements got lost and a bit confusing. With additional "little" features, that turned out unnecessary. What I'd do now is focus more on the lo-fi sketches - preferably in greyscale, so that the content takes the first place, whilst doing the review.