A generic interface can be exactly right at the beginning.
Fast design has one job: make the idea testable. It lets a team check whether a feature makes sense, whether the main interaction works and whether the idea deserves more investment. At that stage, a mature visual identity can wait.
The problem begins when that temporary design outlives the question it was built to answer.
Once the idea, feature or business has been validated, the interface has a different job. It must help unfamiliar people understand what to do. It must behave coherently on a small screen, recover from mistakes, support different access needs and express a direction appropriate to this product - not simply resemble a plausible product in the same category.
AI makes the first stage faster. That is useful. It also makes the transition between a functional scaffold and a considered product easier to miss.
Answer in 60 seconds
Generic design stops being useful when it begins to hide product-specific decisions rather than helping you test them.
- Keep the generic scaffold while you are still proving the problem, feature or core interaction.
- A fast prototype still needs clear logic, understandable information architecture, accessibility, clean execution and small-screen behaviour. Otherwise you may test defects in the prototype rather than the idea.
- When the concept works, decide whether to personalise the existing system or establish a new direction. A full redesign is not the automatic answer.
- Put usability before visual distinctiveness. Fix broken logic, confusing structure, errors and access barriers first.
- Keep AI in the workflow. Use it for speed and breadth, but keep the design decision accountable to people who understand the user, product and context.
This is not an argument against AI or reusable patterns. It is a method for knowing when their defaults are no longer enough.
In this guide
- Generic design is a stage, not a failure
- Start with what is wrong before asking what is distinctive
- Make the generic-to-specific design decision
- Keep AI in the workflow, and keep judgement accountable
- Use one page to decide what the product needs next
1. Generic design is a stage, not a failure
Fast design is valuable because it makes an assumption testable.
Use the simplest prototype that can answer the current question: a sketch for hierarchy, a clickable flow for sequence, or working code when the real interaction matters. The point is to learn before committing to a full build. An experiment and a live product need different evidence.
If the immediate question is “Can somebody understand and use this feature?”, a restrained component library and a fast prototype may be exactly right. They reduce the temptation to debate brand expression before the team knows whether the feature should exist.
Generic does not have to mean careless.
A useful prototype should still be contextualised enough to produce meaningful feedback. Labels should make sense to the intended user. The main action should follow a coherent sequence. Obvious errors, broken states and strange interaction logic should not distort the test. People should be able to try it on the screens they are likely to use.
At IZZY, we start with the small screen. It forces the hierarchy and action priorities into the open: what must remain, what can move and what the user needs first. That does not mean every prototype needs a finished responsive system. It means a wide desktop preview is not proof that the interaction works in context.
Accessibility belongs in this baseline too. WCAG 2.2 applies across desktop and mobile web content and treats responsive variations as part of the page for conformance. A prototype review is not an accessibility certification. It can, however, catch choices that would otherwise invalidate learning or become expensive to unwind later.
The aim is not to make the experiment look finished. It is to make the experiment honest.
If the open question is whether the business can sell, deliver and support the idea - not how its design should develop - use our separate guide to turning a prototype into a commercial product.
2. Start with what is wrong before asking what is distinctive
When we review a fast-built interface, we do not begin by asking whether it has enough personality. We look for mistakes.
That includes bugs, incoherent behaviour, unclear logic, weak information architecture, inaccessible controls, missing states and visual choices that interfere with the task. These are not secondary details. They determine whether the interface can be understood and used.
A polished screen is not evidence of a usable product. The result has to be judged with particular users, goals and conditions in mind.
Our review order is deliberately practical:
| Layer | First question | Typical evidence |
|---|---|---|
| Task and logic | Can the intended user complete the important action, and does the result make sense? | Observed attempts, task outcomes, bugs and contradictions |
| Information architecture | Can people find and understand what they need without a guided tour? | Navigation paths, labels, hierarchy and points of hesitation |
| Accessibility and screen behaviour | Can people perceive, operate and understand the interface across relevant access needs and screen sizes? | Keyboard and assistive-technology checks, responsive states and user testing |
| Errors and edge states | What happens when information is missing, invalid, delayed or unavailable? | Empty, loading, error, partial, success and return states |
| Visual direction | Does the experience feel appropriate to the product, audience and brand? | Direction criteria, brand-system decisions, component use and comprehension testing |
The order is not a claim that visual design is unimportant. It protects visual work from being used to disguise a more fundamental problem.
If the task model is wrong, a new colour palette will not fix it. If the information architecture is unclear, a more expressive typeface may make the confusion more attractive. If a key control cannot be used with a keyboard, distinctiveness is not the next priority.
Usability comes first because it is the condition under which the rest of the design can matter.
3. Make the generic-to-specific design decision
Once the idea has produced useful evidence, teams often jump to one of two extremes: keep the generated or template interface untouched, or commission a total redesign.
We use three routes.
Route 1: keep the scaffold
Keep it when the team is still testing the problem, the audience is controlled and the current interface is not distorting the result.
The design still needs a baseline of clarity, accessibility and responsive behaviour appropriate to the test. It does not need a mature brand system merely to demonstrate that the core action is plausible.
The next investment should buy evidence: another prototype, a corrected flow or research with the intended user.
Route 2: personalise the system
Choose this route when the core interaction works and the structure is fundamentally sound, but the experience still feels borrowed, incomplete or inconsistent.
Personalisation can include:
- defining the brand identity, or translating an existing one into the product - from typography, colour, iconography and imagery to tone of voice, layout principles and motion behaviour;
- rewriting labels and guidance in the customer’s real language;
- clarifying hierarchy and information density;
- designing purposeful microinteractions and animations that provide feedback, clarify state changes, show progress and help people stay oriented;
- making components, states and interaction patterns consistent;
- improving mobile behaviour and accessibility;
- documenting the resulting decisions in reusable design tokens, components and guidance.
This is often focused product-design work rather than a rebuild. Keep the parts that have earned their place. Change the parts that still behave like placeholders.
Route 3: establish a new direction
Choose this route when the current design encodes the wrong assumptions.
That may be the case when the navigation follows the tool rather than the user’s mental model, the visual tone signals the wrong category or level of trust, the interface cannot accommodate real product states, or the product has moved to a different audience and use case since the prototype was made.
Here, styling the existing scaffold can preserve the wrong structure. The team needs to return to the problem, define a direction and decide which patterns should survive.
This is the important boundary: a validated concept can justify more design investment, but validation does not automatically justify more decoration. The investment should address the next unproven decision.
4. Keep AI in the workflow - and keep judgement accountable
AI is too useful to ban. It can be valuable across many parts of design and product work.
It can make an idea tangible sooner, generate alternatives, scaffold a flow, explore content variations, enumerate edge cases and help a team compare directions. Used well, it creates more material to evaluate and leaves more time for decisions that require context.
But speed does not remove accountability.
| AI can accelerate | The product team still owns |
|---|---|
| Prototype screens and interaction alternatives | The user problem and the hypothesis being tested |
| Variations in copy, layout or visual treatment | The criteria for accepting or rejecting a direction |
| Lists of possible states, errors and edge cases | Verification with real product rules, users and conditions |
| Initial accessibility and consistency checks | Accessibility scope, human evaluation and remediation decisions |
| Production handoff drafts and component documentation | The final system, trade-offs and release decision |
The human contribution is not a layer of visual polish added after the machine has done the real work. It is the framing, selection, correction and validation that make the output appropriate.
AI can produce many competent versions. Product design decides which question those versions are answering - and whether any of them should ship.
5. Use one page to decide what the product needs next
Before commissioning more screens, write down six things:
- The current stage: idea, functional proof, tested pilot or customer-facing product.
- What has actually been proved: technical possibility, task comprehension, repeated use, willingness to pay or something else.
- The important user task: the one path the design must make clearer or more reliable.
- The first observed break: bug, logic, information architecture, accessibility, screen behaviour, error handling or visual fit.
- The direction criteria: what the experience should communicate and which constraints it must respect.
- The next decision: keep the scaffold, personalise the system or establish a new direction.
This short record prevents three common mistakes: treating a polished demo as finished, spending on brand expression before the idea is credible, and preserving a generic interface after the product has earned the need for something more specific.
It also creates a better brief. Instead of asking a designer to “make it less AI” or “add personality”, the team can explain what has been validated, what users are trying to do, what currently fails and what the new direction must accomplish.
Conclusion: the right design investment changes with the evidence
The purpose of a prototype is not to look original. It is to help a team learn.
Use fast design to test the functional idea. Keep that early experience clean, coherent, accessible enough for the research and designed for the screens people will actually use. Then, if the idea proves useful, change the design question.
First fix the mistakes, logic, information architecture, accessibility and missing states. After that, decide whether the current system needs focused personalisation or a direction of its own. Judge the result by usefulness and applicability - not visual novelty alone.
AI remains part of the process. Usability remains the priority. Personalisation becomes valuable when it helps a product fit its task, its audience and its identity more precisely.
Choose the design investment the evidence supports
You do not need to arrive with a finished prototype. If you want to test an idea without investing in a custom design system too early, IZZY can help define and design the smallest useful proof of concept: the critical flow, necessary states, clear content, accessible interaction and reliable small-screen behaviour. The aim is to create a credible test - not to make an unproven product look finished.
If you already have a fast-built product and the idea has been proved, we can help determine whether the next step is a focused UX correction, system personalisation or a new product direction.
This is exactly the scope of our Product Design service. Bring the idea or prototype, the important user task and any evidence you already have. We will scope the right level of design investment from the question you need to answer - not assume a custom redesign from the start.
Frequently asked questions
Not necessarily. If the immediate goal is to test whether the feature or interaction works, a restrained generic system may be the right choice. It should still be clear, coherent and appropriate enough that poor execution does not distort the test.
No. Familiar patterns can reduce learning and help a team move quickly. Generic UI becomes a problem when it no longer reflects the user’s task, the product’s real states or the organisation’s direction.
Usability comes first in the review order. Fix broken logic, confusing structure, access barriers and missing states before using visual identity to differentiate the product. The two should eventually work together.
It can contribute useful and original options. Distinctiveness is not guaranteed by the tool or by avoiding the tool. It comes from specific inputs, clear constraints, informed selection, refinement and validation in the product’s context.
Sources and method
This article draws on IZZY’s experience working with real client products and on external material checked on 19 August 2026. Client identities, project details and case material are not disclosed because of confidentiality and NDAs. The generic-to-specific decision and review order are IZZY practice guidance, not external standards or guarantees. No representative market-demand claim is made.