By Mehdi HassanFounders often ask a studio for 'a website' when they mean an app, or for 'an app' when they mean a marketing site. The confusion is understandable, because both run in a browser. But they're designed, built and priced very differently. This hub clears up the split first, then walks through the principles and patterns that matter in web app UI design, with notes on how each gets built in React and Next.js, and links to a deeper guide for each pattern.
What is web app UI design?
Web app UI design is the design of the interface for software people use in a browser to get work done: SaaS products, dashboards, internal tools, editors, booking systems and admin panels. Users usually sign in, return often and perform the same tasks repeatedly, so the interface is judged on speed, clarity and reliability.
UI is the visible layer: layout, components, typography, color and motion. UX is the wider experience: whether people can complete tasks, understand what's happening and recover from mistakes. In web apps they're inseparable. A beautiful table that hides the filter users need is a UX failure, however good it looks. If you hear unfamiliar terms from designers along the way, our product design glossary of UI/UX terms explains them in plain language.
How is web app UI design different from website design?
Web app UI design differs from website design in its goal, its users and its structure. A website persuades mostly new visitors to take one action, like booking a call; a web app helps returning users complete tasks efficiently, often for hours a day.
Factor | Website | Web app |
|---|---|---|
Main goal | Persuade and convert | Help users get work done |
Typical user | First-time visitor | Returning, signed-in user |
Content | Mostly fixed marketing content | User data that changes constantly |
Key design work | Messaging, hierarchy, storytelling | States, forms, tables, navigation |
Success measure | Conversion rate | Task success, activation, retention |
Build | Framer, Webflow or Next.js with a CMS | React or Next.js app with an API and database |
Change rate | Redesigned every few years | Changes every sprint |
Many startups need both: a marketing site that sells and an app that delivers. They share a brand but not a playbook. A marketing page can be bold and unusual; an app should feel predictable, because users are trying to finish something. If you're budgeting for the product side, our guide to app design cost for web and mobile breaks down what drives the price.
What are the core web app design principles?
The core web app design principles are clarity of state, consistency, efficiency for frequent users, forgiveness, and words that explain. They're close cousins of the classic usability heuristics, tuned for products people use every day.
- Always show state. Users should know whether something is loading, saved, failed or empty at every moment.
- Be consistent. The same action looks and behaves the same everywhere. Components, not screens, are the unit of design.
- Respect frequent users. Keyboard shortcuts, bulk actions, remembered filters and sensible defaults matter more the more someone uses the product.
- Forgive mistakes. Prefer undo over confirmation dialogs for common actions, and keep confirmations for truly destructive ones.
- Let words do the work. Clear labels, specific errors and helpful empty states solve problems layout can't.
- Design for real data. Long names, empty lists, thousands of rows and slow networks are normal, not edge cases.
The last principle catches most teams out. Designs made with perfect sample data look great and break the day real customers sign in. Design every screen with too little data, too much data and bad data before you call it done.
Which web app UI patterns matter most?
The web app UI patterns that matter most are the ones users meet on every screen: states, forms, search and filters, navigation, data display, and theming. Get these right as reusable components and most screens almost design themselves.
Pattern | What it solves | Build note | Deep dive |
|---|---|---|---|
Empty states | Blank screens that stall new users | One component with icon, message and primary action | |
Loading states | Apps that feel slow or frozen | Skeletons and optimistic updates in React | |
Error states | Dead ends after something fails | Error boundaries plus specific inline messages | |
Forms | Errors and abandonment in data entry | Schema validation shared by client and server | |
Search and filters | Finding things in large datasets | Filter state stored in the URL | |
Command palette | Slow navigation for power users | Accessible dialog with fuzzy search | |
Dark mode | Comfort and preference | Semantic color tokens as CSS variables | |
Accessibility | Users who can't use a mouse or see low contrast | Accessible primitives, focus management |
For product UI built in React and Next.js, a strong starting point is shadcn/ui, a set of accessible components built on Radix primitives and Tailwind CSS that you copy into your codebase and own. Starting from proven primitives means keyboard behavior, focus handling and screen reader support come with the component, and design time goes into what makes your product different.
How should a web app handle empty, loading and error states?
A web app should treat empty, loading and error states as first-class designs, each with its own message and next step, because users see them far more often than designers expect. A screen has at least five states: empty, loading, partial, error and success.
Empty states
An empty state should explain what will appear, why it's empty and what to do next, with one primary action. For new users, it's the most important onboarding screen you have. Our guide to turning empty states into activation shows patterns for first-use, no-results and cleared states.
Loading states
Use skeletons that match the layout for content that takes a moment, spinners only for short actions, and optimistic UI for actions that almost always succeed, like starring an item. In React, optimistic updates show the result immediately and roll back if the server fails. See loading states, skeletons and optimistic UI for when each fits.
Error states
Errors should say what happened, why if you know, and what the user can do, and they should keep whatever the user typed. Inline errors belong next to the field; page-level failures need a retry and a way out. Our guide to error messages and error states has copy patterns you can reuse.
How do you design forms and data entry in a web app?
Design web app forms to ask for as little as possible, validate inline at the right moment, and remember what users entered. Forms are where users do the most work in your product, so friction here costs the most.
- Visible labels above fields, never placeholder-only labels that disappear on typing.
- Validate on blur, not on every keystroke, and re-validate as soon as the user fixes an error.
- Smart defaults from what you already know: the user's timezone, company name or last choice.
- Multi-step forms for long processes, with progress shown and the ability to go back without losing data.
- Autosave for long or important forms, with a clear saved indicator.
On the build side, define validation once in a schema that both the client and server use, so the rules and messages never drift apart. Our guide to form design with validation, multi-step forms and smart defaults covers the details.
How should navigation, search and command palettes work?
Navigation in a web app should show users where they are, group destinations by what users want to do, and give frequent users a faster path, such as search and a command palette. As products grow, navigation is where inconsistency shows up first.
A common structure is a sidebar for main sections, a top bar for the current context and global search, and page-level tabs for views of the same object. Store search terms and filters in the URL, so users can share a filtered view and the back button behaves as expected. Our guide to faceted search and filter UX for SaaS covers filter patterns for large datasets.
A command palette, opened with Cmd+K or Ctrl+K, lets power users jump to any page or run any action by typing. It doesn't replace navigation; it complements it. Build it as an accessible dialog with fuzzy search, recent items and clear grouping, as covered in how to design a Cmd+K menu.
Build notes: keeping navigation fast in Next.js
In a Next.js app using the App Router, shared layouts keep the sidebar and top bar mounted while page content changes, so navigation feels instant and scroll positions in the sidebar are kept.
Prefetching linked routes makes the next screen ready before the click. Combine that with loading files that render skeletons for each route segment, so users see the layout immediately while data loads.
Keep filter and sort state in search parameters rather than in component state. It survives refreshes, can be shared as a link and works with the browser's back button. The Next.js documentation at nextjs.org covers layouts, loading UI and search parameters in detail.
How do you build accessibility and dark mode into a web app?
Build accessibility and dark mode in from the first component, through semantic color tokens and accessible primitives, because retrofitting either one across a grown product is slow and expensive. Both depend on the same foundation: a token-based design system.
For accessibility, start from components that already handle keyboard navigation, focus management and ARIA roles, then check color contrast, visible focus states, form labels and error announcements. The W3C's WCAG guidelines are the reference standard. Our WCAG checklist for product designers translates them into web app checks.
For dark mode, define colors by role rather than by value: background, surface, text, muted text, border and accent. Store them as CSS variables, map them to your Tailwind theme, and swap values per theme. Then dark mode is a set of token values, not a second design. Dark mode for SaaS apps covers contrast pitfalls and how to handle charts and images.
What does the web app design process look like for product teams?
A good web app design process moves from the job users need done, to flows, to components, to code, with words written early and engineers involved throughout. It's less about polished mockups and more about decisions that hold up when real data arrives.
Define the job and the key flows
Agree what users are trying to do and the few flows that matter most, such as signup, the core task and sharing results.
Write the words first
Draft labels, empty states, errors and confirmations before layout. Copy problems found here are cheap to fix.
Sketch flows, then screens
Map each flow end to end, including failures, before designing high-fidelity screens.
Design components with every state
Build buttons, inputs, tables and dialogs with default, hover, focus, disabled, loading, empty and error states.
Prototype and test the risky parts
Test the flows you're least sure about with a few real users before building them.
Build with the designer in the loop
Designers review the built product, not only the files, and fix gaps together with engineers.
If your product includes AI features, add steps for confidence, review and undo; our guide to designing AI features users trust covers them. Domain-specific products have their own patterns too, such as wallet connections and transaction states in DeFi apps or progress and habit dashboards in fitness apps.
How much does web app UI design cost?
Web app UI design cost depends on the number of flows, the complexity of the data and whether you need design only or design and build. For early products, MVP design quotes we see published range from about $2,000 to $40,000, and they vary widely by scope.
- Typical MVP design range agencies publish
- $2k–$40k
- Designify brand and design sprint, fixed
- $3,000
- Designify retainer for ongoing design and development
- $6,000/mo
Our options are fixed-price. The $3,000 brand and design sprint covers a redesign direction plus 10 product or website explorations in Figma, design only. The $6,000 monthly retainer gives you an ongoing design and development team that designs and ships in your codebase. For mobile, see mobile app design cost for startups; for a broader view of where design budgets go, what a CRO audit costs is a useful comparison for marketing-side work.
