Mid-Level UI Designer Interview Preparation Guide - FAANG Standards

Direct answer

Teaching a skill you don't have natural talent for means separating what you know intuitively from what's actually teachable. You diagnose the real gap first, build an explicit, decomposed framework for the skill (even though you perform it by feel), and validate progress by watching the person apply it independently, not by how confident the coaching sessions felt.

Approach to teaching outside your natural strength

Diagnose before prescribing. "Struggles with X" is rarely one problem. Watch or review their actual attempt and separate the layers: is it a knowledge gap (they don't know the structure), a delivery gap (they know the structure but execution is shaky), or a confidence gap (they know it and can do it, but freeze under real stakes). Each needs a different intervention.

Decompose your own tacit skill into explicit steps. If you're good at something without having consciously learned it as a framework, you have to reverse-engineer your own process before you can teach it. Skipping this step and just saying "do what feels right" doesn't transfer anything.

Practice at graduated, increasing stakes. Start with low-stakes reps where mistakes are cheap and recoverable, then move toward the real, higher-stakes version. Jumping straight to the real thing conflates skill-building with performance evaluation in the person's head, which raises anxiety and slows learning.

Give feedback on the mechanism, not just the outcome. "That worked" or "that didn't work" is much less useful than pointing at which specific move in their approach caused the result.

Worked example

Situation: someone you're mentoring is excellent at the core technical work but has a real gap in a skill that doesn't come naturally to you either, say, communicating findings clearly to people outside the immediate team. Their material was always technically sound, but reviews ran long and the point often got lost.

Task: help them close that gap over a defined stretch, without pretending you have natural talent for it yourself.

Action: you watched a recording of one of their sessions together and separated content problems (no clear headline, too much detail up front) from delivery problems (pace, not anticipating pushback). You gave them a simple structure to practice against: state the conclusion first, then the supporting evidence, then the recommendation. You ran a couple of low-stakes rehearsals where you played a skeptical stakeholder, then let them run the real session solo.

Result: over a few sessions, their reviews needed fewer clarifying follow-up questions from the room, and the structure started showing up unprompted in written material too, not just live presentations. The real signal wasn't how the coaching sessions felt: it was watching them handle a session you weren't part of and hearing secondhand that it landed cleanly.

Trade-offs and pitfalls

A common junior-mentor mistake is trying to transfer your own tacit competence directly ("just do what I do") instead of decomposing it. That fails specifically because the skill you're teaching is one you never consciously learned as steps.

Another mistake: avoiding coaching on gaps you don't personally excel at, on the theory you're not qualified. You don't need to be naturally gifted at a skill to teach its structure. You need to be willing to build the explicit framework, which sometimes non-naturals do better than naturals, because they had to learn it deliberately themselves.

The real trade-off is time. Teaching a skill outside your own strength takes longer to prepare for, because you can't rely on instinct in the room. That prep time is where the actual coaching value gets built.

Direct answer. Start from the capacity: derive what fits, define the one job the MVP (minimum viable product: the smallest product that tests the core idea) must prove, sort features with MoSCoW, and agree the cut order before work starts. Then explain cuts in terms of the goal, not preferences.

Capacity (illustrative: 2 engineers, 6 weeks). 2 x 6 = 12 person-weeks. Keep a 20% buffer (time held back for surprises): 12 x 0.2 = 2.4, leaving 9.6 person-weeks to plan.

MoSCoW (Must, Should, Could, Won't have this time; an approach from rapid application development, a style of building software in short cycles) with estimates, for a community app where people post and follow each other:

Musts total 8.0, plus the Should 1.5 gives 9.5, within 9.6. Coulds (2.0) are not in the committed plan; they only start if we are ahead. Check the Must share against the DSDM (Dynamic Systems Development Method) guideline. MoSCoW was created by Dai Clegg in 1994 for rapid application development and is used heavily in DSDM, whose published guidance is typically no more than 60% Must Have effort, measured against the planned effort for the timeframe (Won't items excluded), with around 20% Could Have effort as contingency. Planned effort here is 8.0 + 1.5 + 2.0 = 11.5 person-weeks, so Musts are 8.0 / 11.5 = 69.6%, Shoulds 13.0% and Coulds 17.4%. That is above the 60% guideline, so this plan is at the risky end: confidence that every Must lands is lower than DSDM recommends. (Against the whole 12 person-weeks the Musts are 67%, and against the 9.6 plannable weeks 83%, but neither is the basis the guideline uses.) The 2.4-week buffer is my own addition, not part of DSDM's rule, and it does not fix the ratio; the fix is to narrow Musts before the build starts, for example a simpler profile (1.0 instead of 1.5) and a chronological feed (1.5 instead of 2.0), which brings Musts to 7.0 of 10.5 planned (66.7%), closer to the guideline though still above it, and to keep the buffer for the surprises that remain.

What to cut first if it slips. Reverse order of value. Because the Coulds are not in the committed plan, the first cut is simply not starting them (notifications, then analytics beyond one launch event) and spending that time on the buffer. If the slip continues, cut comments next, keeping likes only. Musts are never cut; if even they slip, move the date or the launch audience, not quality of safety features like report and block.

Choosing in/out. I use a PR/FAQ (a press release and customer FAQ written as if launched). Write the headline first, for example: "Neighbours can now sign up, post, follow each other, see a feed and stay safe with report and block." If a feature is not needed to write that headline, it is not a Must; direct messages do not appear in it, so they are a Won't. Another way to cut is to serve one segment first. Suppose the app has moderators (volunteers who review reports), power users (who post daily) and casual users (who mostly read). Pick the segment whose need is sharpest, for example moderators, who need report and block to keep a new community safe, and give the others a clear later path.

Explaining cuts. Show the table and the rule: "This is what the first version must prove. Each cut buys the buffer that protects the date." Give the owner of each Won't a date to revisit.

Direct answer

Use spatial and stylistic relationships, proximity, shared enclosure, and similarity, so users infer which controls belong to which content block from how things are arranged, not from what anything says. These are visual-grouping principles borrowed from Gestalt psychology, the study of how people perceive separate elements as belonging to a group.

Structured elaboration

1. Proximity: place a control physically closer to the content it acts on than to unrelated content. Increase whitespace between unrelated groups and decrease it within a group. This alone resolves most "which button goes with what" confusion, because people naturally read things that are close together as related.

2. Common region (enclosure): wrap a group in a shared visual container, a card border, a subtle background tint, or a divider line, so the boundary itself communicates "these belong together" without a label. This is the strongest grouping cue available and should be reserved for genuinely ambiguous cases rather than applied everywhere.

3. Similarity: give controls that belong to the same group the same visual treatment, same button style, same icon weight, same color, and give controls in a different group a visibly different one. Over time users learn to associate a style with a function or section.

4. Alignment: align a control to the edge or baseline of the content block it belongs to, rather than to the page's global grid. For example, a delete icon vertically centered against the specific row it deletes, rather than centered against the page, so position itself signals ownership.

Worked example

Say a screen has a "Team Members" list and an unrelated "Notifications" settings block, currently just floating with a single shared "more options" icon sitting between them that users cannot tell belongs to either. Fix: give "Team Members" its own card, with 8px internal padding, a 1px border, and a subtle background tint, and place the "more options" icon inside that card's own top-right corner, aligned to the card's edge rather than the page edge. Increase the gap between this card and the "Notifications" block from 8px to 32px, while keeping the gap between items inside the card at 8px. Now proximity (32px versus 8px) and common region (the card's own boundary) both point to the same grouping, so the relationship reads instantly.

Trade-offs and pitfalls

Over-enclosing, wrapping every single group in a heavy bordered card, creates visual noise of its own and cancels out the benefit; reserve strong enclosure for genuinely ambiguous groupings and lean on proximity and whitespace for everything else. A related pitfall is relying on a single cue, for example only a shared background tint, when combining two redundant cues (spacing and enclosure together) makes the grouping legible even to someone scanning quickly rather than reading carefully.

Direct answer

Build the Button as a polymorphic, ref-forwarding component: a typed as prop lets consumers render it as any element - most commonly a link - without a second component, forwardRef exposes the real underlying DOM node, and accessibility is handled by defaulting to a native <button> and only adding ARIA/keyboard shims when as overrides that default.

Structured elaboration

Approach

• Prop shape: variant, size, disabled, onClick, children, an as prop for polymorphism, plus pass-through for whatever native props the resolved element supports, via TypeScript's ComponentPropsWithoutRef<E>.
• Polymorphism: as swaps the rendered tag. At the type level this uses a generic <E extends ElementType> so both the prop types and the ref type change correctly per element - as="a" should require href to type-check and forward a ref typed as HTMLAnchorElement, not HTMLButtonElement.
• Ref forwarding: forwardRef passes a ref straight to the rendered host element so a parent can call .focus() or measure it, with no imperative API of the component's own needed.
• Accessibility: default as to "button" (native semantics, native keyboard support, native disabled behavior - nothing extra to add). Only when as is a non-button element does the component need to add role="button", tabIndex, Enter/Space keydown handling, and aria-disabled (non-form elements don't support the native disabled attribute).

Worked example

import React, { ElementType, forwardRef, ComponentPropsWithoutRef, Ref } from "react";

type Variant = "primary" | "secondary" | "ghost";
type Size = "sm" | "md" | "lg";

type PolymorphicProps<E extends ElementType> = {
  as?: E;
  variant?: Variant;
  size?: Size;
  disabled?: boolean;
  children?: React.ReactNode;
  "aria-label"?: string;
} & Omit<ComponentPropsWithoutRef<E>, "as" | "children" | "disabled">;

function ButtonInner<E extends ElementType = "button">(
  { as, variant = "primary", size = "md", disabled = false, children, onClick, onKeyDown, ...rest }: PolymorphicProps<E>,
  ref: Ref<Element>
) {
  const Component = (as ?? "button") as ElementType;
  const isNativeButton = Component === "button";

  const handleClick = (e: React.MouseEvent) => {
    if (disabled) { e.preventDefault(); return; }
    (onClick as React.MouseEventHandler | undefined)?.(e);
  };

  const handleKeyDown = (e: React.KeyboardEvent) => {
    if (!isNativeButton && !disabled && (e.key === "Enter" || e.key === " ")) {
      e.preventDefault();
      (onClick as React.MouseEventHandler | undefined)?.(e as unknown as React.MouseEvent);
    }
    (onKeyDown as React.KeyboardEventHandler | undefined)?.(e);
  };

  return (
    <Component
      ref={ref}
      className={`btn btn--${variant} btn--${size}`}
      onClick={handleClick}
      onKeyDown={handleKeyDown}
      {...(isNativeButton ? { disabled } : { role: "button", tabIndex: disabled ? -1 : 0, "aria-disabled": disabled || undefined })}
      {...rest}
    >
      {children}
    </Component>
  );
}

export const Button = forwardRef(ButtonInner) as <E extends ElementType = "button">(
  props: PolymorphicProps<E> & { ref?: Ref<Element> }
) => React.ReactElement | null;

Key points

• PolymorphicProps<E> derives the correct native prop set per element from ComponentPropsWithoutRef<E>, so as="a" correctly types href and as="button" correctly types type.
• Native disabled is applied only to the real <button>; non-button elements get aria-disabled plus a click-time guard instead, since HTML has no disabled attribute for <a>.
• Keyboard support (Enter/Space triggers click) is added only when the rendered element isn't already keyboard-activatable natively.

Complexity
This is a UI component, not an algorithm, so the relevant complexity is structural rather than asymptotic - rendering, prop-forwarding, and event handling are all O(1) relative to the component's own props, with no loop or recursion over data. The real cost worth naming is at the type level: the generic PolymorphicProps<E> and the forwardRef cast add genuine TypeScript compile-time complexity and a learning curve for contributors unfamiliar with the polymorphic pattern - a maintenance cost, not a runtime one.

Edge cases

• as="a" with no href: renders a link with no navigation target and no visible affordance change - worth a dev-time warning rather than shipping silently.
• Icon-only usage with no visible children text: requires aria-label from the consumer; the component should warn in development if neither text children nor aria-label is present.
• disabled combined with as set to a non-interactive element (e.g. as="div"): must still block both click and keyboard activation, which is why the guard lives in the shared handlers rather than relying on the native disabled attribute alone.
• Ref type mismatch: a consumer typing useRef<HTMLButtonElement>(null) while also passing as="a" gets a type conflict at the call site by design - that's the polymorphic typing working as intended, not a bug to suppress.

Trade-offs & pitfalls

• The polymorphic as pattern is powerful, but the TypeScript required to type it correctly (generic ref forwarding, conditional prop types) is genuinely more complex than a fixed-element component. For a small design system with few link-as-button use cases, two simple components (Button, LinkButton) sharing internal styling logic can be more maintainable than one fully polymorphic component.
• The common wrong turn is forwarding disabled straight into {...rest} for every element type. On a non-button element this silently does nothing (no native support), giving a false sense that the element is disabled when it's still clickable and focusable.
• A second common wrong turn is skipping the keyboard handler because it "looks fine visually." A role="button" div without Enter/Space handling passes a casual visual check but fails immediately for keyboard-only and screen-reader users.

Direct answer

Four KPIs (key performance indicators, metrics a team formally tracks to judge progress) that together cover getting to first value and forming a habit: activation rate, day-7 core-action retention, messages per daily active user (a depth signal), and first-session contact-addition rate. Each is paired with its own confound (a separate factor, unrelated to genuine user behavior, that can inflate or distort the number so the KPI moves for a reason that has nothing to do with what it's supposed to measure), because a KPI that moves without you understanding why is not evidence of anything.

Structured elaboration

Use the first two as leading, onboarding-stage signals and the last two as depth and habit signals; move them together, not in isolation, since a rising activation rate paired with a flat retention rate usually means the funnel got easier to enter, not that the product got better.

Worked example

A weekly cohort of 10,000 signups: 6,200 (62%) sent a message within 24 hours. Of those, 900 were solely an auto-generated welcome-chat reply with no user action, so genuine activation excluding auto-sends is 5,300 (53.0%). Day-7 retention among the 5,300 genuinely activated users: 2,438 (46.0%).

Messages per DAU for the same cohort's active week is 3.1. The heavy tail is what makes that number fragile: the top 1% of senders average about 72 messages a day, so they alone contribute 0.01 x 72.4 = 0.724 messages per DAU, roughly 23% of the whole 3.1 average, from 1% of the accounts. Exclude them as likely bots and the mean for everyone else is (3.1 - 0.724) / 0.99 = 2.4, a materially different number for judging typical engagement depth. Report the median alongside the mean for exactly this reason: a median is unmoved by the tail, so a mean and median that diverge is itself the alarm that a handful of accounts is driving the KPI.

Trade-offs & pitfalls

• Reporting the raw KPI without also reporting the confound-adjusted version hides exactly the cases where the metric is lying to you, as the auto-welcome-message example shows.
• Four KPIs is already a lot to hold in a weekly review; resist adding more without removing one, or the team stops looking at any of them closely.
• A KPI moving in the right direction is not the same as the underlying user behavior improving; always check whether a confound explains the movement before acting on it.
• Any KPI defined as an average over a heavy-tailed count is a trimmed or median statistic waiting to happen; decide the exclusion rule (top 1%, or an explicit bot classifier) before you first report the number, not after a spike makes you want one.

Direct answer

Pick a project you chose deliberately because it filled a specific, named gap in your experience or visibility, not just one that landed on your desk, and be concrete about the one thing that measurably changed in your trajectory afterward, a capability, a relationship, or a type of work you're now trusted with.

Structured elaboration

• Name the specific gap the project targeted. A skill, a type of stakeholder exposure, a kind of ownership, not "it seemed interesting."
• Distinguish accelerant projects from ordinary assigned work. You sought it out or volunteered specifically because of the gap; that intentionality is the actual signal being tested.
• Point to something durable in the "what changed" half. A new kind of work you're now trusted with, a relationship that opened later opportunities, or a capability you now use routinely, versus just "it went well."
• Keep it forward-looking. The project itself is evidence; the answer is really about what it changed about how you're used or seen now.

Worked example

Partway into a role, I noticed a gap in my own experience: I'd never owned something end to end in front of a skeptical stakeholder audience, only ever as part of a larger team. When a short, high-visibility project came up that nobody else wanted because of the tight timeline, I volunteered specifically because it forced that gap. I ran it end to end, made the calls, and presented the outcome directly to the stakeholders who'd been skeptical going in. What actually changed afterward wasn't the project's result, it was that I started getting pulled into that kind of stakeholder-facing, ambiguous work as a matter of course, work I'd never have been offered before proving I could carry it alone.

Trade-offs & pitfalls

• Choosing a project purely because it's visible, without it targeting a real gap, produces a story about luck rather than intentional growth.
• Framing the outcome as "and it went well" rather than naming what changed afterward misses the actual question, the interviewer wants the trajectory change, not the project recap.
• Volunteering for something without being honest about the real risk, a tight timeline, being out of your depth, undersells the growth; own the discomfort as part of the story.

Direct answer

Pick a small set of weighted criteria before scoring anything, typically impact, effort, UX risk, and engineering complexity, score each validated concept against them with a shared rubric, and treat a close score as a signal to break the tie with the cheapest available validation step rather than more debate, since the research budget is exactly the constraint that framework needs to respect.

Structured elaboration

Why these criteria

• Impact: does the concept move the outcome the feature exists to affect.
• Effort: combined design and build cost, which is what actually translates the budget constraint into the scoring.
• UX risk: how much learnability or error risk the concept introduces, especially for a less-tested interaction pattern.
• Engineering complexity: distinct from effort; a concept can be low design effort but high build complexity, or the reverse, so score them separately.

Weighting
Weight the criteria to reflect the constraint actually driving this decision. With a limited research budget, impact and UX risk deserve more weight than usual, since a full study would normally be what de-risks those two, and this decision has to substitute a lighter process for that.

Scoring mechanics
Define a 1 to 5 rubric per criterion before anyone scores (5 is most favorable on that criterion, including for effort and complexity, so a low-effort, low-complexity concept scores a 5 there). Score independently first, then discuss any large deltas between scorers rather than averaging blindly, since a big disagreement usually means people are scoring against different assumptions.

Handling a near-tie
Decide the tie threshold before scoring, for example anything within a small band counts as effectively tied given the imprecision of the exercise. When two concepts land inside that band, do not keep debating the matrix; spend the limited research budget on the cheapest signal that resolves the single riskiest assumption each concept depends on, such as a short unmoderated test or a fast internal expert review, rather than a full study on either.

Worked example

Weights, decided before scoring: Impact 0.35, UX risk 0.25, Engineering complexity 0.25, Effort 0.15 (sums to 1.00). Two concepts, scored 1 to 5, 5 most favorable:

A 0.05 gap on a 5-point scale falls inside a reasonable tie threshold (say, anything within 0.1 points), so this is a tie, not a winner. Concept A's strength is UX risk, Concept B's strength is impact. Given the budget, the tie-break is a short unmoderated test aimed specifically at Concept B's biggest open question (whether its higher-impact interaction is actually learnable without guidance), since that is the one assumption a full study would normally have resolved and the matrix cannot settle on its own.

This holds at larger scope, too. For a broader multi-segment enterprise feature with the same lean budget, the same weighted approach applies; add a segment-coverage or per-segment risk check as an additional criterion rather than rebuilding the framework, and keep the same divergence-convergence (generating many options broadly, then narrowing them down) -stakeholder-review cadence so the extra segments do not silently expand the research ask past what the budget allows. The same logic also applies one level up, to deciding between a full redesign and an incremental improvement: redesign options typically score higher on impact ceiling, incremental options typically score higher on effort and risk, and which one wins depends on which criterion the current constraint (cost, timeline, or how much risk the team can absorb) weights most heavily.

Trade-offs and pitfalls

• Setting weights after seeing scores, even unconsciously, turns the matrix into a way to justify a pre-existing favorite rather than a decision tool; commit to weights first.
• A score to two decimal places is not more true than an honest "this is close"; the matrix's job is to force an explicit conversation about trade-offs, not to produce a number precise enough to hide behind.
• Skipping the tie-break step and defaulting to seniority or whoever argues loudest defeats the entire point of building the matrix.
• Document the rejected concept and the specific condition that would justify revisiting it (new data, a changed constraint), so the decision does not have to be re-litigated from scratch later.

Direct answer

Do not treat the metric win and the UX risk as opposing bets. Before building anything, agree with design and product on the primary success metric and on explicit guardrail metrics chosen specifically to catch the kind of harm the primary metric would not see, then validate cheaply with a prototype or a small qualitative test before committing to a live experiment sized to detect both.

Structured elaboration

Agree on what "good" means before anyone builds

The primary metric, say a conversion or engagement number, tells you if the change works on its own terms. Guardrail metrics are chosen specifically because they would catch harm the primary metric is blind to, such as task completion, return usage a week later, or support-ticket volume. Naming guardrails upfront, with agreed thresholds, prevents "we'll know it if we see it" arguments after the fact.

Validate cheaply before going live

A clickable prototype or a small moderated usability session can surface confusion or trust issues that the metric alone cannot catch, at a fraction of the cost of a live experiment. This is not a substitute for the experiment, it is a cheap filter that catches the worst ideas before they reach real users.

Run a bounded experiment, not a full rollout

Start with a small slice of traffic, watch both the primary metric and the guardrails, and decide the stopping rule, meaning what result on which metric ends the test, before the test starts, not after you see the numbers.

Decide and communicate together

If the primary metric improves but a guardrail moves the wrong way, that is a real finding, not a technicality to explain away. Whether to ship, iterate, or drop the idea is a joint call between design, product, and whoever owns the guardrail metric, made against the thresholds agreed upfront.

Worked example

Design proposes reordering a list of recommended items to increase click-through rate. The concern is that users may have learned to expect a stable, predictable order, and reordering it could hurt their ability to quickly find what they are looking for on repeat visits, something click-through rate would not show because a user can click more and still be more frustrated.

Before building, the group agrees the primary metric is click-through rate, and the guardrails are task completion rate (did the user's search end in the outcome they were after) and a return-usage check at one week out. A moderated usability test with a handful of participants on a clickable prototype surfaces that new users find the reordered list fine, but a couple of returning participants mention it "looks different" and take longer to find what they normally click first. That is a signal, not a stop sign: the team ships the change to a small slice of traffic, watches both metrics for an agreed window, and only expands the rollout if task completion holds steady alongside the click-through gain.

Trade-offs and pitfalls

Over-instrumenting every change with a full guardrail suite slows teams down and trains people to skip the process for anything that feels small. Guardrails should be chosen deliberately for the specific risk in question, not applied as a blanket checklist.

The sharpest failure mode is agreeing on guardrails in principle but not on thresholds, so when a guardrail moves slightly, the debate about whether it is a real regression happens after the data is already in and someone has already committed emotionally to shipping. Fixing the threshold before the test removes that fight.

Direct answer

Problem statement: "Users abandon the checkout flow at a rate we believe is avoidable, driven by unclear pricing or an overly long form; we want to identify the dominant cause and reduce abandonment within one quarter." Then three research questions, ranked by how much uncertainty each removes, and two experiments that test the two most likely causes cheaply before committing to a redesign.

Structured elaboration

Turning "make checkout less confusing" into something actionable means resisting the urge to start sketching a new flow and instead doing three things in order:

1. State the problem without naming the fix. "Confusing" is a symptom description from whoever gave you the brief, not a diagnosis. The statement should capture the business impact (checkout abandonment, cart-to-purchase drop-off) without assuming the cause is visual clutter, form length, or anything else specific.
2. Rank the highest-uncertainty questions. Three that reduce the most uncertainty for the least effort: (a) where in the funnel do users actually drop, step by step, not just "checkout" as a whole; (b) do session recordings or support tickets show a specific point of friction (an unexpected shipping cost, a validation error, a confusing field); (c) has anything changed recently (a redesign, a new payment provider, a pricing change) that correlates with the drop, which would point to a regression rather than a long-standing usability gap.
3. Design experiments that isolate one variable each. Confirming the top hypothesis before building the full redesign avoids spending a sprint on the wrong fix.

Worked example

If step-by-step funnel data (question 1) shows the drop concentrates at the shipping-cost step, and session recordings (question 2) show users repeatedly navigating back to the cart after seeing that price, the two experiments become: (1) show an estimated shipping cost earlier in the flow, on the cart page, and measure the change in step-to-step conversion at the shipping step specifically; (2) offer a lower-friction guest checkout for users who abandon at account creation, and measure whether abandonment at that specific step drops. Both experiments have one clearly measurable outcome each (conversion rate at a named step) rather than "conversion is better," which would leave you unable to tell which change caused any improvement.

The same three-part output, statement, research questions, experiments, holds regardless of who the ambiguous brief comes from: an engineering-reported inconsistency (three teams shipping visibly different versions of the same navigation component), a chief executive officer (CEO)-level ambiguous goal ("increase monetization from casual users," with no design specifics attached), and a product manager's (PM's) "improve discoverability" ask with no defined success metric all reduce to the identical framing move, only the domain changes.

Trade-offs and pitfalls

The trap in this kind of prompt is treating "less confusing" as license to redesign everything at once: a full redesign conflates multiple hypotheses, so even if overall conversion improves you cannot attribute the gain to any one change, and if it does not improve you have no idea which piece to revert. The second trap is skipping the funnel-breakdown question entirely and going straight to user interviews, which surface real but not necessarily representative friction points; pairing quantitative funnel data with qualitative signal is what keeps the research questions honest about what's actually costing conversion versus what's merely annoying.

Direct answer

Aim for 44 by 44 CSS pixels for anything a thumb must hit, and treat 24 by 24 CSS pixels as the floor. Both numbers come from WCAG 2.2 (the Web Content Accessibility Guidelines). WCAG sorts its criteria into three conformance levels: A (lowest), AA (the level most legal and procurement requirements ask for) and AAA (highest, the strictest). Success Criterion 2.5.8 (Level AA) says "The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:" a list of exceptions, and 2.5.5 (Level AAA) says "The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:" its own exceptions. A CSS pixel is a layout unit, not a device pixel, so these sizes survive high-density screens and browser zoom.

To keep a dense desktop toolbar usable without redesigning it, leave the markup and the fine-pointer styles alone and add one @media (pointer: coarse) block that enlarges the buttons, plus flex-wrap: wrap on the toolbar (the flexbox setting that lets items drop onto a new row when they no longer fit) so the bigger buttons break onto a second row. Without it a flex row does not overflow: its items shrink to fit the bar, so the buttons end up smaller than 44px. A "fine" pointer is an accurate one such as a mouse; a "coarse" pointer is a finger on a touchscreen; the browser reports which one the primary input device is through the pointer media feature, a CSS condition about the user's device rather than the window size.

Why the size matters

A fingertip is a much blunter pointer than a mouse cursor, so on a small button it is easy to miss or to hit the neighbour. WCAG states the intent of 2.5.8 as "to help ensure targets can be easily activated", with the full sentence continuing to say without accidentally activating an adjacent target. Two things follow:

• Size and spacing trade off. The 2.5.8 text allows undersized targets when they are spaced so that a 24 CSS pixel circle centred on each does not intersect another target. A dense toolbar can therefore pass AA with small buttons only if they are spread out, and enlarging the buttons is the other way to the same goal. Worked example from WCAG's own explanation of the criterion: the circle has a 12px radius, so the centres of two undersized buttons must be at least 24px apart. Two 20px buttons with a 4px gap have centres 20 + 4 = 24px apart, so the circles only touch and the layout passes; with no gap the centres are 20px apart, the circles overlap and it fails. The 28px buttons in the solution below are already above 24px, so they pass without needing that exception.
• The 44px figure is the Level AAA criterion, stricter than the AA one. Treat AA as the minimum to pass and 44px as the working size for primary controls and anything dense.

Which media query: pointer or any-pointer

MDN defines the feature: "The pointer CSS media feature tests whether the user has a pointing device (such as a mouse), and if so, how accurate the primary pointing device is", where coarse means "a pointing device of limited accuracy, such as a finger on a touchscreen". MDN adds: "If you want to test the accuracy of any pointing device, use any-pointer instead." The primary pointing device is the one the system treats as the main input (on a phone, the touchscreen; on a laptop, usually the trackpad).

Decision: key the size change on (pointer: coarse). It changes density, which is a visible cost on a desktop screen, so it should fire when the primary input is a finger. What flips it: if the product has many touch laptops where users switch between mouse and finger, use (any-pointer: coarse) and accept the larger toolbar for mouse users too. A width query such as max-width: 600px is a poor proxy, because a small laptop window is not a touch device and a tablet is wider than 600px.

The solution

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Toolbar</title>
<link rel="stylesheet" href="toolbar.css">
</head>
<body style="margin:0">
<div class="toolbar">
  <button type="button" aria-label="Bold">B</button>
  <button type="button" aria-label="Italic">I</button>
  <button type="button" aria-label="Underline">U</button>
  <button type="button" aria-label="Link">L</button>
  <button type="button" aria-label="Quote">Q</button>
  <button type="button" aria-label="Code">C</button>
  <button type="button" aria-label="List">#</button>
  <button type="button" aria-label="Clear">X</button>
</div>
<script>
  window.clicks = [];
  document.querySelectorAll('.toolbar button').forEach(b => b.addEventListener('click', () => window.clicks.push(b.getAttribute('aria-label'))));
</script>
</body>
</html>

.toolbar {
  display: flex;
  flex-wrap: wrap;            /* lets the row break instead of shrinking the buttons when they grow */
  gap: 4px;
  width: 300px;
  margin: 16px;
  padding: 0;
}
.toolbar button {
  box-sizing: border-box;
  width: 28px;
  height: 28px;
  padding: 0;
  border: 1px solid #667;
  border-radius: 4px;
  background: #eef0f6;
}

/* Primary input is a finger: same markup, bigger boxes. */
@media (pointer: coarse) {
  .toolbar button {
    width: 44px;
    height: 44px;
  }
}

• The desktop rules are untouched: 28px buttons with a 4px gap.
• The coarse block raises width and height to 44px. Because the buttons are real boxes of that size, the whole 44px square is the target and no extra hit-area trick is needed.
• The toolbar is 300px wide. At 44px with 4px gaps, 6 x 44 + 5 x 4 = 284px fits and 7 x 44 + 6 x 4 = 332px does not, so the eight buttons break into rows of 6 and 2. On a fine pointer, 8 x 28 + 7 x 4 = 252px fits in one row.
• Where wrapping would make the toolbar too tall (a 14-button toolbar at 44px wraps to three rows of 6, 6 and 2, as the last line of the output shows), the alternatives are horizontal scrolling or moving the least-used actions into an overflow menu. Those change the markup and behaviour, which is the point at which "no redesign" stops being possible.

Verifying it

The test runs in Chromium, Firefox and WebKit, the three browser engines (the rendering cores that lay out the page), driven by Playwright 1.48.2, a library that scripts real browsers; its WebKit build is Playwright's, not Safari, and it runs headless, meaning without a visible window, so it can measure layout and simulate a tap but cannot tell how a real thumb feels on a real phone. A fine pointer is the default context. A touch context is created with hasTouch: true, in which matchMedia('(pointer: coarse)') is true in all three engines. It asserts the sizes, the row counts, that nothing pokes out of the toolbar, and that a real touch tap 40px right and 20px down from the first button's corner (inside a 44px box, outside a 28px one) activates it. Deleting the coarse rule or the flex-wrap declaration makes the assertions fail; both mutants fail the 44px size assertion, the second because a non-wrapping flex row shrinks its items to fit instead of letting them overflow.

// check.mjs
import { chromium, firefox, webkit } from 'playwright';
import { readFileSync } from 'node:fs';

const css = readFileSync('toolbar.css', 'utf8');
const html = readFileSync('index.html', 'utf8');
const variants = {
  shipped: css,
  noCoarseRule: css.replace(/@media \(pointer: coarse\) \{[\s\S]*\n\}\n/, ''),
  noWrap: css.replace('flex-wrap: wrap;', 'flex-wrap: nowrap;'),
};
const ok = (c, m) => { if (!c) throw new Error('ASSERT FAILED: ' + m); };

async function open(browser, variant, touch) {
  const ctx = await browser.newContext({ viewport: { width: 400, height: 400 }, hasTouch: touch });
  const p = await ctx.newPage();
  await p.route('**/toolbar.css', r => r.fulfill({ contentType: 'text/css', body: variants[variant] }));
  await p.route('**/index.html', r => r.fulfill({ contentType: 'text/html', body: html }));
  await p.goto('http://x.test/index.html');
  return p;
}
const layout = p => p.evaluate(() => {
  const bar = document.querySelector('.toolbar');
  const r = [...bar.querySelectorAll('button')].map(b => b.getBoundingClientRect());
  const rows = {};
  r.forEach(b => { rows[Math.round(b.top)] = (rows[Math.round(b.top)] || 0) + 1; });
  return {
    coarse: matchMedia('(pointer: coarse)').matches,
    size: [r[0].width, r[0].height],
    perRow: Object.values(rows),
    overflowsBar: r.some(b => b.right > bar.getBoundingClientRect().right + 0.5),
    minSide: Math.min(...r.map(b => Math.min(b.width, b.height))),
  };
});

async function fineTest(b) {
  const p = await open(b, 'shipped', false);
  const m = await layout(p);
  ok(!m.coarse && m.size.join() === '28,28' && m.perRow.join() === '8', 'fine pointer keeps the dense 28px single row');
  return m;
}
async function coarseTest(b, variant) {
  const p = await open(b, variant, true);
  const m = await layout(p);
  ok(m.coarse, 'touch context reports pointer: coarse');
  ok(m.minSide >= 44, 'every button is at least 44 by 44');
  ok(!m.overflowsBar, 'no button pokes out of the toolbar');
  ok(m.perRow.join() === '6,2', 'wraps to rows of 6 and 2');
  // a tap 40px right and 20px down from a button's top-left lands inside its 44px box but outside a 28px one
  const first = await p.evaluate(() => { const r = document.querySelector('.toolbar button').getBoundingClientRect(); return { x: r.x, y: r.y }; });
  await p.touchscreen.tap(first.x + 40, first.y + 20);
  ok((await p.evaluate(() => window.clicks)).join() === 'Bold', 'tap near the edge of the 44px button activates it');
  return m;
}

for (const [name, type] of [['chromium', chromium], ['firefox', firefox], ['webkit', webkit]]) {
  const b = await type.launch();
  const f = await fineTest(b);
  const c = await coarseTest(b, 'shipped');
  console.log(name, 'fine:', JSON.stringify({ size: f.size, perRow: f.perRow }), 'coarse:', JSON.stringify({ size: c.size, perRow: c.perRow }));
  const res = {};
  for (const v of ['noCoarseRule', 'noWrap']) { try { await coarseTest(b, v); res[v] = 'STILL PASSES'; } catch (e) { res[v] = 'fails: ' + e.message; } }
  console.log(' without the rule:', JSON.stringify(res));
  // 14 buttons: clone the first button until there are 14, then count buttons per row at 44px
  const p14 = await open(b, 'shipped', true);
  await p14.evaluate(() => { const bar = document.querySelector('.toolbar'); while (bar.children.length < 14) bar.append(bar.firstElementChild.cloneNode(true)); });
  const m14 = await layout(p14);
  ok(m14.perRow.join() === '6,6,2', '14 buttons wrap to rows of 6, 6 and 2');
  console.log(' 14 buttons, coarse pointer, buttons per row:', JSON.stringify(m14.perRow));
  await b.close();
}

Run in the Playwright 1.48.2 container, it prints the same values for all three engines (repeated runs print the same thing):

chromium fine: {"size":[28,28],"perRow":[8]} coarse: {"size":[44,44],"perRow":[6,2]}
 without the rule: {"noCoarseRule":"fails: ASSERT FAILED: every button is at least 44 by 44","noWrap":"fails: ASSERT FAILED: every button is at least 44 by 44"}
 14 buttons, coarse pointer, buttons per row: [6,6,2]
firefox fine: {"size":[28,28],"perRow":[8]} coarse: {"size":[44,44],"perRow":[6,2]}
 without the rule: {"noCoarseRule":"fails: ASSERT FAILED: every button is at least 44 by 44","noWrap":"fails: ASSERT FAILED: every button is at least 44 by 44"}
 14 buttons, coarse pointer, buttons per row: [6,6,2]
webkit fine: {"size":[28,28],"perRow":[8]} coarse: {"size":[44,44],"perRow":[6,2]}
 without the rule: {"noCoarseRule":"fails: ASSERT FAILED: every button is at least 44 by 44","noWrap":"fails: ASSERT FAILED: every button is at least 44 by 44"}
 14 buttons, coarse pointer, buttons per row: [6,6,2]

How to read it: size is the first button's width and height in CSS pixels; perRow lists how many buttons sit on each row, found by grouping the buttons by the rounded top coordinate of their boxes (getBoundingClientRect() returns a box's position and size), so [6,2] means a row of six and a row of two. In layout(), overflowsBar is true if any button's right edge passes the toolbar's right edge and minSide is the smallest side of any button. fineTest opens a normal (mouse-like) page and expects the dense single row; coarseTest opens a touch page and expects the 44px, two-row result plus the tap. without the rule reruns the touch checks against a stylesheet with the coarse block deleted or with flex-wrap switched off, and fails: followed by the assertion message means the checks caught the missing rule (both mutants trip the 44px size assertion first). The last line adds six more buttons (14 in all) and counts rows again.

Complexity and edge cases

The layout is a single flex pass over eight items. Edge cases to handle:

• Hybrid devices (laptops or tablets that have both a touchscreen and a mouse or trackpad): pointer reports only the primary input (see the MDN definition above), so a touch laptop whose primary input is the trackpad keeps the dense toolbar; any-pointer is true if any attached input matches, so switch to it if that matters.
• Labels: the buttons carry aria-label so the accessible name does not depend on the glyph; resizing them does not change it.
• Page height: wrapping makes the toolbar taller on touch, which pushes content below it down; account for that in the surrounding layout.
• Zoom and user font size: the sizes are in CSS pixels, so they track browser zoom. If the buttons are sized in rem instead, they also track the user's default font size.

Running the code

mkdir demo && cd demo
echo '{"type":"module"}' > package.json
npm i playwright@1.48.2 && npx playwright install chromium firefox webkit
# save the three listings above as index.html, toolbar.css and check.mjs, then:
node check.mjs