Testability is rarely on a designer's checklist. It's not in most product requirement templates. And yet, the decisions made in Figma or during architecture reviews determine 80% of how painful your automation will be.
The Hidden Cost of Untestable UIs
When elements don't have stable identifiers, when modals block the DOM in unexpected ways, when dynamic content shifts element positions — automation engineers spend hours writing brittle workarounds instead of meaningful tests.
This isn't an automation problem. It's a design and architecture problem.
What Testable Design Looks Like
Meaningful test IDs — Every interactive element should have a data-testid attribute. Not data-testid="button", but data-testid="checkout-submit-btn". Descriptive, stable, and scoped.
Predictable states — Loading states, error states, empty states should all be distinct and identifiable. An automation engineer needs to know definitively when a page has finished loading.
Accessible markup — ARIA roles and labels aren't just for screen readers. They're stable selectors that survive styling changes. Accessible UIs are testable UIs.
Stable DOM structure — Avoid deeply nested dynamic wrappers. The more layers between a user action and its DOM target, the more brittle the test.
The Engineering Side
On the backend, testability means:
- Seeding mechanisms — Can you create known test data without manual setup?
- Feature flags — Can you enable/disable features deterministically in tests?
- Predictable IDs — Sequential or deterministic IDs make assertions reliable.
- Clock control — Date-dependent logic needs controllable time.
A Practical Checklist
Before any feature ships to QA, ask these questions:
- Can every interactive element be uniquely selected?
- Are all async operations clearly signalled in the UI?
- Is there a way to seed the required test data programmatically?
- Are error and edge-case states visually distinct and identifiable?
Conclusion
Testability is a design discipline. When it's baked in, automation is a pleasure to write. When it's absent, automation becomes archaeology — digging through layers of generated classnames hoping something doesn't move.
Add a QA voice to your design reviews. It pays off immediately.