UI and UX design
Web app interface design
A web app is software that runs in a browser: a booking system, a client portal, an internal tool, an online editor or a software product. Unlike a marketing website, people use it to get work done, often repeatedly and for long periods. Its interface has to handle complex tasks, large amounts of data, different user roles with different permissions and many states, while staying clear enough that new users can learn it and fast enough that experienced users are not slowed down. Good web app design balances those needs, starting from the tasks people perform and the rules the software must enforce.
This page covers roles and permissions, navigation, forms and tables, states, keyboard use, responsive layouts and accessibility. LetGetGrow provides wireframes, interface design, prototypes, design systems and usability reviews, with the scope, cost and timeline set out in a custom quotation.
Illustrative diagram
Web app interface
- Roles
- Permissions
- Views per role
- Building blocks
- Tables and forms
- Navigation and search
- States
- Empty and error
- Saving and undo
- Access
- Keyboard and focus
- Responsive layouts
Roles and permissions
Many web apps serve several kinds of user: an administrator, a manager, a staff member, a customer. Each sees different screens and can do different things. Map roles and their permissions before designing, so the interface shows each person what they need and hides or explains what they cannot do. Designing only the administrator view and trimming it later tends to leave other users with confusing screens.
Common building blocks
| Block | Design questions |
|---|---|
| Navigation | Sidebar or top bar? How deep? Where is search? |
| Tables and lists | Sorting, filtering, bulk actions, pagination |
| Forms | Grouping, validation, saving drafts |
| Detail views | Tabs or sections? Edit in place or separate page? |
| Notifications | Which events matter, and where do they appear? |
Forms people fill in every day
Web apps are full of forms. Group related fields, show errors next to the field with a clear fix, keep entered data when something fails, and avoid asking for the same information twice; WCAG 2.2 criterion 3.3.7 Redundant Entry addresses this. For long forms, consider saving progress. Experienced users appreciate sensible defaults and keyboard shortcuts.
Tables and data
Tables need to work with ten rows and ten thousand. Design sorting, filtering and search together, decide which columns matter most on narrower screens, and plan bulk actions such as selecting many rows to archive. Show clearly when a filter is active, so users do not think data is missing.
States to design
Data
- Empty on first use
- No results for a filter
- Very large lists
Actions
- Saving and saved
- Errors with recovery
- Undo for destructive actions
Access
- No permission
- Session expired
- Read-only views
Keyboard and focus
Some web app users work with a keyboard, and some cannot use a mouse at all. Design a logical focus order, make the focused element visible (WCAG 2.2 criterion 2.4.7) and make sure it is not hidden behind sticky headers or panels (criterion 2.4.11). Specify these in handoff, because they are easy to lose in build.
From rules to screens
Tasks and rules
What users do and what the system allows.
Output: Task and rule list
Roles
Who sees and does what.
Output: Permission map
Flows
Key tasks step by step.
Output: Flows
Wireframes and test
Structure tested on tasks.
Output: Tested structure
UI and components
Visual design and states.
Output: Handoff files
Example: a client portal
Illustrative example — not a client case study
Situation: An accountancy practice wants clients to upload documents and see the status of their returns.
- Roles are mapped: clients, staff and partners, each with different views and actions.
- Wireframes are tested with clients asked to upload a receipt and check their return's status.
- States are designed for missing documents, rejected uploads and returns awaiting approval.
What this shows: Each role had a clear view before build began. This example is illustrative.
Responsive layouts
Some web apps are used mainly on desktop, but people still check them on phones. Decide which tasks must work on a phone and design those properly. WCAG 2.2 criterion 1.4.10 asks that content works at 320 CSS pixels wide without two-way scrolling, with exceptions for content such as complex data tables that need two dimensions.
New and expert users
New users need clear labels, guidance and forgiving errors. Experts want speed: shortcuts, bulk actions and fewer confirmations. Nielsen's heuristic of flexibility and efficiency of use describes this balance. Design for both, rather than choosing one.
Preventing costly mistakes
Deleting a record or sending an invoice by mistake can cause real harm. Offer undo where possible, and confirm only the actions that cannot be reversed, so confirmations keep their meaning.
Questions about web app interface design
How is a web app different from a website?
People use it to get work done, often daily, with roles and data.
Why map roles first?
Each role sees different screens and actions.
What makes forms easier?
Grouping, clear errors, keeping data and not asking twice.
How should tables work?
Sorting, filtering and bulk actions designed together.
Does keyboard use matter?
Yes; visible, unobscured focus and logical order.
Must web apps work on phones?
At least the key tasks should.
Sources referenced
Platform features, guidance and rules change. We check the current versions before committing to an approach. This page is general information, not legal advice.
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab) — reviewed 2026-11-03
- Nielsen Norman Group: 10 usability heuristics for user interface design (opens in a new tab) — reviewed 2026-11-03
Request a Custom Quote
Ask about Web app interface design
Thank you — your enquiry has been sent.
We have received your message and will reply by email. If you need to add anything, email info@letgetgrow.com.