Answer in brief
The most useful UI design examples come with their reasons. Public design systems such as GOV.UK and USWDS document each pattern: one main button per page, vertical forms with grouped controls, specific error messages kept next to the field, and tables with captions and headers. WCAG 2.2 adds a measurable rule for touch targets. Turn each example into a rule and a reason before you brief a designer.
Read the rule behind every UI design example
Most UI design examples are screenshots: a clean screen, a nice palette, a caption that says why it is good. The screenshot cannot say what the designer decided against or what happened when real users met it. A screen is easy to admire and hard to reuse, because the reader copies the look and misses the reason.
Public design systems give you the reason in writing. The GOV.UK Design System and the U.S. Web Design System, USWDS, publish each component with guidance on when to use it, when not to, and what to write inside it. They were built for public services that must work for everyone, so their rules are conservative, and conservative rules are a good first draft for a business app. You can always loosen a rule once you have evidence from your own users, but it is harder to add care to a screen that was designed without it.
Buttons: one main action and an honest label
The GOV.UK Design System says to use a default button for the main call to action on a page and to avoid several of them, because having more than one main call to action reduces their impact. Secondary buttons are for secondary calls to action. The page also warns that pages with too many calls to action make it hard for users to know what to do next.
Labels get the same care. GOV.UK asks for sentence case that describes the action, with examples such as Start now, Sign in, Save and continue and Sign out, and permits extra words for clarity, as in Add another address. A button that says Submit tells the user nothing about what happens. A button that says Save and continue tells them both.
Two more rules are worth borrowing. Warning buttons are for actions with serious destructive consequences that a user cannot easily undo, and GOV.UK says they only work if used very sparingly. And disabled buttons are to be avoided if possible, because the page says they have poor contrast and can confuse some users; use them only where research shows they make the interface easier to understand.
Forms: a vertical pattern with grouped controls
USWDS gives its form guidance in short, testable lines. Keep form blocks in a vertical pattern, which suits people with limited vision. Mark required fields with a red asterisk and explain the mark in text at the top of the form. Label optional fields with the word optional in parentheses. A single-field form needs no required marker.
Structure matters as much as looks. USWDS says to group each set of thematically related controls in a fieldset with one legend, and to display controls in the same order in the HTML as they appear on screen, because screen readers read in HTML order. A designer who knows this draws the form so that a developer can build it correctly the first time.
Error messages that say what to do next
GOV.UK treats the error message as a piece of interface with its own rules. It is shown next to the field and in an error summary at the top of the page, with the same wording in both places. It explains what went wrong and how to fix it, in plain language and positive terms. It avoids generic lines such as An error occurred or This field is required.
The page distinguishes two cases. For an empty field, give an instruction, such as Enter your first name. For an entry that is wrong, give a description, such as Name must be 35 characters or less. It also asks writers to avoid words such as please, sorry, valid, invalid and oops, because they add noise or blame the user.
Placement is part of the rule: the message follows the question and hint text, in red, with a red border linking it to the question. And the form must not clear the fields. Keep the correct answers and the incorrect ones, so the user can see and edit what they typed. This single behaviour separates a polite form from a punishing one.
Data tables: compare in rows and columns
The GOV.UK table component is for letting users compare information in rows and columns, and the page says never to use it to lay out content on a page. Every table gets a caption, written the way you would write a heading, and headers that tell users what the rows and columns represent. The scope attribute lets assistive technology tell row headers from column headers.
One detail is easy to miss and easy to copy: when comparing columns of numbers, align the numbers to the right in their cells. The eye then compares digits in the same position. On a phone, wide tables rarely fit, so decide early whether the mobile version is a scrolling table or a list of cards, and design both before development starts. A table that looks fine with five invented rows can fail with fifty real ones.
Touch targets: the one rule that is measurable
Taste cannot be measured, but target size can. WCAG 2.2 Success Criterion 2.5.8, at level AA, says the size of the target for pointer inputs is at least 24 by 24 CSS pixels, with exceptions. One exception covers undersized targets spaced so that a 24 pixel circle centred on each does not intersect another target. The others are equivalent, inline, user agent control and essential.
In practice this means icon buttons need padding, not just a small glyph, and links packed in a row need room between them. The minimum is a floor, not a recommendation, and a comfortable target for a thumb is usually larger. Put the target size into the design system as a number, so every component inherits it instead of each designer deciding again. A number also gives the person who tests the finished app something to check.
Turn each example into a rule, a reason and a screen
To use an example in a brief, write three lines for it. First the rule, in a sentence: one main button per screen. Then the reason, taken from the source: more than one main action reduces the impact of each. Then the screen where it applies in your product: the checkout, the booking form, the settings page. Examples without this third line stay decoration.
Then list what the app has to show beyond the happy path. Every form has an error state, every list has an empty state, every request has a slow state. Public systems describe some of these in detail, and the rest you write yourself. A designer who receives the rules, the reasons and the states builds a prototype that answers real questions, not one that merely looks like the gallery.
What to prepare before ordering app UX and UI design
Prepare the three to five tasks a user must complete, the people who will do them, the devices they use and the rules you borrowed from examples. Add the content that appears on each screen, the error messages you can write today, and the integrations the screens depend on. Decide who can approve a screen and how quickly, because waiting for feedback is a common cause of delay.
If you want the work done by a studio, App UX/UI design at VITON13 Studio covers up to 3 user flows, 15 core screens with their states, 30 components and a clickable prototype. It costs from $93 AI-assisted or $113 human-led, with a turnaround of 8–15 working days. The more of your rules and states you bring, the less of that time is spent on questions.
Practical checklist
- Pick three public design-system pages and write the rule and reason of each in a sentence.
- Name the one main action of every screen in your app and give it a verb label.
- Write the error text for each form field now, using an instruction or a description.
- Set a minimum target size in the design system, starting from 24 by 24 CSS pixels.
- List the empty, error and slow states for every list and form before the brief goes out.
Questions and answers
Where can I find good UI design examples that explain themselves?
Public design systems. GOV.UK and USWDS publish each component with guidance on when to use it, what to write and what to avoid, so you can read the reasoning and not only look at the result.
Can a business app copy a government design system?
Copy the rules, not the look. Check each system’s licence and terms before reusing code or assets. The guidance on labels, errors and structure carries over; branding and colour are yours to choose.
How big should a button be on a phone?
WCAG 2.2 sets a minimum of 24 by 24 CSS pixels for pointer targets at level AA, with a spacing exception. Treat it as a floor and test with real thumbs on real devices.
Are disabled buttons always wrong?
GOV.UK advises avoiding them because of poor contrast and possible confusion, and allows them only where research shows they make the interface easier to understand. If you must use one, show the reason on the screen.
What should a UI brief include besides screenshots?
The user tasks, the rules and reasons you want applied, the content, the states beyond the happy path and the devices. Screenshots show taste; the rest tells a designer what the screens must do.