Case Study · CARIAD · Volkswagen Group · 2022–23
B2B App-Store Portals
UX Design Intern · B2B web portals · 3 portals · 8 brands
Developer entry point
3
Internal portals
8
Vehicle brands
5
Stakeholder journeys
2
Modes: Light & Dark
What I owned
- Discovery interviews and heuristic audit
- Information architecture (3 portals)
- User journey mapping (5 stakeholder types)
- Lo-fi and hi-fi screen design
- Dual-mode component library
- Engineering handoff documentation
Who I worked with
- Supervisor (design feedback, prioritisation)
- Developers and architects (1:1 discovery, technical constraints)
- QA team (test report workflow, lifecycle states)
- Legal and compliance (consent, geo-blocking, GDPR)
DEV
Third-party developer
Portal
Developer Portal. Uploads APK, metadata, icons, categories, and legal docs. Waits for approval, then monitors install and uninstall stats.
Model
Familiar with mobile app stores. Expects similar tooling, and is surprised when fields like "Vehicle Install" appear without explanation.
Need
Visibility into where their submission is, what reviewers asked, and what to fix to get unblocked.
Failure
Submits incomplete metadata, waits weeks for a vague rejection, then emails the team for clarification.
REV
Central reviewer
Portal
Domain Approval. Reviews third-party submissions after automated tests pass. Approves, rejects, or sends back. Gates everything that reaches the brands.
Model
A QA mindset. Knows the technical pipeline deeply. Tracks state across many apps at once in Excel.
Need
Pipeline-wide visibility. Bulk operations. Test reports as first-class artefacts, not buried files in shared drives.
Failure
Loses track of which app is in which state and who handed it back, then reconstructs context every morning.
OEM
Brand admin
Portal
OEM Admin Portal. Final approval for their specific vehicle brand. Can approve, reject, delist published apps, or force-uninstall from vehicles.
Model
A brand and legal lens. Less interested in technical APK details; cares about compliance, market fit, and a curated brand experience.
Need
Confidence that central QA happened. Per-country legal toggles. Campaign tooling for brand-specific promotion.
Failure
Approves apps without reviewing because the portal gives no signal of what to look at. Misses geo-blocking gaps.
Discovery artifact · The submission path mapped end-to-end, open questions logged inline before any screen was drawn
Findings
Example journey · The OEM brand admin, from portal access through approve, reject, delist and force-uninstall · Open questions logged inline
Kanban concept · Environment toggle over status columns · The two-view decision, sketched before the hi-fi
Component system
A system, not a set of screens
The OEM Admin Portal hi-fi, composed from the component library. The whole portal was designed iteratively, in a continuous back-and-forth with developers and stakeholders, so the decisions and the system evolved together. What follows is a representative sample of that work, not the full set; each screen is annotated with the decision it represents, not what it looks like.
SSO entry · Loading state designed to avoid blank screens during the auth handshake
Developer entry point · Empty state with one clear next action
Replaces the Excel sheet · Sortable table · Light and dark mode from one component set
One app, tabbed submission · Technical, legal, licensing, rollout split into stages · APK upload and cluster targeting
Calendar view · Brand campaign scheduling · Pattern borrowed from CMS tooling
4-eye approval surfaced explicitly · Reviewer sees who has signed off and what is blocking