Attempt A
Sync Visual QA
- Live screen-share: implementation ↔ Figma
- High visual integrity within one feature story
- Related fixes could ship together
- Interrupted developer deep work
- Design-system fixes competed with higher-priority engineering work
Visual QA without the ticket war
How we redesigned remote Visual QA — not as a checklist, but as a negotiation system between design, QA, engineering, and product.
Role
Senior Designer · process owner
Context
Vodafone · remote · design system
Partners
Design · QA · Eng · PO
Outcome
Hybrid QA pipeline adopted
Situation
«Done» in Jira was not the same as looking like the design.
On a remote product team, Visual QA couldn't mean sitting next to a developer. Design-system consistency across markets mattered — but quality depended on who cared that week. We needed a process that protected product integrity without burning design capacity or developer flow.
"This wasn't a Figma problem. It was a negotiation problem."
Two experiments
Both extremes were half-right.
We tried two approaches. Each solved one side of the conflict and broke the other.
Attempt B
Async ticket factory
- Fit engineering's async culture
- Made work batchable and prioritizable
- Design spent too much time writing tickets
- "Small" consistency fixes lost priority
- Related visual fixes became fragmented
Sync Visual QA
Live screen-share: high integrity per feature, but broke developer deep work and couldn’t scale beyond one story.
Async ticket factory
Fit eng culture, but design drowned writing tickets. Priority killed consistency fixes. Surface integrity fragmented.
Keep what worked. Gate what’s expensive.
- QA absorbs coarse visual bugs via existing ticket habit
- Short designer–QA sync replaces long dev sessions
- AI drafts residual tickets — designers own severity
- Live dev QA becomes PO-gated premium mode
Two extremes. One hybrid that kept the best of each.
Hidden actor
QA engineers already ran functional testing — and often caught coarse visual bugs through the same ticket workflow. Developers trusted that stream. Rather than adding another parallel review ritual, we could build on an existing habit.
The conflict
Three valid goals. Zero pure winners.
Design wanted coherent surfaces and design-system fidelity. Engineering wanted protected focus and clear, batchable work. QA needed reliable coverage without a separate visual-testing bureaucracy.
We sat down with QA, developers, and the Product Owner — and redesigned the sequence, not the tool.
Integrity
Coherent surfaces and design-system fidelity.
Flow
Protected focus and clear, batchable work.
Coverage
Functional and coarse visual checks, using familiar workflows.
Redirect habits. Gate expensive modes.
- QA tickets cover coarse visual defects
- Designer-QA triage resolves overlap and ambiguity
- Designers document residual fine-grained issues
- PO prioritises fixes and gates live developer reviews
Three forces. One negotiated pipeline.
The hybrid
A pipeline of filters — not one ritual for everything.
Default mode is lean and async. Live Visual QA with developers becomes a premium mode — justified by product needs, not designer preference.
01
Functional QA + coarse visual checks
QA checks behaviour and obvious visual defects, then files actionable tickets in the format engineering already trusts. Design is kept in the loop rather than starting a separate stream for the same findings.
02
Short sync: Designer ↔ QA
Review QA findings, remove duplicates, and separate coarse defects from fine design-system issues. Resolve design ambiguity before adding residual tickets; escalate priority decisions to the PO.
03
Residual designer tickets
Designers inspect the remaining fine-grained issues and document actionable fixes. AI assists with ticket drafts; designers own accuracy and severity, while the PO owns delivery priority. Engineering works from the documented, prioritised ticket stream, and fixes are verified.
04
Live Visual QA — PO-gated
Optional escalation, not a mandatory final meeting. When visual consistency materially matters to the story, the PO authorises a live designer-developer review so related fixes can be resolved together.
Ownership stays explicit
QA owns functional coverage and coarse visual findings. Design owns fine visual judgment and design-system fidelity. Engineering owns implementation. The PO prioritises bugs against OKRs and engineering capacity. Findings, decisions, and deferred work remain documented.
Outcome
A shared quality process, not competing review streams.
The hybrid pipeline was adopted as shared team practice. QA handled the coarse layer, designers retained fine design-system judgment, and the PO decided which fixes mattered now — including when a live review was worth the interruption.
Design ticket volume dropped as QA absorbed coarse visual findings. Live designer-developer sessions became the exception rather than the default. These were qualitative process outcomes; the effort estimates below are a separate model, not rollout measurements.
"The goal wasn't fewer quality checks. It was less duplicated effort and clearer decisions."
Making the tradeoffs explicit
Illustrative estimate · not measured resultsWhat could this save on one cross-platform story?
I modelled a small dashboard-control story spanning three weeks and delivered across iOS, Android, and web. The scenario uses a team of two designers, two QA engineers, and three platform developers, with one developer per platform.
Hours are summed across the people doing the work — not multiplied by every team member. A one-hour designer-developer call therefore costs two person-hours.
~24%
Less total review-and-fix effort
31.5 → 24.1 person-hours across three platforms, compared with the live-review workflow.
~34%
Less engineering review-and-fix time
18 → 11.9 developer-hours across three platforms.
Against the independent async-ticket workflow, the same model estimates approximately 15% less total effort and 21% less engineering time.
| Role | Live review | Independent tickets | Hybrid model |
|---|---|---|---|
| Design | 6.0 | 6.0 | 5.25 |
| Engineering | 18.0 | 15.0 | 11.85 |
| QA | 7.5 | 7.5 | 6.75 |
| POAdditional prioritisation | Not modelled | Not modelled | 0.25 |
| Total modelled effort | 31.5 | 28.5 | 24.1 |
The estimated saving is 7.4 person-hours per story against live review, or 4.4 against independent tickets. It comes from less correction work and shorter follow-up — not from removing designer ownership.
View assumptions and calculation
Scope and baseline
- One small story, three platforms, one developer per platform. Design and QA work is allocated across their respective two-person teams.
- Four hours of visual corrections per platform is the midpoint of the assumed three-to-five-hour range.
- Each platform is counted separately. Shared cross-platform findings are not credited with extra savings.
- Initial design, implementation, functional bug fixes, and existing PO work are outside the model. QA technical-check time is included and held constant.
Live-review workflow · per platform
Design: 1 hour initial live review + 1 hour final review = 2 hours. Engineering: 1 hour initial review + 4 hours corrections + 1 hour final review and small fixes = 6 hours.
Independent tickets · per platform
Design: 1 hour inspection and ticket creation + 1 hour final review = 2 hours. Engineering: 4 hours corrections + 1 hour final review and small fixes = 5 hours.
QA in both baselines · per platform
1 hour technical checks + 30 minutes coarse visual checks + 30 minutes ticket creation and clarification + 30 minutes verification = 2.5 hours.
Hybrid model · per platform
Design: 15 minutes QA triage + 1 hour deep visual inspection and residual tickets + 30 minutes final review = 1.75 hours.
Engineering: 15 minutes ticket review and clarification + 3.2 hours visual corrections + 30 minutes final review and small fixes = 3.95 hours.
QA: 1 hour technical checks + 30 minutes coarse visual checks + 15 minutes ticket creation + 15 minutes designer triage + 15 minutes verification = 2.25 hours.
PO: 15 additional minutes of prioritisation for the whole story, not per platform.
Where the assumed saving comes from
Correction effort is assumed to fall by 20%: 4 × 0.8 = 3.2 hours per platform. This represents removing duplicate requests, batching related fixes, and agreeing current scope. Ticket creation and QA verification are assumed to shorten, while final review falls from one hour to 30 minutes.
No additional saving is assigned to AI drafting. The designer's deep inspection and residual-ticket work remains one hour per platform.
Arithmetic
Live review: (2 + 6 + 2.5) × 3 = 31.5 person-hours. Independent tickets: (2 + 5 + 2.5) × 3 = 28.5 person-hours. Hybrid: (1.75 + 3.95 + 2.25) × 3 + 0.25 = 24.1 person-hours.
Total reduction: (31.5 − 24.1) ÷ 31.5 = 23.5%, rounded to 24%. Engineering reduction: (18 − 11.85) ÷ 18 = 34.2%, rounded to 34%.
Against independent tickets: (28.5 − 24.1) ÷ 28.5 = 15.4% total reduction; (15 − 11.85) ÷ 15 = 21% engineering reduction.
What I learned
Process design is product design for the organisation.
- 01Don't invent rituals — redirect habits partners already trust.
- 02"Perfect QA" that destroys partner flow fails. Integrity without dignity is temporary.
- 03Put expensive modes behind a product gate — the PO, not designer preference.
- 04Sequence matters: functional → coarse visual → fine visual. Document decisions, not just defects.
- 05AI accelerates writing residual tickets. Humans still decide what matters.