The Complete UI/UX Guide for Vibe Coding No more AI slop

A Complete Product, Design System, Workflow, and AI Prompting Framework

Hi Friends,

I am not a designer.

I am a Product Manager. My job is to understand user needs, map the complete workflow, and decide what information each screen should present so users can take the right action without confusion.

While working on an enterprise manufacturing SaaS product, I designed the complete UI/UX flow and built an interactive prototype through vibe coding.

The product included project management, quotations, scheduling, budgets, quality, documents, payments, and progress tracking. It was designed for large enterprise customers, including Fortune 500 companies.

Building individual screens with AI was fast.

Making those screens feel like one connected, consistent, and usable product was the difficult part.

A page could look attractive on its own, but when I connected it with the complete workflow, the problems became obvious:

• Inconsistent widths, spacing, and alignment
• Too many cards, colours, badges, gradients, and generic charts
• Repeated navigation and information
• Important details removed in the name of minimalism
• Actions and statuses that did not match the real workflow
• Internal information appearing on customer facing screens
• Different modules looking like they belonged to different products
• AI inventing unnecessary fields, data, actions, and processes

The result looked polished but it did not always work as a complete product.

And this is where vibe coding becomes interesting.

AI can generate a dashboard in minutes, but can it understand

Who is using it?

What decision are they trying to make?

What should they see first?

What should remain hidden?

What action should be available at this stage?

What happens before and after this page?

Usually, not unless you tell it.

Without clear direction, AI falls back on familiar patterns: rounded cards, purple gradients, equal metric boxes, status pills, generic charts, repeated navigation, and unrealistic placeholder data.

A hospital platform, manufacturing portal, construction application, and recruitment dashboard may solve completely different problems. Yet a prompt such as build a modern SaaS dashboard can make all of them look almost identical.

That is the real problem.

The solution is not one magical prompt. It is a repeatable system for defining the user, workflow, business rules, information architecture, visual hierarchy, reusable components, and review process before asking AI to build.

During nearly three months of design, development, regression testing, and repeated improvements, I collected more than 100 practical UI/UX principles, product rules, workflow lessons, and AI prompting techniques.

I am sharing all of them in this article.

The main principle is simple

AI should execute your product and design decisions—not make all of them for you.

Save this article for the next time AI gives you a beautiful interface that does not work as a complete product.

Part One: Product Thinking Before Interface Design

1. Why Most Vibe Coded Applications Look the Same

Imagine asking AI to create dashboards for four completely different industries using the same vague prompt. The screens may look polished, but the structure will often be nearly identical.

AI generates predictable interfaces because predictable interfaces are statistically safe.

When a model receives a vague request, it tends to select patterns that frequently appear together in modern frontend repositories, component libraries, templates, tutorials, and design examples.

These patterns often include

• A collapsible left sidebar
• A top bar with search and notifications
• A page heading with a subtitle
• Four metric cards
• One line chart
• One bar chart
• One recent activity card
• Rounded components
• Light shadows
• A blue or purple accent
• Inter or another neutral sans serif font
• Shadcn style components
• Tailwind utility classes
• Status pills with pastel backgrounds

None of these components is automatically bad.

The problem is that they are added without a reason connected to the user’s work.

For example, imagine an application that helps laboratory teams manage equipment calibration. The AI may generate four cards displaying:

• Total equipment
• Active equipment
• Pending calibration
• Compliance score

It may then add a line chart titled “Calibration Trends.”

But the actual laboratory manager may not need a general dashboard. Their most urgent questions may be:

Which equipment cannot be used today?

Which calibration certificates expire this week?

Which tests are blocked?

Who owns the corrective action?

What evidence must be provided before an audit?

A visually polished dashboard can therefore fail even when every component is attractive.

This distinction is fundamental

Visual completeness is not the same as product usefulness.

An interface should not be judged only by whether it looks professional. It should be judged by whether it helps the correct user understand the correct information and take the correct action at the correct time.

2. The Real Problem Is Missing Direction

This usually becomes visible when a generated page feels wrong, but the feedback given to AI is only “make it better.”

People often blame AI when the generated interface is generic.

However, a large part of the problem originates in the request.

Consider the instruction

Make this page look better.

The word “better” contains no usable design constraints.

Better for whom?

A first time consumer?

A procurement manager?

A senior finance executive?

A factory operator?

A field technician?

A software administrator?

A mobile user working outdoors?

An analyst reviewing hundreds of rows?

Better in what way?

Faster to scan?

Easier to learn?

More compact?

More trustworthy?

More expressive?

More accessible?

More premium?

More suitable for a customer presentation?

More suitable for daily operational use?

AI cannot reliably answer these questions without context. It therefore replaces one generic interpretation with another.

A stronger request translates subjective dissatisfaction into observable rules.

Weak instruction

Make it professional and minimal.

Stronger instruction

Preserve the current workflow and all decision critical information. Redesign the page as a compact enterprise interface. Reduce decorative containers, remove gradients and unnecessary shadows, use thin dividers, maintain consistent alignment, keep one clear primary action, and use semantic colour only for statuses and exceptions.

The stronger prompt does not merely contain more words. It contains better decisions.

Long prompts can still be weak when they are filled with adjectives rather than constraints.

For example

Make it highly professional, sophisticated, clean, elegant, premium, modern, intuitive, world class, beautiful, and user friendly.

This sounds detailed but provides almost no operational guidance.

A useful prompt should reduce uncertainty.

It should tell the model

• What problem the page solves
• Who uses it
• What must remain
• What must change
• What rules must not be violated
• What visual system should be followed
• What patterns are prohibited
• What type of output is expected

3. Product Design Must Begin Before Visual Design

Consider a team starting with colours, cards, and charts before deciding what the user must understand or do on the page.

A common mistake in vibe coded product development is beginning with the appearance of the screen.

Teams discuss

• Card colours
• Border radius

Shadows

• Icons
• Gradients
• Animations
• Charts

before answering

What is the user trying to accomplish?

What decision does this page support?

What information is essential?

What is the next expected action?

What can go wrong?

Which information is confidential?

Which role is allowed to perform the action?

What happens after the action?

Visual design should communicate product logic. It cannot replace missing product logic.

For every page, begin with a one sentence objective.

A weak objective might be

Show order details.

A stronger objective might be

Help the customer understand the current order status, identify whether any action is required, see what will happen next, and access the documents that prove completed work.

The stronger objective immediately affects the layout.

The page should probably priorities

• Current status
• Required action
• Next expected step
• Progress or milestones
• Exceptions or delays
• Evidence and documents
• Secondary record information

It should not begin with decorative metrics merely because dashboards usually contain metrics.

This method applies to every product surface.

A quotation page should help the user understand options and make a purchase decision.

A project overview should help the user understand status, risks, actions, and next steps.

A quality page should explain what was checked, what failed, what was resolved, and what evidence is available.

A closure page should confirm that operational, financial, and documentation requirements are complete.

A form should collect only information required by a decision, workflow, calculation, permission rule, or downstream process.

When the page objective is clear, visual decisions become easier.

4. Start With the User, Not the Interface

To see why this matters, compare two people using the same product for completely different responsibilities.

Before designing a page, identify the user precisely.

“Business user” is not precise enough.

A customer who opens an application once per month behaves differently from an internal operator who uses it eight hours per day.

A senior executive needs different information from a project coordinator.

An administrator needs different controls from an employee.

A technical expert may understand domain terminology that would confuse a purchasing manager.

At minimum, define

• Primary user
• Secondary user
• User expertise
• Frequency of use
• Device
• Environment
• Responsibilities
• Decisions they make
• Information they already know
• Information they do not know
• Consequences of making a mistake

For example, consider a logistics application.

A customer may want to know

Where is my shipment?

Is it delayed?

Do I need to provide any document?

When will it arrive?

Who can I contact?

An internal logistics coordinator may need

• Carrier assignment
• Warehouse scan history
• Route exception
• Customs status
• Driver details
• Internal notes
• Escalation owner
• Cost variance

Displaying the internal interface to the customer creates noise, confusion, and possible information exposure.

Displaying the simplified customer interface to the internal operator may hide information required for their job.

A well designed system can use the same underlying data while presenting different experiences based on role and responsibility.

User centered design therefore does not mean making every screen simple. It means making the screen appropriate for the person using it.

5. Understand the Questions Inside the User’s Mind

A useful way to design any page is to stop thinking about components for a moment and listen to the questions the user is already asking.

Users rarely think in terms of UI components.

They do not open a page thinking

I hope this page contains four attractive cards and a vertical timeline.

They open the page with questions.

Common questions include

What is happening right now?

Is everything on track?

Is anything blocked?

Do I need to do something?

What will happen next?

How much will this cost?

What changed since my last visit?

What has been completed?

What is still pending?

Who is responsible?

When should I expect an update?

Where is the supporting evidence?

Can I download the final record?

Can I change this decision?

Why is this action unavailable?

A good page answers these questions in priority order.

This is a more reliable basis for information architecture than copying another dashboard.

Before creating a wireframe, write the user’s questions. Then place the answers in the order the user needs them.

For a project overview, the sequence may be

• Current status
• Action required
• Progress
• Current stage
• Next milestone
• Risks or issues
• Recent activity
• Important files

For a quotation review, the sequence may be

What has been quoted?

Are any items missing or pending?

What options are available?

What is the price?

What is the delivery time?

What are the trade offs?

Which option is currently selected?

What happens after approval?

The interface should follow the user’s reasoning, not the component library’s default examples.

6. Define the Job of Every Page

For example, a document upload page and an invoice page may use similar components, but they exist to help users complete very different jobs.

Every page should have one primary job.

This does not mean the page can contain only one action. It means the page should have one dominant purpose.

Use the following framework

Who is using the page?

Why did they open it?

What must they understand?

What decision might they make?

What action might they take?

What information is necessary?

What information is secondary?

What should not appear?

What indicates success?

What can go wrong?

Consider a document upload page.

The primary job is not simply “upload a file.”

A more complete objective may be

Help the user provide the correct technical document in an accepted format, verify that the upload succeeded, and understand what review will happen next.

This objective suggests that the page needs

• Clear document requirements
• Accepted formats
• Maximum file size
• Version guidance
• Upload progress

Validation

• Failure explanation
• Successful upload confirmation
• Next step explanation

It does not need unrelated charts or metrics.

Consider an invoice page.

The job may be

Help the customer understand the amount due, payment status, payment history, tax breakdown, and available invoice documents.

The most important elements may be

• Payment status
• Amount due
• Due date
• Primary payment action
• Cost breakdown
• Invoice download
• Previous payments
• Support route

A large activity chart or project progress widget may distract from the actual job.

When the page objective is documented, it also becomes easier to review AI output. You can ask:

Does this screen help the user complete the page’s job?

This is more useful than asking whether the screen looks modern.

7. Freeze Business Rules Before Generating UI

Business rules define how the product actually works. For example, imagine a B2B SaaS product where a customer creates a project, receives a quotation, completes payment, and then tracks the project through execution, quality review, dispatch, and closure.

Examples include

A workspace is available only after payment succeeds.

A quotation becomes read only after approval.

A rejected request must include a reason.

Only administrators can invite new users.

Employees can view only assigned projects.

A record cannot be closed while payment is pending.

A customer can download quality documents only after review is complete.

Internal supplier pricing is not customer visible.

A completed shipment cannot be edited.

A cancelled order can be reordered but not resumed.

A user cannot approve their own high value request.

An expired quote must be regenerated before purchase.

These rules should be defined before visual design because they determine:

• Which pages exist
• Which pages are available
• Which actions appear
• Which actions are disabled
• Which fields are editable
• Which statuses are possible
• Which information is visible
• Which transitions are allowed
• Which warnings are required
• Which confirmations are necessary

AI tools frequently invent workflow behavior when business rules are missing.

Consider the quotation stage in the same workflow.

Before payment, the customer may compare available options, review the price and delivery time, select a quotation, and proceed to checkout.

After payment succeeds, the purpose of the quotation page changes. It is no longer an active purchase screen. It becomes a read only transaction record.

However, an AI generated post payment quotation page may still show

• Edit quotation
• Change option
• Add to cart
• Apply coupon
• Approve quotation

These actions may look reasonable on a quotation page, but they are incorrect because the customer has already completed the purchase.

This is why the prompt should explicitly describe state dependent behaviour.

For example

Before payment, the customer may compare quotation options, select one, and proceed to checkout. After successful payment, the quotation becomes a read only transaction record. Remove option selection, approval controls, coupon fields, and purchase buttons. Show only the approved quotation, payment details, downloadable records, and the next project stage.

A visual redesign that ignores these rules can make the product less correct even when it appears more polished.

8. Separate Customer Experience From Internal Operations

For example, imagine a B2B manufacturing platform where the internal team manages suppliers, procurement, receiving, quality checks, production, dispatch, and finance. The customer uses the same product to understand project progress, provide required inputs, review documents, and track delivery.

Although both users rely on the same underlying project data, they do not need the same interface.

A company may internally manage

• Supplier discovery
• Negotiation
• Cost comparison
• Risk assessment
• Procurement approval
• Purchase order creation
• Warehouse allocation
• Internal quality review
• Rework discussions
• Financial reconciliation
• Escalation chains

The customer may only need to see

• Review in progress
• Quotation ready
• Order confirmed
• Materials secured
• Production started
• Quality inspection completed
• Dispatch scheduled
• Delivered
• Closure completed

Transparency does not mean exposing every internal activity. It means showing the customer the information they need to understand progress, risk, required actions, and expected outcomes.

Useful transparency answers

What is happening?

Is the work on track?

Is action required from me?

What is the expected next step?

Is there a risk or delay?

What evidence is available?

Unhelpful transparency exposes

• Internal negotiation notes
• Supplier level commercial data
• Administrative comments
• Unconfirmed internal estimates
• Employee only actions
• Internal blame or escalation language
• Technical system codes

Internal status

Supplier quotation comparison awaiting procurement lead approval.

Customer facing status

We are reviewing pricing options for your project. Your final quotation is expected by 26 August. No action is required from you at this stage.

For example, the internal team and the customer may need different descriptions of the same situation.

Internal status

Inward batch blocked due to quantity mismatch.

Customer facing status

A quantity discrepancy was identified while receiving the materials. Our team is resolving it, and the updated completion estimate is 28 August. We will notify you if any action is required.

The customer facing message remains honest while presenting information in a useful and understandable way.

Part Two: Workflows, Lifecycles, and Information Architecture

9. Map the Complete Product Lifecycle

Imagine building a B2B product one screen at a time without first deciding how a customer moves from signup to payment, delivery, and closure.

A multi module application should be designed as one connected journey.

Many vibe coded products are created page by page

• First, the dashboard
• Then, the form
• Then, the quotation
• Then, the payment screen
• Then, the tracking page

Each page may look acceptable independently, but the pages do not form a coherent lifecycle.

Before designing them, map the complete journey.

A common B2B lifecycle may include

• Account creation
• Organisation setup
• Request or project creation
• File or data submission

Validation

• Clarification
• Quotation
• Comparison
• Approval
• Checkout
• Payment
• Order confirmation
• Execution
• Quality review
• Dispatch
• Delivery
• Invoice settlement
• Closure
• Support
• Reorder

For each stage, define

• User goal
• System status

Required information

• User action
• Internal action
• Entry condition
• Exit condition
• Success state
• Failure state
• Notification
• Evidence
• Next stage

For example

Stage: Quotation Review

User goal: Understand options and select the right commercial outcome.

Entry condition: Technical review is complete enough to generate pricing.

Information required: Coverage, price, delivery time, pending items, alternatives, taxes, validity.

User actions: Compare, download, ask a question, select an option, proceed.

Exit condition: A valid option is selected and purchase is initiated.

Failure states: Quote expired, pricing incomplete, required file missing.

Next stage: Checkout and payment.

This lifecycle prevents disconnected design decisions.

10. Define State Transitions Explicitly

For example, the same approval page can behave very differently depending on whether the record is a draft, under review, approved, rejected, or expired.

A page does not exist in only one condition.

For example, an approval page may be

• Waiting for review
• Ready for approval
• Partially approved
• Approved
• Rejected
• Expired
• Superseded
• Locked
• Under revision

Each state can change

Visible information

Primary action

Secondary actions

Status language

• Warning messages
• Editable fields
• Available downloads
• Next step guidance

AI often designs only the happy path because the prompt describes only the ideal situation.

A stronger product specification includes a state model.

For each state, define

This makes the UI more reliable because every action is tied to state.

11. Design Information Architecture Before Components

Consider a project platform containing customer workflows, transaction records, organisation settings, and administrative controls. Before choosing tabs or cards, those areas must be separated logically.

Information architecture determines

• What information exists
• How it is grouped
• Where it appears
• How users move between sections
• What is global
• What is contextual
• What is primary
• What is secondary

Cards, tabs, tables, and accordions are presentation methods. They are not the information architecture itself.

Imagine a project platform containing

• Overview
• Requirements
• Files
• Quotation
• Orders
• Quality
• Dispatch
• Invoices
• Activity
• Reports
• User management
• Settings

Before choosing tabs or cards, determine the relationships.

Questions include

Which sections belong to the organisation?

Which belong to an individual project?

Which belong to a transaction?

Which are customer facing?

Which are administrative?

Which are used frequently?

Which are records rather than workflows?

Which sections must appear only after certain stages?

Which sections require different permissions?

A strong structure may use

• Global navigation
• Home
• Projects
• Orders
• Documents
• Organisation
• Support
• Project level navigation
• Overview
• Requirements
• Quotation
• Execution
• Quality
• Delivery
• Finance
• Documents
• Activity
• Administrative navigation
• Users
• Roles
• Billing settings
• Integrations
• Audit controls

This is clearer than placing everything into one long sidebar.

12. Avoid Duplicate Navigation

This problem often appears when each new screen adds another navigation pattern without checking what the existing navigation already communicates.

AI generated applications often contain too many navigation layers.

A screen may include

Global sidebar

• Top navigation
• Secondary sidebar
• Breadcrumbs
• Tabs
• Stepper
• In page anchor navigation

Each layer may be individually reasonable, but together they compete for attention.

Use navigation only when it represents a meaningful structural level.

For example

Global sidebar: Move between major product areas.

Project tabs: Move between modules inside one project.

Breadcrumb: Show hierarchy when users can arrive through multiple paths.

Stepper: Show progress inside a temporary multi step workflow.

In page anchors: Navigate a very long document or settings page.

Do not use a second sidebar simply because the first sidebar exists in a reference application.

Do not repeat the same module links in the sidebar and the top tabs.

Do not place project identity in the sidebar, header, breadcrumb, and page title simultaneously.

Every navigation element should answer a distinct question

Where am I in the product?

Which project am I viewing?

Which module am I in?

Which step am I completing?

When two elements answer the same question, one may be unnecessary.

13. Create a Consistent Application Shell

Imagine moving between quotation, quality, delivery, and finance pages inside the same project. The surrounding structure should remain stable even though the content changes.

The application shell is the stable frame surrounding changing page content.

A common enterprise shell includes

Global sidebar

Top application bar

• Project or workspace header
• Project level navigation
• Main content area
• Optional contextual side panel

The exact structure depends on the product, but consistency is essential.

Global sidebar

Use it for high level destinations.

Examples

• Home
• Projects
• Orders
• Reports
• Documents
• Organisation settings

Avoid placing every project module in the global sidebar.

Top application bar

Use it for global utilities

Search

• Notifications
• Help
• Organisation switcher
• User menu

Do not turn the top bar into another primary navigation system unless the product is intentionally designed that way.

Project header

A project header may contain

• Project name
• Project type
• Project ID
• Customer or organisation
• Current status
• Project owner
• A limited number of contextual actions

Avoid repeating the same identity information in the page body.

Main content

Use a consistent width, horizontal padding, and section rhythm.

Contextual panel

A right side panel can be useful for

• Summary
• Required actions
• Risks
• Contacts
• Cost details
• Selected option

It should not be added to every page automatically.

14. Design Page Composition Before Styling: Top Navigation, Page Breaking, Content Density, and Alignment

A page can use good colours, attractive typography, polished components, and modern interactions while still feeling completely wrong.

This usually happens because the problem is not the styling. The problem is the page composition.

Page composition determines

• Where the user enters the page
• How the user understands their location
• What appears first
• Which information receives the most attention
• How sections are grouped
• Where actions are placed
• What remains visible while scrolling
• How the page aligns with the rest of the application
• What moves to another page
• What remains hidden until required
• How the layout changes on smaller screens

AI frequently generates weak page composition because vague prompts force it to make all these decisions automatically. The original source material correctly identifies that an apparently simple instruction such as “build a modern dashboard” leaves the model to decide navigation, hierarchy, spacing, containers, actions, tables, status treatment, and responsive behaviour by itself.

The approved article structure also covers many of these issues individually, but they need to be treated as one connected discipline rather than isolated visual decisions.

Before asking AI to style a screen, define the page composition system.

14.1. Understand the Five Levels of an Application Page

A complex business application may contain five different structural levels:

• Global product navigation
• Workspace or project context
• Module navigation
• Page level context
• Page content and actions

These levels should not repeat one another.

Level 1: Global product navigation

This helps the user move between major product areas.

Examples

• Home
• Projects
• Orders
• Documents
• Reports
• Organisation
• Support

Global navigation should remain stable across the application.

Level 2: Workspace or project context

This explains which account, project, order, customer, or workspace the user is currently viewing.

It may contain

• Project name
• Project ID
• Service or project type
• Organisation
• Current status
• Owner
• High level contextual actions
• Level 3: Module navigation

This helps the user move between related areas inside the current project or workspace.

Examples

• Overview
• Requirements
• Quotation
• Execution
• Quality
• Delivery
• Finance
• Documents
• Activity
• Level 4: Page context

This explains the job of the current page.

It may contain

• Page title
• Short status summary
• Page specific action
• Relevant filters
• A small amount of explanatory context
• Level 5: Page content

This contains the actual information, decisions, records, forms, progress, or evidence.

A common AI mistake is representing the same context at several levels.

For example, the application may show

• The project name in the sidebar
• The project name again in the top bar
• The project name in a large project header
• The project name in the breadcrumb
• The project name in the page heading
• The project name inside the first summary card

This does not improve orientation. It wastes vertical space and creates visual repetition.

Each level should have a distinct responsibility.

14.2. Design the Top Navbar as Infrastructure, Not Decoration

AI often treats the top navbar as a decorative strip that must be filled.

It may automatically add

• Product logo
• Global search
• Organisation selector
• Workspace selector
• Help
• Documentation
• Messages
• Notifications
• Theme switcher
• Language selector
• Settings
• Profile image
• Upgrade button
• Create button

This creates an overloaded header before the user has reached the actual page.

A top navbar should contain only globally relevant navigation, identification, and utilities.

Material Design describes top app bars as areas for navigation, screen related text, and actions associated with the current screen. Carbon similarly treats the UI shell header as the highest level of navigation, which may stand alone in a simple product or work with side panels in a more complex product.

Appropriate top navbar content

Depending on the product, it may contain

• Product identity
• Global navigation for a simple application
• Organisation switcher
• Global search
• Notifications
• Help
• User profile
• A hamburger trigger on smaller screens
• Content that usually does not belong there

Avoid placing the following in the top navbar by default

• Project specific status
• Project progress
• Page filters
• Page tabs
• Table actions
• Download buttons
• Approval buttons
• Payment actions
• Detailed project metadata
• Several competing creation buttons

These elements belong closer to the context they affect.

Global action versus contextual action

A global action applies across the application.

Example

Create new project

A contextual action applies only to the current page or record.

Examples

• Approve quotation
• Upload revised file
• Confirm dispatch

Do not place contextual actions in the global navbar merely because the bar is always visible.

Doing so creates two problems

The action appears visually disconnected from the information it affects.

The header changes too much between pages and stops feeling global.

Do not duplicate sidebar navigation in the top navbar

When a product already has a persistent sidebar, the top navbar should not repeat the same major destinations.

For example, do not show

• Projects
• Orders
• Documents
• Reports

in both the left sidebar and top navbar.

The top bar can instead focus on utilities

Search

• Notifications
• Help
• Profile

Carbon’s guidance distinguishes between a header only structure for products with a small number of major sections and a header paired with side navigation when deeper navigation is required. It also recommends collapsing persistent side navigation into a hamburger menu as the header becomes smaller.

A useful top navbar rule

Before adding anything to the top bar, ask

Is this control useful across most pages, or only on the current page?

If it is useful only on the current page, it probably belongs in the page header, contextual panel, or content area.

14.3. Do Not Allow Too Many Header Layers

AI generated enterprise pages often begin with several horizontal bars:

• Global top navbar
• Organisation selector bar
• Project identity bar
• Breadcrumb bar
• Project tabs
• Page heading row
• Filter row

By the time the actual content begins, a large portion of the viewport has been consumed.

This is especially harmful on laptops, where vertical space is limited.

A user may open a project page and see only navigation, headings, and controls before scrolling.

Reduce the header stack

A practical enterprise structure may be

• Global shell
• Compact project header
• Project tabs
• Page content

The page title can sometimes be part of the content rather than another independent bar.

Breadcrumbs should be used only when they provide useful hierarchical navigation. They should not be added automatically when the sidebar and tabs already make the user’s location obvious.

Merge related information

Instead of creating

• A project identity bar
• A status bar
• An owner bar

combine them into one compact project header.

For example

• Factory Modernisation Program
• Implementation project · PRJ 2048 · North Division
• In progress · Managed by Ananya Rao

The goal is not to remove context. The goal is to communicate it efficiently.

14.4. Break a Page by User Task, Not by Available Components

“Breaking the page” does not mean placing every section in a different card.

A page should be divided according to

• User questions
• Decisions
• Workflow stages
• Information relationships
• Interaction boundaries

Weak page breaking looks like this

• One card for status
• One card for progress
• One card for the next stage
• One card for expected completion
• One card for project manager
• One card for documents
• One card for activity

This makes related information feel disconnected.

Stronger page breaking might be

• Section 1: Current situation
• Status
• Action required
• Progress
• Current stage
• Next milestone
• Section 2: Issues and updates
• Open issues
• Delays
• Recent decisions
• Expected resolution
• Section 3: Evidence and records
• Documents
• Reports
• Completion evidence
• Activity

The second structure reflects the questions in the user’s mind.

Semantic section test

Before creating a new section, ask

Does this information answer a different user question?

Does it have a different interaction?

Does it have a separate state?

Does it require a separate permission?

Does the user need to compare it independently?

Can it be moved or reused independently?

If the answer to all these questions is no, it may not need a separate container.

14.5. Use One Continuous Page When the User Needs One Story

Keeping information on one page is useful when the user needs to understand a continuous story.

Examples

• Reviewing a quotation before purchase
• Understanding project progress
• Checking an invoice
• Reviewing a quality report
• Confirming closure readiness

Breaking the information into multiple pages may force the user to remember details from one page while viewing another.

A continuous page works well when

• Information belongs to one decision
• The content follows a clear sequence
• Users need to compare sections
• Moving between pages would interrupt understanding
• The page can remain scannable through strong headings

Use

• Clear section headings
• Consistent section spacing
• Anchor links for very long pages
• A sticky summary or action when necessary
• Progressive disclosure for secondary details

GOV.UK guidance recommends considering well structured content, multiple pages, headings, or anchor links before hiding large amounts of content in accordions.

14.6. Split Content Across Pages When the User’s Task Changes

Do not keep everything on one page merely to avoid navigation.

Split content when

• The user begins a different task
• A different permission applies
• A different mental model is required
• The content has an independent lifecycle
• The user may enter that section directly
• The section has many records or complex interactions
• The page has become difficult to scan
• The content needs a distinct URL or shareable state

For example, an overview may summarise quality status, but detailed inspection records should exist on a dedicated quality page.

An overview may show invoice status, but payment history and tax documents can exist on a finance page.

An overview may show the latest three files, while the complete version controlled library belongs on a documents page.

The overview should answer

What do I need to know?

The detailed module should answer

What exactly happened?

14.7. Decide Correctly Between Pages, Tabs, Accordions, Drawers, and Expansion

AI frequently chooses tabs or accordions because they reduce visible content. That does not mean they improve usability.

• Use separate pages when
• Tasks are meaningfully different
• Users may share or bookmark the location
• Each area has substantial content
• Permissions differ
• Each area has an independent workflow
• The user does not need constant comparison
• Use tabs when
• Content belongs to the same object
• Only one section needs to be visible at a time
• Users need to switch quickly
• The number of tabs is limited
• Labels remain short and understandable

GOV.UK’s design guidance notes that tabs are appropriate when users do not need to see several sections simultaneously and need to switch quickly between related areas. Tabs fit fewer sections because they are arranged horizontally.

Avoid

• Too many tabs
• Multi line tabs
• Tabs within tabs
• Tabs that duplicate the sidebar
• Tabs for sequential process steps
• Tabs whose content is extremely unequal
• Use accordions when
• Sections are related
• Users may need more than one section open
• The content is secondary
• Section labels clearly communicate what is hidden
• User research supports the pattern

Do not use accordions to hide information every user needs.

Do not create accordions inside accordions.

Do not use them simply because the page is long.

GOV.UK explicitly warns that accordions hide content and that some users may not notice or understand them. Its guidance recommends testing structured content without an accordion first.

• Use expandable rows when
• A table must remain scannable
• Each record has secondary details
• Users need to inspect one or two rows
• Opening a separate page would interrupt comparison

Do not place the complete application workflow inside expandable rows.

• Use a drawer or side panel when
• The user needs temporary contextual information
• The main list should remain visible
• The action is quick
• The detail does not require a full working page

Examples

• Quick record preview
• Filter panel
• Short edit form
• Contextual summary

Do not use a drawer for

• Long forms
• Complex comparisons
• Large document review
• Multi stage approval
• Content that requires deep linking

14.8. Control AI Generated Content With a Content Budget

AI commonly generates too much content because it attempts to make the interface feel complete.

It may add

• Introductory paragraphs
• Helper text below every heading
• Descriptions under every row
• Tooltips
• Recommendation boxes
• “Did you know?” messages
• Summary cards
• Activity sections
• Charts
• Empty explanatory panels
• Repeated status text

The solution is not to say only

Use less content.

Instead, provide a content budget.

Page header content budget

Allow

• One clear title
• One short supporting line when necessary
• One primary action
• A limited number of contextual secondary actions

Avoid

• A paragraph explaining the entire product
• Several badges
• Multiple metadata rows
• Three primary buttons
• Repeated project identity
• Section header content budget

Allow

• Section title
• Optional one sentence explanation
• One contextual action

Avoid

• Title
• Subtitle
• Badge
• Description
• Information icon
• Link
• Button
• Status

all appearing together without a clear reason.

Row content budget

Allow

• Primary label
• Important value or status
• Necessary metadata
• Relevant action

Avoid

• Helper text below every row
• Multiple icons
• Several coloured badges
• Repeated dates
• Repeated action menus
• Content classification

Before implementation, classify content into four levels.

Level 1: Always visible

Information necessary for the page’s primary job.

Examples

• Current status
• Required action
• Price
• Delivery date
• Critical issue
• Level 2: Visible but quiet

Useful supporting information.

Examples

• Owner
• Last update
• Reference number
• Secondary totals
• Level 3: Available on demand

Details needed by some users.

Examples

• Calculation breakdown
• Complete history
• Technical evidence
• Secondary metadata
• Level 4: Remove

Information that does not help a decision, workflow, or understanding.

Examples

• Decorative metrics
• Repeated descriptions
• Invented insights
• Meaningless charts
• Generic motivational content

Progressive disclosure is useful for delaying advanced or rarely used functionality until users request it, reducing initial complexity and the opportunity for mistakes. It should not be used to hide information required for the primary task.

14.9. Give Every Page a Visual Entry Point

When AI receives a large amount of content, it often gives every element similar visual importance.

The page becomes technically organised but visually flat.

A user needs an obvious place to begin.

The entry point should usually communicate one of the following

• Current status
• Required action
• Primary decision
• Main result
• Current problem

For an order page

Dispatch delayed

Address confirmation is required before 4:00 PM.

For a quotation page

Quotation ready for review

Compare the three available commercial options.

For a closure page

Two requirements remain

Final payment and document acknowledgement are pending.

The visual entry point should not automatically be the largest metric.

It should be the information that best explains why the user opened the page.

14.10. Establish Alignment Lines Before Adding Components

Poor alignment is one of the most common reasons AI generated pages feel unprofessional.

Typical problems include

• Page title begins at one position
• Summary card begins at another
• Table begins at another
• Section headings use different padding
• Buttons float at unrelated positions
• Values are inconsistently aligned
• Cards have different internal padding
• A right panel does not align with the main content

Alignment should be defined through shared vertical and horizontal key lines.

Carbon’s grid guidance emphasises visible vertical and horizontal key lines so the eye can follow content and perceive visual harmony. Its spacing system also uses repeatable tokens for both component construction and layout density.

Create a page alignment contract

Define

• Left edge of the page title
• Left edge of major sections
• Left edge of tables
• Right edge of the main content
• Width of the contextual panel
• Position of primary actions
• Internal container padding
• Table numeric alignment
• Form label alignment
• Avoid arbitrary indentation

Do not allow

• One section padded by 16 pixels
• Another by 24 pixels
• Another by 32 pixels
• Table content indented independently
• Accordions using unrelated widths
• Tabs extending beyond the content grid
• Align related values

For summary data

• Subtotal ₹142,000
• Tax ₹25,560
• Grand total ₹167,560

The labels can be left aligned within the summary block, while financial values are right aligned.

For a structured summary

• Coverage 96%
• Delivery 14–18 days
• Open issues 2
• Last updated 22 August

Use consistent columns and dividers instead of four unrelated cards.

14.11. Do Not Make Every Section a Different Width

AI frequently creates

• A full width banner
• A 70% summary card
• A narrow progress card
• A wider table
• A floating activity section
• A right panel with an arbitrary width
• A form using another width

This creates a collage rather than an application page.

Use a small number of layout modes.

Full width mode

Use for

• Large data tables
• Complex timelines
• Wide comparisons
• Charts that genuinely require width

Standard content mode

Use for

• Overview pages
• Record details
• Quality summaries
• Documents
• Activity

Reading width mode

Use for

• Guidance
• Policies
• Long descriptions
• Instructions

GOV.UK’s layout guidance uses limited width columns for many page types to prevent lines of text becoming difficult to read, while allowing wider layouts where the content requires it.

Split mode

Use for

• Main content plus summary
• Main form plus contextual help
• Decision options plus purchase summary

A split layout should use a consistent ratio, such as

• Two thirds main content
• One third contextual panel

Do not change the ratio in every section.

14.12. Use the Right Summary Panel Only When It Supports the Main Task

AI often adds a right side panel because enterprise pages commonly use one.

A contextual panel is valuable when it holds information the user needs while working in the main area.

Examples

• Selected quotation option
• Cost summary
• Required actions
• Risk summary
• Project contact
• Approval summary
• Checkout total

It is less useful when it contains

• Random metrics
• Generic activity
• Repeated status
• Help content that belongs elsewhere
• Unrelated links
• Decorative charts

The right panel should answer

What information must remain visible while the user reviews or edits the main content?

If there is no strong answer, do not add it.

On smaller screens, the panel should not simply shrink until it becomes unreadable. It may need to:

• Move above the main content
• Move below the main content
• Become a collapsible summary
• Become a sticky bottom action
• Open as a drawer

14.13. Use Sticky and Fixed Actions Carefully

Sticky bottom actions can be highly useful on long pages.

Examples

• Proceed to purchase
• Submit for review
• Save changes
• Confirm selection
• Approve and continue

They prevent the user from scrolling back to the top after reviewing a long form, table, or quotation.

However, AI often implements them badly.

Common problems include

• The sticky bar covers the last table rows
• The bar is too tall
• It contains too many actions
• The same action is already repeated at the top
• It appears on short pages where it is unnecessary
• It remains fixed on mobile and blocks important content
• The bar width does not align with the page
• It ignores the sidebar width
• It appears before the user is eligible to act
• Sticky action rules

A sticky action should

• Support the page’s primary task
• Appear only when the page is sufficiently long
• Remain aligned with the main content
• Provide bottom padding so content is not covered
• Show one primary and limited secondary actions
• Reflect the current state
• Remain keyboard accessible
• Adapt on mobile

Example

• Selected option: Balanced plan · ₹167,560 · 14–18 days
• [Download quotation] [Proceed to purchase]

Do not place six actions inside the sticky bar.

14.14. Separate Status From Action

AI often places status and actions together without explaining their relationship.

For example

In review Approve Reject Edit Download

This creates confusion.

If the item is still under review, why is approval available?

A stronger structure is

• Current state
• Technical review in progress
• Explanation

The engineering team is checking the submitted specification. No action is required from you.

• Available action
• View submitted files

Or

• Action required
• Revised specification required
• Explanation

Two dimensions are missing from the uploaded drawing.

Primary action

Upload revised file

Status tells the user what is happening.

Action tells the user what they can or must do.

The design should connect them clearly.

14.15. Prevent AI From Giving Every Section Equal Importance

AI tends to produce equal height cards, equal width columns, and repeated visual patterns because symmetry is safe.

Real products are rarely that symmetrical.

A critical issue may require more space than a simple metadata value.

A quotation comparison may need a large primary area and a small summary panel.

A progress timeline may require more vertical space than a cost summary.

Do not force every section into

• Equal cards
• Equal columns
• Equal heading sizes
• Equal colour intensity
• Equal button weight

Use asymmetric layouts when the information importance is asymmetric.

Hierarchy should reflect

• Urgency
• Decision impact
• Workflow relevance
• Frequency of use
• Supporting detail

Visual equality should not override product meaning.

14.16. Add a Maximum Content Rule to AI Prompts

AI should be told not only what to include but how much to include.

Example

Do not add new sections, cards, charts, metrics, explanatory copy, or actions unless they directly support the stated page objective or a supplied business rule.

Another useful instruction

Each major section may contain one title, one optional explanation, one primary information group, and one contextual action. Do not repeat the same status, value, or action across multiple sections.

For helper text

Add helper text only when it prevents an error or explains a non obvious business rule. Do not place descriptive text below every field or row.

For metrics

Do not create metric cards automatically. Use a compact structured summary when several values belong to the same context.

For charts

Do not generate charts unless a time based trend, distribution, or comparison is required for a defined user decision.

This prevents AI from filling blank areas merely because the layout appears empty.

14.17. Give AI a Grid Instead of Asking It to Fix Alignment

A vague instruction such as

Fix all alignment.

may produce inconsistent local changes.

Instead, provide a grid contract.

Example

Use one shared content grid across the complete page

• Maximum content width: 1180 pixels
• Desktop horizontal padding: 24 pixels
• Major section gap: 24 pixels
• Internal container padding: 16 pixels
• Main and side panel gap: 24 pixels
• Right panel width: 336 pixels
• Standard border radius: 8 pixels

All page titles, section titles, tables, and action bars must align to the same left and right content boundaries

• Right align financial and numeric totals
• Do not introduce arbitrary widths or margins

The exact values can be changed according to the product’s design system.

What matters is that the model receives one layout system.

14.18. Design Mobile Reflow Intentionally

On smaller screens, content should not simply become a long stack in its original desktop order.

W3C’s reflow guidance explains that responsive layouts can adjust or relocate sections for smaller viewports as long as information and functionality remain available, with the aim of avoiding unnecessary two dimensional scrolling.

Define the mobile order.

For example, a desktop quotation page may contain

• Main option comparison
• Right side selection summary
• Sticky action

On mobile, it may become

• Selected option summary
• Option switcher
• Comparison
• Pending items
• Terms
• Sticky purchase action

A project overview may become

• Current status
• Action required
• Current stage
• Next milestone
• Progress
• Issues
• Files
• Activity

Do not preserve desktop ordering when it pushes the most important information far down the page.

14.19. Common AI Page Composition Mistakes to Prohibit

Add these to the repository or prompt instructions.

Navigation mistakes

Do not create a second sidebar.

Do not repeat global links in the top navbar and sidebar.

Do not place contextual page tabs in the global navbar.

Do not create tabs inside tabs.

Do not show internal modules to customer roles.

Do not redesign the global shell unless requested.

Header mistakes

Do not create more than one large page heading.

Do not repeat project identity in several bars.

Do not place several primary buttons in the header.

Do not place project specific metrics in the global top bar.

Do not create a separate bar for every type of metadata.

Page breaking mistakes

Do not place every section inside a card.

Do not split information that users must compare.

Do not keep unrelated workflows on one page.

Do not use accordions to hide primary information.

Do not create nested accordions.

Do not create a new page for one small secondary detail.

Content mistakes

Do not add helper text below every row.

Do not add generic introductory paragraphs.

Do not invent recommendations.

Do not add meaningless metrics.

Do not add charts without a defined question.

Do not repeat the same status in several areas.

Alignment mistakes

Do not use arbitrary section widths.

Do not use different left padding for each container.

Do not misalign page headings and tables.

Do not centre align operational data.

Do not use full width inputs for short values without a reason.

Do not float actions without connection to their content.

Sticky element mistakes

Do not cover page content.

Do not repeat the same sticky action at several locations.

Do not show inactive actions.

Do not make the bar wider than the content grid.

Do not keep desktop sized sticky panels on mobile.

14.20. A Reusable AI Prompt for Page Composition

Use this before asking AI to implement styling.

Act as a senior enterprise product designer and frontend engineer.

Redesign only the page composition and information hierarchy. Preserve the existing product workflow, data, permissions, global shell, and business rules.

First define the structural levels

• Global product navigation
• Project or workspace context
• Module navigation
• Page context
• Page content and actions

Do not repeat the same identity, navigation, status, or action across these levels.

Top navbar rules

Keep only globally relevant identity, navigation, search, notifications, help, and profile controls.

Do not place page filters, project progress, approval actions, payment actions, or table actions in the global navbar.

Do not duplicate sidebar navigation.

Page breaking rules

Group content according to user questions, decisions, workflow stages, and interaction boundaries.

Do not place every section inside a card.

Keep information together when users must compare it.

Move detailed independent workflows to dedicated pages.

Use tabs only for closely related sections that do not need to be visible simultaneously.

Do not hide primary information in accordions.

Content rules

Preserve all decision critical information.

Remove repeated descriptions, decorative metrics, meaningless charts, and unnecessary helper text.

Classify information as always visible, visually secondary, available on demand, or removable.

Do not invent new sections or content.

Alignment rules

Use one shared content grid.

Align page headings, summaries, tables, forms, panels, and sticky actions to common key lines.

Use consistent section gaps and internal padding.

Right align comparable numeric and financial values.

Do not introduce arbitrary widths.

Action rules

Maintain one dominant primary action.

Place contextual actions near the information they affect.

Use a sticky bottom action only for long decision or form pages.

Ensure sticky elements do not cover content.

Responsive rules

Reprioritise content for smaller screens instead of stacking everything blindly.

Collapse global navigation appropriately.

Move contextual panels according to mobile priority.

Preserve all essential information and functionality.

Before generating code, provide

• Current page composition problems
• Proposed structural hierarchy
• Content to retain, simplify, disclose, or remove
• Alignment and grid plan
• Desktop and mobile layout
• Primary and secondary action placement

14.21. Page Composition Review Checklist

Before approving an AI generated page, check the following.

Top navbar

Does every item have global relevance?

Is sidebar navigation duplicated?

Are contextual actions placed too high?

Is the top navbar overcrowded?

Does the navbar behave correctly on smaller screens?

Header stack

How much of the initial viewport is consumed before content begins?

Are project identity and page identity repeated?

Are breadcrumbs necessary?

Are tabs performing a distinct role?

Can any horizontal bars be merged?

Page breaking

Are sections divided by user task?

Are related details unnecessarily separated?

Is any one page carrying several independent workflows?

Are cards being used as decoration?

Would headings and dividers work better?

Content volume

What must always remain visible?

What can be visually quieter?

What can be shown on demand?

What can be removed?

Has AI invented content to fill space?

Is helper text preventing real mistakes?

Alignment

Do all major sections follow shared key lines?

Are widths consistent?

Are financial values right aligned?

Are internal paddings consistent?

Do tables, headings, and action bars share boundaries?

Actions

Is one primary action dominant?

Are actions placed near the information they affect?

Is any action duplicated?

Do actions match the current lifecycle state?

Does a sticky action cover content?

Responsive composition

Is the mobile order intentional?

Does important information remain near the top?

Are side panels relocated correctly?

Do tables remain usable?

Does content reflow without losing functionality?

The final principle is

A welldesigned page is not a collection of attractive components. It is a controlled composition in which navigation, context, information, alignment, and actions work together to guide the user through one clear job.

When AI is not given this structural system, it fills the screen.

When AI is given this structural system, it builds the product.

15. Standardise Content Width and Alignment

This becomes obvious when users move between modules and the page title, table, and actions shift horizontally on every screen.

Inconsistent content width makes a product feel assembled from unrelated templates.

One page may use 960 pixels. Another may stretch edge to edge. A third may use 1280 pixels with different padding. Tables may begin at different alignment points. Page titles may shift horizontally between modules.

Users may not consciously identify the problem, but the application feels unstable.

Define

• Maximum content width
• Full width exceptions
• Page padding
• Section gaps
• Column gaps
• Header alignment
• Table alignment
• Side panel width
• Form width
• Modal width

Example layout tokens

• Maximum standard content width: 1180–1280 pixels
• Desktop horizontal padding: 24–32 pixels
• Tablet horizontal padding: 20–24 pixels
• Mobile horizontal padding: 16 pixels
• Major section gap: 24–32 pixels
• Internal row gap: 8–12 pixels
• Contextual panel width: 320–380 pixels

A data heavy table may use the full available content width, while a short onboarding form may use a narrower column. These are intentional exceptions rather than random differences.

The key is not selecting one universal number. The key is applying a coherent system.

16. Build Reusable Page Patterns

For example, most enterprise screens can be organised around a small number of recurring jobs such as reviewing status, comparing options, editing a form, or reading a completed record.

Do not design every page as a completely new composition.

Create a small collection of reusable page patterns.

This creates consistency and gives AI stronger boundaries.

Overview pattern

Use when the user needs a broad understanding of a project, order, account, or operation.

Possible structure

• Page or project header
• Current status
• Required action banner
• Compact key summary
• Progress
• Issues and updates
• Files and evidence
• Recent activity
• Data list pattern

Use for collections such as projects, orders, documents, or users.

Possible structure

• Title and primary action
• Summary line

Search

• Necessary filters
• Table or structured list
• Pagination
• Empty and error states
• Decision page pattern

Use when the user compares options or makes an approval.

Possible structure

• Context
• Available options
• Comparison dimensions
• Recommendation
• Selected option summary

Primary action

• Terms and supporting information
• Record page pattern

Use for completed or read only transactions.

Possible structure

• Record identity and status
• Key details
• Line items
• Totals
• Documents
• Activity or audit history
• Tracking pattern

Use for delivery, production, onboarding, or review progress.

Possible structure

• Current stage
• Required action
• Progress summary
• Milestone timeline
• Current work
• Next step
• Exceptions
• Evidence
• Closure pattern

Use when a process is being completed.

Possible structure

• Closure readiness
• Outstanding requirements
• Final documents
• Payment or financial completion
• Support
• Reorder
• Feedback

AI should select and adapt a known pattern instead of inventing a new layout for every screen.

Part Three: Designing the System Before Designing the Screens

17. Start With Structure, Not Production Code

A common example is asking AI to produce the final responsive, interactive, production ready page before the workflow and hierarchy have been reviewed.

A common failure occurs when teams ask AI to generate everything at once:

• Final layout
• Final styling
• Working interactions

Responsive behaviour

• Production ready code
• Realistic data
• All edge states

The model must make hundreds of decisions simultaneously.

A better process separates decisions into phases.

Phase 1: Product structure

Define

User

Page objective

Business rules

Required information

Primary action

States

Section order

At this stage, do not discuss shadow softness or icon colours.

Phase 2: Low fidelity layout

Create a simple structural representation.

Review

Is the most important information first?

Are related items grouped?

Is anything missing?

Is anything unnecessary?

Is the action placed correctly?

Is the density appropriate?

Phase 3: Design system application

Apply

• Typography
• Spacing
• Colour

Borders

Components

• Responsive rules
• Phase 4: Interaction

Add

• Navigation
• Selection
• Expansion

Validation

• Modals
• Status transitions
• Error handling
• Phase 5: Production implementation

Connect

• Real APIs
• Permissions
• State management
• Analytics
• Logging
• Security
• Tests

This sequence reduces expensive redesign.

18. Sketch Before Asking AI to Design

Even a rough box and arrow sketch can prevent AI from deciding the page hierarchy on its own.

A rough sketch communicates more than a vague paragraph.

It can show

• Which section appears first
• Which sections are grouped
• Where the primary action is placed
• Whether a panel is fixed
• How wide the table is
• What remains visible while scrolling
• Which information is secondary
• How desktop and mobile differ

The sketch does not need to look professional.

It can be

• A paper drawing
• A whiteboard
• A simple Figma wireframe
• An annotated screenshot
• A text based layout
• A box and arrow diagram

For example

• [Project header and current status]
• [Action required banner]
• [Summary: cost | timeline | quality | owner]
• [Progress bar] [Current stage]
• [Next milestone]
• [Issues and updates]
• [Files and evidence]

This already constrains the model.

AI is generally better at expanding a decided structure than inventing the correct structure from nothing.

The sketch also makes review more objective. Instead of rejecting a finished screen because it “feels wrong,” the team can first validate the hierarchy.

19. A Design System Is More Than a Component Library

For example, having one shared button component does not prevent pages from using different density, status language, navigation, or card behaviour.

A design system is often reduced to

• Buttons
• Inputs
• Cards
• Modals
• Colours

A complete design system also includes decisions about

• Product personality
• Information density
• Content hierarchy
• Layout
• Navigation

Status language

• Empty states
• Error patterns
• Permissions

Responsive behaviour

Accessibility

• Content writing
• Component composition

Prohibited patterns

For AI assisted development, the design system acts as a decision boundary.

Without it, AI may generate

• One page with 16-pixel radius
• Another with 8-pixel radius
• One page with outlined buttons
• Another with filled secondary buttons
• One table with 56-pixel rows
• Another with 40-pixel rows
• One warning shown in amber
• Another shown in red
• One page using cards
• Another using floating panels

A design system reduces this drift.

It should explain not only what components exist but when each component should be used.

For example

Use a card only when the content has a distinct state, action, or interaction boundary. Use a section with thin dividers when related information belongs to one continuous context.

That instruction is more valuable than merely defining the card’s border radius.

20. Define Product and Design Principles

Before defining exact pixels and colours, a team needs principles that explain how the product should behave and feel across different situations.

Before tokens, define principles.

Example product principles

Actionable clarity

The user should always understand whether action is required.

Lifecycle awareness

The interface should reflect the current stage and show what happens next.

Customer appropriate transparency

Show enough information to create trust without exposing irrelevant internal operations.

Evidence over claims

Completed work should be supported by documents, dates, reports, or audit records.

State correctness

Actions and information must change correctly across draft, active, completed, cancelled, and read only states.

Example design principles

Compact but readable

Use information density appropriate for professional users without creating visual clutter.

Restrained colour

Use colour primarily for brand emphasis, state, risk, and feedback.

Fewer containers

Prefer hierarchy, spacing, and dividers over placing every section inside a card.

One dominant action

Each decision area should have one visually dominant action.

Consistent alignment

Page titles, sections, tables, and actions should follow shared alignment lines.

Minimal does not mean empty

Remove decorative noise, not useful operational context.

These principles help resolve decisions that tokens alone cannot answer.

21. Define Spacing Tokens

Random spacing is one of the clearest signs of an unstructured AI generated interface.

Use a spacing scale such as

• 4 pixels
• 8 pixels
• 12 pixels
• 16 pixels
• 24 pixels
• 32 pixels
• 40 pixels
• 48 pixels

Then define typical uses.

4 pixels

Use between tightly related metadata.

8 pixels

Use between an icon and label, or between compact controls.

12 pixels

Use between related rows or inside compact components.

16 pixels

Use for standard internal component padding.

24 pixels

Use between related subsections.

32 pixels

Use between major page sections.

40–48 pixels

Use sparingly between large conceptual areas.

The purpose is not to prevent every exception. It is to create rhythm.

A common AI failure is combining

• 10-pixel gaps
• 18-pixel padding
• 30-pixel section margins
• 22-pixel card gaps

without a reason.

A stable spacing system improves visual quality even before colours or typography change.

22. Typography for Operational Applications

Typography should create hierarchy without relying on excessive size or weight.

A possible system

• Page title: 24–28 pixels, semibold
• Page subtitle: 14 pixels, regular, muted
• Section title: 16–18 pixels, semibold
• Subsection title: 14 pixels, medium or semibold
• Body: 14 pixels, regular
• Table text: 13–14 pixels
• Labels: 12–13 pixels, medium
• Metadata: 12 pixels, regular, muted
• Important numeric value: 18–24 pixels depending on context

The exact sizes depend on the application, but the relationships should remain stable.

Avoid bold text everywhere

If titles, labels, values, statuses, and metadata are all bold, nothing is emphasised.

Use weight to show importance.

Avoid excessively grey text

Muted text should remain readable. Low contrast creates a stylish screenshot but a poor working interface.

Treat numbers carefully

Financial values, quantities, percentages, and dates should be easy to compare.

Use

• Right alignment for comparable numeric columns
• Consistent decimal formatting
• Consistent currency formatting
• Tabular numerals when available
• Clear negative and positive indicators
• Monospace only when useful, such as technical identifiers
• Use line height intentionally

Dense does not mean cramped. Body copy still needs sufficient line height for scanning.

23. Colour Should Communicate Meaning

A strong enterprise interface usually begins with a neutral foundation.

Use

• Neutral page background
• Neutral surfaces
• Clear text hierarchy
• One main brand accent
• Semantic colours for status

Possible semantic meanings

• Green: confirmed success or completion
• Amber: warning or attention
• Red: error, failure, or destructive action
• Blue: informational state or selected state
• Grey: inactive, pending, unavailable, or neutral

Do not use colour simply to make the page feel lively.

Common failure patterns include

• Every metric has a different icon colour
• Every section has a tinted background
• Every status uses a pastel pill
• Gradients are added to primary cards
• Success green is used for ordinary positive numbers
• Warning amber is used for decorative highlights

This weakens meaning.

When everything is colourful, genuinely important states become less visible.

A useful rule is

Before adding colour, ask what information the colour communicates.

Also ensure that colour is not the only indicator. Include labels, icons, patterns, or text for users with colour vision differences.

24. Define Shape, Border, and Elevation Rules

AI generated interfaces frequently overuse shape.

Common patterns include

• 20–24-pixel card radius
• Pill-shaped inputs
• Rounded tables
• Rounded banners
• Rounded metric tiles
• Rounded icon boxes
• Rounded nested containers

A more controlled system might define

• Standard container radius: 8 pixels
• Input radius: 6–8 pixels
• Button radius: 6–8 pixels
• Modal radius: 10–12 pixels
• Pill radius: reserved for genuine tags or statuses
• No radius above 12 pixels except intentionally branded components

Borders and shadows should also have rules.

Borders

Use one pixel neutral borders for

• Inputs
• Tables

Dividers

• Standard containers
• Selected areas when appropriate

Shadows

Use shadows mainly for

• Menus
• Popovers
• Dialogs
• Floating overlays
• Sticky elements requiring separation

Avoid using shadows on every card.

Dividers

Use dividers when related information belongs to the same section.

Separate containers

Use separate containers when content has its own

• State
• Action
• Interaction
• Permission boundary
• Scroll behaviour

This prevents unnecessary box heavy layouts.

25. Good Minimalism Versus Empty Minimalism

This problem often appears after the instruction “make it more minimal,” when AI removes useful context instead of removing visual noise.

Minimalism is frequently misunderstood.

A user says

Make the page minimal.

The AI responds by

• Removing useful details
• Increasing empty space
• Making text smaller
• Turning everything grey
• Hiding actions
• Reducing contrast
• Removing operational context
• Leaving one large empty card

The result may look clean in a screenshot but becomes less useful.

Good minimalism

Good minimalism includes

• Strong hierarchy
• Limited competing surfaces
• Clear section relationships
• Visible key information
• Clear next action
• Consistent spacing
• Reduced decoration
• Progressive disclosure
• Readable typography
• Appropriate density

Empty minimalism

Empty minimalism includes

• Large unused areas
• Missing context
• Weak labels
• Tiny metadata
• Unclear actions
• Low contrast
• Removed evidence
• Hidden business rules
• Pages that feel unfinished

The goal is not to minimise information.

The goal is to minimise unnecessary visual competition.

A useful instruction is

Reduce decorative containers and repeated helper text, but preserve all information required for decisions, workflow understanding, risk awareness, and evidence.

26. Familiar Design Is Not Automatically Generic

For example, two products may both use tables and left navigation while still feeling completely different because their workflows, terminology, density, and decisions are different.

Users benefit from familiar interaction patterns.

They generally understand

• Left navigation
• Tabs
• Search fields
• Standard forms
• Checkboxes
• Tables
• Dropdowns
• Primary buttons
• Modal confirmations
• Breadcrumbs

A product does not become valuable by making these interactions unusual.

The goal is not to create novelty for its own sake.

A familiar application can still feel distinctive through

• Domain specific workflows
• Appropriate information density
• Clear terminology
• Brand typography
• Consistent spacing
• Meaningful status patterns
• Relevant evidence
• Specialised page structures
• Thoughtful customer communication

The difference is

Familiar design uses known patterns intentionally.

Generic design uses common patterns without understanding the product.

A healthcare platform and an industrial sourcing platform may both use tables. That is not a problem. Their tables should contain different information, support different decisions, and behave according to different business rules.

Part Four: Components for Real Business Software

27. Stop Making Everything a Card

Imagine a project overview where status, progress, owner, next milestone, and expected date are each placed inside separate cards.

Cards are useful when they create meaningful separation.

They are not useful when every piece of information becomes its own floating rectangle.

Common card overuse patterns include

• One card for each metric
• One card for each row
• One card for current status
• One card for next step
• One card for expected date
• One card for owner
• Cards inside larger cards

This creates visual fragmentation.

Instead, ask whether information can be combined into one structured section.

For example, instead of four separate cards

• Total cost
• Delivery time
• Coverage
• Quality result

use one summary section with four aligned columns and thin dividers.

This creates

• Better comparison
• Less visual noise
• Stronger alignment
• Lower vertical height
• More consistent density

Use a card when

• The section has an independent action
• It has a distinct status
• It can be moved or reused independently
• It needs its own interaction boundary
• It requires visual isolation

Use rows and dividers when

• Information belongs to one continuous subject
• The user must compare values
• The section has one shared action
• The content is primarily descriptive

28. Design Clear Statuses

For example, a customer looking at an order should immediately understand whether it is waiting, blocked, delayed, completed, or waiting for their action.

A status should communicate the current condition of an object or process.

Examples

• Draft
• Under review
• Action required
• Approved
• In progress
• Delayed
• Completed
• Rejected
• Cancelled
• Expired
• Paid
• Partially paid
• Unpaid

Do not create a colourful pill for every descriptive phrase.

For example

“Updated 2 hours ago” is metadata, not necessarily a status.

“Owned by Priya” is ownership, not a status.

“12 files” is a count, not a status.

“High value” may be a classification, not a workflow status.

Status components should follow consistent rules

• Same wording for the same state
• Same semantic colour for the same meaning
• Same placement within similar pages
• Clear relationship to available actions
• Accessible text
• No colour only meaning

Also distinguish between system status and user action.

“Under review” describes a system state.

“Action required” tells the user that they need to do something.

A page can contain both

Technical review is paused because a revised file is required from you.

This is more useful than showing only an amber “Pending” pill.

29. Design Progress Around Meaningful Milestones

Imagine seeing “72% complete” without knowing what is finished, what is happening now, or what is blocking the remaining work.

Progress is often represented by a percentage without explaining what the percentage means.

A circular gauge displaying “72% complete” may look impressive but provide little guidance.

Users need to know

• Which stages are complete
• What is happening now
• What comes next
• Whether anything is blocked
• Whether action is required
• When the next update is expected

A useful progress component may include

• Header
• Project progress
• Six of eight stages complete
• Action banner

Shown only when action is required.

Example

Updated specification required

Upload the revised file to continue production review.

• Numeric summary
• 75% complete

Stage 7 of 8 is in progress.

Horizontal bar

A compact visual summary.

• Vertical milestones
• Requirement confirmed — 12 August
• Commercial approval — 14 August
• Materials secured — 18 August
• Production started — 20 August
• Quality review — In progress
• Dispatch — Upcoming
• Delivery — Upcoming
• Closure — Upcoming
• Current stage description

Final inspection is in progress. Dimensional checks are complete, and documentation review is underway.

Next expected step

Dispatch planning begins after final approval.

This is more useful than a decorative gauge.

30. Avoid Long Horizontal Progress Rails

This becomes a serious problem when a simple three step checkout pattern is reused for an operational process containing eight or more stages.

Horizontal progress rails work well for short, simple processes such as:

• Details
• Payment
• Confirmation

They become difficult when there are many stages.

Problems include

• Labels become unreadable
• Mobile layouts break
• Completed and upcoming stages become visually crowded
• Detailed dates do not fit
• Sub stages cannot be represented
• Users cannot easily understand the current work

For complex operational processes, use

• A compact progress bar for overall completion
• A vertical timeline for milestones
• A separate detailed module for sub stages

The overview should communicate the current situation, not display every internal task.

For example, an overview might show

Assembly — In progress

The detailed assembly page can show

• Material kitting
• Line setup
• First article inspection
• Main assembly
• Functional test
• Rework
• Final inspection

This preserves clarity while keeping detail available.

31. Design Action Hierarchy

For example, a quotation page may allow downloading, asking a question, selecting an option, approving, rejecting, and purchasing—but only one of those actions should dominate at the current stage.

Every visible action competes for attention.

A page may contain

• Approve
• Reject
• Download
• Share
• Edit
• Compare
• Contact support
• Save
• Cancel
• Upload
• Add note
• View history

The design should communicate which action matters most at the current stage.

Primary action

The main action required to complete the page’s job.

Examples

• Proceed to payment
• Submit for review
• Approve quotation
• Upload revised file
• Confirm dispatch
• Save changes

Secondary action

Useful but not dominant.

Examples

• Download PDF
• Save draft
• Ask a question
• View calculation

Tertiary action

Lower priority actions shown as links or menu items.

Examples

• View history
• Duplicate
• Export data

Destructive action

Requires clear warning and often confirmation.

Examples

• Delete
• Cancel order
• Remove user
• Reject permanently

Avoid making several actions visually equal.

Also avoid duplicating the same action in multiple areas unless there is a strong usability reason.

A sticky bottom action can be useful on long review pages, but the same action may not need to appear in the top header, side panel, and footer simultaneously.

32. Design Tables for Real Operational Work

Consider an operations user reviewing hundreds of orders or line items. The table must support comparison and action, not merely display data attractively.

Tables are appropriate when users need to compare structured information across multiple records.

Examples include

• Orders
• Line items

Components

• Users
• Documents
• Quality issues
• Transactions
• Shipments
• Audit events

A useful table begins with column priority.

Ask

Which columns support the user’s decision?

Which columns are secondary?

Which columns are useful only after opening a row?

Which values must be compared?

Which values must remain visible while scrolling?

Which columns can be hidden on smaller screens?

Row density

Frequent professional users often benefit from compact rows.

However, compact should still allow

• Readable text
• Clear hover state
• Sufficient click target
• Visible status
• Multi line content where necessary
• Numeric alignment

Right align

• Quantity
• Unit price
• Tax
• Total
• Percentage
• Variance
• Text alignment

Left align

• Name
• Description
• Owner
• Status label
• Category
• Selection

Do not add checkboxes unless a meaningful bulk action exists.

A checkbox column with no bulk workflow creates unnecessary complexity.

Filters

Do not add filters simply because tables usually have filters.

Use filters that support real decisions.

For example

• Status
• Owner
• Date range
• Risk
• Category

Avoid ten low value filters that make the page feel powerful but slow down ordinary use.

Search

Search is useful when users know what they are looking for.

Filters are useful when users want to narrow a known category.

Sorting is useful when comparison order matters.

These are different behaviours and should not be added automatically.

33. Design Forms Around Necessity

For example, an onboarding form may ask for company size, systems, tax details, integrations, and internal preferences even when only a few fields affect the next step.

Every form field creates cost.

The user must

• Understand it
• Enter data
• Correct mistakes
• Trust why it is required

The organisation must

• Store it
• Protect it
• Validate it
• Maintain it
• Use it responsibly

Before adding a field, ask

What decision, workflow, calculation, permission, compliance rule, or downstream operation requires this information?

If no answer exists, the field may not be necessary.

Required versus optional

Do not mark most fields optional while still visually presenting them as equal.

Group optional details under

• Additional information
• Advanced settings
• Add another detail
• Progressive disclosure

Show fields only when relevant.

For example, asking “Do you use an existing accounting system?” can reveal a searchable system selector only when the answer is yes.

Searchable multi select

Use when

• The option set is large
• Users may select several values
• Search reduces scrolling
• The selections are important for configuration

“Other” option

Use “Other” only when the system can handle the resulting value.

Do not include it automatically if the product cannot use free text answers.

Helper text

Use helper text when it prevents a mistake.

Avoid adding a descriptive sentence under every field.

Validation

Explain

• What is wrong
• How to correct it
• Whether the entered data was preserved

Bad

Invalid input.

Better

Enter a work email in the format name@company.com.

34. Design File Uploads as a Workflow

Imagine a customer uploading a technical drawing that controls whether review or production can continue. A basic file picker does not provide enough guidance or confidence.

A file upload control is not enough for many business applications.

The user may need to understand

• Which file is required
• Why it is required
• Accepted format
• Maximum size
• Naming requirements
• Version requirements
• Whether multiple files are allowed
• Whether an earlier file will be replaced
• How long processing takes
• Whether validation succeeded
• What happens after upload

A complete upload flow may include

• Requirement explanation
• File selection
• Upload progress
• Format validation
• Processing state
• Validation result
• Error resolution
• Successful confirmation
• Next step explanation

For example

Upload the revised technical drawing as a PDF or DXF file under 50 MB. The previous version will remain available in version history.

After upload

Drawing v4 uploaded successfully. Automated validation is in progress and usually completes within two minutes.

After validation

Validation completed. Two dimensions require confirmation before review can continue.

This creates trust and reduces uncertainty.

35. Design Quotation and Comparison Experiences

Consider a customer choosing between a lower cost option and a faster delivery option. The page must explain the commercial trade off, not simply display two attractive cards.

A quotation page is a decision page, not merely a data display.

The user may need to compare

• Price
• Delivery time
• Coverage
• Availability
• Quality level
• Warranty
• Service level
• Alternatives
• Risk
• Payment terms
• Validity

The page should clearly explain what each option optimises.

Examples

Best price

Lowest overall cost, with a longer expected delivery time.

Faster delivery

Prioritises available inventory and expedited processing.

Balanced option

Balances cost, lead time, and supply reliability.

The selected option should remain visible.

Example

• Faster delivery selected
• ₹184,500 total
• Estimated completion: 12–15 working days

The page should also explain incomplete coverage.

Example

82 of 86 items are fully priced. Three items are awaiting supplier confirmation, and one alternative has been suggested.

Avoid adding

• Row checkboxes when individual line selection is not allowed
• Bulk selection controls without a bulk decision
• Unrelated charts
• Internal sourcing details
• Scores that the user cannot interpret
• Several competing purchase buttons

The primary job is to help the user make a confident decision.

36. Separate Quotation, Checkout, Payment, and Record States

This distinction matters because the same commercial information serves different purposes before purchase, during payment, and after the transaction is complete.

These states should not be mixed.

Quotation state

The user reviews

• Scope
• Options
• Price
• Delivery
• Terms
• Pending items

Primary action

• Select option
• Proceed to purchase

Checkout state

The user confirms

• Billing details
• Tax information
• Delivery address
• Purchase order
• Payment method

Primary action

Continue to payment

Payment state

The user completes the transaction.

Primary content

• Payment amount
• Payment method
• Secure provider
• Processing feedback
• Failure recovery

Payment success state

The system confirms

• Payment reference
• Order number
• Amount
• Date
• Next step
• Workspace availability

Post payment record

The quotation becomes a read only commercial record.

It should show

• Approved status
• Paid status
• Quote number
• Issuer
• Line items
• Subtotal
• Tax
• Grand total
• Downloadable documents

It should not show

• Change option
• Add to cart
• Approve
• Edit line items
• Apply coupon

State correctness is a major part of good UX.

37. Design Quality and Exception Management

For example, a quality percentage alone cannot explain what failed, whether it was resolved, whether delivery is affected, or whether the customer must act.

Quality pages should not only display a green success percentage.

Customers may need to understand

• What was inspected
• Which standards were used
• How many items passed
• What failed
• Whether rework was required
• Whether the issue was resolved
• What evidence is available
• Whether customer action is required

A useful issue record may include

• Issue title
• Severity
• Affected item
• Detected stage
• Description
• Evidence
• Immediate action
• Root cause when available
• Resolution
• Owner
• Expected resolution date
• Final status

Customer facing language should remain clear and accountable.

Weak

QC issue found.

Stronger

Two units failed the initial functional test because of an incorrect connector orientation. The units have been isolated for rework. No action is required from you, and the updated completion date remains 29 August.

If customer action is required

The enclosure dimensions do not match the approved drawing. Confirm the revised dimension by 3:00 PM tomorrow to avoid delaying assembly.

This communicates the problem, impact, action, and timing.

38. Design Documents and Evidence

Imagine a project containing technical files, approvals, inspection reports, delivery records, and invoices. A single unstructured download list quickly becomes difficult to trust and navigate.

Documents should not be presented as one unstructured file dump.

Organise them by purpose.

Possible categories

• Requirements
• Quotations
• Purchase records
• Technical files
• Quality reports
• Delivery documents
• Invoices
• Final package

For each file, consider showing

• File name
• Category
• Version
• Status
• Uploaded by
• Upload date
• File size
• Preview
• Download
• Approval state
• Related stage

Versioning is important.

Instead of replacing a file invisibly, show

• Drawing_v4.pdf — Current
• Drawing_v3.pdf — Superseded
• Drawing_v2.pdf — Archived

Evidence should also be connected to work.

A completed quality milestone can link directly to

• Inspection report
• Test results
• Images
• Certificate

This is stronger than a generic “Completed” label because it gives the user proof.

39. Design Activity and Audit History Differently

For example, a customer may need to know that inspection started, while an administrator may need the exact user, timestamp, previous value, and permission context behind the change.

Activity feeds and audit logs serve different purposes.

Activity feed

Designed for ordinary users.

It may contain

• File uploaded
• Review completed
• Comment added
• Milestone updated
• Payment received
• Shipment dispatched

The language should be understandable.

Audit log

Designed for compliance, security, or administrative review.

It may contain

• User
• Timestamp
• Action
• Previous value
• New value
• Source
• IP or device information
• Permission context

Do not expose technical audit information to all users by default.

Also avoid filling the overview with every system event.

Show meaningful activity.

For example

“Status field changed from processing_state_4 to processing_state_5” is not useful customer communication.

“Final inspection started” is useful.

Part Five: States, Responsiveness, and Accessibility

40. Design Empty States Intentionally

An empty project list, an empty search result, and a quality page with no open issues are all empty states, but they communicate completely different situations.

An empty state is not simply a blank table with “No data.”

Different empty states have different meanings.

New account

The user has not created anything.

The page should explain

• What this area is for
• How to begin
• What information is required

Example

No projects yet

Create your first project to submit requirements, receive a quotation, and track execution.

No search results

Data exists, but nothing matches the current search.

The page should suggest

• Clear search
• Remove filters
• Try another term

No issues

This is a positive state.

Example

No open quality issues

All recorded inspections are currently resolved.

No documents

The message depends on whether the user is expected to upload something.

Example

No delivery documents are available yet. They will appear after dispatch is scheduled.

An empty state should explain why it is empty and what happens next.

41. Design Loading States Based on the Operation

For example, loading a page, uploading a file, processing a quotation, and running a background validation should not all use the same unexplained spinner.

Not every loading state should use the same spinner.

Use

Skeletons

For page content that is expected to load quickly.

Progress bars

For uploads or operations with measurable completion.

Step messages

For long processes with meaningful phases.

Example

• Uploading file
• Validating format
• Processing data
• Preparing results
• Background processing state

When the user can leave the page.

Example

Validation is running in the background. You can continue working, and we will notify you when the results are ready.

Avoid indefinite loading without explanation.

If an operation may take time, tell the user

• What is happening
• Whether they can leave
• How they will know it is complete
• What to do if it fails

42. Design Error States for Recovery

Imagine a payment or upload failing after the user has already spent several minutes entering information. The message must explain what happened and how to recover.

An error message should help the user recover.

A strong error contains

• What happened
• Why it happened when known
• What the user can do
• Whether their work was saved
• How to get help if necessary

Weak

Something went wrong.

Stronger

Payment could not be completed because the bank declined the transaction. No amount was charged. Try another payment method or contact your bank.

Weak

Upload failed.

Stronger

The file could not be uploaded because it is larger than 50 MB. Your current form data has been saved. Compress the file or upload it as a ZIP archive.

Also distinguish

• Validation error
• Permission error
• Network error
• Server error
• Data conflict
• Expired session
• Payment failure
• Processing failure

Each requires a different recovery path.

43. Design Edge Cases Before Production

A prototype may look perfect with short names and complete data, but production users will introduce long values, missing fields, delays, cancellations, and partial states.

AI-generated prototypes often contain perfect data

• Short names
• Complete records
• One currency
• No missing values
• No long file names
• No delays
• No partial payment
• No rejected decisions

Production data is not perfect.

Test

• Very long organisation names
• Very large totals
• Zero values
• Negative variance
• Missing dates
• Unknown owners
• Several open issues
• Hundreds of table rows
• Expired records
• Cancelled transactions
• Partial completion
• Delayed milestones
• Duplicate file names
• Multiple currencies
• Different time zones
• Long translated text
• Unavailable integrations
• Restricted permissions

A design that works only with perfect placeholder data is not production ready.

44. Responsive Design Is More Than Stacking

For example, stacking a desktop quotation page into one long mobile column may place the selected option and purchase action far below the information the user needs first.

A common AI generated mobile layout simply places every desktop component in one vertical column.

This may technically fit the screen but does not create a useful mobile experience.

Responsive design should reconsider priority.

On mobile

What must remain visible?

Which actions should become sticky?

Which summary information should appear first?

Which table columns can be hidden?

Which details should open in a drawer?

Should filters become a modal?

Can the sidebar become a menu?

Should the contextual panel move below the main content?

Can a wide comparison become horizontally scrollable?

Should a complex form remain multi step?

For example, a project overview on mobile may prioritise

• Current status
• Required action
• Next milestone
• Progress
• Issues
• Files

A desktop right side action panel may become a sticky bottom action area.

A large line item table may become

• A horizontally scrollable table for expert users
• A structured card list for simpler records
• A summary list with row detail drawers

Choose based on the user’s task, not a generic mobile rule.

45. Accessibility Must Be Included From the Beginning

Accessibility decisions affect the page structure, interaction, labels, focus order, and feedback—not only a final compliance check.

Accessibility should not be added after the visual design is complete.

Include it in the system and prompts.

Important areas include

Keyboard navigation

Users should be able to

• Move through controls
• Open menus
• Select options
• Submit forms
• Close dialogs
• Navigate tables

Focus states

Focus must be visible and consistent.

Do not remove focus outlines without providing an accessible alternative.

Contrast

Text, icons, borders, and statuses must remain readable.

Semantic structure

Use

• Correct heading levels
• Form labels
• Table headers
• Buttons for actions
• Links for navigation
• Lists where appropriate
• Screen reader labels

Icons without visible text require accessible names.

Form errors

Associate errors with the relevant field.

Status announcements

Important changes such as upload completion or payment failure should be announced appropriately.

Reduced motion

Respect user preferences for reduced motion.

Touch targets

Interactive elements should be large enough for touch use.

Accessible interfaces are usually clearer for everyone because they require explicit labels, predictable interaction, and meaningful structure.

Part Six: Content Design and Product Communication

46. Write Microcopy That Explains the Product

For example, a well designed button can still create uncertainty when its label says only “Continue” and does not explain what will happen next.

Good UI/UX includes language.

Weak product language creates uncertainty even when the layout is strong.

Page titles

Use titles that match the user’s mental model.

Weak

Management Console

Better

Project access

Button labels

Use actions that describe the result.

Weak

Continue

Better

Review quotation

Weak

Submit

Better

Submit for technical review

Status language

Avoid vague statuses such as

• Processing
• Pending
• Active

unless the meaning is clear from context.

Better

• Awaiting customer approval
• Technical review in progress
• Payment confirmation pending
• Ready for dispatch

Helper text

Use only when it prevents confusion.

Weak

Enter your email address here.

Better

Use your company email. Personal email addresses are not accepted.

Confirmation language

Tell the user what happened and what happens next.

Example

Your quotation has been approved. Continue to checkout to confirm billing details and complete payment.

Content design should reduce the number of questions users must ask support teams.

47. Avoid Internal Jargon

This is especially important when internal teams use abbreviations and process language that customers have never seen before.

Internal teams often use language that customers do not understand.

Examples

• RFQ batching
• PO reconciliation
• GRN completed
• NCR raised
• Vendor allocation
• Internal gate approval
• L2 verification
• Finance closure queue

These terms may be valid internally but inappropriate for customer facing interfaces.

Translate them into user meaning.

Internal

GRN discrepancy under reconciliation.

Customer

A quantity difference was identified during receiving and is being resolved.

Internal

NCR raised during incoming QC.

Customer

A quality issue was identified during incoming inspection. The affected material has been isolated for review.

Do not oversimplify important facts, but present them in language that helps the user understand impact and next steps.

48. Use Realistic Content and Data

For example, a layout tested only with “Project Alpha,” short filenames, and round totals may break as soon as realistic enterprise data is used.

Placeholder content influences design.

If every project name is “Project Alpha” and every price is “$12,000,” the interface is not being tested realistically.

Use

• Long project names
• Long customer names
• Realistic quantities
• Different statuses
• Missing values
• Long file names
• Multiple dates
• Pending information
• Partial coverage
• Open issues
• Realistic tax breakdowns
• Large totals
• Different currencies when relevant

Example project names

• Regional Warehouse Automation and Safety Upgrade
• High Volume Controller Assembly for North Plant
• Multi Site Employee Access Migration

Example file name

Revised_Assembly_Drawing_Approved_2026-08-14_v7.pdf

Example status combinations

• Payment completed, production delayed
• Technical review completed, customer approval pending
• Quality inspection partially completed
• Delivery completed, invoice payment outstanding

Realistic data exposes layout problems before release.

Part Seven: Working With AI More Effectively

49. Use the Existing Repository as Context

Imagine asking AI to redesign one page without showing it the existing components, tokens, permissions, or data patterns already used by the product.

AI produces better results when it works inside the real product repository.

The repository provides

Existing components

Design tokens

• CSS variables
• Layout patterns
• Naming conventions
• Folder structure
• State management approach
• Form libraries
• Table components
• Permission utilities
• API patterns

Responsive behaviour

Accessibility conventions

Without repository context, AI may create

• Duplicate button components
• New spacing values
• Another modal system
• Different status badges
• Inconsistent table behaviour
• Hard coded colours
• Unsupported state management
• Invented APIs

A useful instruction is

Inspect the existing repository before creating new components. Reuse the current application shell, typography, buttons, inputs, status badges, tables, and spacing tokens. Create a new component only when no suitable reusable component exists.

AI should also be told

• Preserve the existing folder structure
• Preserve current state management
• Do not replace working dependencies without a reason
• Do not invent backend endpoints
• Clearly mark mocked data
• Do not change unrelated screens
• Maintain existing accessibility behaviour

Repository context turns AI from a template generator into an implementation assistant.

50. Create a Repository Instruction File

A reusable instruction file prevents every new AI session from starting with incomplete product and design context.

A reusable instruction file can improve every future task.

Possible file names include

• PRODUCT_CONTEXT.md
• DESIGN_SYSTEM.md
• AI_INSTRUCTIONS.md
• CLAUDE.md
• AGENTS.md

The exact name depends on the tools being used.

The file should include

Product context

• What the product does
• Who uses it
• Primary workflows
• Main modules
• Domain terminology
• User roles
• Customer
• Employee
• Administrator
• Partner
• Finance user
• Technical reviewer
• Visibility rules
• Which information is customer visible
• Which information is internal
• Which controls are role\ restricted
• Lifecycle rules
• Creation
• Review
• Approval
• Payment
• Execution
• Quality
• Delivery
• Closure
• Design rules
• Content width
• Spacing
• Typography
• Colour
• Radius

Borders

• Tables
• Forms
• Statuses

Responsive behaviour

• Engineering rules
• Reuse existing components
• Follow architecture
• Preserve data flow
• Do not invent backend behaviour
• Maintain types
• Handle loading and error states
• Maintain accessibility

Prohibited patterns

• No second sidebar
• No decorative gradients
• No unnecessary charts
• No excessive cards
• No random coloured icon boxes
• No duplicated primary actions
• No admin controls in customer views
• No changes to global navigation unless requested
• No removal of decision critical information

This context prevents repeated correction.

51. Use Screenshots Correctly

For example, a reference screenshot may have useful table density but completely inappropriate branding, navigation, and consumer style interactions for your product.

Screenshots are useful, but “make it like this” is insufficient.

AI may copy

• Brand colours
• Navigation
• Consumer interaction patterns
• Excessive radius
• Content that does not apply
• A layout designed for another user type

Explain the purpose of each reference.

Example

Use Reference A for its compact information hierarchy and spacing rhythm. Do not copy its colours, branding, navigation, or rounded card treatment.

Use Reference B for table density and row expansion behaviour.

Use Reference C only for mobile filter interaction.

You can use different references for

• Page structure
• Tables
• Forms
• Density
• Visual style

Responsive behaviour

Interaction

Also annotate screenshots.

Mark

• Keep
• Remove
• Move
• Merge
• Make read only
• Hide after payment
• Show only for admins
• Use as sticky action

A screenshot becomes more useful when the decisions are explained.

52. Ask AI for Analysis Before Redesign

Before changing a page, AI should first explain what is wrong with the workflow, hierarchy, content, interaction, and visual system.

Before asking AI to rewrite the interface, ask it to evaluate the current screen.

The evaluation should identify

• Product issues
• Missing business information
• Incorrect actions
• Wrong state behaviour
• Internal data exposed to users
• Missing permissions
• Information architecture issues
• Weak hierarchy
• Repetition
• Unclear grouping
• Navigation duplication
• Important information buried
• Interaction issues
• Unclear actions
• Disabled actions without explanation
• Missing confirmations
• Missing states
• Unclear selection
• Visual issues
• Too many boxes
• Too much colour
• Weak alignment
• Inconsistent typography
• Excessive whitespace
• Poor density

Then ask for a proposed structure before code.

This creates three stages

• Critique
• Proposed information architecture
• Implementation

It is usually more reliable than immediately asking

Redesign this page.

53. Write Prompts in a Structured Order

A structured prompt works like a compact product specification: it removes the decisions that AI should not invent.

A strong AI design prompt can follow this structure.

1. Role

Act as a senior B2B SaaS product designer and frontend engineer.

2. Product context

Explain

• What the product does
• Which domain it serves
• Which modules exist

3. User context

Explain

• Who is using the page
• Their expertise
• Their goal

4. Page objective

Write one clear sentence.

Example

The user’s primary job is to understand the current project status, identify whether action is required, know what happens next, and access supporting evidence.

5. Business rules

List rules that must remain true.

6. Current problems

Describe observable issues.

Example

• Too many independent cards
• Inconsistent alignment
• Duplicate status information
• Several competing actions
• Too much colour
• Missing next step context

7. Required information

List what must remain visible.

8. Required structure

Define the section order.

9. Design system rules

Specify

• Width
• Typography
• Spacing
• Colour

Borders

Components

10. Reuse constraints

Explain which existing components must be used.

11. Prohibited patterns

Explain what not to generate.

12. Required states

Include

• Loading
• Empty
• Error
• Action required
• Completed
• Read only

13. Responsive behaviour

Describe desktop, tablet, and mobile priorities.

14. Output expectation

Ask for

• Wireframe
• Component plan
• Code
• Design critique
• State matrix

Structured prompts reduce accidental decisions.

54. Replace Subjective Feedback With Observable Rules

For example, feedback such as “make it cleaner” does not tell AI whether to remove content, reduce colour, merge sections, or fix alignment.

Weak feedback

This looks bad.

Useful feedback

The page uses seven independent cards for information that belongs to one project summary. Merge related metrics into one section with thin vertical dividers.

Weak feedback

Make it less colourful.

Useful feedback

Remove decorative background colours from standard sections. Keep colour only for the selected option, status, warning, error, and primary action.

Weak feedback

Fix alignment.

Useful feedback

Align the page title, summary section, table, and bottom action bar to the same content grid. Right align all financial values and keep labels left aligned.

Weak feedback

Make it minimal.

Useful feedback

Reduce decorative containers and repeated helper text, but preserve status context, next steps, exceptions, financial details, and evidence.

Weak feedback

Make the design premium.

Useful feedback

Use restrained neutral surfaces, consistent typography, strong alignment, compact spacing, and subtle one pixel borders. Avoid gradients, glowing shadows, and decorative illustrations.

AI responds more reliably when the requested change can be observed and verified.

55. Use an Anti Generic UI Instruction

This instruction is useful when AI repeatedly falls back to gradients, floating cards, oversized metrics, and generic dashboard patterns.

A reusable anti generic instruction can be placed near the beginning of design tasks.

Do not generate a generic AI SaaS interface. Avoid decorative gradients, glassmorphism, excessive rounded cards, oversized metric tiles, colourful icon containers, unnecessary status pills, random charts, decorative shadows, and large unused whitespace.

Use a compact, structured, trustworthy interface appropriate for professional operational software. Prefer thin dividers, restrained neutral backgrounds, strong alignment, clear typography, compact data rows, meaningful status communication, and one primary action per decision area.

Preserve all decision critical information and business rules. Minimal does not mean empty. Use progressive disclosure for secondary information instead of deleting useful context.

This should not be treated as a complete prompt.

It must be combined with

Product context

User context

Page objective

Business rules

Required structure

Design tokens

Existing components

Required states

The instruction controls visual tendencies, while the rest controls product correctness.

56. Preserve Scope

For example, improving one quotation screen should not silently replace the product sidebar, typography, colour system, or project header.

AI can make unrelated changes when scope is unclear.

For example, a request to improve one quotation page may result in

• A new global sidebar
• Changed colours across the application
• New navigation
• Different typography
• New project header
• Changed button system

This creates inconsistency and unnecessary work.

State the scope explicitly.

Example

Redesign only the quotation content area. Preserve the existing global sidebar, project header, tabs, content width, typography tokens, and navigation. Do not modify other project modules.

For a system wide change

Apply the updated status component across all project types and modules. Preserve project-specific labels and lifecycle rules.

Scope should include

• Current screen only
• Current module
• Current workflow
• All project types
• Global design system
• Specific components

This prevents accidental redesign.

57. Ask AI to Preserve Product Logic

A redesigned screen can look better while becoming less correct when selection, permissions, or lifecycle behaviour changes accidentally.

A visual redesign should not silently change behaviour.

Use instructions such as

Preserve the current information, user permissions, lifecycle, and action logic. Change only information hierarchy, component composition, spacing, typography, and visual treatment unless a product logic change is explicitly listed.

When a product logic change is required, list it separately.

Example

Product changes

Remove selection checkboxes because line items cannot be individually approved.

Replace “Approve quotation” with “Proceed to purchase.”

Make the quotation read only after payment.

Hide internal supplier information from customers.

Visual changes

Merge four metric cards into one summary section.

Reduce coloured backgrounds.

Align totals to the right.

Use thin dividers.

Add a sticky purchase summary on long screens.

Separating product and visual changes makes implementation clearer.

58. Tell AI What Not to Invent

When information is missing, AI often fills the empty space with plausible looking fields, metrics, charts, permissions, and workflow steps.

Models often fill missing areas with invented content.

They may invent

• Backend data
• Analytics
• Scores
• Charts
• User permissions
• Workflow stages
• Notifications
• Payment methods
• API behaviour
• Integrations

Filters

Admin controls

Use explicit restrictions.

Do not invent backend fields, analytics, workflow stages, user permissions, charts, integrations, or actions. Use only the supplied data model and existing repository capabilities. If information is missing, mark it as a design assumption rather than implementing unsupported behaviour.

For prototypes

Clearly label mocked interactions and sample data. Do not present mocked values as production data.

This is particularly important in B2B products where invented fields can change business meaning.

Part Eight: Review, Testing, and Production

59. Review AI Generated UI in the Correct Order

For example, there is little value in debating shadows and colours while a paid quotation still displays an active purchase button.

Reviewing aesthetics first leads to repeated rework.

Use the following order.

Layer 1: Product logic

Ask

Is the workflow correct?

Are business rules preserved?

Are actions correct for the current state?

Are permissions respected?

Is internal information hidden appropriately?

Does the lifecycle make sense?

Layer 2: User usefulness

Ask

Does the page answer the user’s main questions?

Is required action obvious?

Is the next step clear?

Is supporting evidence available?

Can the user make the intended decision?

Layer 3: Information architecture

Ask

Is important information first?

Are related elements grouped?

Is anything repeated?

Is anything missing?

Is navigation appropriate?

Layer 4: Interaction

Ask

Are actions predictable?

Are states covered?

Are errors recoverable?

Is selection clear?

Are confirmation steps appropriate?

Layer 5: Visual hierarchy

Ask

Is anything competing unnecessarily?

Is the primary action dominant?

Are typography and spacing consistent?

Is colour meaningful?

Is density appropriate?

Layer 6: Aesthetics

Ask

Does the product feel polished?

Does it fit the brand?

Is it visually coherent?

Does it feel trustworthy?

Do not debate the shade of blue while the workflow remains incorrect.

60. Test the Entire State Matrix

A page that works in the default happy path may fail completely when it becomes empty, blocked, expired, read only, or permission restricted.

For every important page, test

• Default state
• Loading state
• Empty state
• Error state
• Partial state
• Action required state
• Completed state
• Read only state
• Cancelled state
• Expired state
• Permission restricted state

Create a matrix.

This reveals inconsistencies that a happy path prototype hides.

61. Test Permissions Explicitly

For example, hiding an internal action from a customer and disabling a temporarily unavailable action for an employee are two different permission decisions.

Permission design affects both product logic and UI.

For every action, define

• Who can see it
• Who can use it
• Who can approve it
• Who can reverse it
• Who can view history
• Who can download evidence
• Who can edit after submission

Do not simply disable every restricted action.

Sometimes the action should be hidden.

Use a disabled action when

• The action is normally available
• The user may become eligible
• The reason is useful

Example

Approve quotation

Disabled because finance approval is still pending.

Hide an action when

• It is irrelevant to the user’s role
• Exposing it creates confusion
• It reveals an internal capability

A customer should not see an inactive “Create supplier purchase order” button.

62. Test Data Volume

A table designed with five neat records may become unusable when real users load hundreds of rows, long names, and multiple open statuses.

A design that works with five records may fail with five hundred.

Test

• One row
• Ten rows
• Hundreds of rows
• Very long values
• Empty values
• Duplicate names
• Large totals
• Multiple statuses
• Many open issues
• Large document libraries

Consider

• Pagination
• Virtual scrolling
• Sticky headers
• Search performance
• Filter persistence
• Bulk actions
• Export
• Column visibility
• Loading behaviour

Also test narrow screens and browser zoom.

Data volume is not only an engineering problem. It changes the usability of the interface.

63. Test Content Consistency

This drift often appears when different screens are generated independently and the same concept receives different names, labels, and status wording.

Review the entire product for terminology.

Check whether the same concept is called

• Project in one place
• Order in another
• Request in another
• Job in another

Check status language.

For example

• In progress
• Processing
• Ongoing
• Active

If these represent the same state, choose one term.

Also check

• Date format
• Currency format
• Tax labels
• Button wording
• Error style
• Capitalisation
• File labels
• User role names

AI generated products often contain inconsistent language because screens were generated independently.

A content system should be treated like a component system.

64. Test Responsive Behaviour at Real Breakpoints

For example, a layout that works on a large desktop may fail on a standard laptop before it ever reaches a mobile screen.

Do not test only one desktop and one mobile screenshot.

Test

• Large desktop
• Standard laptop
• Small laptop
• Tablet landscape
• Tablet portrait
• Mobile
• Browser zoom at 125% or 150%

Check

• Sidebar behaviour
• Table overflow
• Sticky actions
• Modal size
• Form layout
• Text wrapping
• Long buttons
• Tabs
• Charts
• Contextual panels

Touch targets

• File names
• Status labels

Responsive problems often reveal weak hierarchy.

If a page cannot be simplified for mobile, the desktop information architecture may already be too fragmented.

65. Test Accessibility

Automated checks can identify some problems, but keyboard flow, focus behaviour, screen reader meaning, and recovery still require manual review.

Use both automated and manual testing.

Review

• Keyboard order
• Focus visibility
• Heading hierarchy
• Form labels
• Error association
• Colour contrast
• Screen reader output
• Modal trapping
• Table headers
• Accessible names

Touch targets

Reduced motion

Zoom behaviour

Do not assume component libraries make the application automatically accessible.

Composition matters.

A correctly built button component can still be used incorrectly if

• It contains only an unexplained icon
• It is placed in an illogical focus order
• It opens a modal without focus management
• Its disabled state has no explanation

66. Move From Prototype to Production Carefully

A working prototype is not a production product.

Before release, address

• Data
• Replace mocks with real data
• Validate types
• Handle missing values
• Handle stale data
• Handle concurrency
• APIs
• Loading states
• Retry behaviour
• Timeouts
• Error mapping
• Permission failures
• Security
• Authentication
• Authorisation
• Data exposure
• File access
• Audit logging
• Sensitive information
• Analytics

Track meaningful behaviour

• Workflow completion
• Drop off
• Errors
• Time to decision
• Support contact
• Repeated actions

Avoid tracking everything without a question.

Performance

Review

• Initial load
• Table performance
• Image size
• File preview
• Bundle size
• Slow network behaviour
• Quality assurance

Perform

• Design QA
• Functional QA
• Accessibility QA
• Content QA
• Cross browser testing
• Role testing
• State testing
• Documentation

Document

Components

Tokens

Business rules

• Permissions
• State transitions
• Known limitations

AI accelerates implementation, but production quality still requires disciplined validation.

Part Nine: Common Vibe Coding Failure Patterns

67. Every Section Is Inside a Box

This failure pattern usually begins when AI interprets every new group of information as a reason to create another rounded container.

Why it happens

AI associates modern SaaS design with cards.

Why it fails

• Relationships become unclear
• The page becomes vertically long
• Important sections do not stand out
• Nested cards create clutter
• Alignment becomes inconsistent

Better approach

• Use sections and dividers
• Merge related metrics
• Reserve cards for independent interactions or states

68. The Interface Is Too Colourful

This often happens when colour is used to make the interface feel energetic instead of communicating selection, risk, success, or failure.

Why it happens

The model tries to make the page feel modern and lively.

Why it fails

• Status meaning becomes weaker
• The product feels less trustworthy
• Important warnings compete with decoration
• Different modules drift visually

Better approach

• Neutral foundation
• One brand accent
• Semantic colour only
• Colour based on meaning

69. The Interface Is Too Minimal

This failure appears when visual simplicity is prioritised without first identifying the operational information users must retain.

Why it happens

“Make it minimal” is interpreted as removing content.

Why it fails

• Status context disappears
• Evidence is hidden
• Users do not know what happens next
• Pages feel unfinished
• Important workflow details are lost

Better approach

• Remove decoration
• Preserve operational information
• Use progressive disclosure
• Maintain readable density

70. Multiple Primary Actions Compete

For example, a page may show Approve, Pay, Edit, Download, and Contact Support with nearly equal visual weight.

Why it happens

AI treats every important action as visually important.

Why it fails

The user cannot identify the next step.

Better approach

• Define the page job
• Select one dominant action
• Move secondary actions into quieter positions
• Change actions according to state

71. Random Charts Are Added

A chart becomes useful only when it helps the user understand a trend, distribution, or comparison that affects a decision.

Why it happens

Dashboards are associated with charts.

Why it fails

• The data may not support the chart
• The chart may not answer a question
• It consumes space
• It creates fake sophistication

Before adding a chart, ask

What question does it answer?

What decision will change?

Is visual comparison better than a table or summary?

Is the underlying data reliable?

If no useful answer exists, remove the chart.

72. Internal Operations Are Exposed

This happens when AI receives the complete internal workflow and assumes every stage, note, price, and control should be visible to the customer.

Why it happens

The model receives the full workflow and displays all stages to every user.

Why it fails

• Customers become confused
• Sensitive details may be exposed
• Internal terminology reduces trust
• Employee actions appear in customer views

Better approach

• Map visibility by role
• Translate internal states
• Show customer relevant impact
• Hide internal controls

73. Pages Look Good Individually but Not Together

This is common when quotation, quality, delivery, and finance screens are generated in separate prompts without one shared shell and design system.

Why it happens

Screens are generated in separate conversations or prompts.

Symptoms

• Different widths
• Different header structures
• Different table density
• Different status colours
• Different card radius
• Different action placement
• Duplicate components
• Different terminology

Better approach

• Define the application shell
• Use reusable page patterns
• Use a design system
• Work in the repository
• Maintain an instruction file
• Run cross product design QA

74. AI Changes More Than Requested

For example, a request to improve one table may unexpectedly change navigation, typography, colours, and unrelated modules.

Why it happens

Scope is not defined.

The model redesigns

• Navigation
• Header
• Colours
• Typography

Components

Workflow

when only one page section needed improvement.

Better approach

• Freeze unaffected areas
• Define current screen versus global scope
• Separate product changes from visual changes
• Ask for a change summary before code

75. AI Removes Useful Information While Simplifying

This happens when the prompt says only “simplify the page” without identifying the information that must remain visible.

Why it happens

The prompt focuses on visual clutter without identifying required content.

Better approach

Provide two lists.

• Must remain
• Current status
• Required action
• Price
• Delivery estimate
• Open issues
• Supporting evidence
• Can be simplified
• Decorative icon boxes
• Repeated descriptions
• Duplicate status labels
• Unnecessary filters
• Separate metric cards

This protects product usefulness.

Part Ten: A Complete End to End Process

76. Step 1: Define the Product

Document

• Problem
• Users
• Value proposition
• Primary workflows
• Main modules
• Business model
• Operational constraints
• Compliance needs

Do not begin with a dashboard.

Begin with what the product enables.

77. Step 2: Define Roles and Responsibilities

For each role, document

• Goals
• Permissions
• Data visibility
• Actions
• Approval authority
• Frequency of use
• Device context

This prevents one interface from trying to serve everyone.

78. Step 3: Map the Lifecycle

Create the complete journey from entry to closure.

Include

States

• Transitions
• Preconditions
• User actions
• System actions
• Notifications
• Evidence
• Failure paths

This connects the screens.

79. Step 4: Freeze Business Rules

Document

• Editable states
• Read only states
• Payment rules
• Approval rules
• Permission rules
• Visibility rules
• Completion rules
• Reopening rules
• Cancellation rules

AI should not invent these.

80. Step 5: Define the Job of Each Page

Write one objective for each page.

Then define

User questions

Required information

Primary action

• Secondary actions
• Prohibited information

Required states

This creates the basis for information architecture.

81. Step 6: Create the Information Architecture

Define

• Global navigation
• Module navigation
• Project navigation
• Administrative areas
• Document organisation
• Record relationships

Avoid duplicate navigation.

82. Step 7: Create the Application Shell

Define

• Sidebar
• Top bar
• Contextual header
• Tabs
• Content grid
• Side panel
• Sticky actions

Responsive behaviour

Apply it consistently.

83. Step 8: Define Reusable Page Patterns

Create patterns for

• Overview
• Data list
• Decision
• Record
• Form
• Tracking
• Quality
• Closure

Do not reinvent page structure repeatedly.

84. Step 9: Define the Design System

Document

• Product principles
• Layout
• Typography
• Spacing
• Colour
• Shape

Borders

Shadows

• Buttons
• Forms
• Tables
• Statuses
• Feedback

Accessibility

• Responsive rules
• Content style

85. Step 10: Sketch the Important Pages

Sketch

• Overview
• Creation
• Decision
• Payment
• Tracking
• Quality
• Closure

Validate hierarchy before styling.

86. Step 11: Provide Context to AI

Give AI

Product context

User context

Page objective

Business rules

• Required sections
• Design system
• Repository context
• References

Prohibited patterns

Required states

Scope

Do not rely on “make it better.”

87. Step 12: Generate Low-Fidelity Layouts

Ask for

• Section hierarchy
• Component choices
• Action placement
• Desktop and mobile structure
• State variations

Review product logic first.

88. Step 13: Apply Visual Styling

Only after structure is approved, apply

• Typography
• Spacing

Borders

Colour

Components

• Icons
• Responsive details

This prevents visual polish from hiding structural problems.

89. Step 14: Implement Interactions

Add

Selection

Validation

• Modals
• Expansion

Filters

Search

• Pagination
• Status transitions
• Error recovery

Ensure the interactions follow business rules.

90. Step 15: Integrate With the Repository

Reuse

• Existing components
• Tokens
• Layouts
• State management
• APIs
• Utilities

Avoid duplicate systems.

91. Step 16: Test Roles, States, and Edge Cases

Test

• Every role
• Every major state
• Every failure path
• Large data
• Mobile

Accessibility

Permission restrictions

Do not release only the happy path.

92. Step 17: Run Design QA

Compare screens for

• Width
• Alignment
• Typography
• Spacing
• Colour
• Statuses
• Buttons
• Tables
• Forms
• Navigation
• Terminology

Correct drift.

93. Step 18: Learn From Real Usage

After release, study

• Where users stop
• Which actions are missed
• Which statuses create support questions
• Which fields are abandoned
• Which filters are used
• Which documents are difficult to find
• Which errors repeat
• Which workflows take too long

Use evidence to improve the product.

Master AI Prompt Template

Use the following structure when asking an AI coding tool to design or redesign a screen.

Role

Act as a senior B2B SaaS product designer and frontend engineer. Prioritise product usefulness, business logic, workflow clarity, accessibility, responsive behaviour, and maintainable implementation.

Product context

Describe

• What the product does
• Which industry it serves
• Which workflows it supports
• Which application modules exist

User context

Describe

• User role
• Expertise
• Frequency of use
• Primary responsibility
• Information they need
• Information they should not see

Page objective

Write one sentence

The user’s primary job on this page is to...

Business rules

List every rule that must remain true.

Examples

The page becomes read-only after approval.

Internal supplier information is not customer-visible.

The primary action changes after payment.

Only administrators can change user access.

A closed record cannot be edited.

Current problems

Use observable issues.

Examples

The page uses too many independent cards.

Status information is repeated.

There are multiple competing primary actions.

Financial values are misaligned.

The page is too colourful.

Important next-step information is missing.

Content width is inconsistent.

Required information

List everything that must remain visible.

Required structure

Define the exact section order.

Design direction

Use a compact, structured, trustworthy enterprise interface. Prefer neutral surfaces, thin dividers, strong alignment, clear typography, compact information rows, meaningful status communication, and one primary action per decision area.

Design tokens

Specify

• Content width
• Page padding
• Section gap
• Typography
• Radius

Borders

• Colour usage
• Table density
• Button hierarchy

Reuse constraints

Inspect the repository before creating components.

Reuse the current application shell.

Reuse existing buttons, inputs, tables, tabs, badges, and tokens.

Preserve state management and folder structure.

Do not change unrelated pages.

Prohibited patterns

• No decorative gradients
• No glassmorphism
• No excessive rounded cards
• No random charts
• No colourful icon boxes
• No unnecessary status pills
• No duplicate navigation
• No duplicate primary actions
• No invented backend data
• No internal controls in customer views
• No removal of decision-critical information

Required states

Design

• Default
• Loading
• Empty
• Error
• Action required
• Completed
• Read-only
• Permission restricted

Responsive behaviour

Explain

• Desktop layout
• Tablet adaptation
• Mobile priority
• Table handling
• Sticky actions
• Navigation behaviour

Output

First provide

• Product and UX critique
• Proposed information architecture
• Component structure
• State behaviour

Responsive behaviour

Only then provide implementation code.

Final Product and UI/UX Checklist

Product logic

Is the user clearly defined?

Does the page have one primary job?

Are business rules correct?

Are state transitions correct?

Are permissions respected?

Is confidential information hidden?

Does the lifecycle make sense?

User usefulness

Can the user understand the current situation?

Is required action obvious?

Is the next step clear?

Are delays and issues understandable?

Is supporting evidence available?

Can the user complete the intended task?

Information architecture

Is the most important information first?

Are related elements grouped?

Is anything repeated?

Is anything missing?

Is navigation consistent?

Are page names understandable?

Action hierarchy

Is there one dominant primary action?

Are secondary actions quieter?

Are destructive actions protected?

Are disabled actions explained?

Do actions change correctly by state?

Are duplicate actions removed?

Visual hierarchy

Is content width consistent?

Are alignment lines consistent?

Is spacing based on tokens?

Is typography consistent?

Is colour meaningful?

Is the page appropriately dense?

Are unnecessary containers removed?

Components

Are existing components reused?

Are cards used intentionally?

Are tables scannable?

Are forms necessary and clear?

Are statuses consistent?

Is progress meaningful?

Are documents organised?

States

• Loading
• Empty
• Error
• Partial
• Action required
• Blocked
• Completed
• Read-only
• Cancelled
• Expired
• Permission restricted

Responsive design

Is mobile priority intentional?

Are tables handled correctly?

Are actions reachable?

Is navigation usable?

Does content wrap safely?

Are touch targets large enough?

Accessibility

Keyboard navigation

Visible focus

Contrast

• Form labels
• Error association

Semantic structure

Screen-reader labels

Reduced motion

Accessible tables and dialogs

Content

• Clear page titles
• Specific action labels
• Understandable statuses
• No internal jargon
• Useful error messages
• Useful confirmation messages
• Consistent terminology
• Realistic data

Engineering

• Existing architecture preserved
• Components reused
• No invented APIs
• Mocked data identified
• Errors handled
• Permissions enforced
• Performance considered
• Tests included
• Documentation updated.