Company
SAP
Timeline
6 months
Team
Designer, researcher, 3 PMs
Role
Lead Product Designer
Scope of work
Overview
Setting up rules took buyers months.
Business Rules decide what suppliers can send a buyer on SAP Business Network, like whether an invoice needs a tax ID or an order can be changed after it’s sent.
Opportunity
The product had stopped working as a self-serve tool
Across stakeholder meetings, consultant interviews, and journey mapping, the same thing kept coming up: consultants had built their own Excel templates because the product couldn’t guide buyers on its own.
Finding 01
Rules lived in four different places in the product
Default, country, group, and supplier rules each had their own entry point, some five levels deep.
Brought every rule type into one Settings page.
Finding 02
Moving to production was manual
Admins wrote settings down, logged out, and re-entered them in production. Nothing showed when the two drifted.
Made sync status visible and moved migration into the app.
Finding 03
Nobody could point to a rule
No IDs, no history, and no place to record why a rule was set.
Gave every rule an ID, a change history, and comments.
“Buyers struggle with seeing how all the rules work with each other.”
— Network Deployment Lead
The reframe
Is this a migration or a redesign?
The brief was to move the old screens onto SAP’s new UI framework. Mapping the system showed the real problem was structure: four rule types spread across three entry points, with no shared way to name, track, or explain a rule.
4
Rule types
3
Separate entry points
2
Data models underneath
How might we help buyer admins set up rules without consultant workshops?
Design statement
Solution
One place to find, set, and track every rule
I brought every rule type into one Settings page and gave each rule an ID, a status, and a history, so admins could set things up without a consultant in the room.
01 / Organization
Tabs by transaction type, and an ID on every rule
Rules are grouped under Orders, Invoices, Ship Notices, and more, and only rules for products the buyer owns are shown. Every rule has an ID, so a support call can start with “check INV060.”
02 / Production status
See what’s out of sync before it breaks
A color-coded status shows which rules don’t match between test and production. Admins move settings to production in the app instead of logging out and copying them by hand.
03 / Rule details
Keep the reason next to the rule
Selecting a rule opens its details beside the table, with comments and a full change history. The next admin can see who set it, when, and why.
Research
Starting with the people who set rules up
I ran stakeholder meetings with PMs and SAP services, interviewed Network Deployment Leads, and mapped the as-is journey for buyers, suppliers, and consultants.
Admins set rules once and forget why
Most buyers touch these rules once or twice a year, so the first-time experience matters most.
Consultants had built their own tools
Each consultant kept their own Excel version of the rules, and one estimated the shared template was only about 15% accurate.
Narrowing the scope
Deciding what had to ship first
The system covered four rule types, several teams, and two data models, so I split the work into modules. Default rules came first as the pattern every other rule type would follow.
Default rules
Rebuilt first, as the pattern every other rule type would follow.
Shipped
Supplier group rules
The rules admins change most. Pulled into the MVP after testing.
Added after testing
Test to production
Production status on every rule, plus migration inside the app.
Shipped
Active Buyers count
Showed how many buyers used each rule. Misleading without context.
Cut
Collaboration
Mapping the whole system with PM and engineering
I ran a workshop where PM, engineering, and design mapped every Business Rules screen on one journey. Each team tagged it with their own layer: technical constraints, status, and UI patterns.
It showed the scope was bigger than anyone had estimated, and led to two tracks: quick wins like navigation and labels, and a longer-term vision we added to the roadmap.
Testing
Putting it in front of admins and consultants
With our UX researcher, I tested the prototype with 5 participants, two buyer admins and three consultants across EMEA, the US, and LATAM. They walked through their current setup, then completed tasks in the prototype.
Insight 1
Active Buyers
A number without context misled people.
All three consultants called the count of buyers using each rule unhelpful at best and misleading at worst. They wanted to know which industries and countries those buyers were in.
What changed: We cut it from the MVP.
Insight 2
Editing
Each edit took three extra clicks.
Splitting the table from the details made editing one rule slower than the old single Save.
What changed: Clicking a rule now opens it for editing, and rules can be turned on or off from the table.
Insight 2
Moving to production
Migration felt high-risk.
Participants asked for safeguards before anything reached production, like a confirmation step and a record of each move.
What changed: Migration now has a confirmation step and logs every move in the audit trail.
Results
Shipped, and adopted beyond the original plan
Business Rules released in September 2025 and turned on for every buyer on SAP Business Network, with no opt-in.
Product teams that built their own rules on it
Place to set every rule type, down from 3
Support tickets about the new experience since launch
Month 1
Kickoff and research
Month 3
Workshop and usability testing
Month 6
Final designs
Sep 2025
Shipped to every buyer
Impact
For buyers
Setup moved into one self-serve page. After a demo, one large customer asked to move up their migration date.
For SAP services
Buyers can now set up rules on their own, which frees consultants from 5 to 8 hours of workshops per buyer to focus on the customer relationship.
For the platform
Eight teams reused the framework instead of building their own rule screens.
Rule setup went from months of consultant workshops to something buyer admins can do on their own.
Reflection
What I learned
Map the system before designing screens
The workshop showed the problem was structural. Redesigning screens one by one would have kept the same three entry points.
Set a baseline before shipping
No support tickets have come in about the new experience so far, but we never measured how many the old version got. Next time I’d agree on a baseline with PM before launch, so the drop is easy to show.
Plain language is part of the redesign
Many rule names still use legacy terms. A wording pass was cut to meet the deadline, and it’s the fastest remaining win for first-time admins.