{"checkpoints":{"s-ds-1":[{"q":"<p>A startup’s design lead proposes a three-month ‘design system sprint’ with a launch party at the end and no owners afterwards. Based on Northwind’s history, what is the strongest objection?</p>","options":[{"text":"After launch nobody owns bugs, requests or releases, so teams start patching their own copies.","why":"Correct. The 2021 Northwind system failed this way: it was finished, and finished systems drift."},{"text":"Three months is too short to build any components.","why":"Plenty of useful components can be built in three months; the problem is what happens after."},{"text":"Launch parties make adoption mandatory, which teams resent.","why":"Announcements don’t force adoption; the real gap is ownership after launch."},{"text":"Design systems should be built by product teams, not design leads.","why":"Who starts it matters less than whether someone keeps it current."}],"answer":0},{"q":"<p>Your interface inventory found 9 table styles on 31 screens, 4 tooltip styles on 6 screens, and 52 greys used everywhere. In what order should the system own them?</p>","options":[{"text":"Tooltips first, because they’re the quickest win.","why":"Quick wins on six screens don’t address the most widespread drift."},{"text":"Tables first, because they’re the hardest component.","why":"Difficulty doesn’t set priority; frequency times inconsistency does."},{"text":"All three at once to show the system’s full scope.","why":"Spreading a small team across everything delays the most valuable consolidation."},{"text":"Greys first, then tables, then tooltips.","why":"Correct. Greys are everywhere and wildly inconsistent, tables are common and varied, tooltips are rare."}],"answer":3},{"q":"<p>Which proposed principle would best settle a debate about adding a fourth button variant for the marketing site?</p>","options":[{"text":"Our UI is clean and modern.","why":"Nobody argues for messy and dated UI, so it can’t decide anything."},{"text":"We value collaboration between design and engineering.","why":"A good value, but it gives no guidance on whether to add the variant."},{"text":"Fewer, better components: extend an existing one before adding a near-duplicate.","why":"Correct. It takes a side in a real trade-off and points directly to a decision."},{"text":"Every product team should feel ownership of the system.","why":"Ownership is about process, not about whether this variant belongs."}],"answer":2},{"q":"<p>A company has eight product teams. Its design system is maintained by two designers on the dispatch team in their spare time, and the other seven teams copy what dispatch builds. Which team model is this, and what’s its typical failure?</p>","options":[{"text":"Centralized; the system team becomes a bottleneck.","why":"There’s no dedicated system team here; it lives inside one product team."},{"text":"Solitary; the system reflects one team’s needs and others drift as they adapt copies.","why":"Correct. A solitary model works for one team and frays as soon as several teams depend on it."},{"text":"Federated; contributions stall because nobody reviews them.","why":"Federated means many teams contribute; here only one team builds."},{"text":"Hybrid; the core and contributors disagree about direction.","why":"A hybrid model needs a dedicated core, which this company doesn’t have."}],"answer":1},{"q":"<p>Your audit script reports <code dir=\"ltr\">#1F2933</code>, <code dir=\"ltr\">#1f2933</code> and <code dir=\"ltr\">#222b35</code> as three greys. What should the audit report say?</p>","options":[{"text":"Three distinct greys, exactly as typed.","why":"The first two are the same value in different case; reporting them separately inflates the numbers."},{"text":"One grey, because they all look the same.","why":"<code dir=\"ltr\">#222b35</code> is a different value; it should be shown as a near-duplicate, not silently merged."},{"text":"Nothing yet; greys don’t matter until components exist.","why":"Color drift is often the most widespread finding, and it shapes the token work that comes first."},{"text":"Two values after normalizing case, flagged as one near-duplicate cluster for designers to consolidate.","why":"Correct. Normalize notation automatically; let designers decide which near-duplicates become one token."}],"answer":3}],"s-ds-2":[{"q":"<p>A product team writes <code dir=\"ltr\">.order-card { border-color: var(--nw-gray-200); }</code> in its own CSS. Dark mode ships next week. What will happen to that border?</p>","options":[{"text":"It adapts automatically, because all tokens change in dark mode.","why":"Dark mode remaps semantic tokens; primitives keep their values."},{"text":"It turns transparent, because primitives are removed in dark mode.","why":"Primitives stay defined; they just aren’t remapped."},{"text":"The browser picks a dark equivalent through <code dir=\"ltr\">color-scheme</code>.","why":"<code dir=\"ltr\">color-scheme</code> affects browser-drawn UI, not your custom properties."},{"text":"It keeps the light grey, because it references a primitive that dark mode doesn’t remap.","why":"Correct. Using <code dir=\"ltr\">--nw-color-border</code> instead would let the theme change it."}],"answer":3},{"q":"<p>Which of these is a correctly formed DTCG 2025.10 dimension token?</p>","options":[{"text":"<code dir=\"ltr\">&quot;inset-md&quot;: { &quot;$type&quot;: &quot;dimension&quot;, &quot;$value&quot;: { &quot;value&quot;: 1, &quot;unit&quot;: &quot;rem&quot; } }</code>","why":"Correct. A dimension value is an object with a numeric <code dir=\"ltr\">value</code> and a <code dir=\"ltr\">unit</code> of <code dir=\"ltr\">px</code> or <code dir=\"ltr\">rem</code>."},{"text":"<code dir=\"ltr\">&quot;inset-md&quot;: { &quot;$type&quot;: &quot;dimension&quot;, &quot;$value&quot;: &quot;16px&quot; }</code>","why":"Earlier drafts used strings, but 2025.10 requires the object form with <code dir=\"ltr\">value</code> and <code dir=\"ltr\">unit</code>."},{"text":"<code dir=\"ltr\">&quot;inset.md&quot;: { &quot;$type&quot;: &quot;dimension&quot;, &quot;$value&quot;: { &quot;value&quot;: 16, &quot;unit&quot;: &quot;px&quot; } }</code>","why":"The value is fine, but periods aren’t allowed in names because they separate reference paths."},{"text":"<code dir=\"ltr\">&quot;inset-md&quot;: { &quot;$type&quot;: &quot;dimension&quot;, &quot;$value&quot;: { &quot;value&quot;: 1, &quot;unit&quot;: &quot;em&quot; } }</code>","why":"Only <code dir=\"ltr\">px</code> and <code dir=\"ltr\">rem</code> are valid units for dimension tokens."}],"answer":0},{"q":"<p>Northwind’s generated CSS contains <code dir=\"ltr\">--nw-color-action-bg: var(--nw-color-blue-600);</code> on <code dir=\"ltr\">:root</code>. A campaign page’s own stylesheet sets a brighter <code dir=\"ltr\">--nw-color-blue-600</code> on <code dir=\"ltr\">:root</code>, and every action button on that page follows. What made this possible?</p>","options":[{"text":"It works because primitives are always resolved last; no setting is involved.","why":"Resolution order has nothing to do with it; the output had to keep references."},{"text":"References were kept in the generated CSS, so the semantic token still points at the primitive at runtime.","why":"Correct. With <code dir=\"ltr\">outputReferences</code>, the link from semantic to primitive survives into the browser, so overriding the primitive on the same element flows through."},{"text":"The pipeline generates one file per page.","why":"Northwind generates per theme, not per page; the override happens in the browser."},{"text":"Style Dictionary watches the page and rebuilds when values change.","why":"Build tools run at build time; the override works entirely in the browser’s cascade."}],"answer":1},{"q":"<p>A designer names a new token <code dir=\"ltr\">--nw-color-tidewater-teal-button</code>. What is the main problem?</p>","options":[{"text":"It’s too long for CSS.","why":"Custom property names have no practical length limit; long names are fine if they’re meaningful."},{"text":"It’s missing the state part of the grammar.","why":"Not every token needs a state; the issue is what the name describes."},{"text":"It bakes a brand, a color and a component into a semantic name, so it breaks when any of them changes.","why":"Correct. A role-based name like <code dir=\"ltr\">--nw-color-action-bg</code> lets each brand map its own color."},{"text":"Token names can’t contain brand names in the DTCG format.","why":"The format allows any name without <code dir=\"ltr\">$</code>, <code dir=\"ltr\">{</code>, <code dir=\"ltr\">}</code> or <code dir=\"ltr\">.</code>; this is a design problem, not a syntax one."}],"answer":2},{"q":"<p>The dark theme block is <code dir=\"ltr\">[data-theme=&quot;dark&quot;] { … }</code> and density is <code dir=\"ltr\">[data-density=&quot;compact&quot;] { … }</code>. A page sets both on <code dir=\"ltr\">&lt;html&gt;</code>. What do you need to add for the combination to work?</p>","options":[{"text":"Nothing, because each axis remaps different tokens and the cascade combines them.","why":"Correct. Independent axes that own separate tokens compose without combined selectors."},{"text":"A combined <code dir=\"ltr\">[data-theme=&quot;dark&quot;][data-density=&quot;compact&quot;]</code> block.","why":"Only needed where two axes truly interact on the same tokens; theme and density don’t."},{"text":"A JavaScript function that merges the two token sets.","why":"The CSS cascade already merges declarations; no script is needed."},{"text":"A third attribute, such as <code dir=\"ltr\">data-mode=&quot;dark-compact&quot;</code>.","why":"Combining modes into one attribute brings back the multiplication you were avoiding."}],"answer":0}],"s-ds-3":[{"q":"<p>A Select component API has <code dir=\"ltr\">isSmall</code>, <code dir=\"ltr\">isLarge</code> and <code dir=\"ltr\">isCompact</code> booleans. What’s the best redesign?</p>","options":[{"text":"One <code dir=\"ltr\">size</code> enum (<code dir=\"ltr\">sm</code>, <code dir=\"ltr\">md</code>, <code dir=\"ltr\">lg</code>) matching the other components, with compactness left to the density mode.","why":"Correct. Mutually exclusive sizes become one enum, and density belongs to the theme axis, not each component."},{"text":"Keep the booleans but document which combinations are invalid.","why":"Docs don’t stop invalid combinations; the type should."},{"text":"Replace them with a <code dir=\"ltr\">className</code> prop so teams size it themselves.","why":"That gives up the system’s control of sizing and creates drift."},{"text":"Add <code dir=\"ltr\">isMedium</code> so every size has a boolean.","why":"More booleans means more impossible combinations."}],"answer":0},{"q":"<p><code dir=\"ltr\">&lt;Tabs&gt;</code> passes the selected value to its triggers by cloning <code dir=\"ltr\">children</code>. A team wraps one trigger in <code dir=\"ltr\">&lt;Tooltip&gt;</code>. What happens, and what’s the fix?</p>","options":[{"text":"The tooltip breaks; tooltips can’t wrap buttons.","why":"Tooltips wrap buttons all the time; the problem is how Tabs finds its triggers."},{"text":"Nothing; cloning reaches nested elements automatically.","why":"Cloning only touches direct children, so the wrapped trigger is missed."},{"text":"The tab panel unmounts; add a <code dir=\"ltr\">key</code> to the tooltip.","why":"Keys control identity in lists, not how state reaches a nested trigger."},{"text":"The wrapped trigger no longer receives its props; share state through context instead.","why":"Correct. Context reaches the trigger however deeply it’s nested."}],"answer":3},{"q":"<p>A designer’s mockups show a custom checkbox drawn with a <code dir=\"ltr\">&lt;div&gt;</code>. What should the system’s Checkbox be built on?</p>","options":[{"text":"The <code dir=\"ltr\">&lt;div&gt;</code> with <code dir=\"ltr\">role=&quot;checkbox&quot;</code>, <code dir=\"ltr\">tabindex</code> and key handlers added.","why":"Possible, but it rebuilds by hand what the native input already does correctly."},{"text":"An <code dir=\"ltr\">&lt;img&gt;</code> that swaps between checked and unchecked pictures.","why":"Images carry no state or keyboard behavior for assistive technology."},{"text":"A native <code dir=\"ltr\">&lt;input type=&quot;checkbox&quot;&gt;</code>, visually styled, with its label associated.","why":"Correct. Native elements bring focus, keyboard and state for free; style them rather than replace them."},{"text":"A <code dir=\"ltr\">&lt;button&gt;</code> with <code dir=\"ltr\">aria-pressed</code>.","why":"That’s a toggle button pattern, which is announced differently from a checkbox."}],"answer":2},{"q":"<p>The Dialog docs page lists every prop accurately, but teams keep using Dialog for success messages. Which part of the page is missing?</p>","options":[{"text":"A more detailed props table.","why":"The props table is already accurate; it can’t tell people when not to use Dialog."},{"text":"A changelog link.","why":"History doesn’t help someone decide which component to use today."},{"text":"A longer description of the overlay animation.","why":"Animation details don’t address choosing the right component."},{"text":"‘When not to use’ guidance with the alternative, Toast, and a do-and-don’t example.","why":"Correct. Misuse comes from missing judgment, which only written guidance provides."}],"answer":3},{"q":"<p>A Button is disabled with <code dir=\"ltr\">aria-disabled=&quot;true&quot;</code> so a tooltip can explain why. A tester clicks it and the form saves anyway. What was missed?</p>","options":[{"text":"<code dir=\"ltr\">aria-disabled</code> should be <code dir=\"ltr\">aria-disabled=&quot;disabled&quot;</code>.","why":"The valid values are <code dir=\"ltr\">true</code> and <code dir=\"ltr\">false</code>; the value isn’t the problem."},{"text":"<code dir=\"ltr\">aria-disabled</code> only announces the state; the component must block the action itself.","why":"Correct. Unlike the <code dir=\"ltr\">disabled</code> attribute, <code dir=\"ltr\">aria-disabled</code> doesn’t stop clicks."},{"text":"The tooltip intercepted the click.","why":"Tooltips don’t change click behavior; the button’s handler ran because nothing stopped it."},{"text":"Screen readers ignore <code dir=\"ltr\">aria-disabled</code> on buttons.","why":"Screen readers announce it; the issue is the missing guard on the action."}],"answer":1}],"s-ds-4":[{"q":"<p>The tokens JSON is the source of truth, but a designer published a new action blue directly in the Figma library. What should happen next?</p>","options":[{"text":"Copy the Figma value into the JSON so both match.","why":"That accepts an unreviewed change and skips the contrast and naming checks."},{"text":"Leave both; small differences don’t matter.","why":"Small differences are how two products ended up with two blues."},{"text":"Revert the library to the released values and turn the change into a pull request against the JSON.","why":"Correct. The change goes through the normal review and checks, then syncs back to Figma on release."},{"text":"Lock the Figma library so nobody can edit variables.","why":"Designers need to explore in branches; the process, not a lock, prevents divergence."}],"answer":2},{"q":"<p><code dir=\"ltr\">@northwind/tokens</code> is at 2.3.1. A release adds three new tokens and renames one existing token, keeping no alias. What’s the correct version?</p>","options":[{"text":"3.0.0, because the rename without an alias breaks anyone using the old name.","why":"Correct. Additions alone would be 2.4.0, but the highest bump wins and a removal is major."},{"text":"2.4.0, because most of the changes are additions.","why":"The majority doesn’t decide; one breaking change makes the release major."},{"text":"2.3.2, because token changes are always patches.","why":"Renames and removals change the public API, which is never a patch."},{"text":"2.4.0 now, and 3.0.0 when teams complain.","why":"Versions describe the change when it ships, not after the damage."}],"answer":0},{"q":"<p>Which change belongs in a major release of Northwind UI?</p>","options":[{"text":"Fixing Tabs so Arrow keys move focus as documented.","why":"Restoring documented behavior is a patch."},{"text":"Adding a <code dir=\"ltr\">size</code> prop to Badge.","why":"A backward-compatible addition is minor."},{"text":"Slightly darkening a token’s value within its role.","why":"A value refinement within the same role is a minor design update."},{"text":"Changing Dialog so it no longer closes on Escape by default.","why":"Correct. Changing a default changes behavior for every existing use without any code change."}],"answer":3},{"q":"<p>A codemod renamed <code dir=\"ltr\">kind</code> to <code dir=\"ltr\">variant</code> in a repository, but the deprecation warning still appears in the console. What’s the most likely reason?</p>","options":[{"text":"The codemod didn’t run on test files.","why":"Possible, but tests rarely trigger warnings in the developer’s running app."},{"text":"Some Buttons receive <code dir=\"ltr\">kind</code> through spread props built elsewhere, which static rewriting can’t see.","why":"Correct. The runtime warning exists precisely to catch the cases codemods miss."},{"text":"The warning is cached by the browser.","why":"Console warnings aren’t cached; they’re logged when the code runs."},{"text":"Codemods only work in production builds.","why":"Codemods rewrite source files and have nothing to do with build mode."}],"answer":1},{"q":"<p>A visual test shows that a padding token change altered 3 Dialog stories and 40 Table stories. The pull request only meant to change Dialog. What does this tell the reviewer?</p>","options":[{"text":"The token is used more widely than intended, so Dialog probably needs its own component token.","why":"Correct. The diff revealed the change’s real reach; a component token scopes it to Dialog."},{"text":"Visual tests are unreliable for padding changes.","why":"A consistent diff across 40 stories is a real signal, not flakiness."},{"text":"Accept all 43 diffs, since padding changes are minor.","why":"Accepting unintended changes to 40 Table stories ships a regression to every table."},{"text":"Delete the Table stories until Dialog ships.","why":"Removing coverage hides the side effect instead of fixing it."}],"answer":0}],"s-ds-5":[{"q":"<p>A team proposes contributing its <code dir=\"ltr\">FreightRateCalculator</code> to the system. No other team calculates rates. What’s the right triage outcome?</p>","options":[{"text":"Accept it, because contributions are free capacity.","why":"A system component carries maintenance costs forever, even when someone else wrote it."},{"text":"Reject it and ask the team to delete it.","why":"The component solves a real problem; it just isn’t a shared one."},{"text":"Ask the core team to rebuild it properly first.","why":"Core capacity should go to shared needs, not a one-team feature."},{"text":"Keep it local, built from system parts, and list it so a second team’s need can trigger an RFC.","why":"Correct. Local is a legitimate outcome, and the list keeps the option open."}],"answer":3},{"q":"<p>Tidewater’s brand team wants its Tabs to use a different keyboard interaction than Northwind’s. What should happen?</p>","options":[{"text":"Accept it through a brand token that switches the key handling.","why":"Tokens carry visual values; behavior hidden in tokens is untestable and surprising."},{"text":"Treat it as a product proposal for both brands, decided in API review against the WAI-ARIA tabs pattern.","why":"Correct. Brands change personality, not behavior; if the interaction is better, both brands get it."},{"text":"Fork Tabs for Tidewater.","why":"Forks diverge in fixes and accessibility, which defeats the shared system."},{"text":"Add a <code dir=\"ltr\">brand</code> prop to Tabs.","why":"Brand-aware components must change for every new brand, which doesn’t scale."}],"answer":1},{"q":"<p>The DOM scan reports 88% Button adoption, but users still report three different button styles on the billing pages. What should you check first?</p>","options":[{"text":"Whether the scan counts something teams can copy, such as the <code dir=\"ltr\">nw-button</code> class, instead of the component’s own marker.","why":"Correct. Forked components with copied class names look like adoption to a naive scan."},{"text":"Whether users are using old browsers.","why":"Old browsers don’t create three distinct button designs."},{"text":"Whether the survey sample was too small.","why":"The issue is the adoption measurement, not the satisfaction survey."},{"text":"Whether 88% is above the company target.","why":"Hitting a target doesn’t explain why the UI is inconsistent."}],"answer":0},{"q":"<p>Two senior engineers argue about whether Table should support inline editing. Which governance step makes the decision durable?</p>","options":[{"text":"Let the engineer with more experience decide privately.","why":"Private decisions by seniority get re-argued as soon as someone new joins."},{"text":"Ship inline editing as an experimental flag and see what happens.","why":"Shipping to avoid deciding moves the decision onto every product team."},{"text":"Discuss it in the open API review using principles and usage evidence, then record the decision and reasons in the log.","why":"Correct. A written decision with reasons can be revisited with new evidence instead of re-fought."},{"text":"Postpone it until the next annual planning cycle.","why":"A year of ‘maybe’ is worse for teams than a clear answer either way."}],"answer":2},{"q":"<p>Reporting’s adoption is 25%, far below other teams. Leadership wants to list team scores in the monthly all-hands. What’s the better use of the number?</p>","options":[{"text":"Publish the ranking so low teams feel pressure to improve.","why":"Public ranking invites gaming, like relabeling local components, rather than better fit."},{"text":"Set Reporting a 90% target for next quarter.","why":"A target without understanding why adoption is low pushes components into places they don’t fit."},{"text":"Ignore it, because adoption metrics are unreliable.","why":"The number is a useful signal; the question is how to use it."},{"text":"Treat it as research: ask Reporting what the system lacks, and report organization-wide trends upward.","why":"Correct. At Northwind, the answer was charts and dense tables, which became the next roadmap."}],"answer":3}]},"final":[{"q":"<p>Northwind wants Tidewater’s marketing hero to be dark while the rest of the page stays light. Which setup achieves this with no component changes?</p>","options":[{"text":"Set <code dir=\"ltr\">data-theme=&quot;dark&quot;</code> on the hero section, with dark tokens under a bare <code dir=\"ltr\">[data-theme=&quot;dark&quot;]</code> selector and component tokens declared on component selectors.","why":"Correct. The attribute starts a dark subtree, and component tokens resolve against it on each element."},{"text":"Add a <code dir=\"ltr\">.dark</code> class to every component inside the hero.","why":"Per-component classes mean every component must know about themes."},{"text":"Load a second stylesheet for the hero section.","why":"Stylesheets apply to the whole document; they can’t be scoped to one section without selectors."},{"text":"Use <code dir=\"ltr\">filter: invert(1)</code> on the hero.","why":"Inversion distorts brand colors and images, and produces untested contrast."}],"answer":0},{"q":"<p>Which file content would a DTCG 2025.10 tool reject?</p>","options":[{"text":"A group with <code dir=\"ltr\">&quot;$type&quot;: &quot;color&quot;</code> containing tokens without their own <code dir=\"ltr\">$type</code>.","why":"Tokens inherit <code dir=\"ltr\">$type</code> from their group, so this is valid."},{"text":"A token whose <code dir=\"ltr\">$value</code> is <code dir=\"ltr\">&quot;{color.blue.600}&quot;</code> where <code dir=\"ltr\">color.blue.600</code> is a token.","why":"That’s a valid alias to a token."},{"text":"A color token with <code dir=\"ltr\">colorSpace</code>, <code dir=\"ltr\">components</code> and an optional <code dir=\"ltr\">hex</code>.","why":"That is the 2025.10 color format."},{"text":"A token named <code dir=\"ltr\">space.inset</code> inside a <code dir=\"ltr\">space</code> group.","why":"Correct. Periods are reserved for reference paths, so names can’t contain them."}],"answer":3},{"q":"<p>A Button’s API is <code dir=\"ltr\">variant</code>, <code dir=\"ltr\">size</code>, <code dir=\"ltr\">loading</code>, <code dir=\"ltr\">startIcon</code>, <code dir=\"ltr\">endIcon</code>, plus all native button attributes. A team needs a Button that opens a menu. What should the system do?</p>","options":[{"text":"Add a <code dir=\"ltr\">menuItems</code> prop to Button.","why":"Menu content as a Button prop starts prop explosion and mixes two components’ jobs."},{"text":"Provide a composed MenuButton built from Button and a Menu, following the WAI-ARIA menu button pattern.","why":"Correct. Composition keeps Button simple and gives the menu its own accessible behavior."},{"text":"Tell the team to build it from scratch with a <code dir=\"ltr\">&lt;div&gt;</code>.","why":"The system should cover a common pattern like this, and a <code dir=\"ltr\">&lt;div&gt;</code> drops native behavior."},{"text":"Add a <code dir=\"ltr\">isMenu</code> boolean to Button.","why":"A boolean can’t express menu content or keyboard behavior, and it grows the API."}],"answer":1},{"q":"<p>In Northwind’s token pipeline, why is the dark theme built with primitives in <code dir=\"ltr\">include</code> and only the dark semantic file in <code dir=\"ltr\">source</code>, filtered on <code dir=\"ltr\">isSource</code>?</p>","options":[{"text":"Because <code dir=\"ltr\">include</code> files are minified.","why":"Style Dictionary doesn’t minify include files; the difference is whether tokens count as source."},{"text":"Because Figma exports only dark modes.","why":"Figma exports any mode; this is about the generated CSS."},{"text":"So references resolve against primitives while only the remapped semantic tokens are written under the dark selector.","why":"Correct. Otherwise the dark file would repeat every primitive for no reason."},{"text":"Because dark mode doesn’t use primitives.","why":"Dark semantic tokens point at primitives; they just don’t need to be re-emitted."}],"answer":2},{"q":"<p>Which situation calls for <code dir=\"ltr\">aria-disabled=&quot;true&quot;</code> rather than the <code dir=\"ltr\">disabled</code> attribute?</p>","options":[{"text":"A Submit button while the form is being sent, with no explanation needed.","why":"<code dir=\"ltr\">disabled</code> (or a loading state) is fine when nobody needs to reach the control."},{"text":"A decorative button that never does anything.","why":"A control that never works shouldn’t be a button at all."},{"text":"A button hidden on mobile.","why":"Hidden elements need neither attribute; they aren’t reachable."},{"text":"A Save button that must stay focusable so keyboard users can reach the explanation of why it’s unavailable.","why":"Correct. <code dir=\"ltr\">aria-disabled</code> keeps it in the tab order; the component blocks the action itself."}],"answer":3},{"q":"<p>The <code dir=\"ltr\">light-dark()</code> CSS function is suggested as a replacement for Northwind’s theme token blocks. What’s the accurate assessment?</p>","options":[{"text":"It handles two-mode color values well but can’t express brands, density or more than two modes, so token remapping is still needed.","why":"Correct. It’s useful for simple light and dark colors, not for a multi-axis theming system."},{"text":"It replaces custom properties entirely.","why":"It only picks between two colors (or images) by color scheme; it doesn’t replace variables for spacing, radii or brands."},{"text":"It only works in Figma.","why":"It’s a CSS function supported by modern browsers."},{"text":"It requires JavaScript to switch modes.","why":"It responds to the <code dir=\"ltr\">color-scheme</code> in effect; no script is required."}],"answer":0},{"q":"<p>After 5.0.0 removes the deprecated <code dir=\"ltr\">kind</code> prop, the billing team can’t upgrade for two months. What does Northwind’s deprecation policy give them?</p>","options":[{"text":"Nothing; they must upgrade immediately.","why":"Forcing an immediate upgrade is what led to forks in Northwind’s first major."},{"text":"A private fork of 5.0.0 with <code dir=\"ltr\">kind</code> restored.","why":"Private forks are what the support policy is designed to prevent."},{"text":"Bug and security fixes on 4.x for six months, so they can upgrade on their own schedule.","why":"Correct. A stated support window for the previous major keeps teams safe while they migrate."},{"text":"A new 5.0.1 that brings <code dir=\"ltr\">kind</code> back.","why":"Re-adding a removed API in a patch would make the version numbers meaningless."}],"answer":2},{"q":"<p>Visual baselines were generated on a designer’s Mac and CI runs on Linux. Every text-heavy story fails by a few pixels. What’s the right fix?</p>","options":[{"text":"Raise the diff threshold until the tests pass.","why":"A threshold loose enough to hide font rendering differences also hides real regressions."},{"text":"Generate and compare baselines in the same CI environment.","why":"Correct. Comparable screenshots need the same browser, OS and fonts."},{"text":"Disable visual tests for text-heavy stories.","why":"Those stories are where typography regressions, like the line-height one, appear."},{"text":"Run visual tests only on designers’ machines.","why":"Then CI can’t block a regression, and machines still differ from each other."}],"answer":1},{"q":"<p>A contributor’s new Combobox has stories only for its default and hover states. What should the review ask for?</p>","options":[{"text":"Nothing more; two stories are enough to document it.","why":"Missing states are where components fail, and they need visual and accessibility coverage."},{"text":"A longer description in the docs.","why":"Docs are needed too, but the gap here is untested states."},{"text":"A screenshot of each state in the pull request description.","why":"Screenshots in a description aren’t re-checked on future changes; stories are."},{"text":"Stories for every cell of its state matrix, including focus, open, disabled and invalid.","why":"Correct. Each state becomes documentation, an accessibility check and a visual test."}],"answer":3},{"q":"<p>Which description of the DTCG 2025.10 release is accurate?</p>","options":[{"text":"The first stable version of a W3C Community Group report, implemented by tools such as Style Dictionary and Figma’s variable import and export.","why":"Correct. It’s stable and widely implemented, but it isn’t a W3C Recommendation."},{"text":"A W3C Recommendation that browsers implement natively.","why":"Community Group reports aren’t Recommendations, and browsers don’t read token files."},{"text":"An early draft with no tool support yet.","why":"2025.10 is the stable release, with support in several tools."},{"text":"A proprietary Figma format.","why":"The format is vendor-neutral and developed by a community group."}],"answer":0},{"q":"<p>The dispatch app shows Northwind and Tidewater sections side by side, and Tidewater sections still use Inter for headings even though <code dir=\"ltr\">[data-brand=&quot;tidewater&quot;]</code> sets <code dir=\"ltr\">--nw-brand-font-heading</code>. What fixes it?</p>","options":[{"text":"Add <code dir=\"ltr\">!important</code> to the Tidewater font token.","why":"Importance doesn’t help; the semantic token was already resolved at the root."},{"text":"Load the Georgia font file.","why":"Georgia is a system font here; the problem is which value the heading receives."},{"text":"Re-declare the semantic mappings, including <code dir=\"ltr\">--nw-font-heading</code>, under <code dir=\"ltr\">[data-brand]</code> as well as <code dir=\"ltr\">:root</code>.","why":"Correct. Then each brand section computes its semantic tokens from its own brand tier."},{"text":"Give Tidewater headings their own class.","why":"Brand classes on components bypass the token architecture."}],"answer":2},{"q":"<p>Which combination of signals gives the most trustworthy picture of a design system’s health?</p>","options":[{"text":"Number of components in the library.","why":"A big library can be unused or inconsistent; size isn’t health."},{"text":"Stars on the documentation site’s repository.","why":"Popularity outside the company says little about internal adoption."},{"text":"Total pull requests merged per month.","why":"Activity can be high while teams quietly fork; it measures the core team, not the users."},{"text":"Component adoption, token coverage, version lag and team satisfaction, tracked as trends together.","why":"Correct. Several signals together resist gaming and show where the system fails its users."}],"answer":3}],"glossary":[{"id":"design-system","term":"Design system","definition":"The shared tokens, components, patterns, documentation and the people and processes that keep them current, so many teams can build consistent interfaces without re-deciding everything.","lesson":"l-ds-1-1"},{"id":"interface-inventory","term":"Interface inventory","definition":"An audit that collects every instance of each UI element across products, grouped by type, to make duplication visible and to decide what a design system should own first.","lesson":"l-ds-1-2"},{"id":"design-principle","term":"Design principle","definition":"A short statement that picks a side in a real trade-off, such as accessible before beautiful, so it can settle design arguments without a long meeting.","lesson":"l-ds-1-3"},{"id":"hybrid-team-model","term":"Hybrid team model","definition":"A way of running a design system in which a small dedicated core owns tokens, reviews and releases while product teams contribute components and fixes through a defined process.","lesson":"l-ds-1-3"},{"id":"design-token","term":"Design token","definition":"A named design decision, such as a color, spacing value or font size, stored once and referenced by name from design tools and code instead of repeating raw values.","lesson":"l-ds-2-1"},{"id":"primitive-token","term":"Primitive token","definition":"A token that names a raw value by what it is, such as <code dir=\"ltr\">--nw-blue-600</code>, without saying where it is used. Primitives form the system’s palette and scales.","lesson":"l-ds-2-1"},{"id":"semantic-token","term":"Semantic token","definition":"A token that names an intent, such as <code dir=\"ltr\">--nw-color-action-bg</code>, and points at a primitive. Themes and brands change which primitive each semantic token points at.","lesson":"l-ds-2-1"},{"id":"component-token","term":"Component token","definition":"A token scoped to one component, such as <code dir=\"ltr\">--nw-button-bg</code>, that points at a semantic token and lets that component be adjusted without affecting others.","lesson":"l-ds-2-1"},{"id":"naming-grammar","term":"Token naming grammar","definition":"A fixed order of name parts, such as category, concept, property, variant and state, that makes token names predictable to guess, sortable, and checkable by a lint rule.","lesson":"l-ds-2-2"},{"id":"theme","term":"Theme","definition":"A remapping of semantic tokens to different primitives, such as a dark theme, applied with a selector like <code dir=\"ltr\">[data-theme=&quot;dark&quot;]</code> while components stay unchanged.","lesson":"l-ds-2-3"},{"id":"mode-axis","term":"Mode axis","definition":"An independent dimension of theming, such as color scheme, brand or density, that owns its own set of tokens so combinations compose without separate files for each.","lesson":"l-ds-2-3"},{"id":"dtcg-format","term":"DTCG format","definition":"The JSON format for design tokens defined by the W3C Design Tokens Community Group, whose first stable version, 2025.10, covers tokens, types, groups, aliases and color.","lesson":"l-ds-2-4"},{"id":"alias","term":"Alias (token reference)","definition":"A token whose value refers to another token by its path in curly braces, such as <code dir=\"ltr\">{color.blue.600}</code>. It must point at a token, never at a group.","lesson":"l-ds-2-4"},{"id":"token-pipeline","term":"Token pipeline","definition":"A build step that parses token files, resolves aliases, transforms names and values per platform, and writes formats such as CSS custom properties, Swift and Kotlin.","lesson":"l-ds-2-5"},{"id":"output-references","term":"Output references","definition":"A pipeline setting that keeps aliases as <code dir=\"ltr\">var()</code> references in generated CSS instead of resolved values, so the token tiers and runtime overrides survive into the browser.","lesson":"l-ds-2-5"},{"id":"variant","term":"Variant","definition":"One of a fixed set of mutually exclusive styles of a component, such as primary, secondary or danger, best expressed as a single enum prop rather than separate booleans.","lesson":"l-ds-3-1"},{"id":"slot","term":"Slot","definition":"A place in a component where the consumer passes content, such as <code dir=\"ltr\">children</code> or a <code dir=\"ltr\">startIcon</code> element, instead of configuring that content through more props.","lesson":"l-ds-3-1"},{"id":"compound-component","term":"Compound component","definition":"A component made of cooperating pieces, such as <code dir=\"ltr\">Tabs.List</code> and <code dir=\"ltr\">Tabs.Trigger</code>, that the consumer arranges freely while the pieces share state through context.","lesson":"l-ds-3-2"},{"id":"state-matrix","term":"State matrix","definition":"A grid of every variant against every interaction state, such as hover, focus visible, disabled, loading and pressed, used to design, build and test a component completely.","lesson":"l-ds-3-3"},{"id":"focus-visible","term":":focus-visible","definition":"A CSS pseudo-class that matches when the browser decides focus should be visible, typically after keyboard navigation, used to show focus rings without showing them on most mouse clicks.","lesson":"l-ds-3-3"},{"id":"figma-variable-mode","term":"Figma variable mode","definition":"One of several sets of values for the variables in a Figma collection, such as Light and Dark, applied to frames the way theme selectors apply to page sections.","lesson":"l-ds-4-1"},{"id":"semver","term":"Semantic versioning","definition":"A MAJOR.MINOR.PATCH version scheme where patches fix bugs, minors add backward-compatible features, and majors contain changes that can break existing usage.","lesson":"l-ds-4-2"},{"id":"changeset","term":"Changeset","definition":"A small file added to a pull request that states the version bump a change needs and a consumer-facing summary, later combined into the release version and changelog.","lesson":"l-ds-4-2"},{"id":"deprecation","term":"Deprecation","definition":"Marking an API, token or component as scheduled for removal while it still works, naming its replacement and removal version so teams can migrate before it disappears.","lesson":"l-ds-4-3"},{"id":"codemod","term":"Codemod","definition":"A script that rewrites source code automatically, such as renaming a deprecated prop across a repository, so migrations become reviews instead of manual work.","lesson":"l-ds-4-3"},{"id":"visual-regression-test","term":"Visual regression test","definition":"A test that screenshots a component state and compares it with an approved baseline, failing on differences that a human then accepts as intended or rejects as bugs.","lesson":"l-ds-4-4"},{"id":"rfc","term":"RFC (request for comments)","definition":"A written proposal for a significant change, such as a new component, laying out the problem, evidence, API sketch and accessibility plan for open review before building.","lesson":"l-ds-5-1"},{"id":"brand-tier","term":"Brand tier","definition":"A small layer of tokens between primitives and semantic tokens, such as a color ramp, fonts and radii, that each brand points at its own values.","lesson":"l-ds-5-2"},{"id":"adoption-rate","term":"Adoption rate","definition":"The share of UI elements in a product that are rendered by the real design system components, measured with signals only those components produce, tracked as a trend.","lesson":"l-ds-5-3"}]}