# Product design decisions Use these cards when reviewing screens, flows, and UI decisions. For each decision in the work you're reviewing, find the matching card, apply its rule and its numbers, say which option fits and why in one sentence, and check the edge case before you recommend it. Cite the card by title and link. Source: https://productfordesigners.com · Author: Alex Dovhyi --- # Tabs or Sidebar > Persistent navigation is for destinations users switch between. Everything else is a link. ## Situation How many destinations, and how often do people switch? ## Decision ### Use Tabs when You have a handful of peer destinations and people jump between them constantly. Tabs keep every option visible without spending a column of the screen. - Three to five peer destinations - Hierarchy is mostly flat - Frequent switching within one context - Horizontal space matters - Growth is unlikely ### Use Sidebar when You have many destinations, often in groups, and people work across sections all day. A sidebar has room for labels, grouping, and growth. - More than five destinations, or groups of them - Labels need reading, not guessing - Frequent work across sections - The roadmap adds destinations - Desktop-first product **The numbers:** Tabs: 3–5 peer destinations, switched many times per session. Sidebar: 6+ destinations, any grouping, or a roadmap that adds sections. If the labels don’t fit in one row at your smallest breakpoint, it’s a sidebar. ## Why People switch between these five areas all day and we don’t expect more, so tabs keep everything one click away without giving up a column of the screen. ## Edge cases A product with 4 sections today and 12 planned. Choose the sidebar now: moving navigation later retrains every user. Source: https://productfordesigners.com/cards/tabs-sidebar Author: Alex Dovhyi --- # Skeleton or Spinner > Match the loading treatment to the wait: nothing under a beat, structure for seconds, progress for longer. ## Situation Do you know what’s coming, and how long is the wait? ## Decision ### Use Skeleton when You know the layout that’s coming and the wait runs a few seconds. Holding the structure steady lets content land where the eye already is. - Predictable layout: lists, cards, profiles - First load of a page or view - Roughly one to ten seconds - A layout jump would be jarring ### Use Spinner when The wait is short or the result has no predictable shape, like a submit or a search. Delay it by a few hundred milliseconds so fast responses never flash. - Unknown result layout - An action in progress, not a page loading - Roughly one to three seconds - Small spaces, like inside a button **The numbers:** Under 1 s: show nothing, and delay any indicator by about 300 ms so fast responses never flash. 1–10 s: skeleton if the layout is known, spinner if not. Over 10 s: real progress, and let people keep working. ## Why This view loads in two to four seconds and we know its layout, so a skeleton keeps the page steady and makes the wait feel shorter than a spinner would. ## Edge cases If the data usually arrives in under half a second, a skeleton becomes a flicker. Delay it, or show nothing at all. Source: https://productfordesigners.com/cards/skeleton-spinner Author: Alex Dovhyi --- # Undo or Confirm > Prefer undo to confirmation. Confirm only what can’t be undone, and name the consequence in the button. ## Situation Can it be undone, and how often does it happen? ## Decision ### Use Undo when The action is frequent and reversible. Do it instantly and offer a way back for a few seconds. - Archive, move, mark as done - Happens many times a day - Can genuinely be reversed - A trash or soft delete exists ### Use Confirm when The action is rare and permanent. Slow people down once, and say exactly what will happen on the button. - Permanent deletion - Affects other people or money - Rare enough to actually be read - The button names the outcome, never OK **The numbers:** Happens daily and can be reversed: undo, available for 5–10 seconds. Rare and permanent: confirm, with the outcome on the button (‘Delete 3 files’). Highest stakes: ask people to type the name. ## Why People archive dozens of emails a day, and a dialog every time would get clicked through without reading. Undo protects them without slowing them down. ## Edge cases Deleting a whole workspace is permanent and affects everyone, so a plain confirm isn’t enough. Ask people to type the workspace name. Source: https://productfordesigners.com/cards/undo-confirm Author: Alex Dovhyi --- # Primary or Secondary > One primary action per view. Everything else steps back, and destructive actions look destructive. ## Situation Which action do most people take next? ## Decision ### Use Primary when The single most likely next step on this screen. Filled, high contrast, in a predictable place. - What most people do next - Moves the task forward - One per view or dialog - Labeled with a verb and an object ### Use Secondary when Everything valid but less common: cancel, back, export, save as draft. Outlined or plain, so it never competes. - Alternatives and escapes - Less frequent actions - Cancel and Back - Destructive actions get their own style **The numbers:** Count the filled buttons on the screen. More than one is a decision you haven’t made yet. A destructive action is never primary unless deleting is the whole point of the dialog. ## Why Most people who open this screen are here to publish, so Publish is the one filled button. Preview and Save draft are still there, just quieter. ## Edge cases In a ‘Delete project?’ dialog, deleting is the decision. The destructive button can be primary, styled as dangerous and named for the outcome. Source: https://productfordesigners.com/cards/primary-secondary Author: Alex Dovhyi --- # Ask or Default > Don’t ask what you can infer. Default to what most people would choose, as long as it’s safe. ## Situation Could you answer this question for them? ## Decision ### Use Ask when There’s no clear majority answer, or the choice has real consequences for money, privacy, or commitment. - Role or use case - Plan and pricing choices - Consent and marketing - Inferences would often be wrong ### Use Default when The system already knows the answer, or most people pick the same thing. Show the value and make it easy to change. - Country, currency, time zone - Choices made last time - A safe, common option exists - Values stay visible and editable **The numbers:** Default when the system already knows (location, last choice) or when one option covers most people and is safe. Ask when no option covers most people, or when the choice involves money, privacy, or consent. Consent is never pre-checked. ## Why We know the user’s country from their billing address, so currency is already set and still editable. Roles vary too much to guess, so we ask. ## Edge cases A common default can still be unsafe: pre-selecting the most expensive plan, or opting people into marketing. Common isn’t the same as safe. Source: https://productfordesigners.com/cards/ask-default Author: Alex Dovhyi --- # Suggestions or Results > Once the query means something, show the thing, not a guess at the question. ## Situation Does the person already know what they’re looking for? ## Decision ### Use Suggestions when The catalog is huge and unknown to the person searching, like a marketplace. Helping them phrase the query narrows a space they can’t see. - Open, unbounded catalog - People don’t know item names - Exploratory browsing - Wording changes results a lot ### Use Results when People look for something they’ve seen before: a file, a customer, a ticket. The best suggestion is the item itself, opened with Enter. - Known-item retrieval - Finite content the team owns - Items have memorable names - Repeat users who want speed **The numbers:** Finite, named content: switch from suggestions to real results after 2–3 typed characters. Open catalogs where people can’t know item names: keep query suggestions. Empty field: recent items, not results. ## Why People search here for files they’ve already seen, so the fastest answer is the file itself, opened with Enter, not a guess at their question. ## Edge cases Before anyone types, there’s nothing to match. Show recent items and saved searches instead of results. Source: https://productfordesigners.com/cards/suggestions-results Author: Alex Dovhyi --- # Optimistic or Wait > Show success instantly when failure is rare and cheap. Wait when money, other people, or permanence is involved. ## Situation Does it almost always succeed, and is failure cheap? ## Decision ### Use Optimistic when The action succeeds almost every time and a failure is easy to undo. Update the screen immediately and roll back visibly if the server says no. - Likes, stars, reactions - Reordering, renaming, toggling - Failures are rare - Rollback is simple and visible ### Use Wait when A failure would hurt: money moves, other people are notified, or something can’t be undone. Show progress and confirm only after the server does. - Payments and transfers - Sending to other people - Permanent changes - Validation only the server can do **The numbers:** Optimistic if it fails well under 1% of the time and rolling back costs nothing. Anything involving money, other people’s inboxes, or deletion waits for the server. ## Why Starring a file almost never fails, and if it does we just unstar it, so it updates instantly. Payment waits for the bank, because showing success early would be a lie. ## Edge cases Chat messages are sent optimistically because a failed message stays visible with a ‘Not sent, retry’ state. Optimism works when failure stays visible. Source: https://productfordesigners.com/cards/optimistic-wait Author: Alex Dovhyi --- # Modal, Panel, or Page > Choose the container by what the user needs to see while they work. ## Situation What do people need to keep in view while they work? ## Decision ### Use Modal when A short, focused decision that must be finished or cancelled before anything else. - A few fields or a single decision - No need to see the page behind - Blocking is intended - It never opens another modal ### Use Panel when Inspecting or editing one item while the list stays in view, or working through items one after another. - The list is useful context - Reviewing items in sequence - Comparing against what’s behind - Wide screens ### Use Page when Long or complex work, or anything people will link to, bookmark, or come back to. - Many fields or sections - Needs its own URL - Shared or revisited - Deserves full attention **The numbers:** Modal: up to about 3 fields or one decision. Panel: one item from a list, when the list stays useful. Page: more than a screen of content, or anything people link to or come back to. ## Why Reviewers go through tickets one after another, so details open in a panel. The queue stays visible and the next ticket is one click away. ## Edge cases On a phone there’s no room beside the list. Panels become full-screen sheets, and the ‘keep the list in view’ argument disappears. Source: https://productfordesigners.com/cards/modal-panel-page Author: Alex Dovhyi --- # Table or Cards > Tables for comparing values across items. Cards for judging items by what they look like. ## Situation Do people compare values, or judge items one at a time? ## Decision ### Use Table when People compare the same attributes across many items, sort them, and scan down columns. - Same attributes on every item - Sorting and filtering by value - Numbers, dates, statuses - Many items, read side by side ### Use Cards when Each item is judged as a whole, often visually: a listing, a template, a project with a cover. - Images carry the decision - Few attributes per item - Browsing, not comparing - Items vary in shape **The numbers:** People compare 3+ attributes across items: table. The image is the main reason to click: cards. Unsure? Ask whether people would want to sort it. ## Why Finance compares amounts, dates, and statuses across hundreds of payments, so it’s a sortable table. Cards would turn every comparison into a scroll. ## Edge cases Tables collapse badly on phones. On mobile, a table often becomes a list of compact cards with the two most-compared values up front. Source: https://productfordesigners.com/cards/table-cards Author: Alex Dovhyi --- # Toggle or Checkbox > Toggles act immediately. Checkboxes wait for a submit. ## Situation Does it take effect right away, or after Save? ## Decision ### Use Toggle when A setting that switches on or off the moment it’s flipped, like a light switch. - Takes effect immediately - Standalone setting - No Save button nearby - Clear on and off states ### Use Checkbox when A choice that’s part of a form and applies on submit, or one of several options people can select together. - Part of a form with Submit or Save - Multiple selections from a list - Agreeing to terms - Nothing happens until confirmed **The numbers:** If flipping it changes something before any button is pressed, it’s a toggle. If it waits for Save or Submit, it’s a checkbox. A toggle never sits inside a form with a Save button. ## Why Dark mode changes the moment you flip it, so it’s a toggle. The notification preferences are saved together at the bottom, so they’re checkboxes. ## Edge cases A toggle whose action takes a few seconds, like connecting an integration, needs a loading state on the toggle itself, or people will flip it again. Source: https://productfordesigners.com/cards/toggle-checkbox Author: Alex Dovhyi --- # Inline or Summary > Say what happened and how to fix it, next to where it happened, without losing anyone’s work. ## Situation Is it one mistake, or several at once? ## Decision ### Use Inline when One field is wrong, or you can check it as people leave the field. The fix sits right beside the problem. - A single field has the problem - Validation when leaving the field - Short forms - Format hints for dates and phone numbers ### Use Summary when Submitting finds several problems at once, often in a long form. A summary at the top counts them and links to each field. Keep the inline messages too. - Several errors after submit - Long or multi-section forms - Checks that run on the server - Keyboard and screen reader users need one place to land **The numbers:** One error: inline only. Two or more after submit: a summary at the top with a count and a link to each field, plus the inline messages. Validate a field when people leave it, never on every keystroke. ## Why Submitting can surface several server errors at once, so a summary tells people how many there are and takes them to each one. The inline messages stay so the fix sits next to the field. ## Edge cases Very short forms, like a login. Even with two errors, inline is enough: the whole form is already in view. Source: https://productfordesigners.com/cards/inline-summary Author: Alex Dovhyi --- # Breadcrumbs or Back > Breadcrumbs show where you are. Back shows where you were. Deep hierarchies need both. ## Situation Do people jump up levels, or just retrace their steps? ## Decision ### Use Breadcrumbs when Content lives in a hierarchy three or more levels deep, and people jump up more than one level at a time. - Three or more levels of nesting - People arrive mid-hierarchy from search or links - Jumping up two levels at once - Folders, categories, docs ### Use Back when A shallow, linear path where the previous screen is almost always where people want to go. - One or two levels deep - Mobile drill-down - Linear flows, list to detail - The previous screen’s title makes a useful label **The numbers:** Two levels deep: a back button is enough. Three or more, or people arrive mid-hierarchy from search or links: add breadcrumbs. Label back with the destination’s name, not just ‘Back’. ## Why Half our traffic lands on a document from search, so they’ve never seen the folder above it. The breadcrumb tells them where they are and gets them up in one click. ## Edge cases On mobile, a full breadcrumb trail truncates badly. Show only the parent (‘‹ Projects’) and keep the full path one tap away in the header. Source: https://productfordesigners.com/cards/breadcrumbs-back Author: Alex Dovhyi --- # Autosave or Save > Save automatically when every edit is safe to keep. Ask for Save when changes must land together or affect others. ## Situation Is every edit safe to keep the moment it’s made? ## Decision ### Use Autosave when Documents, notes, and canvases where each edit stands alone and losing work is the worst outcome. - Continuous editing - Version history exists - Only the author is affected - People forget to save ### Use Save button when Settings and records where changes should land together, be validated first, or will reach other people. - Several fields that must agree - Changes affect billing, access, or others - Server validation before applying - People expect to review, then commit **The numbers:** Autosave if a half-finished edit is harmless and version history lets people go back. Save button if a half-finished state could break something or reach someone else. Never mix both models on one screen. ## Why Changing the billing email affects invoices for the whole team, so changes on this screen wait for Save. A typo here shouldn’t reach anyone until it’s confirmed. ## Edge cases With a Save button, closing the page loses work. Warn about unsaved changes, or keep a local draft. Source: https://productfordesigners.com/cards/autosave-save Author: Alex Dovhyi --- # Comfortable or Compact > Comparison wants density. Decisions want room. ## Situation Are people deciding on one thing, or comparing many? ## Decision ### Use Comfortable when People look at a few items at a time, or are new to the screen and need room to understand each row. - Occasional or new users - Rich rows with images or actions - Decisions about one item - Touch input ### Use Compact when People scan and compare many rows, all day. Seeing twice as many at once beats any amount of white space. - Data tables, logs, queues - Daily power users - Spotting patterns across rows - Offer it as a setting when audiences mix **The numbers:** Comfortable rows around 48–56 px, compact around 32–40 px. Compact when people compare 20+ rows at once or use the screen daily. Mixed audiences get a density setting, defaulting to comfortable. ## Why Support agents scan hundreds of tickets a day looking for patterns, so the queue is compact. Seeing twice the rows matters more to them than white space. ## Edge cases Touch input. Compact rows break tap targets; on touch, density comes from showing less per row, not from shrinking it. Source: https://productfordesigners.com/cards/comfortable-compact Author: Alex Dovhyi --- # Radio or Dropdown > Show the options when there are few and they need comparing. Collapse them when there are many and people know their answer. ## Situation How many options, and should people compare them? ## Decision ### Use Radio when A handful of options people should see side by side before choosing: plans, shipping speeds, priorities. - Two to five options - Options need comparing - Each option needs a short description - The choice matters ### Use Dropdown when Many options, or a list where people already know their answer: country, year, time zone. Make it searchable past a dozen items. - More than six or seven options - People know their answer - Space is tight - Searchable when the list is long **The numbers:** 2–5 options: radio buttons. 6–15: dropdown. More than 15: searchable combobox. Two options that mean on and off: a checkbox or toggle, not radios. ## Why There are only three shipping speeds and the price difference matters, so they’re radio buttons people can compare. Country has nearly two hundred options and everyone knows theirs, so it’s a searchable list. ## Edge cases Even with three options, a dropdown can win inside a dense table row where there’s no room to show them all. Source: https://productfordesigners.com/cards/radio-dropdown Author: Alex Dovhyi