.png){kind=small}
ROLE/SERVICES
Product Design Lead · UX Engineering · Platform Analysis
LOCATION
USA 🇺🇸
YEAR
2025–2026
Summary
BanQu is a ten-year-old platform serving supply chains across 17+ user roles — and like any platform that age, its complexity is a mix: some of it intentional, some accumulated over time. Testing hadn't kept pace. Coverage was unit tests plus a manual UAT that walked one scripted path per flow, even when a flow had four ways to complete. Critical flows depended heavily on manual regression, which made product risk hard to see before release. The product owner and I started this as a working question: could end-to-end testing double as a product audit — mapping which flows matter, which break, and where complexity was intentional versus accumulated? I architected the framework; engineering and QA adopted it. And its byproduct became a second system entirely: an automated documentation pipeline, with 40+ trilingual client guides published to Zendesk.
SaaS Blockchain platform
The Challenge
Solution & Impact
Product Design Lead UX Engineering Playwright E2E Architecture UAT Strategy & Audit Risk Analysis & Roadmap Self-Initiated
Scope
BanQu is a multi-sided SaaS connecting supply chains, smallholder farmers, and financial institutions: 17+ user roles with distinct permissions, forms of 50–100+ fields with conditional logic and computed scores, blockchain transactions that take 2.5 minutes, and an offline-first mobile layer for low-connectivity regions. A massive product surface — and before this work, very little of it had systematic proof that it worked as designed.
Manual UAT answered one question: does the scripted path still complete? It couldn't answer the ones that mattered. Does each of 17 roles get the experience we designed? Do the other three ways of completing a transaction work, or just the one we always walk? Which of the product's many paths are intentional design, and which are complexity that accumulated over time — the distinction that made it possible to decide what deserved coverage at all? Standard QA tests what was built. This framework connects what was built to what was intended — and that connection is where product risk lives. Who was involved: self-initiated, never solo. The product owner and I scoped it together and ran the UX-audit lens jointly. The engineering lead shaped the test strategy — his rule became the framework's backbone: “We already unit-test in code. Verify a component once end-to-end, then drive everything else through the API.” The dev team was trained on the framework and now extends it; QA has started using the framework for day-to-day validation. For the documentation pipeline, I pitched the move off PowerPoints to the VP overseeing client-facing operations and enablement, since it changed what clients receive.
A testing framework built around three capabilities. Role-based verification: critical flows test as real user types, proving permissions work rather than merely exist. Workflow testing: multi-step flows (Farmer creates → Reviewer checks → Approver gates) verified end-to-end — API-driven for speed and stability. Condition-based testing: blockchain confirmation delays, session expiry mid-flight, offline→sync cycles — the conditions users actually experience, not just happy paths.
The form engine (technical detail)
Forms reach 50–100+ fields with conditional visibility, computed scores, and role-gated inputs; hardcoded field names produce tests that break on every schema change — or silently pass while testing nothing. completeFormFromSchema fetches the live schema and fills in multiple passes, handling conditionals, computed fields, and relationship pickers. A new form test is ~10 lines, and field renames don't break it. A typed API client covers the full REST surface, so multi-step workflows run end-to-end without driving every step through the UI.
Tech Stack (technical detail)
Playwright (TypeScript) · role-based storageState for 17+ roles · global-setup + auth wrappers · typed API client · multi-pass form engine. A new role is one line; a new test is ten — which is why the team could adopt it instead of depending on me.
What I deliberately didn't build
Coverage is a budget. BanQu has surveys of up to 700 fields across ten survey types — I declined to automate each one, and built a single representative mini-survey exercising every field type and behavior instead: test the functionality once, not every instance. Same principle at the component level — if ten flows touch the search bar, one flow verifies it and the other nine go through the API. End-to-end testing that repeats unit testing is just slower unit testing.
Building the framework surfaced an asset nobody was using: Playwright captures a screenshot at every step, and tests already existed for the flows every client shares. Meanwhile, client documentation lived in hand-maintained PowerPoints — different per client, scattered across SharePoints, drifting the moment a flow changed. So the test suite became a documentation engine. Generic guides (login, password reset, contact support) are generated from the same runs that verify those flows work. Client-specific guides were migrated from the legacy decks through a pipeline I built, and published to Zendesk: 40+ guides live in English, French, and Spanish, with internal use underway and client rollout beginning. The one concern raised — vendor dependence on Zendesk — shaped the architecture: every guide exists as Markdown, HTML, and PDF in the GitHub repo; Zendesk is a publish target, not a home. For generated guides, documentation is tied directly to the tested product flow, reducing the risk of drift. For migrated guides, the repo becomes the source of truth instead of scattered PowerPoints.
How the pipeline works (technical detail)
Each meaningful test action is wrapped in articleStep(), which captures a screenshot and records step metadata; generateArticle() emits the article and a structured steps.json. For migrated guides, the pipeline parses each PowerPoint's XML for its images, composites the deck's own highlight callouts onto each screenshot so visual annotations survive conversion, validates structure and step text word-for-word against the source, then publishes as a draft — uploading images as hosted attachments and reinjecting them positionally, per locale, with trilingual-ready guides prioritized.
Eight structural risks surfaced: five infrastructure risks that fed the first two roadmap phases, and three product-level promises no one could yet prove were being kept.
The team adopted the framework because it came with a prioritized roadmap that made tradeoffs visible. QA moved from reactive (“what breaks this week?”) to strategic (“what's the highest-value product promise still unverified?”). Engineering extends the framework independently; QA has started using it for day-to-day validation; the guides are live and rolling out to clients — one investment now improving both product quality and operational scalability.
What got automated
+ Multi-Purchase, Revert Transaction — 12 areas total.
Coverage map
55 scenarios mapped — status of the highest-traffic areas at a glance.
Invite delivery gaps flagged
C5 role visibility, C7 export flagged
Single-field assertion only
Field behavior automated; Approver workflow uncovered
Pricing config automated; fixed-price enforcement not covered
Reject path absent
Go-offline→sync untested end-to-end