B2B App-Store Portals

Before any app reaches a car screen, three internal portals decide what happens to it. None of them had been properly designed. I rebuilt the governance layer end-to-end: information architecture, user journeys for five stakeholder types, a component system, and a hi-fi OEM Admin Portal covering app discovery, lifecycle management, and brand-level approval.

CARIAD, Volkswagen Group’s software subsidiary, was building an in-car App Store on Android Automotive OS. Getting a third-party app onto a driver’s screen meant passing through three internal web portals, across the eight Group brands (Volkswagen, Audi, Porsche, Škoda, SEAT, and more), with no shared tooling. I joined the Group App Store team as the sole designer on the portal redesign.

Three portals, none properly designed

For an app to reach a driver’s screen, it had to pass through three internal web portals: one where third-party developers upload their APK, one where the central team reviews it, and one where each vehicle brand makes the final call. None of those portals had been designed with users in mind.

The QA team tracked apps in Excel sheets. There was no shared view of where an app sat in its lifecycle. Reviewers couldn’t see what was in the pipeline. Brand approvers had no analytics. The legal complexity, GDPR consent, geo-blocking, automotive compliance, was buried in code with no UI affordance. Internally everyone called it the API admin tool. The brief was to turn a backend into a system three teams could use.

Sole designer on the portal redesign

I joined as a UX design intern in the Group App Store team. After the first month I was the only designer on the portal redesign work. I led discovery, research synthesis, lo-fi, hi-fi, the component library, and the documentation handed to engineering.

Three teams, three jobs to be done

The three portals serve three distinct stakeholder groups with conflicting needs. One UI couldn’t serve all of them, so each portal had to be designed around its specific user.

Discovery and an audit of the existing portal

There was no research budget and no access to OEM employees outside the company, so discovery had to come from inside: 1:1 conversations with developers, architects, and QA, plus a structured audit of the existing Developer Portal. That audit was the primary evidence source for the redesign.

The work ran in parallel tracks. I started low-fidelity on the Domain Approval portal first, an easier entry point that built team buy-in, then benchmarked Google Play for cars and the Apple App Store to inform the in-car Store surface. Alongside the redesign I also ran app quality testing on the test bench, exercising General App Behaviour, UI, Login/Logout, and Video Playback.

Discovery artifact · The submission path mapped end-to-end, open questions logged inline before any screen was drawn

The approval pipeline as a system

App approval pipeline · Developer upload through review and brand-level approval to publish

Before designing any screen, I mapped the full app lifecycle as a system: who touches an app at each stage, what decisions they make, and what state the app sits in between decisions. A swimlane across developer, supplier (smoke and manual testing, then an APK validator report), CARIAD reviewer, and brand admin put a rough number on it: around seven days end-to-end, most of it manual handoffs. That map became the spine for every IA decision that followed.

Five stakeholders mapped end-to-end

I built journey maps for each role: third-party developer, internal group developer, central reviewer, brand admin, and global admin. The internal group developer path diverged in one telling way: submitting for Beta auto-approved, where a third party had to wait. Each map surfaced the open questions engineering hadn’t answered yet. "What is Generating Delta?" "Do five lifecycle stages need to match between the reviewer and the brand portal?" "When a brand approves, what state does the app move to in the other two portals?" "When a brand force-uninstalls, does the app disappear from cars?" These questions drove the design decisions that followed.

Example journey · The OEM brand admin, from portal access through approve, reject, delist and force-uninstall · Open questions logged inline

Key design decisions

• Kanban for state visibility: Excel-based tracking gave no shared view of pipeline state. A Kanban exposed bottlenecks per environment in one glance.
• Two Kanban views, one source of truth: Environment columns (Beta, Staging, Production) for brand admins; status sub-columns (In review, Submitted, Approved, Published, Generating Delta) for central reviewers. Different jobs, different lenses.
• Test report as a first-class object: QA results were buried in shared drives. Promoting them to their own tab with search, favourites, and per-app history removed Excel from the loop.
• Rejection reasons on the record: Rejections used to vanish into email. A timestamped evaluation history on each app, with the reason attached, meant a developer could see exactly why a build was turned down and who turned it down.
• Component system before screens: No Figma library existed. Building primitives first, a shared set of component groups, was the only way to iterate on three portals in nine months.
• Dark mode by default: Reviewers work long sessions, and reduced eye strain was a stated team ask. I built the token system dual-mode from day one.

Kanban concept · Environment toggle over status columns · The two-view decision, sketched before the hi-fi

On the in-car Store

In parallel, I contributed to the design of the in-car Store itself, the surface where drivers browse apps. I benchmarked Google Play for cars and the Apple App Store, then prototyped a low-fi concept screen. The portals exist to feed this surface, so understanding it shaped what the admin tools had to expose.

What I found, and the moves it drove

The findings came from two streams that ran the whole time: a structured audit of the existing portals, and the workshops and walkthroughs I ran with central reviewers and brand admins as the designs took shape. Each finding paired with a concrete move and the lifecycle state it touched.

One system behind every screen

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

What I delivered, and what it changed

• OEM Admin Portal hi-fi: Login, my apps, all releases, app detail, campaigns and the approval flow among the screens, in light and dark mode, fully composed from the component library.
• A dual-mode component library: Reused across all three portals. The first shared design system the Group App Store team had access to.
• IA and approval pipeline maps: One canonical diagram answering "where does this app go next?", adopted as the shared reference by every team touching the pipeline.
• Five end-to-end journey maps: One per stakeholder type, with open questions surfaced so product could close them.
• Audit findings and redesign moves: A working document mapping each usability problem to a specific redesign decision and lifecycle state.
• Atomic UX Research synthesis of legal and product findings: Consent, geo-blocking, payment, and update policy organised as design opportunities.

The approval pipeline ran about seven days end to end, most of it manual handoffs. The redesign gave every team shared visibility of pipeline state, removing those handoffs.

What I’d do differently

Find a way to talk to real users

The biggest gap in this work was that I never sat with a third-party developer, a central reviewer, or a brand admin while they tried to do their job. I told myself this was an access constraint, but in retrospect there were routes I could have negotiated: shadowing QA during test bench runs, a screen-share session with one developer team, even a remote walkthrough with a brand approver. I would push harder on that today, and I’d push earlier.

Push back on the five-stage lifecycle

I designed around Beta, Staging, Production, Deleted, and Delisted because that’s what engineering described as the existing pipeline. Looking back at my own journey maps, the open question "are five stages necessary?" sits on a sticky and is never resolved. A designer in a system this complex shouldn’t only render the existing model; the job is to challenge it. I rendered when I should have challenged.

Resolve the vocabulary, not just the screens

My audit caught the system using Delete, Revoke, Cancel Submission, and Delist almost interchangeably, four words for overlapping destructive actions, and a sticky note asking which meant what. I flagged the confusion but never delivered a resolved vocabulary the three portals could share. In a multi-stakeholder system, naming is interface: a content and state model that pinned each term to one action would have removed a whole class of user error. I’d treat that terminology as a deliverable next time, not a footnote.