Change Propagation

Designed the Change Propagation feature for Variant Management within SAP Signavio Process Manager, helping organisations keep process variants aligned with template changes.

I was brought over from my usual product space to lead the design work under a highly compressed timeline, shaping a feasible first release across unclear requirements, multiple product environments, and major technical constraints.

ROLE

Brought in from an adjacent domain to lead the design end to end

SCOPE

Variant Management, Hub flow, Editor handoff, history, and customer workshops

FOCUS

A feasible first release under major technical and time constraints

OUTCOME

Shipped a validated first release and clarified the long-term direction

01 / PROBLEM

Variant Management let organisations create process variants from an initial template, but once those variants diverged there was no reliable way to keep them aligned when the template changed.

That was a serious gap for enterprise customers managing regional or operational deviations. Template updates could range from minor text edits to structural model changes, and not every change should automatically apply to every variant.

At the same time, the feature had already been committed on an aggressive timeline, before the product concept, ownership model, technical feasibility, or interaction approach had been defined. The challenge was not just to design a new flow, but to define what “change propagation” could realistically mean inside a free-form modelling environment where automation was inherently limited.

02 / PROCESS

I started by quickly building context across the product space through Variant Management documentation, and discussions with product owners, developers, and domain experts. Because I had been brought in to establish direction quickly, the first priority was to turn a loosely defined user need into something concrete enough to discuss, design, and deliver. Unknowns were fundamental: where propagation should live, what should trigger it, who should own it, which changes could be automated, how they should be communicated, and accountability requirements.

With the scope still vague and the timeline extremely short, I moved almost immediately into early visual exploration. I created wireframes and interactive prototypes across several directions, from low-effort (manual handling) through to more ambitious (semi-automated) concepts. This made abstract discussions concrete and helped the team align quickly on trade-offs between customer value, UX quality, and technical feasibility.

I worked closely with developers throughout to keep the exploration grounded. For example, although the feature made more sense living in the Process Editor or Comparator, those codebases were too old and risky to change within the timeframe; the only viable home for the first release was the Hub, which forced a less natural but buildable user-flow.

In parallel, I co-led several full-day workshops with the pilot customer to validate the core flow, clarify priorities, and manage expectations. Once the direction stabilised, I moved into higher-fidelity design, refining the change-review flow, the split between automatic and manual changes, and a history view for accountability.

03 / SOLUTION

The final concept used a pull model: when template updates were published, variant owners were notified and could review them from a dedicated Change Propagation flow.

To reflect the real technical limits of the platform, changes were split into two categories. Automatic changes could be applied by the system, while manual changes required the variant owner to update the model in the Editor. In both cases, the user still had to make an explicit decision: apply, acknowledge for manual follow-up, or ignore where appropriate. This preserved control for variant owners while still supporting accountability.

The first release was delivered in the Hub as a micro-frontend, with the process diagram shown for context and the change list presented alongside it. Where manual work was required, the user was redirected into the Editor and then returned to continue the propagation flow. This was not the long-term ideal structure, but it was achievable within our technical constraints. I also designed a supporting History view to make decisions and activity visible over time for auditing.

04 / OUTCOME

A major part of the outcome was rebuilding confidence around the feature. Early customer discussions reflected pre-existing frustration and low trust, but the workshop process helped shift the relationship into a more positive, collaborative direction as it became clear that the core requirements were addressed and would land as expected.

We successfully delivered a workable first release of Change Propagation within a very compressed timeline. Customers could now be notified of template updates and track how those changes were handled across variants, which had not been possible before. It also clarified the real shape of the problem early, aligned stakeholders around a feasible first release, and made clear what stronger long-term support would require: tighter integration with the modelling environment and broader architectural groundwork, including staging, revision handling, and model data prepared for such functionality.

Prev.