Case study · SAP Business Network

A shared studio for building SAP screens with AI

Designers on our team were prototyping SAP screens with AI, but everyone set it up differently and the results rarely looked like SAP.

UI5 Starter is one shared studio for that work: describe a screen, get real SAPUI5 controls back, and share it through GitHub. I designed and built it in a month.

Bento overview of the studio: UI5 Feedback, Web UI Kit controls, the SAPUI5 library, the Joule panel, Design explorations, Compare mode, the Learning hub, one-step setup and updates, sharing a link, and presenting cleanly — Fig. 1 · What's in the studio as of Version 3.

Role

Product designer and builder, design and code

Timeline

1 month · 3 releases

Team

Solo, with feedback from the SBN design team

Tools

SAPUI5, SAP Web UI Kit, UI5 and Figma MCP, Claude Code, GitHub

Context

SAP Business Network · internal design tooling

03 · AT A GLANCE

Three releases in a month, each one simpler.

Process

8 → 4

steps in the core workflow

Home

19 → 0

git commands on the first screen

Variations

6 → 2

fields to start a variation

Each number is counted from the code at that release, not from a survey. Steps are the workflow a new designer has to learn: set up, branch and review, update, and share.

04 · SAME PROMPT, DIFFERENT SCREENS

Everyone was vibe-coding, just not the same way.

Vibe-coding means building a screen by describing it to an AI assistant instead of drawing it.

The same prompt given to three designers produces three different purchase-order screens: a playful pink one, a generic gray table, and one that is almost SAP — Fig. 2 · Each setup was a little different, so each screen was too.

A few designers were already using AI to mock up SAP screens, each with their own setup. That caused three problems:

Every session started from scratch, with different prompts and reference files.
The assistant guessed at controls it didn't know, so screens looked close to SAP but never matched.
Work lived on one laptop, with no easy way to share it or stay current.

How might every designer vibe-code on the same design system? — Fig. 3 · The question behind the project.

05 · TWO COMMANDS, THE WHOLE SYSTEM

I put the design system into the starter itself.

A terminal running npm run setup installs the SAPUI5 library, UI5 and Figma MCP, approved skills, rules, and UI5 Feedback, then npm run start opens the Learning hub in an SAP shell. Below, the GitHub flow: branch, review, stay current, share — Fig. 4 · Setup installs the system, then the work moves through GitHub.

Before, every designer wired up prompts, tools, and references by hand. Now it takes two commands:

npm run setup installs the library, MCP servers, skills, and rules.
npm run start opens the studio inside an SAP shell.

From there, the work moves through GitHub: branch and review, update, and share.

06 · A REAL SAP SHELL TO DESIGN IN

Designers work inside the product, not on a blank canvas.

The Learning hub with three callouts: product navigation, design tools pinned to the sidebar footer, and the Hide design tools control — Fig. 5 · Product menu up top, design tools below, and a switch to hide them for reviews.

Every new screen opens inside a sample SAP Business Network shell, so designers work in context. Design explorations turns each page into a tile where you can save variations and compare two side by side. Every variation is a real UI5 view, so the one the team picks is already working code, not a mockup someone has to rebuild.

Design explorations page with page, person, and team filters above a Starter template tile with three variations — Fig. 6 · Design explorations, from page tiles to side-by-side compare.

Starter template page with a workbench bar showing V1 Workflow steps, a Current status, New variation, and Compare — Fig. 6 · Design explorations, from page tiles to side-by-side compare.

Most of the craft was taking things out. I showed each release at design share-outs and cut whatever tripped the team up. The Feedback panel, where designers click part of a page and tell their assistant what to change, lost a priority picker nobody could choose from, then everything else until it was two steps and one Save.

The Feedback panel at Version 1, Version 2, and Version 3 with sticky notes crossing out the separate server, the priority picker, and the second primary button — Fig. 7 · The Feedback panel lost a server, a picker, and a button.

Saving took five tries, from Save and Save as buttons to a six-field dialog. What finally stuck was a New variation button in the title bar that only asks for a name.

Version 1 · 6 fieldsVersion 2 · 1 field

Fig. 8 · Drag to compare the New variation dialog before and after. Both sides work.

07 · FROM SETUP TO ONE BUTTON

New designers start by making something, not reading setup.

Version 1 home with a workspace-ready banner and a three-step workflow — Fig. 9 · The home screen across three releases.

Version 2 home with the workflow and five sections of git commands — Fig. 9 · The home screen across three releases.

Version 2 put 19 git commands in front of you before you had made anything. In Version 3 they moved into a short guide, and the home screen just asks you to create a page.

“This is exactly what our team needs to build out our designs.”
Designer, early tester

08 · LOOKING BACK

Designers didn't need more tools, just the right ones loaded by default.

Version 2 tried to show everything at once, and in share-outs the multi-step setup was what confused people most. The system works best when it simply loads with the template and nobody has to think about it.

If I started again, I would:

Begin from the template instead of a blank chat.
Design in the running app instead of static mockups.
Run share-outs earlier and more often, and let that feedback drive the agent directly.

Now in testing

8–10

designers and PMs across the company are using the studio now

What I'm watching

Do their screens stay consistent?
Where do people still get stuck?
What do PMs build on their own?

More adventures in design

Case study

Orbit

See why the plan breaks. Then choose the fix.

Case study

GG Spill

Built in six hours, read by 11,000 neighbors.