Every application solves similar problems: displaying lists, editing records, confirming actions, showing status. Without patterns, each screen is designed from scratch and users learn each one separately. The question is: what does software look like when the same interaction works the same way everywhere?
When Interfaces Are Inconsistent
Software built without patterns becomes a patchwork. Each screen reflects whoever designed it, whenever they designed it. The application feels like several different applications stitched together.
The problems accumulate:
Consistent patterns solve this. Define how things work once, apply everywhere. Users learn the system, not each screen. Development accelerates. Quality becomes predictable. This is a core principle of good user experience design.
How We Approach Interface Patterns
We build systems where solved problems stay solved. The same patterns appear throughout the application. Users learn once, developers build faster, quality improves through repetition.
Consistency for users. Delete works the same everywhere. Search works the same everywhere. Tables sort the same everywhere. Users don't need to relearn for each screen.
Speed for development. Standard patterns mean developers reach for components rather than designing from scratch. More time for unique problems, less for routine ones.
Quality through refinement. Patterns used across many screens get more attention. Edge cases get handled. Accessibility gets improved. Components mature.
Core Pattern Categories
Interface patterns fall into distinct categories, each solving a specific class of problem. Understanding these categories helps teams make consistent decisions across the application.
Data Display Patterns
How information is presented to users: tables, lists, cards, detail views, dashboards. These patterns govern how users consume data and understand the current state of the system.
Data Entry Patterns
How users input and modify data: forms, inline editing, wizards, bulk operations. These patterns control how data enters the system and how errors are prevented.
Navigation Patterns
How users move through the application: menus, breadcrumbs, tabs, search, filtering. These patterns determine how quickly users can find what they need.
Feedback Patterns
How the system communicates with users: loading states, success confirmations, error messages, progress indicators. These patterns build trust and reduce anxiety.
Table and Data Grid Patterns
Tables are the workhorse of business applications. They display collections of records, allow comparisons, and provide entry points for detailed views. A well-designed table pattern becomes invisible. Users focus on the data, not the interface.
The principle: Every table in the application should work identically. Column headers sort. Rows are selectable. Actions appear in consistent positions. Users never wonder "how does this table work?"
Column Headers and Sorting
Sortable columns are indicated visually (an arrow or chevron). Clicking a header sorts ascending; clicking again sorts descending; a third click clears the sort. This three-state cycle is standard enough that users expect it without instruction.
Primary sort columns are indicated clearly. Secondary sorts (shift-click) are available for power users but not required for basic operation. The current sort state persists when users navigate away and return.
Row Selection and Batch Actions
Checkboxes appear on the left edge of each row. A header checkbox selects or deselects all visible rows. Selected rows are highlighted with a subtle background colour change.
When rows are selected, batch action buttons appear: "Delete Selected", "Export Selected", "Assign Selected". These buttons remain disabled until at least one row is selected. Destructive batch actions require confirmation with a count: "Delete 7 records?"
Row Actions
Individual row actions appear on the right edge. Common patterns include:
Visible Action Buttons
Edit, View, and Delete icons visible on every row. Works well when actions are few (three or fewer) and space permits. Users can act without additional clicks.
Action Dropdown Menu
A single "Actions" button or ellipsis icon that opens a dropdown. Better when actions are numerous or space is limited. Keeps the table clean while still providing quick access.
Hover-Reveal Actions
Actions appear only when hovering over a row. Creates a cleaner default view but fails on touch devices. Use only when you can guarantee a mouse-based interface.
Pagination vs Infinite Scroll
Pagination works better for most business applications. Users can bookmark specific pages, share links to page 3 of results, and understand how much data exists. "Page 12 of 47" communicates scale in a way infinite scroll cannot.
Infinite scroll suits browsing interfaces where position doesn't matter: activity feeds, image galleries, social media timelines. For records that need to be referenced, found again, or shared, pagination is the safer choice.
When using pagination, include: page numbers (not just next/previous), items per page selector, total record count, and keyboard navigation (arrow keys to move between pages).
Empty States
An empty table is an opportunity, not a dead end. The empty state should explain why the table is empty and provide a path forward.
| Context | Poor Empty State | Better Empty State |
|---|---|---|
| No records exist | "No data" | "No customers yet. Add your first customer to get started." [Add Customer] |
| Filter returns nothing | "No results" | "No customers match these filters. Try adjusting your search or clearing filters." [Clear Filters] |
| Search returns nothing | "No results for 'xyz'" | "No customers found for 'xyz'. Check spelling or try a different search term." |
Form Design Patterns
Forms are where data enters the system. Every form is a negotiation between the system's need for complete, accurate data and the user's need to complete tasks quickly. Good form patterns reduce friction while maintaining data quality.
The reality: Users do not read forms carefully. They scan, assume, and act quickly. Form patterns must account for this behaviour rather than fight against it. This is why low-friction interfaces rely so heavily on smart defaults and progressive disclosure.
Layout Principles
Single-column layouts work best. Eye-tracking studies consistently show that single-column forms complete faster and with fewer errors than multi-column layouts. The exception is genuinely related fields (city/state/postcode) that form a natural group.
Labels above fields, not beside. Labels positioned above input fields create a clear visual flow and work consistently across screen sizes. Labels beside fields create alignment problems on mobile and force users to track in two directions.
Group related fields visually. Use fieldsets, dividers, or spacing to create logical sections. A form for "Contact Details", "Billing Address", and "Preferences" should visually separate these concerns. Users can then skip to relevant sections.
Field-Level Patterns
Individual fields follow consistent rules that users learn once and apply throughout the application:
Required Field Indication
Mark required fields consistently. The standard pattern is an asterisk (*) next to the label. Alternatively, mark optional fields as "(optional)" when most fields are required. Never leave users guessing which fields they can skip.
Placeholder Text Usage
Use placeholders for format hints ("DD/MM/YYYY") not as replacements for labels. Placeholder text disappears when typing begins, leaving users without guidance. Labels remain visible throughout.
Help Text Positioning
Place help text below the field, not above. Users read top-to-bottom; help text above the field delays the user before they even start typing. Brief help text below the field is available when needed without impeding progress.
Input Constraints
Use appropriate input types: email fields with email keyboards, number fields with number keyboards, date fields with date pickers. Let the browser and device help users enter valid data from the start.
Validation Patterns
Validation prevents bad data from entering the system while respecting the user's workflow. The timing and presentation of validation messages significantly affect completion rates.
Validate on blur, not on keystroke. Showing errors while users are still typing creates anxiety and interrupts thought. Wait until the user moves to the next field (blur event) before validating. This gives them a chance to complete their input.
Validate on blur, confirm on keystroke. Once a field shows an error, validate on each keystroke so users see the error clear as soon as they fix it. This immediate feedback confirms they've addressed the issue.
Position errors next to fields. Error messages appear directly below the problematic field, not in a summary at the top or bottom of the form. Users shouldn't have to map "Email is invalid" to the actual email field.
| Validation Aspect | Avoid | Prefer |
|---|---|---|
| Error message tone | "Invalid email" | "Please enter a valid email address" |
| Specificity | "Field is required" | "Email address is required" |
| Guidance | "Date is invalid" | "Enter a date in DD/MM/YYYY format" |
| Error styling | Red text only | Red border, red text, error icon |
Form Submission Patterns
Primary action is obvious. The main submit button is visually prominent (filled, coloured). Secondary actions (Cancel, Save as Draft) are visually subdued (outlined, grey).
Button labels describe the action. "Create Customer" is better than "Submit". "Save Changes" is better than "OK". Users should know what will happen before they click.
Disable during submission. Once clicked, the submit button disables and shows a loading state. This prevents double-submission and confirms the system is working.
Preserve input on failure. If submission fails, all entered data remains in the form. Users should never have to re-enter information because the server returned an error.
Search and Filtering Patterns
As data grows, finding specific records becomes the primary interface challenge. Search and filtering patterns determine whether users can locate what they need in seconds or minutes. The same principles apply whether you are designing list views for operational software or building dashboards with filterable data displays.
Global Search
A single search field, accessible from anywhere in the application, that searches across all record types. This is the "I know what I'm looking for" pathway.
Keyboard shortcut access. Cmd+K or Ctrl+K opens the search field from any screen. Power users expect this; providing it rewards their investment in learning the application.
Search-as-you-type with debouncing. Results appear as the user types, but the system waits for a pause (200-300ms) before querying. This provides responsiveness without overwhelming the server with partial queries.
Results grouped by type. Search results for "Smith" might return customers named Smith, orders for a Smith, and projects with Smith in the title. Group these by type with clear headings so users can scan to the relevant section.
Recent searches and quick access. Before the user types, show their recent searches and frequently accessed records. This shortcuts the search process for common tasks.
List Filtering
Within a list or table, filters narrow the visible results based on specific criteria. This is the "I'm exploring or narrowing down" pathway.
Faceted Filters
Predefined filter options based on data attributes: status (active, inactive, pending), category, date range, assigned user. Users click to apply filters without typing. Works well when filter values are known and limited.
Text Search Within List
A search field that filters the current list. Simpler than global search, scoped to the current context. "Find customers containing 'London'" filters the customer list without leaving the page.
Saved Filters / Views
Allow users to save filter combinations as named views. "My Active Projects", "Overdue Invoices", "Leads from Last Week". These become one-click pathways to frequently needed subsets.
Filter Visibility and Clearing
Active filters are visible. When filters are applied, show which filters are active and what values are set. Users should never wonder why they're seeing a subset of data.
One-click filter clearing. Provide a "Clear All Filters" action that resets to the default view. For individual filters, allow removal with an "X" on each active filter chip.
URL reflects filter state. Filter parameters appear in the URL. This allows users to bookmark filtered views, share links with colleagues, and use browser back/forward navigation. If the URL doesn't update when filters change, users lose these capabilities.
Modal and Dialog Patterns
Modals interrupt the user's flow to demand attention or gather input. This interruption has a cost. Used well, modals focus attention on critical decisions. Used poorly, they become irritating obstacles.
The test: Before using a modal, ask: "Does this require the user to stop what they're doing?" If the answer is no, the modal is probably the wrong pattern.
When Modals Are Appropriate
When Modals Are Problematic
Modal Behaviour Standards
Escape key closes the modal. Users expect this. Failing to support it feels broken.
Clicking the backdrop closes the modal (for non-critical modals). This provides an easy dismiss mechanism. For destructive confirmations, disable backdrop close to prevent accidental dismissal.
Focus is trapped inside the modal. Tab key cycles through modal elements only. Focus doesn't escape to the page behind. This is essential for accessibility and prevents confusion.
Focus returns to the trigger on close. When the modal closes, focus returns to the button that opened it. Users pick up where they left off.
Empty States and Error States
The moments when things aren't working as expected reveal the quality of an interface. Empty states, error states, and loading states are not afterthoughts. They are critical touchpoints that determine whether users persist or abandon.
Empty State Design
Every empty state should answer three questions: Why is this empty? What can I do about it? Is this temporary or permanent?
First-Time Empty
User hasn't created any records yet. This is an onboarding opportunity. Explain what this section is for, show benefits of adding data, provide a prominent "Add First Item" action. Consider including sample data or a guided tour.
Filtered to Empty
Records exist but current filters exclude all of them. Explain clearly that filters are limiting results. Provide quick access to clear filters or adjust search. Never leave users wondering if data has disappeared.
Deleted to Empty
User has removed all records from a previously populated section. Acknowledge the current state without judgment. Offer the path to add new records. This is different from first-time empty because the user understands what goes here.
Permission Empty
Records exist but the user lacks permission to view them. Explain the access limitation clearly. Provide a path to request access or contact an administrator. Don't pretend the records don't exist.
Error State Design
Errors happen. Server timeouts, network failures, validation problems, permission issues. The way errors are presented determines whether users recover or give up.
Explain what happened in plain language. "Something went wrong" tells users nothing. "We couldn't save your changes because the server isn't responding" gives them information to act on.
Suggest what to try next. "Please try again in a few minutes" or "Check your internet connection" or "Contact support if this continues" gives users a path forward.
Preserve user input. If a form submission fails, keep all entered data intact. Losing work to an error is unforgivable. Users will not re-enter information; they will leave.
Provide escape routes. Even in error states, users need a way out. Navigation remains functional. "Go back" or "Return to dashboard" links provide exit paths.
| Error Type | Poor Handling | Better Handling |
|---|---|---|
| Network error | "Error" | "Unable to connect. Check your internet connection and try again." |
| Server error | "500 Internal Server Error" | "Something went wrong on our end. Our team has been notified. Please try again shortly." |
| Permission error | "403 Forbidden" | "You don't have access to this page. Contact your administrator if you think this is a mistake." |
| Not found | "404 Not Found" | "This page doesn't exist. It may have been moved or deleted. Try searching or return to the dashboard." |
Loading State Patterns
Loading states bridge the gap between action and result. Without them, users wonder if anything is happening. With poor loading states, users assume the application is broken.
Acknowledge immediately. When a user clicks a button or navigates, show a response within 100ms. A spinner, a skeleton screen, a progress bar. Something that says "I heard you, I'm working."
Skeleton screens over spinners. For content-heavy screens, skeleton screens (grey placeholder shapes) give users a preview of the layout. This feels faster than a spinner because users can see where content will appear.
Progress indicators for long operations. Operations longer than a few seconds benefit from progress bars. "Uploading file: 45%" gives users confidence and allows them to estimate wait time.
Disable actions during loading. If a save operation is in progress, disable the save button. If data is loading, disable filters until results arrive. This prevents conflicting actions and race conditions.
Navigation Patterns
Navigation determines how users move through the application. Poor navigation forces users to hunt. Good navigation lets users focus on their tasks while always knowing where they are and how to get elsewhere.
Primary Navigation
Persistent side navigation works well for applications with many sections. Users can see all available areas at a glance. The current section is highlighted. Collapsing the sidebar provides more content space when needed.
Top navigation suits simpler applications with fewer sections. Horizontal menus don't scale as well but work when section count stays under seven or eight items.
Whichever pattern you choose, apply it consistently. Don't mix side navigation on some screens with top navigation on others.
Contextual Navigation
Tabs switch between aspects of a single record: Overview, Activity, Settings, Permissions. Tabs work horizontally and should not scroll. If you need more than six or seven tabs, reconsider the information architecture.
Breadcrumbs show hierarchical position: Dashboard > Customers > ABC Ltd > Orders. Users can click any level to navigate up. Breadcrumbs are essential for hierarchical content but unnecessary for flat structures.
Back links return users to their previous context. "Back to Customer List" is clearer than a browser back button because it names the destination. Use back links in linear flows where the previous step is predictable.
Wayfinding Cues
Current location is always visible. Whether through highlighted navigation items, breadcrumbs, or page titles, users should never ask "where am I?"
URL reflects state. The URL should tell users where they are. If a user shares a URL, the recipient should land in the same place. Deep linking to specific records, views, and filter states enables collaboration and bookmarking.
Responsive Patterns
Business applications are increasingly used on tablets and phones. Patterns that work on desktop don't automatically translate to smaller screens. Responsive design isn't about shrinking; it's about adapting.
Table Adaptation
Data tables are particularly challenging on mobile. Several adaptation strategies exist:
Priority Columns
Show only the most important columns on mobile. Additional columns appear in an expanded row or detail view. This preserves the table structure while focusing on essential data.
Card Transformation
Tables become stacked cards on mobile. Each row becomes a card with labels and values stacked vertically. Works well when column headers are needed for context.
Horizontal Scroll
The table scrolls horizontally within a container. Simple to implement but can be disorienting. Works acceptably for occasional mobile use but not for mobile-primary workflows.
Navigation Adaptation
Side navigation becomes a hamburger menu. The navigation panel slides in from the left when triggered and can be dismissed. Icons become more important on mobile; text labels may be hidden.
Tabs may become a dropdown. Horizontal tabs that fit on desktop may not fit on mobile. Converting to a dropdown selector or vertical tabs preserves functionality.
Form Adaptation
Single-column forms work everywhere. This is why single-column is the default recommendation. Multi-column forms require stacking logic for mobile that adds complexity.
Touch targets are larger. Buttons and interactive elements need sufficient size (minimum 44x44 pixels) for touch accuracy. What works with a mouse cursor may be too small for fingers.
Keyboards match field types. Email fields trigger email keyboards. Number fields trigger numeric keypads. Date fields open native date pickers when appropriate. Mobile users benefit enormously from appropriate input types.
How We Build Pattern Libraries
A pattern library is only valuable if teams use it. Building the library is the first step; maintaining and governing it is the ongoing work.
Document everything
Each pattern has documentation: when to use it, how it behaves, visual examples, code implementation. The library is a reference for designers and developers.
Show variations
Patterns have variants. A table might be selectable or read-only. A form might be compact or spacious. We document variants and when each applies.
Include anti-patterns
What not to do is as valuable as what to do. Common mistakes and misuse cases help teams avoid problems.
Keep it living
Pattern libraries evolve with the application. New patterns get added. Existing ones get refined. The library stays current.
A pattern library that isn't maintained becomes a historical document. Patterns drift. New solutions emerge. The library loses relevance. Regular review and updates keep the library authoritative.
What You Get
Applications built with consistent patterns deliver measurable benefits:
-
Learn faster Users learn interactions once, not per-screen. Training time decreases. Support tickets decrease.
-
Build faster Developers use components, not rebuild from scratch. Features ship more quickly. Consistency is automatic.
-
Fewer bugs Refined patterns have fewer edge case issues. Problems fixed once stay fixed everywhere.
-
Better accessibility Patterns get accessibility improvements once, everywhere. Keyboard navigation, screen reader support, and focus management become standard.
-
Easier maintenance Changes to patterns propagate throughout. Updates happen in one place rather than scattered across the codebase.
-
Design consistency The application feels like one coherent system, not a collection of unrelated screens built by different people at different times.
The application feels like one coherent system. Users trust it. Developers enjoy working on it. The business benefits from both.
Further Reading
- GOV.UK Design System - Accessibility-focused design patterns from the UK government, extensively researched and tested.
- Nielsen Norman Group - Form Design - Research-backed guidance on form usability patterns.
- Carbon Design System - IBM's open-source design system with well-documented component patterns.
Build Consistent Interfaces
We establish interface patterns as part of every application we build. Your patterns, documented and implemented as reusable components. A foundation that makes ongoing development faster and keeps the user experience consistent. Not ad-hoc screens designed in isolation. A systematic approach to interface that scales with your application.
Let's talk about consistent interfaces →