An approved design is not yet a tested application.

A convincing screen does not provide the answer

A supplier wants to develop an application quickly using AI. Superusers are invited to review the designs in Figma along the way. Their feedback is meant to build confidence in the result. A specialist testing team is not involved.

That sounds efficient: build quickly and involve users directly. Yet an essential element is missing when reviewing designs takes the place of testing the working application. How will the client know that processes, data and integrations actually work correctly?

What a prototype can help you investigate

A prototype helps you discover early whether people understand the design. Can they find the right function? Does the sequence make sense? Is a step missing from their workflow?

This is valuable research. It helps prevent a team from building a confusing or unusable design. But a prototype does not yet have to meet the same standards as production software. The UK government’s prototyping guidance explicitly makes this distinction, including for security and performance. [1]

Suppose someone clicks “Save” and sees a confirmation. In a clickable design, that may simply be the next screen. It does not establish that data is stored correctly, an integration succeeds or an error is handled properly.

Call this activity design validation or prototype testing. Do not present its outcome as completed user acceptance testing (UAT) of the application.

Superusers and testers contribute different expertise

Superusers understand the everyday work. They recognise illogical steps, missing information and exceptions that developers may not know about. Their contribution is essential.

Professional testers add a systematic approach to investigation. They make risks explicit, explore boundary cases, combine user roles and data conditions, and record what has and has not been examined.

Can superusers test systematically? Absolutely, with appropriate preparation and support. But domain knowledge alone does not replace testing expertise. Equally, a tester cannot replace users’ practical knowledge. ISTQB describes acceptance testing as collaboration involving the business, product stakeholders and testers. [2]

What remains unseen when you only review screens?

The most important unanswered questions often concern what happens behind the screen. Not every project needs equally extensive testing. The depth should follow the risks. But approving a design does not make these questions disappear.

1. Data: are changes preserved, and are calculations and validation rules correct?
2. Authorisation: can someone view or change data they are not allowed to access?
3. Integrations: what happens when another system is slow, fails or returns unexpected information?
4. Concurrent use: what happens when two employees update the same record?
5. Accessibility and performance: does the implemented application work with a keyboard and assistive technology, and does it remain usable under load?
6. Operations and recovery: can errors be traced, is recovery possible, and do existing features still work after changes?

Involve testing expertise before the code exists

This is where shift left helps: start investigating quality earlier. During the first discussions, a tester can already expose unclear requirements, missing exceptions and decisions that will be difficult to test. Test analysis need not wait until the application is ready. [3]

“An employee can approve a request” immediately raises questions. Which employee? Can someone approve their own request? What happens if the request changes in the meantime?

Those answers support both design and implementation. Early testing does not subsequently replace testing the implemented software.

How to strengthen the approach

Bring the supplier, client, superusers and testing expertise together from the start:

1. Make risks and acceptance criteria concrete. Agree on the required behaviour and the evidence the client expects.
2. Use prototypes for early feedback. Address findings before they become code.
3. Check each working increment. Combine code review, automated checks and focused investigation.
4. Run UAT on working software. Use representative roles, data, integrations and business processes. Record the limitations of the test environment.
5. Make an evidence-based acceptance decision. Make findings, remaining risks and responsibilities visible.

Fast development needs clear responsibility

“Vibe coding” often refers to creating software through AI instructions and rapid iterations. The amount of human oversight varies. Ask specifically who understands, reviews, tests and maintains the code.

For SBIT, quality belongs in development from the first question. User feedback, testing expertise and technical checks together provide the evidence a client needs to make an informed decision.