Enterprise Demand Management
A governance workflow used by more than 45,000 people, redesigned so each role sees only the part of it they own.
A governance workflow,at company scale.
An internal enterprise platform for demand management. Someone raises a demand, the system routes it to the approver who owns that decision, and an approved demand becomes a service request in a downstream system.
More than 45,000 people used it, across seven roles, on Microsoft Power Apps, SharePoint and Power Automate.
I was the UX Lead, responsible for the experience end to end rather than a set of screens.
- UX strategy
- Information architecture
- Workflow analysis
- Interaction design
- UI design
- Prototyping
- Design reviews
- Employee validation
- Stakeholder and developer collaboration
45,000+ people.One experience for all of them.
A single demand could travel through seven hands before it closed.
Governance was not the thing to fix: every approval level existed for a reason. The structure was. One interface served every role, so the information architecture followed the system’s shape rather than anyone’s task, and each person had to work out which part was theirs.
- Requester
- System assignment
- Approver
- Decision
- ApproveSR initiator → External system
- Refer backReturns to requester
- RejectEnds
- ExceptionCU L2 → CU L3 → CU L4
Approve is one of four outcomes. Refer back returns the demand to the requester, reject closes it, and an exception climbs a three-level review ladder. Each path is a different screen for a different person: the whole design problem in one picture.
What that cost the people using it.
Relevance was the reader’s job
Before any task could start, people worked out which parts of the screen were theirs: cognitive load the interface handed back.
The decision was hard to find
Approvers hunted for their four actions among fields they never filled in. The task they came for was the least discoverable thing on screen.
The process had to be learned first
It made sense only once you knew the governance behind it. Recall did the work recognition should have, and new joiners started behind.
Every handoff was a place to wait
Demands passed through several people and levels, and someone had to track where each stood and when it was due.
The problem was not the interface’s complexity.It was the distance between the system’s structure and the person’s context.
Understand the system,then the people in it.
It started with the workflow and the people in it, not the screens.
Stakeholder and employee discussions
How each role moved a demand along in practice, and where it stalled.
Workflow analysis
The existing governance mapped end to end: every stage, branch, approval level and handoff. It became the map in section 02.
UX evaluation
A heuristic evaluation, walking the information architecture and core task flows for where cognitive load, discoverability and recall were doing the interface’s work.
Role-based analysis
Each of the seven roles described by responsibility, task, information need and action. It became the model every view was designed against.
Seven roles.One record between them.
Seven roles share the workflow and almost nothing else. Each was designed against the same model: role, responsibility, task, information need, action.
| Role | Responsibility | Task | Information need | Action |
|---|---|---|---|---|
| Requester | Raises the demand | Get a demand approved and know where it stands | Status, current stage, anything referred back | Raise · Track · Respond |
| Approver | Owns the decision | Decide on a demand within its SLA | The record, its history, the SLA clock | Approve · Refer back · Reject · Exception |
| Admin | Keeps the workflow moving | Clear stalled demands and keep queues healthy | Queue health, escalations, configuration | Reassign · Override · Configure |
| SR Initiator | Turns approval into execution | Raise the service request downstream | The approved demand and the fields the request needs | Raise service request |
| CU L2 | First exception review | Review an exception raised at decision | The demand and the reason for the exception | Review · Escalate |
| CU L3 | Second exception review | Review an exception escalated from L2 | The demand, the exception, and the L2 review | Review · Escalate |
| CU L4 | Final exception decision | Close the exception ladder | The full exception history | Final decision |
The same experience was trying to serve everyone.
- Every role landed on the same navigation and record, with every field at every stage.
- The information architecture mirrored the system’s modules, not anyone’s task.
- A role-based experience: the role sets the navigation; the record shows what the current stage needs.
- The four decision actions sat among form fields, below information the approver never used.
- The record was built as a form to fill in, when for most roles it was a decision to make.
- Design the decision: actions, context and history together, beside the record.
- Moving a demand on meant already knowing who held it next, and when it was due.
- The workflow state lived in people’s heads, so routing and deadlines ran on recall.
- Let the system carry the process: workflow state visible on the record, automation owning assignment, reminders and SLA.
The system knew what role you had.The experience should too.
One workflow.A view for every role.
The platform was fixed, and so was the governance. The design worked inside each layer: role-based views built in Power Apps from one shared component set; records in SharePoint that keep every field while the interface shows what the current workflow state needs; and Power Automate flows for assignment, reminders, SLA and escalation, with the experience deciding which a person sees, and when.
- One navigation for all seven roles
- Every field, at every stage
- Decision actions among the form fields
- Navigation set by the role
- Fields for the current stage
- The decision beside the record
Reconstructions of the structure, not screens from the product. The real role views follow.
From the demo built for this case study, with sample data.
Sees what they need.
Raise a demand and see where it sits. Nothing about approval mechanics they will never touch.
Sees what they need to decide.
The four actions grouped around the decision itself, with the record and its history beside them.
Sees what they need to manage.
The override path for when a demand stalls where it shouldn’t.
Sees what they need to execute.
Only what the service request downstream needs. Nothing upstream.
Same product. Same governance. Different context.
Designing the decision,not the form.
Context
The form surfaces the information relevant to the current stage, not all thirty fields at once.
Decision
Approval actions are grouped around the decision the user actually has to make.
History
Previous actions stay visible instead of disappearing into the workflow.
Validation
Anything that blocks the next action is surfaced before the user commits to it.
Auto assignment
Notifications
Reminders
SLA tracking
Reassignment
Exception workflow
Auto-rejection
I designed the experience around the automation: what it should surface, when it should interrupt, and what it should never ask a person to remember. The flows themselves were built in Power Automate by the engineering team.
Underneath the screens is one design system: brand colour, tokens, type and components defined once, then reused by every role’s view and every state a demand can be in.
Review. Test. Refine.
Internal UX reviews
Role views and decision screens were reviewed by the UX team as they were designed, before anything went to employees.
Prototype testing with employees
Prototypes were tested with employees working through their own tasks, in their own role.
Design iteration
What surfaced in reviews and testing went into the next version of the design, in phases.
Every round came back to the same three questions: what does this role need to see, what decision is being made here, and what should the system remember so that nobody has to.
Scale unchanged.Experience rebuilt.
For the people using it
Each role opens the product on its own work, sees where a demand stands, and decides beside the record it belongs to.
In the product
Seven role-based views over one workflow, one component system, and an automation layer that owns the routing, the reminders and the SLA clock.
Assessed
The business vertical’s own team assessed the redesigned experience with new joiners: the people the old one asked to learn the process first.
From a shared enterprise portal to an experience that understands who is using it.
What this one taught me.
Enterprise software rarely fails because it cannot do enough.It fails when it leaves every person to work out which part of it is theirs.