Most SaaS teams treat UAT as a final checkpoint. Design ships, engineers build, QA (or someone with a spreadsheet) walks through the flows before release and flags what's broken. It's a familiar process, and on the surface it sounds reasonable — you're checking the work before it goes to users.

The problem is that manual UAT doesn't scale with product complexity, it doesn't run on every deploy, and — most critically — it produces inconsistent results depending on who's doing it and how much time they have. Bugs that a tired person misses on a Friday afternoon reach production. Regressions introduced by a small backend change don't get caught because no one thought to retest that flow. The spreadsheet feels like a safety net, but it has holes.

But there's a deeper issue that the "let's automate our tests" conversation usually skips over entirely. The question isn't just how you test — it's what you test, and who in the organization is responsible for defining that. Because the answer to that question is, fundamentally, a product design decision.

The test suite is a design artifact

When you sit down to write end-to-end tests for a SaaS product, the first thing you have to do is define the critical paths: the flows that, if broken, mean the product has failed. Not failed in a minor way. Failed in the way that makes a user churn, file a support ticket, or lose trust in the product entirely.

That definition is a UX decision. It requires understanding the user well enough to know which flows are load-bearing — which ones users depend on as part of their core job — and which failures are tolerable versus which ones are catastrophic. An engineer can write the test once you've defined the path. But defining the path is design work.
‍

Most teams never make this explicit. Tests get written by whoever has time, covering whatever flows come to mind, with no framework for prioritization. The result is a test suite that's wide but shallow — it covers a lot of surface area but not necessarily the right surface area. When something breaks, you find out from a user, not from the pipeline.

Defining what cannot break is one of the most consequential product decisions you can make. It forces clarity about what the product actually is, for whom, and what it promises.

How to think about critical paths

A critical path isn't just a happy path. It's a flow where failure has a meaningful cost — to the user, to the business, or to trust in the product. In practice, identifying them means asking a few specific questions for every major feature area:

Working through these questions produces something more valuable than a test plan. It produces a shared, explicit definition of what the product promises — which is something most teams only discover they've never articulated when something important breaks and there's a disagreement about how serious it is.

What this looks like in Playwright

Once critical paths are defined, the translation into Playwright tests is relatively direct. The framework is built around simulating exactly what a user does — navigating, clicking, filling inputs, waiting for responses — and asserting that the outcome matches what was designed. The test reads like a user flow because it is one.
‍

Here's what a critical path test looks like for a multi-role form submission flow — the kind where role-based visibility rules mean different users see and can interact with different fields:
‍

That second point is worth dwelling on. A common mistake in E2E testing is asserting only that the UI looks right — the button is hidden, the field is disabled — without asserting that the underlying route or action is actually protected. These are different guarantees, and conflating them produces tests that pass while real security and permission failures go undetected.

‍

The products that feel effortless — the ones where things are always where you expect them, where nothing behaves inconsistently, where change feels safe — aren't the result of better UI design alone. They're the result of systems built with enough structure that good outcomes are the default. Designing those systems is UX work. It just doesn't look like it from the outside.