UX & UI Real World Vademecum
Part II: Design System and Components
Now that you know how the eye perceives an interface, it's time to physically build the pieces to make it real. This section covers everything you need to scale the design without creating chaos: typographic rules, color palettes, shadows, spatial logic, and tangible components like buttons, cards, forms, and navigation.
The Design System
A design system is the set of rules, scales, and components that make your design consistent and fast to produce. Instead of making every decision from scratch, you rely on a toolkit of predefined, cohesive values.
13. What a Design System Is (And Why You Need It)
Every time you choose a font size, a color, a margin, or a shadow, you are making a decision. In a complex project, these decisions stack into the hundreds. Without a system, each one is made independently, resulting in an interface where margins bounce haphazardly from 11px to 17px to 23px, where there are 14 slightly different shades of gray, and where every button features a different padding.
A design system solves this problem by defining a limited set of values for every property upfront. You no longer choose from infinite options; you choose from 8-12 pre-approved, cohesive values. You do the hard work exactly once (locking in the initial values), and then every future decision becomes rapid.
What a Design System Includes
A comprehensive design system encompasses multiple layers. The visual style dictates the brand's visual language. Typography locks down the scales for sizes and weights. The color palette includes every variant of every color, not just the base shade. Iconography guarantees that all icons share the same style, line weight, and proportions. Grid definitions anchor columns and breakpoints. Guidelines cover both design rules and implementation specs (how to translate design into code). UI patterns document how recurring elements should behave. Base components (buttons, cards, inputs, modals) are ready to be reused. Templates demonstrate how components click together into full-page layouts.
You don't have to define everything before you start. Build the system as you make decisions. The rule is: if you find yourself making the exact same choice for the second time, turn it into a system rule. If you are deciding "which gray do I use for secondary text?" and you just did that yesterday (and you like the result), it's time to map that gray permanently.
Design Systems to Study
The most well-known design systems are Material Design (Google), Human Interface Guidelines (Apple), Polaris (Shopify), Fluent (Microsoft), and Carbon (IBM). They are all public and heavily documented online. You will notice they all follow the exact same structural logic: they start from foundations (colors, typography, spacing), then define components, and finally show how to combine them into patterns and templates.
A practical approach to kickstart yours: create a Figma page (the sticker sheet) and dump all your active components there, complete with their interaction states (default, hover, active, disabled). Every time you create a new component, drop it into the sticker sheet. Over time, that naturally evolves into your design system.
Rule: a design system is an investment that pays off in speed and consistency. Don't define everything immediately; turn every repeated decision into a system rule.
14. Spacing Scales
Spacing is the interface's invisible glue. If it's jarringly inconsistent, the entire design feels amateur, even if your colors and fonts are flawless.
The 16px-Based Scale
The most widespread scale starts at 16px (the default browser font size) and scales up via progressive multipliers:
4px (16 × 0.25)
8px (16 × 0.5)
12px (16 × 0.75)
16px (16 × 1) ← BASE
24px (16 × 1.5)
32px (16 × 2)
48px (16 × 3)
64px (16 × 4)
96px (16 × 6)
128px (16 × 8)
The multipliers are intentionally not linear. The small jumps (0.25, 0.5, 0.75) are meant strictly for internal component details (button padding, the gap between an icon and text). The medium jumps (1.5, 2, 3) drive the separation between distinct elements. The large jumps (4, 6, 8) force separation between entirely different sections.
Why Not the 8-Point Grid?
The 8-point rule (where everything strictly multiplies by 8) is a solid starting point, but it has a flaw: the jumps between higher values get too small to be accurately perceived. The difference between 40px and 48px is only 20%, practically invisible. The scale mapped out above solves this: the leaps are always massive enough to instantly recognize, relying on a progression where the ratio between adjacent values remains significant.
The Fast Workflow
When you have to space two elements, the process is: grab a value from the scale. Not enough? Grab the next one up. Too much? Grab the previous one. Running this setup guarantees you will never waste time deciding between 37px and 39px, simply because those values don't exist. This limitation is complete liberation, not a restriction.
In CSS, you can implement the scale with variables:
:root {
--spacing-1: 4px;
--spacing-2: 8px;
--spacing-3: 12px;
--spacing-4: 16px;
--spacing-5: 24px;
--spacing-6: 32px;
--spacing-7: 48px;
--spacing-8: 64px;
--spacing-9: 96px;
}
Rule: define a spacing scale and use strictly those values. The 16px scale with non-linear jumps is currently the industrial standard.
15. Typography Scales
The Practical Scale
Just like spacing, defining font sizes in advance obliterates pixel anarchy:
12px - 14px - 16px - 18px - 20px - 24px - 30px - 36px - 48px - 60px - 72px
This scale does not follow a pure mathematical ratio (like the "perfect fifth" 1.5×), but it has been selected to work in reality. The values are all distinct enough to forge visible hierarchy, perfectly clustered in the low ranges (where micro-differences matter most) and spread out in the large ranges (where a 2px difference is completely invisible).
Elements Don't Scale Uniformly
A common trap is believing that if a heading is purely 2.5× the base text on desktop, it must absolutely be 2.5× on mobile. That doesn't work. If desktop base text is 18px, a 2.5× heading sits at 45px, perfect. On mobile, base text drops to 14px, and 2.5× lands at 35px, way too massive for a tiny screen. The appropriate mobile size is closer to 22px, which is roughly 1.6× the base text. Therefore, proportions change across breakpoints.
This is exactly why em units are universally discouraged for typography scales: it maintains the exact same ratio across every screen, but ratios that work on desktop are wrong on mobile. It is always better to declare explicit pixel sizes per breakpoint.
Rule: define a strict typography scale (12-72px) and use only those values. Proportions between dimensions drastically change between desktop and mobile.
16. Color Scales
Building the Palette
You can't just pick one color and run with it. As we've already seen, in practice, every single color demands variants: an incredibly light version for alert backgrounds, an ultra-dark one for text clamped against light surfaces, and everything in between. If your primary color is blue and you only utilize its base form, the exact second you need a washed-out blue background for an info alert and you have nothing mapped, you'll be forced to invent a color on the fly. Do that ten times, and you have ten slightly different blues in your interface.
The process for forging a cohesive scale:
- Start with the base color (the 500): the exact tone you'll deploy for buttons and the core CTA. Verify it by testing if it works as a button background layered with white text. If the contrast is sufficient and the color represents your brand, it's your starting point.
- Create the darkest variant (900): practically black but with the base hue perfectly perceptible. And the lightest (100): essentially white with just a breath of the color.
- Fill in the center stops: 700 and 300 are your dead-center compromises. Then knock out 800, 600, 400, 200.
The result is a heavy-duty scale of 9 variants. You can tag them with numbers (100-900) exactly like Tailwind CSS does, so the name instantly communicates luminosity: 100 means bright, 900 means dark. Zero ambiguity.
Compensating for Saturation Loss
When you lighten a color by driving up the luminosity (L in HSL), the color washes out. Just adding light isn't enough; you must crank up the saturation to compensate. A blue sitting at hsl(210, 80%, 50%) turns dead and lifeless at hsl(210, 80%, 80%). By manually fighting back the saturation loss with hsl(210, 95%, 80%), the color remains razor-sharp and vivid.
The exact same rule applies when darkening: the color turns to mud if you only drop the luminosity. Force a slight bump to the saturation there as well.
Rotating Hue to Shift Luminosity
An advanced trick: instead of lightening a color by drowning it in white (which destroys saturation), you can manually rotate the hue toward a color the brain naturally perceives as lighter. Colors circling yellow (60°), cyan (180°), and magenta (300°) are inherently perceived as brighter. Colors crowding red (0°), green (120°), and blue (240°) are naturally perceived as darker.
This trick is particularly lethal for yellow: if you darken yellow by dropping the luminosity, you get a dead, muddy brown. But if you twist the hue toward orange while dropping luminosity, you forge a heavy, intense golden yellow.
Warm and Cold Grays
Grays flatlining at 0% saturation tend to look flat and expressionless. By injecting just a 5–15% shot of saturation (using either a warm hue like yellow/orange, hue ≈ 40° or a cold hue like blue, hue ≈ 210°), the gray gains character. A tech site builds authority with cold grays; a cooking site feels more welcoming with warm grays. The single unbreakable rule: the temperature must remain perfectly synchronized across the entire interface.
Rule: every color requires 5-10 strict variants (from 100 to 900). Compensate saturation when shifting luminosity. Grays injected with a chromatic undertone build personality.
17. Shadow and Border-Radius Scales
The 5 Shadow Levels
Exactly like colors and spacing, shadows must be systematically locked down. Forging a unique shadow for every single element brings the same chaos as picking colors on the fly. 5 fixed levels completely cover all the cases you will encounter:
- Level 1: barely perceivable. Reserved for static info cards and thin dividers between sections. The user won't consciously clock it, but the brain inherently acknowledges the element is "slightly hovering."
- Level 2: light elevation. Used for clickable cards and buttons resting in default state. It broadcasts "you can interact with me."
- Level 3: medium elevation. Built for open dropdowns, tooltips, and context menus. The element clearly detaches itself above the page content.
- Level 4: high elevation. Engineered for modals, dialogs, and overlays. The element captures attention and obscures the rest.
- Level 5: maximum elevation. Reserved exclusively for critical notifications and elements that absolutely must dominate everything.
In section 12 of the CSS Real World Vademecum, we saw how to implement shadows with box-shadow. The objective here is different: inside your design system, you define the 5 levels exactly once, and whenever an element requires a shadow, you deploy the appropriate level. You never invent new values.
The best professional shadows always run two distinct layers. The first layer visually mimics direct light: it's soft, exceptionally large, and features a marked vertical offset. The secondary layer simulates the tight shadow beneath the object where ambient light doesn't reach: it's tight, significantly darker, with minimal offset. Combined, they forge a hyper-realistic elevation that a single shadow can never achieve.
During interactions, the shadow operates as system feedback. Hover state: the shadow scales up one level and the element visibly lifts. Click/pressed state: the shadow instantly collapses or vanishes entirely, making the element sink under pressure. Release: it snaps instantly back to baseline. This cycle physically transmits the state of the interaction.
Cohesive Border-Radius
Lock down a strict system for radiuses and deploy it everywhere:
- 0px: sharp, formal, minimal design
- 4-8px: standard rounding, the most common
- 12-16px: aggressive rounding, pushing a more playful vibe
- Pill (999px): completely rounded, engineered for badges and tags
The ultimate rule: never, ever mix razor-sharp square corners with rounded ones in the same interface. If your cards run a smooth rounding, your buttons, inputs, and badges must identically mirror it. Pure consistency is vastly more important than the specific choice itself.
Concentric Radiuses (The Apple Formula)
Whenever a rounded element houses another rounded element (like a button trapped inside a card), the radiuses must run perfectly concentric. This means the inner curve and the outer curve travel flawlessly parallel, exactly like two lanes on a track: the inner lane has a tighter radius than the outer, but the distance between them remains absolute. The math is simple: inner element radius = outer element radius - padding between the two.
If the card runs a 16px radius and the button sits 8px from the hard edge, the button absolutely must run an 8px radius (16 - 8). If you lazily assign the exact same radius to both, the negative space separating their curves distorts violently: it gets crushed tight in the corners and blows wide open along the flat edges. The eye instantly perceives something is skewed without knowing what, and the design loses that "done right" feeling. Apple aggressively enforces this rule everywhere, from app icons to OS window framing, and it serves as a massive pillar behind their obsessively cohesive visual identity.
Rule: 5 locked shadow levels, dual-layered shadows for realism. Cohesive border-radius across the entire interface. Concentric radiuses for nested elements.
18. Design Personality
Every interface dictates a personality. The choices across typography, color, radiuses, and copy actively narrate the product itself.
Personality Tools
Typography transmits the strongest signal. A serif font (with little feet) loudly broadcasts elegance and tradition. A rounded sans-serif screams playful energy. A geometric sans-serif geometric projects modern tech. A monospace font signals pure technicality.
Color dictates the emotional temperature. Blue is intensely safe and familiar. Pink is inherently fun. Gold broadcasts luxury. Absolute black projects minimalist elegance.
Border-radius contributes significantly more than expected. Razor-sharp 0px angles broadcast severe formality. Expansive curves (16px+) push a wildly approachable, friendly tone.
The interface's copywriting absolutely zeroes in on the exact tone. "Thank you, Mr. Benson, your reservation has been confirmed" operates with stiff, professional formality. "Sweet, thanks Steve! You're all set!" runs informal and intensely friendly. Words are literally everywhere in an interface, and locking down the right tone is just as structurally critical as choosing the right color.
How to Lock In Personality
If you are totally lost, analyze what your target demographic already engages with. If their environment is severely professional, you must be severely professional. If it's playful and laid-back, pivot hard in that direction. Do not straight-up clone your direct competitors (you never want to look like a copy); actively absorb the industry tone to strategically dominate your positioning.
Rule: the design's personality aggressively emerges from typography, color, radiuses, and copy. It must be brutally cohesive and intentional, never accidental.
Recap (Design System at a Glance)
| Concept | Key Rule | Common Trap |
|---|---|---|
| Design system | Forge the rules once, apply them always | Starting every single decision from zero, every single time |
| Spacing scale | Locked to 16px baseline, extreme non-linear jumps | Firing off random pixel values (13px, 17px, 22px) |
| Typography scale | Lock in a 12-72px scale. Dramatically shift proportions for mobile | Blindly forcing the exact same ratio across all breakpoints |
| Color scale | Force 9 strict variants per color, from 100 to 900 | Running one lone color completely lacking variants |
| Saturation comp | Always heavily crank saturation whenever pushing brightness up | Dropping brightness and landing completely washed-out tones |
| Grays | Force a warm or cold undertone, strictly lock it everywhere | Deploying pure 0% saturation grays |
| Shadows | Map 5 definitive levels, run dual-layers for sharp realism | Spinning up completely ad-hoc shadows for every component |
| Border-radius | Brutally cohesive system, concentric radiuses for internal nesting | Randomly mixing razor-sharp square and softly rounded corners |
| Personality | Fonts + color + radiuses + copy | Running a scattered, entirely accidental personality |
The Components
Components are the fundamental bricks of the interface. Every single button, card, menu, and input field operates on precise rules that, when strictly enforced, forge completely fluid interaction. If ignored, they instantly generate friction.
19. Buttons (The Hierarchy of Actions)
The single most critical law regarding buttons: absolutely one primary call to action per page. Your only job is to deliberately isolate the single most critical action and grant it the spot of honor.
Button Hierarchy
Buttons break down into three hierarchical tiers.
The primary is the apex action, the absolute core thing you need the user to execute. Solid heavy color, massive contrast, dominating placement. There is exactly one per screen.
The secondary is the fallback. Hollow outline (a border housing a transparent background) or heavily muted color. Only deploy it if it sits directly alongside a primary; a lone secondary rarely makes any structural sense.
The tertiary is the absolute lowest priority. Pure text, zero bounding box. You can blanket the screen with these within the same layout structure.
❌ Three identical blue buttons sitting in a row. Which is the CTA? Total visual collapse.
✅ A heavy blue primary, a hollow outline secondary, a pure text tertiary. Hierarchy is instantaneous.
The Destructive Button
The destructive button ("Delete", "Cancel Account") doesn't invariably need to scream red and dominate the view. It strictly depends on context. If it isn't the apex action of the screen, crush it down to a secondary or tertiary rank with just red text. Only maximize it as a heavy solid red primary if it truly is the definitive CTA of that screen (like pushing for action inside a hard confirmation modal).
Real-world scenario: the McDonald's kiosk tucks the order cancellation button down as a subtle tertiary link sitting among other standard options. It looks harmless, but the user is highly likely to misclick it because it doesn't dynamically distinguish itself from "normal" actions. The exact opposite is Spotify's execution: their "Close account and delete my data" button runs an inviting, heavy green, the exact same green as their core brand. That color permanently broadcasts "positive action" when in reality it triggers a catastrophic move you almost never want to execute impulsively.
We already observed how Feltrinelli tactically deploys green for the core CTA instead of their heavy red brand color. Red universally screams "danger" or "destruction" in digital UI logic. A user would instantly hesitate in front of a giant red "Add to Cart" button because the color violently contradicts the text.
Padding, Sizing, and Alignment
The absolute golden ratio for button padding runs heavily at 1:2 between height and width. If vertical padding hits 12px, horizontal padding absolutely must push to roughly 24px. This mechanically dictates a visual weight that feels deeply balanced to the eye.
Hard-lock a maximum of 3 sizes into the design system (small, medium, large). Three sizes brutally cover every possible context: small for severely tight spaces like dense tables and toolbars, medium for universally standard deployment, and large for massive CTAs built to completely dominate the screen.
Buttons absolutely must align flawlessly to the full width of whatever content sits directly above them. If an image stretches 300px wide, the button beneath it stretches exactly 300px wide. This engineers flawless visual continuity, making the design "feel right" even if the user possesses zero understanding of underlying grid logic.
Button States
Every single button inherently cycles through 5 distinct visual states: default (how it rests globally), hover (cursor actively intersecting, forcing a slight color/elevation shift), active/pressed (user actively clicking, making the button physically "compress"), disabled (flat gray, severely reduced opacity, unclickable), and focus (keyboard targeted, pushing a heavy outline for strict accessibility). These are the static properties you rigidly define in the design system and forge via CSS. Everything that happens after the raw click (the wait sequence, the systemic confirmation, the visual feedback that securely steers the user to the result) is interaction behavior, deeply explored in section 4 on System Feedback.
Rule: one absolute primary per page. The destructive action is not exclusively red. Force a 1:2 padding ratio. Max 3 sizes rigidly locked into the system. Every single button actively cycles 5 states.
20. Cards (Grouping and Inviting)
Cards act as structural visual containers engineered to herd related data. They dominate modern interface patterns, driving everything from relentless social feeds to massive product grids.
Shadow Only if Clickable
If the card is purely interactive (punches through to a detail view, launches a product module), bolt on a fast, light shadow. That shadow aggressively broadcasts: "you can engage with me." If the card operates strictly to containerize static data with zero interactive intent, strip the shadow entirely and rely purely on a tight stroke (thin border) or a subtle background hue shift off the main canvas. Forcing a shadow onto a dead, unclickable card instantly breeds a counterfeit expectation of interaction, ripping to massive frustration when clicked.
Clustering
If a single card is heavily stacked with incoming data (e.g., massive title, subtitle, price node, stock availability, ratings module, CTA), the user's brain is forced to violently scan 6 totally detached elements. It's an aggressive overload. Mechanically crush them into tight visual macro-blocks relying entirely on whitespace: choke out the spacing tight between directly related items, blow the spacing wide open separating the different blocks. Title and subtitle form block one. Price and stock lock into block two. Rating and the CTA fuse into block three. The user now effortlessly scans exactly 3 solid zones instead of 6 scattered orphans.
This relentlessly leverages the Law of Common Region (a Gestalt protocol we already locked down): elements physically trapped within identical visual radii are instantly processed as a cohesive squad. You don't need heavy dividing walls or layered nested boxes; raw, absolute proximity handles all the heavy lifting.
Images inside Cards
The modern standard aggressively demands forcing the main image out edge-to-edge, entirely stripping away any internal padding clamping the image against the card's outer border. It drives an exceptionally clean, highly minimalist baseline aesthetic compared to legacy layouts where massive images sat violently trapped inside heavy internal margins. If you immediately compare a modern Airbnb card (full-bleed edge-to-edge visual) against a dated site (images completely trapped in 16px borders), the brutal difference in structural modernity is absolutely clear.
Cognitive Overlap
If the card inherently houses an internal data carousel (heavily swipeable nested graphics), brutally strip off the shadow from the main container matrix. If the host shadow screams "this entire block acts as a singular interactive click region," yet the internal carousel strictly demands "swipe me horizontally to process more deep-layer assets," you have forcefully crammed two actively conflicting systemic interactions simultaneously into the identical spatial zone. The user entirely freezes because they literally cannot decode if striking the graphic will violently push them into a secondary detail index page or simply engage the scroll-slide protocol. This catastrophic friction is clinically documented as cognitive overlap, and it actively generates massive UX chaos.
The brutal resolution protocol: if you absolutely mandate the carousel to survive, instantly terminate the main foundational container shadow (the card completely fails to function securely as an integrated clickable node). If you demand the card to operate as the singular apex click target, completely murder the carousel array (force exactly one static display graphic). Under absolute extreme scrutiny never attempt to aggressively engineer both interacting systems violently across each other seamlessly.
The exact identical core law equally dictates any dual-zone interactivity trap: attempting to nest an active button directly inside a container card WHILE making the FULL CARD globally clickable strictly forces explosive systemic ambiguity. The navigating user completely fails to decode whether striking the card directly initiates the precise identical macro-action as striking the deeply nested core button, or if doing so deploys a violently totally disconnected sequence layer.
Concentric Radiuses
As fiercely established in Concentric Radiuses (The Apple Formula), nested elements' curve trajectories must run flawlessly parallel at all times.
Rule: shadow exclusively on highly interactive functional elements. Aggressively cluster vast data into tight visual mega-blocks. Blow interior graphics out fully edge-to-edge. Force rigid concentric radiuses targeting internal element hierarchies.
21. Navigation (Guiding Without Confusing)
Navigation natively serves exactly as the architectural signage system deployed across an active facility. If it is ruthlessly explicitly organized, the traversing user mechanically locks onto their destination target totally without processing secondary thoughts. If it's convoluted or totally absent, the moving user immediately gets completely lost and aggressively bounces from the domain structure (if they eventually lock the path layout).
Tab Bar (Mobile)
The bottom tab bar is the most common navigation pattern for mobile apps. The rules: minimum 3 items, maximum 5. Fewer than 3 do not justify a tab bar (use other patterns). Beyond 5 items, the brain can no longer process them as a single unit; it has to scan them one by one like a list, and the tab bar loses its value as a visual anchor that is always available. The ideal number is 3-4.
For the selected item: filled icon + text at 100% opacity. For the others: outline icon + text at 40-50% opacity. Do not color the entire bar while highlighting the selected icon, unless the background color is neutral enough not to create confusion.
Home typically goes on the left because we read from left to right, making the first item in a horizontal sequence the natural starting point.
Hamburger Menu
The hamburger menu (the three horizontal lines) is declining as primary navigation in mobile apps, replaced by the bottom tab bar which is always visible and doesn't hide items. The problem with the hamburger is that it "buries" navigation: the user doesn't know what they will find behind the icon, and what isn't seen is used much less. If you decide to use it, position it at the top left or top right.
A parallel trend concerns settings: they are migrating from the gear icon (or the hamburger) straight into the profile menu at the top right. The profile communicates "your stuff" better than a generic gear, and groups both account and configuration into a single point. You can observe this trend in action in the Mosaic project.
Mega Menu vs Dropdown
The classic dropdown is a vertical list of items that opens on hover or click. It works well when the items are few (5-10) and homogeneous: "Products, Pricing, Documentation, Blog" for a SaaS, or an "Account" menu with 4-5 options. Beyond 10 items it becomes a long list to scroll, and the user struggles to keep track of what they've seen while scrolling.
The mega menu is a wide panel that appears below the navigation item and displays dozens of options organized in thematic columns. It is the standard pattern for e-commerce sites with many categories: clicking on "Clothing" immediately reveals "Men / Women / Kids" in columns, each with its subcategories. The user sees the entire structure at a glance and chooses where to go without opening nested menus or scrolling an endless list.
The rule is simple: if your items fit comfortably in a list of 5-10 homogeneous elements, use the dropdown. If you have dozens of items that logically group into categories, use the mega menu. Forcing a dropdown on a rich catalog forces the user to scroll and remember; forcing a mega menu on a site with few items makes it look visually oversized.
Other Navigation Patterns
Breadcrumbs (e.g., Home > Documentation > API > Authentication) are a trail that shows the user where they are in the site's hierarchy and allows them to move up a level with one click. They only make sense when there is a deep hierarchy with at least three levels: documentation sites, management software with sections and subsections, a corporate site with nested folders. On a flat site, where all pages are on the same level, breadcrumbs would always show "Home > Current Page" and add absolutely nothing.
The sticky navbar remains fixed at the top of the screen while the user scrolls the page. It's useful when the page is long and the user might want to switch sections midway without scrolling back to the top: landing pages with many sections, long articles, apps where navigation must always be a click away. On short pages that fit in one or two screens, it's superfluous and steals precious vertical space, especially on mobile.
The vertical sidebar is a navigation column on the left (or right) side of the screen, always visible. It's the standard for dashboards, admin panels, and complex applications where the navigation items are too numerous to fit in a horizontal header and the user switches from one section to another dozens of times a day. The sidebar can be collapsible (reducing to just icons to free up space) or expanded by default. On mobile, it almost always transforms into a hamburger menu, because a fixed column would occupy half the screen.
You can observe this pattern on this very site. If you are reading on desktop, you have a left sidebar with site sections and a right one with the current page's index. If you are reading on mobile, both have been collapsed into a hamburger menu at the top left to free up the screen.
Rule: 3-5 items in a mobile tab bar. Hamburger menu only if necessary. Mega menu for websites with many categories. No pattern is universally better; it heavily depends on the product and the users.
22. Forms and Inputs (Collecting Without Frustrating)
Forms are the point where you ask the user for something. Every field, every label, every error message is a potential moment of pure frustration. The less friction you create, the more forms get completed.
Group by Category
When a form holds more than 6 inputs, cluster them into visual categories. "Personal Data", "Address", "Payment" are sections the brain processes as three fast blocks, not as 15 individual fields. Utilize <fieldset> and <legend> in your HTML (as seen in section 10 of the HTML Vademecum) and visual separators in the design.
Auto-formatting and Helpers
The phone number field that automatically inserts hyphens. The currency symbol already present on the left/right in the price field. The date that auto-formats as you type. Every single piece of mental overhead you spare the user regarding formatting is a direct step toward form completion.
Always include the eye icon in the password field to show/hide the inputted text, as it has become a strict baseline standard.
Inline Validation
Do not wait for the submit trigger to display errors. Validate exactly as the user inputs the data: display a green checkmark when the field clears, a red X when it doesn't, accompanied by the error message directly below the field (not buried in a generic alert at the top of the page that the user has to mentally connect back to the input).
The error message must not simply state what is wrong; it must explicitly state how to fix it. Never "Invalid format," but "The email must contain @ and a domain (e.g. mario@example.com)."
Ask the Bare Minimum
Every single field in a registration form operates as a wall between the user and the signup. Exclusively ask only for what you absolutely need to start the service. Extraneous data (phone number, physical address, preferences), if strictly necessary, should be requested after registration, once the user has safely established the account.
Rule: cluster inputs exceeding 6 into tight categories. Auto-format wherever possible. Execute inline validation featuring corrective messaging. Ask for the absolute bare minimum.
23. Modals, Toasts, Tooltips, and UI Patterns
Modal
The modal is a heavy overlay that completely locks interaction with the remainder of the page. Use it exclusively for critical confirmations ("Are you sure you want to delete?"), core actions requiring absolute focus (executing a mini-form), or critical systemic alerts. It must always feature an immediate escape route: the top-right X, a clear "Cancel" button, or an active click targeting the dark background. Trapping the user inside a modal devoid of an exit brutally violates Nielsen's heuristic #3 (User control and freedom).
Toast
The toast is a non-blocking transient alert that briefly appears purely to confirm a completed action. "Item saved", "Email sent", "Copied to clipboard". It surfaces in a far corner (usually bottom or top), remains visible for precisely 3-5 seconds, and vanishes. It demands zero user interaction. Never deploy a toast for critical errors (those explicitly mandate a modal or an inline message, meaning an error text rendering directly beneath the field or element that originally spawned the failure).
Tooltip
The tooltip is an on-demand informational node that surfaces entirely on mouse hover (or long tap on mobile). It operates specifically for deep details that aren't constantly necessary but someone might actively hunt for. The standard question mark icon stationed directly beside a form field explicitly detailing exactly why we demand that specific data is a classic baseline example.
Accordion
The accordion mechanically expands and compresses content blocks. The arrow direction signifies the exact vector: arrow down = expands downward. Never invent alternate trajectory indicators. The accordion is the absolute ideal deployment for FAQs, where the user actively hunts down a severely specific question and absolutely does not want to visually process all answers simultaneously.
Toggle, Checkbox, Radio
The toggle (switch) represents a heavily binary state that executes absolute immediate effect: you activate dark mode and the screen snaps immediately; you kill notifications and the system instantly stops firing them. The user taps it and the modification executes immediately, demanding zero secondary confirmation.
The checkbox allows the user to aggressively select multiple options from a distinct list simultaneously, without one choice excluding the others. You select the exact pizza toppings (mozzarella, mushrooms, and olives concurrently), you aggressively check off the terms and conditions, you target multiple distinct files strictly inside a management array. Unlike the toggle, the checkbox usually demands a secondary structural action to successfully commit the selection (a heavy "Confirm" or "Save" button).
The radio button forces the user to lock onto exactly one singular choice from an array of alternatives, where explicitly selecting one strictly automatically excludes all others. You target a strictly specific t-shirt size (S or strictly M or L), the payment vector, the exact subscription tier.
Confusing these three distinct operators absolutely shatters the user's operational expectations. Deploying a toggle where a checkbox is expected forces the brain to assume the variable is already saved exactly when it actively isn't. Running a checkbox instead of a radio button deceptively implies you can successfully lock multiple options when the system logic strictly accepts one. Firing a radio instead of a toggle actively forces the user to hit "Confirm" for a strike that natively should be an instant toggle. Every control carries a highly specific, unbreakable contract of expectation, and violating it instantly generates massive friction.
Chips, FAB, Onboarding
Chips operate as heavily compressed, fully rounded, pill-shaped elements that allow the user to rapidly tap or select options to relentlessly filter, categorize, or lock in an active variable. You see them heavily dominating the UI in apps like Gmail (when a locked-in email target is instantly wrapped into a pill stacked with a hard 'x' for rapid removal), or buried deep inside Airbnb and Booking filter grids ("Wi-Fi", "Pool", "Pets Allowed"), where actively engaging an option physically solidifies it into a visible active chip on the board. They are aggressively compact, built specifically to stack tight horizontally without bleeding out massive screen real-estate, and their intensely rounded shape completely severs them from standard text, explicitly broadcasting that they are a highly interactive node.
The FAB (Floating Action Button) holds the line as a heavily anchored circular trigger generally locked in the bottom right, brutally enforcing the absolute ultimate primary action of the entire application. Google actively deployed it via the Material Design protocol. It securely holds its fixed position utterly irrespective of vertical scroll depth, transforming it into the ultimate tactical nuke for a single massive CTA (blasting open a new sequence in Gmail, instantly triggering an event inside a calendar). The bottom-right tactical anchor was heavily adopted simply because it represents the most accessed strike-zone for a right thumb while operating the device one-handed. While this default bottom-right anchoring dominates natively, it is not, thankfully, an absolute prison: many high-level applications actively allow customization of its axis through deep accessibility settings.
Onboarding is the initial, rapid sequence designed to gracefully introduce the user to the application's core capabilities. The strict laws: crush it to an absolute minimum sequence (strictly 3-5 screens), only showcase the most core features (do not explain the entire system architecture), and absolutely mandate a fully exposed escape sequence to instantly skip the entire thing. The user is eager to execute the software, not read a manual. Remember the section "We'll Muddle Through" (Nobody Reads Instructions)?
Rule: aggressively deploy modals purely for major systemic confirmations, always with a clear exit vector. Run toast markers strictly for light, fast interactions. Anchor tooltips for on-demand deep context. Toggle = instant on/off execution. Checkbox = multi-target variable. Radio = singular, mutually exclusive lock.
Recap (Components at a Glance)
| Concept | Key Rule | Common Trap |
|---|---|---|
| Buttons | One primary per page. Hierarchy: primary > secondary > tertiary | All buttons styled identically sharing the exact same color and footprint |
| Destructive | Not identically red. Primary red purely if it acts as the true CTA | An aggressively large, heavily red "Delete" target completely dominating every view |
| Cards | Shadow strictly if clickable. Heavily cluster internal info grids | A purely static card running a shadow mimicking false interactivity |
| Concentric radiuses | Infinite inner curve = absolute outer curve perfectly minus padding | Jamming the exact identical radius onto both the container and internal anchor |
| Tab bar | 3-5 nodes, solid filled icon strictly for the targeted active state | Vastly more than 5 elements or running strict icons heavily missing explicit textual labels |
| Hamburger | Rapidly disappearing, securely pinned explicitly to top left/right bounds | Running it as the absolute lone structural navigation specifically on vast desktop canvas |
| Form | Cluster heavy inputs entirely exceeding 6, strictly execute inline validation | Exclusively surfacing data errors completely post-server submit strike |
| Modal | Always featuring a clear exit. Purely for heavy systemic confirmation | Modals heavily lacking an X trigger or an explicit Cancel button |
| Toast | Transient, strictly 3-5 seconds, built entirely for light confirmations | Deploying a toast clearly for severe critical system failures |
| Toggle vs checkbox | Toggle = instant on/off, checkbox = multiple, radio = strictly exclusive | Blindly mixing all three across the identical system |