Setting a quality bar for design teams: Craft excellence standards

Lead Product Designer. I created the craft excellence standards framework for the administration design organisation — articulating the quality bar and structuring how it mapped to critique stages. The framework drew on existing Atlassian design principles (authored by others), accessibility guidance (maintained by the accessibility team), and design system standards, alongside original content I wrote specifically for admin contexts. My role was synthesis, articulation, and operationalisation — creating the connective tissue between existing standards and a usable framework that designers could apply in practice.

Atlassian's design organisation was scaling, and craft quality wasn't keeping pace. Designers across 30+ teams were shipping work at inconsistent quality levels, but nobody had articulated what "good" actually meant. The head of design was raising concerns. Leaders were seeing work at higher-level reviews that didn't meet expectations, but the feedback was reactive — things would get torn apart late in the process rather than guided early.

There were two root causes. First, the quality bar wasn't written down. There was no shared definition of what a design needed to satisfy before it could ship. Second, there were organisational forces at play — some designers were under pressure from cross-functional peers to deliver at speeds where certain craft standards were impossible to meet. Leaders expected quality, but the conditions on the ground weren't always conducive to it.

I created a series of craft excellence standards — statements organised into two clusters: conceptual quality and executional quality.

Conceptual quality statements addressed whether the design direction was grounded in the right thinking. Does the design express our design principles? Is the direction informed by our customer's world? Has the designer utilised research — desk research, user testing, firmographic data? Each statement could be evaluated as true or false, and each expanded into guidance on how to meet it, with examples of what meeting and not meeting the standard looked like.

Executional quality statements addressed whether the design was built correctly. Must be accessible — linking to the accessibility team's guidelines. Must be designed for scale — I wrote a supplementary designing-for-scale checklist covering data set sizes, language translation testing, pagination strategies for unbound lists, and methods for stress-testing at enterprise volumes. Must conform to the design system — both the central Atlassian system and the domain-specific admin system I'd established.

These standards mapped onto a 30/60/90 framework — a widely adopted design critique structure (originating from Jason Freedman's "30 percent feedback" philosophy and common across design organisations) — that my manager and I implemented across the teams. The idea was that at 30%, you're still in conceptual territory — the first cluster of statements applies. At 60%, you're transitioning from concept to execution. At 90%, it's all executional. This gave critique sessions a shared language: a designer would declare what stage they were at, and reviewers knew which statements to evaluate against.

I built Figma critique context cards so designers could drop a card into their file specifying their stage, and the relevant standards were right there. The standards became embedded in the weekly critique ritual.

Adoption was stratified. Some designers — particularly juniors — valued the clarity and used the standards to self-assess before critique. Others disengaged. The real challenge came from teams where engineering partners had more organisational leverage and were pressuring designers to skip process steps in favour of speed.

One team in particular operated under conditions where designers felt subservient to engineering timelines. Their work would routinely arrive at higher-level reviews in poor shape. When I worked with their designers directly, the pushback I heard was "your process is too heavy." When I asked which parts they wanted to skip, they couldn't articulate it — because the statements aren't skippable. You can't opt out of accessibility. You can't skip designing for scale in an enterprise product.

The resolution required escalation. I articulated to leadership that cross-functional peers needed to understand the quality bar, and that enforcing it at the design layer alone wasn't sufficient. I ran retrospectives with affected teams, synthesised findings, and presented them upward — a pattern I continued throughout my time in this role. The argument was straightforward: catching quality problems at the 11th hour is more expensive than building them right in the first place.

The standards became the rubric for design critique across the administration design organisation. They gave leaders a framework for evaluating work consistently, gave designers clarity on what was expected, and surfaced the organisational friction that was undermining quality — which was arguably more valuable than the standards document itself.