Cross Team Alignment

Global Bulk Actions Alignment

8 modules. 8 inconsistent patterns. One standard, adopted by 3 engineering teams without a single follow-up.

My Role

Sole Designer · Self-initiated scope

Scope

Design Systems · Cross-team Alignment · Documentation

Teams Involved

3 Engineering Teams · 3 PMs · Design Leads

Outcome

8+ modules unified · 0 design involvement for subsequent alignments

Before & After of bulk action inconsistencies

The Problem

8 modules. 8 ways to do the same thing.

Bulk actions had been built independently across every module in the Ignite CMS. Same core action, select multiple items, perform an operation, but every module handled it differently. Different trigger points. Different confirmation patterns. Different feedback states.

Nothing was broken. But nothing was predictable either. For clients working across modules daily, it was persistent low-level friction, the kind that accumulates silently and erodes trust in a product without anyone filing a ticket about it.

The Critical Detail

This problem wasn't on anyone's roadmap. No PM had scoped it. No ticket existed for it. I identified it, scoped it, and drove alignment entirely off my own initiative, while maintaining my regular IC design responsibilities.

Audit snapshot - gaps colour-coded by type: missing (red), partial update needed (amber)

The heuristic evaluation covered Copy consistency, UI pattern consistency, and Interaction design consistency across all 8+ modules. Every gap was categorised by type and severity, not just flagged as "broken", so engineering teams could understand what each fix actually required without returning to design.

THE RESEARCH - HEURISTIC EVALUATION

Before designing anything, I needed to know what I was actually dealing with.

The brief was narrow: fix bulk actions for one module. But the brief had no visibility into how far the inconsistency actually ran. Before touching a single design file, I conducted a heuristic evaluation across 8+ modules, mapping every bulk action surface against four dimensions: listing page, selection pattern, validation modal, and feedback state.

The evaluation surfaced something the brief couldn't have anticipated: 6 modules with fundamentally different interaction patterns for the same user action. Not minor variations , completely different trigger points, confirmation approaches, and feedback behaviours across the same platform.

Global Schedule - Brief vs. What Was Discovered - Scope Expansion Diagram

Key Finding

8 modules. 6 different interaction patterns for the same action. The heuristic evaluation changed the scope from fixing one module to establishing a standard for all of them. Without this step first, the solution would have been a local patch, not a system.

Heuristic evaluation - modules mapped against interaction dimensions

The Approach

Heuristic evaluation first. Solution second.

The tempting move was to design the "correct" bulk actions pattern upfront and retrofit it across all modules. I'd seen that approach fail before: when you start with the answer, you miss the edge cases that existing implementations were actually solving for, quirks that look like inconsistency but are in fact intentional responses to module-specific constraints.

So the heuristic evaluation came first. Every module was mapped against four dimensions before a single new pattern was proposed.

Map the current state, without judgment

Document what each module does today across listing page, selection pattern, validation modal, and feedback state. No immediate design decisions. The goal at this stage is truth, not solution.

Identify gaps vs. intentional differences

Some inconsistencies are genuine gaps, features that simply weren't built yet. Others reflect module-specific constraints that a universal standard needs to accommodate. Treating all inconsistency as error produces a standard that breaks edge cases.

Design the standard with rationale, not just specs

Every pattern decision in the documentation included the why, not just what the correct pattern was, but why that pattern was chosen over alternatives. Teams that understand the reasoning can handle edge cases themselves, without returning to design.

Pair implementation effort with each change

Each proposed change in the documentation was accompanied by an engineering effort estimate. This reframed alignment sessions from "do you approve this?" to "how do we prioritise this?", a critical shift that made adoption realistic, not just theoretical.

Before & After: consistent modal structure, selection footer, and toast feedback - standardised across all modules

The Alignment Move

All three teams in the same room. No sequential briefings.

Presenting alignment work to teams sequentially is how alignment dies. Each team hears a slightly different version. Questions get answered differently. And you end up with three teams who've each agreed to something marginally different, and no single source of truth.

Instead: one simultaneous cross-team session. All PMs, all design leads, and all engineering leads in the same room at the same time. The agenda was structured module-by-module: current state of each module vs. proposed standard, with implementation effort estimates visible for every change.

"It shifted the conversation from 'will you approve this?' to 'how do we prioritise this?' "

The framing mattered as much as the content. By showing implementation effort alongside each proposed change, the session stopped being a design review and became a prioritisation workshop. Teams weren't being asked to sign off on aesthetics, they were being asked to allocate engineering capacity in a way they could all see and agree on simultaneously.

Why simultaneous

One version of the truth

Sequential briefings introduce drift. Each team's understanding of the agreed standard diverges slightly from the last, and those small divergences compound into real implementation inconsistencies. One session, one room, eliminates drift at the source.

Why effort estimates

Approval → prioritisation

When engineering effort is invisible in a design review, engineers say yes in principle but no in practice, the work never gets scheduled. Making effort visible changes the conversation. Teams can negotiate scope, not just approve it.

The tracking sheet used in the cross-team session - current state, proposed standard, effort estimate, and status per module

The Documentation Standard

Documentation that runs without the designer.

Most design documentation describes what a pattern looks like. This documentation described why each decision was made, what alternatives were considered, what constraints were being solved for, and what to do when a new module doesn't fit the standard pattern cleanly.

The proof that it worked: a PM I had never worked with used the bulk actions documentation to brief the Event Manager engineering team, without contacting me. They didn't need clarification. They didn't need a walkthrough. The documentation was self-sufficient.

The moment that confirmed it worked

A PM I hadn't worked with used the bulk actions documentation to brief the Event Manager team, without looping me in. No questions. No follow-up. The documentation had replaced the designer as the source of truth.

That outcome is the highest bar for alignment work: when the standard is adopted not because the designer is in the room, but because the documentation is clear enough to stand alone. The goal of design system work isn't to be consulted indefinitely, it's to make yourself unnecessary for the decisions the documentation can already answer.

The Result

The documentation ran itself.

All three teams adopted the standard. 8+ modules brought to a single consistent pattern. Zero design involvement required for subsequent module alignments after the standard was set.

The core insight: imagination is a tax on the user. Any interface that requires you to imagine the outcome is harder to use than one that shows it to you. WYSIWYG removes that tax entirely. Clients see the fan-facing output update in real time as they configure, no gap between input and result.

8+

Modules brought to a single consistent bulk actions standard across the product

3

Engineering teams coordinated in a single alignment session, no sequential briefings

3

Teams now using the bulk actions documentation as a self-sufficient reference standard

0

Design involvement required for subsequent module alignments after the standard was set

Zero design involvement is the metric that matters most here. Not because the work was finished, but because a standard that requires the designer to be consulted for every new case isn't a standard — it's a dependency. The goal was to make the documentation comprehensive enough that teams could apply the standard independently. The PM briefing the Event Manager team without reaching out was proof that goal was achieved.

The changes tracking spreadsheet - visible to all teams, live-updated during and after the alignment session