Image Overview

A summary of the new approval experience in Hub, with workflow selection and participant assignment brought into the approval submission flow instead of relying on hidden document-specific setup.

The earlier approval submission experience from inside the Editor. Users had to start a workflow separately from the document context and without clear connection to the required participant configuration.

Exploration of a workflow-template approach, to address feedback about the complexity of configuring a new workflow. Approval workflows define their own participants and applicability, helping shift governance setup from multiple disconnected touchpoints toward a signle workflow-centred foundation.

Workflow-trigger explorations showing how participants could be defined as part of the workflow itself, with different data sources depending on the submitted object and governance context.

Evolution of the approval modal from legacy submission to a simplified Hub-based flow, gradually adding workflow context, participant visibility, and direct assignment within the same action.

A refined participant-configuration screen for diagram approval workflows, mapping required roles to document data sources in a clearer, convenient setup model. Some design comporomise on location due to technical limitations, though positioned for a simple future migration to the "Trigger" tab.

A overview of highlighted artefacts from this project: Call-to-action, notifications, the review panel, and history tracking for accountability/reporting.

A flow diagram mapping the "pull" model from template update through variant-owner notification, review, acceptance or rejection, and new revision creation.

Concepts comparing where the experience could live across a separate dedicated app, Process Hub, Process Editor, Variant Management, or Comparator tool. The Editor was the preferred environment, but technical limitations forced us to focus on the Hub for the initial delivery.

A lineup of review-panel concepts exploring automatic and manual change handling, and effective communcation.

An end-to-end prototype flow showing how a variant owner is notified, reviews automatic and manual changes, moves into the editor, saves, and verifies completion. This was also built as an interactive prototype.

A Hub-based solution key-screen flow showing the notification banner, change review panel, representation of applied changes visible on the diagram, and history view for accountability and reporting via an export option.

A small excerpt from the project file, focusing on layout wireframes, brief feature explorations to discuss with the team, and focused prototypes for alignment. I was able to collect feedback here from internal experts and customer representatives, which would be used to inform subsequent design iterations.

Exploration notes and wireframes around the core challenge of combining individual users and groups while preserving accurate confirmation tracking, and respecting privacy restrictions.

A progression of recipient-selection concepts, showing how the request creation flow evolved from basic entry to separate user and group handling.

Comparison and progression from Lo-fi to Hi-fi mockups for the request progress monitoring stage. Process Owners can conveniently track the read status for any individually included users, with the ability to export a more detailed report for auditing purposes.

Interactive prototype flow, covering creation of confirmation requests, supporting either users or groups. Includes selection, presentation, and confirmation before changing list type.

The published process view with a confirmation callout and action, keeping the Consumer experience visible, direct, and low friction.

Overview of highlights from this project, contrasting the older Process Governance interface with the modernised direction, showing how navigation, task views, form controls, and page structure were approached.

The legacy workflows overview, with side filters, table rows, labels, and actions illustrating accumulated UX debt across core list/table and filtering patterns.

Research and synthesis artefacts mapping customer feedback, recurring problem areas, and improvement themes across the product, helping turn scattered UX issues into a focused modernisation strategy. I consolidated disparate feedback items, and collaborated with Product and stakeholders (including customer representatives) to arrive at a prioritised list; particularly grouping related items which could be potentially addressed together.

Filter standardisation explorations comparing the old sidebar-heavy approach with a more compact, reusable filtering model for tasks, processes, and document views. Addresses user complaints about limited horizontal space for the table, while also bringing filtering into alignment with existing suite patterns.

Overview of the Workflows index before-and-after exploration, showing the shift from a large filter sidebar and inconsistent table styling toward a cleaner, design-system-aligned list experience.

A high-fidelity modernised task view with clearer hierarchy, sidebar navigation, task metadata, a cleaner, more focused form area, and a standardised side-panel for "core information".

A high-fidelity modernised workflow Editor aligning the canvas, toolbar, action configuration panel, labels, and page actions with the wider suite patterns and design direction (which I also helped to codify collaboratively as part of this project).

A compact collection of design system inconsistency, existing contemporaneously in the product suite, illustrating the need for design system adoption and centralisation of recurring components/patterns. This was used both for communicating the problem with stakeholders, as well as auditing existing use-cases to inform the new designs.

Another compilation of inconsistency examples, this time focused on tables. This was used partly in communicating the problem visually with stakeholders, and partly within a wider collection of table use-cases to inform the unified Table component design.

A demonstration of the new, unified Table component, mapped to existing use-cases of local table solutions (in this case, all within Process Governance).

Direct comparison between the status quo Glucose components, and the incoming SAP Fiori design system components and guidelines (via the "re-skin" project).

An excerpt from the Figma design library, illustrating the component variants for the Tag component, as well as some example popover configurations for the Chip component. I built all these components myself, along with the majority of the SAP Signavio design library components. In the case of Tags and Chips, I also designed them and intitated the topic to include these components into the design system, supporting it through delivery.

A design system comparison showcase focused on form-related elements. I built everything here, and designed most of it (with consideration for conformance to existing reference points, such as SAP Fiori).

In this case I only built and structured the modal components in Figma, across both visual styles, but was adapating existing designs. The structure was modular to reduce variant complexity, while retaining flexibility for designers to customise elements without needing to detach it. I built the whole design system component library following this philosophy, usually based around a single layout component to centralise updates. This approached proved very useful when we eventually needed to change the visual style of the whole system.

The legacy participant-configuration model, where approval roles had to be mapped to custom diagram attributes before they could be used in a workflow.

Research and journey-mapping artefacts tracing the end-to-end governance configuration, submission and approval flows, surfacing dependencies and flow-gaps between products, attributes, workflows, approval submission, and follow-up cases.

Concepts for configuring approval workflows at organisation level, comparing approaches for mapping required participants to attributes or user-configurable sources across document types.

Exploration of participant mapping directly on the workflow model, testing how notation-specific participants and reusable workflow roles could fit into the editor experience.

A prototype diagram-flow showing approval initiation from the document context through workflow selection, participant assignment, submission, and the resulting in-progress approval state.

The final approval submission solution based in the Hub, dynamically revealing required participant assignments after workflow selection so users can complete/manage the request in one interface, and one focused flow.

A diagram of the core problem, showing how a template update can leave an existing variant process missing changes and out of sync with its origin.

An early review-changes concept, snapshot from the working files, including technical questions, design notes, limitations, and feedback, showing how feasibility and technical (or flow-related) questions impacted the design direction. Since this project was outside my usual domain, there were many open questions I surfaced at the start, to quickly narrow down a design path compatible with our strict time constraints.

A rough key-screen prototype sequence testing an editor-based environment for reviewing changes, applying manual updates, saving a revision, and resolving propagation work. Used to communicate the concept visually with developers and stakeholders while discussing our options.

Handover panel designs for reviewing changes and auditing history. Also included: a 'vision' proposal exploring future extension of the new history panel into a suite applicable pattern for document activity.

A high-fidelity mock-up of the Hub review panel showing automatic changes (visible) and manual changes (not visible), within the process context in the Hub.

A overview of highlighted design atrefacts from this project: Request configuration, call-to-action banner for acknowledgement, and progress monitoring.

Another except from the project file, this time a cleaner, almost final, design proposal. It documents the current, mature state of the design proposal. It includes an interactive prototype for the core user-flow, designs for anticipated states, and some notes on still-open issues in need of clarification or decision.

A comparison of modal variants used to test list structure, list-type switching, status visibility, and save behaviour across the configuration flow. Feedback was gathered from designers across the suite, and from customer represenatitves.

Comparison of Lo-fi to Hi-fi mockups for the request creation stage. Process Owners can select recipients directly from the Hub environment, without entering a heavyweight workflow.

Comparison of Lo-fi to Hi-fi mockups for the Process Consumer experience, comprised of a low-friction confirmation prompt embedded directly above the published process content. This approach avoids any need to bounce from the persona's usual Hub environment to a 'task' in the less-familiar Process Governance app.

A final configuration modal integrated into Process Collaboration Hub, showing recipient selection and request setup in the context of a published process.

The monitoring experience (in this case, after confirmation), showing progress/status, dates, export access, and the path back into configuration.

The legacy task view, showing dated navigation, inconsistent structure, unaligned with the suite design system, and interaction patterns that made everyday task work feel cognitively heavy.

The workflow editor, showing the existing task configuration model and visual structure before design-system alignment and layout modernisation for improved consistency with suite conventions.

Table standardisation work comparing old and new patterns across tasks, cases, workflows, and analytics, aiming to initially illustrate the inconsistency in experience for users. I designed a unified table component in close communication with the Design Systems team, ensuring that while the Process Governance team would build it, it would be designed for applicability across all suite use-cases and products.

Task view before-and-after exploration, showing how the mature task experience could be simplified with clearer navigation, improved metadata, cleaner forms, a more focused layout, and without investing in a heavy overhaul of the user-flows or functionality.

Workflow Editor before-and-after exploration, showing how page structure, toolbar placement, tabs, form panels, and workflow canvas controls were able to be modernised and brought into alignment with suite patterns without changing the underlying interaction model or functionality.

A high-fidelity modernised workflows overview using compact filters, standardised table component, filter chips, and clearer primary actions.

Overview of design highlights from this project, comparing some differences between the earlier Glucose design system, and the incoming Fiori design system.

Form element examples of inconsistent interface patterns and product-specific solutions that made a stronger shared system necessary.

A token and theming artefact showing how Glucose Figma components were adjusted and mapped to support future SAP alignment. I built most of the Glucose components and variants myself to support the design team in moving from Sketch to Figma, and collaborated on the re-skin project and SAP Fiori adoption strategy.

An example of design handover documentation and behaviour guidance produced for delivery of the form elements/inputs.

Another example excerpt from the design handover documentation, this time for the Tag & Chip components.

A comparison of input components, between the Glucose version, and the re-skinned Fiori version. This approach allowed us to adopt Fiori proper incrementally, with the temporary discrepancy disguised by visually matching the two systems. I built all of these components and variants myself, and collaborated with the Design Systems team for the re-skin project.

An excerpt from my design handover documentation for form inputs and form groups.