FY2026 planning cycle
BOARD · SUEZ> ENTERPRISE PRODUCT DESIGN
Enterprise Planning
A shared task model for a €1.2B budget cycle.
The decisionI made each task carry its owner, current state and next handoff.
[ PROJECT SCALE ]
One FY2026 planning cycle across a distributed finance organisation.
Working across the cycle
Contributing plans and approvals
National, regional and agency
[01.00]>The problemPeople could find the numbers.
People could find the numbers.
They could not see what should happen next.
Work moved across teams, but its status and dependencies did not travel with it.
Finance leads, regional controllers and agency teams entered the same annual plan at different stages. The product held the forms, figures and approvals, while the connections between them were hard to read: what had changed, who owned the next step and what was blocked.
The design question became: how could someone understand their place in the cycle without asking another person to reconstruct it?
[01.01]>BeforeEach destination made sense on its own.
Each destination made sense on its own.
The handoffs between them were hard to follow.
[01.02]>Map the work
Mapping the cycle exposed where ownership changed hands.
I mapped four planning phases across the National Finance Lead, CAPEX Planning Owner and Finance PMO. The artefact shows who starts, reviews and receives each piece of work.
That view clarified the product need: keep the full cycle available as context, while giving each person a clear task, current state and next handoff.
How might the interface keep the work connected as it moves between people?
Cleaner navigation and more consistent screens.
Status, ownership and dependencies were separated.
Make the next action clear at each handoff.
The product asked people
to carry four answers in memory.
I used these four questions to judge whether a screen gave someone enough context to act.
Progress
Where am I, and what is complete?
Ownership
Who approves this? Who owns next?
Dependencies
What is blocking me?
Next steps
What should I do now?
[02.00]>Set the rules
I turned those questions into three product rules.
Each rule gives the interface a consistent answer about progress, priority or what happens after a task.
Where am I?
PRODUCT RULEKeep workflow state persistent
The cycle remains visible when a person moves between screens.
What is waiting on me?
PRODUCT RULERank work by consequence
Priority reflects the people and steps an action is blocking.
What happens next?
PRODUCT RULETreat dependencies as product data
Every approval makes its next owner and outcome explicit.
[02.01]>The central decision
The task became the point where the cycle connects.
I treated a task as more than a unit of work. It links the person acting now to the person or phase that follows.
That let the screens share a clear pattern: show the current state, name the owner and explain what this step enables next.
How the task pattern works01 02 03
Orient
Show the work that needs attention.
Coordinate
Keep the owner and dependency in view.
Hand off
Make the next step explicit.
[02.02]>From model to screen
The screens follow one person from context to handoff.
The guide moves from role selection to Home, then into the cycle, task detail and completion. Each screen answers a question from the workflow map.
[02.03]>The flow in motion
One task moves from role selection to an approved handoff.
The coded prototype follows one CAPEX submission from role selection through Home and task detail to Finance PMO review.
[02.04]>The decision at task level
A task's status gains meaning through what it blocks.
The This task blocks panel connects CAPEX Planning to Allocation Validation, Budget Consolidation and Regional Approval. It shows why this submission matters beyond its own status.
[02.05]>Participant tests
Could people see what to do next, and why it mattered?
Eight participants across three finance roles completed moderated prototype scenarios covering orientation, blockers and approval handoffs.
Moderated prototype tests · directional evidence, not post-launch product analytics.
[03.00]>The designed outcome
One task model connects the cycle from entry to approval.
One shared lifecycle
The task keeps its status visible as it moves between roles.
Named handoffs
Each step shows who acts next and what the task depends on.
Rules teams can review
Interaction decisions connect the workflow map to the coded prototype.
The implemented flow brings those rules into the screens, so each handoff carries context into the next role.
[03.01]>What stayed
See how this principle evolved in TAP Design System ↗The workflow rules connect to a wider design system.
The project links roles, states and dependencies to a reusable knowledge base. The related TAP Mindset work shows the design-system layer behind those rules.
What shipped, and what still needs measurement.
A shared task model for roles, status and dependencies.
The screens carry context from a role-based Home through task review.
The task flow moved into the SUEZ product.
The work shown here covers role-based Home, workflow list, task detail, review and approval.
Impact after implementation.
This case study does not include comparable live data for task completion, approval time or unresolved handoffs.
Enterprise software becomes useful when it makes the work between people visible.
> MORE WORK