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
Reach
4 languages · 2 brands
Status
In development, pre-launch
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
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.
For four years I have been the product designer on a custom transport management system for a European road-freight operator. Five products: forwarders, dispatchers, drivers, back office, carriers. In June 2026 the company asked for a sixth, a portal for their own customers, the firms that order the transport. I led it end to end: research, scope, design system, dev handoff. A second designer joined once the foundation was in place.
The portal is also the first product I ran fully through the way I work now. Over 2026 my process changed shape around AI, and I do not mean prompting a chatbot. 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. I write my methods down as skills, small packaged workflows in git that a second designer can pull and use. Thirteen of them so far. When a tool does not exist, I build it, including a Figma plugin that generates our brand typography maps. Designing the product and building the machinery around it have become the same job for me.
Kickoff to the first dev-ready module took four weeks. Research closed in week two.
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 doesn’t have the truck number; they have their own reference numbers, which the hotline couldn’t search by. Escalations ended up on someone’s private phone at night.
Some customers had been promised a portal two years earlier and were being kept on shared spreadsheets in the meantime. New EU tachograph rules added pressure: delivery timing got harder to improvise, and customers — automotive especially — started treating live tracking and reliable ETAs as a requirement in sales conversations.
This was also the company’s first external product, which raised the bar more than any feature decision did: customers in Germany, France, and Belgium meant four languages from day one, full responsive range (we had no data on what screens customers use), and a separate application with its own replicated database. The September deadline was self-imposed but real.
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.
Research was never the part I skipped. My vault has interview notes, usability tests and shadowing sessions going back to 2023 — the planner role, the back office, the document flow. What changed in 2026 is what happens after the room. Clustering a wall of post-its used to eat hours. 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.
In the first week I had a research plan, a screener, a moderator cheat-sheet, and separate interview guides for internal proxies and real customers, in Polish and English — drafted from a written method, reviewed and sharpened by me. Recordings became structured reports with verbatim quotes; reports became a synthesis; the synthesis fed a jobs-to-be-done map where every kickoff hypothesis got a verdict: confirmed, reframed, killed, or new.
AI did not sit in the room. I moderated every session. A model can draft a non-leading question; it can’t notice a participant hesitating and decide to wait. Every claim in the synthesis traces to a quote or a named source, because I checked them against the recordings.
The market. A teardown of seven competitor portals: Flexport, Forto, MyDHLi, myKN, project44, Shippeo, Transporeon. All seven hide operational detail from the end customer. Milestones and ETA — never raw GPS, never the carrier or driver, never margins.
The internal proxies. Three of the company’s forwarders. Their instinct went further than the market: customers shouldn’t see live TMS statuses at all. The reasoning is professional, not defensive — a 15-minute delay the driver will make up isn’t information, it’s noise, and a customer pinged about every one of them stops reading. Deciding what a customer hears, and when, is part of the job.
The customers. Two in-depth interviews. Both asked for more visibility, up to live GPS. One had ordered a crane for a fixed unloading slot and couldn’t find out whether the truck would make it; the forwarder’s honest answer was ”I don’t know,” and the crane cost money either way. The people closest to the customer had the most conservative instinct; the customers themselves asked for more than anyone had assumed. That gap is what the table below resolves, row by row.
A caveat that stays in the case study: both interviewed customers are intermediaries — forwarding houses with their own TMS. Their appetite for operational data is probably the top of the range, not the middle. The findings carry that warning, and the shipper-without-a-TMS persona stays a labelled assumption until we interview one. AI makes this discipline harder, not easier — a language model will generalize two interviews into confident prose if you let it.
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. One planned MVP pillar died: invoices — both customers independently described them as a non-problem.
Three research rounds, three answers. Seven competitor portals hide operational detail, the company's own forwarders wanted to hide more, and the two interviewed customers asked for everything up to live GPS.
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 wasn’t a screen. We drew the line separately for each piece of data:
What | Decision | Why |
|---|---|---|
Statuses | All of them, live | The validated job is to react in time — rebook the crane, warn your own customer |
Delays | Never labelled as delays | A 15-minute delay the driver will make up is noise. The customer can infer; the explaining stays with the forwarder |
GPS location | Default off; grantable per transport or per standing agreement | Sharing location became a per-customer business decision instead of a default |
Driver comments | Never | Informal, multilingual, risky. The forwarder handles the narrative |
Route context | Never | The customer sees their order. How orders combine into routes is operational logic — and margin |
Two of those rows reverse decisions the team had made at kickoff (”delays — yes”, ”GPS default on”). The research flipped both. Six more rows — timestamps, ETA, plates, driver phone, credit limits — went the same way, one data point at a time. Every decision in that table sits in the PRD’s decision log with a date, a rationale, and a link to the meeting or interview behind it — when someone asks in November why timestamps are hidden, the answer is one search away.
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 in the product 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.
The account model: 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. The knowledge base surfaced what similar workarounds had cost us on the carrier portal.
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 September — 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. All the research conclusions, hard boundaries, brand rules, and MVP scope live in one written design brief — a reusable prompt, 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: the full MVP flow, four languages, both brands. Scope and style questions got settled there — the client review that narrowed the MVP happened on clickable screens, not slideware. Then the design moved 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 design-system library, the dev doc, and the coded prototype — in one reviewed pass. Where no tool existed, I wrote one: the brand typography maps in Figma come from a plugin I built.
Copy in four languages, measured. Drafted against written tone rules per language (formal Sie/vous — B2B customers), reviewed by native speakers inside the company. The login-flow 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.
And four places where AI stays out, on purpose: the interview room (the follow-up question that wasn’t in the guide is the research); deciding what’s true (synthesis drafts come from the tool, the verdict on each finding is mine, checked against recordings); the final visual call (generated variants are options); and client-facing lines (nothing ships unread, and the four-language copy goes through native speakers).
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. The dashboard header carried a counter line nobody had asked for: it duplicated the KPI tile and the alert banner directly below it, and it had crept in from a prototype subtitle that turned into numbers along the way. I cut it, wrote down where it came from, and now treat reviewing generated output as a budgeted part of the process.
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 — wasn’t consuming the calendar, so the saved time went into the layer that usually dies in planning:
A deliberate visual identity instead of default SaaS: editorial direction — large display headings, quiet body text, generous whitespace, monospace numerals in the data tables. Written into the foundation as a rule: the design investment goes into tokens, typography, detail, and motion, not into reinventing primitives.
An interaction and motion layer designed on purpose: transitions and micro-interactions built in the code prototype, where motion can actually be felt and iterated, then carried into the spec. Loading states got designed shimmer, not an afterthought spinner — with prefers-reduced-motion respected, because delight that ignores accessibility isn’t craft.
Two brands that feel intentional, not one theme with swapped hexes: separate accent ramps, wordmarks, and on-accent behavior, switchable live in both the prototype and Figma.
None of this was a stakeholder requirement. It’s the work I’ve always wanted the time to do in operational software, and this is the first project where the process gave it to me. That’s my honest summary of what AI changed: not that the product shipped, but which parts of my skill set finally made it into the product.
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.
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
At the time of writing, 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.
The before-and-after for the process: a year earlier, each of these deliverables existed in a shorter form. This project has a multi-round research programme, a JTBD map with a verdict on every hypothesis, per-flow handoff docs, clickable prototypes in four languages, a dated decision log and a designed motion layer. 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
Interview the segment I did not reach before locking scope.
Interview the shipper segment — customers without their own TMS — before locking MVP priorities, not after.
Push the multi-entity login question in week one instead of letting it become the last open blocker.
Catch the counter line sooner. Fast generation needs budgeted review; I learned that by missing something for a few weeks.