In a design system for a cloud admin console, real data makes long resource names wrap to five lines inside a table row on several pages. How do you fix it through atomic design's levels?
answer
- not a page-level patch
- lowest level that owns it
- a more atomic level
- decide the content rule
- walk every consuming page
basics
~20 sDo not patch the pages. Fix the lowest level that owns the failing decision, usually the name cell's truncation rule; agree the content rule, document it, keep the long name as a permanent example, and recheck every page using it.
solid answer
~50 sA page-level override fixes one screen and leaves the defect everywhere else the row appears. Frost's own example says that if a name wraps onto five lines within a pattern, the broken behaviour must be addressed at a more atomic level. So I reproduce it on the pattern in isolation with the real string, then find the level that owns the decision: the name cell's overflow rule, the table's column-width policy, or the template's promise about how much the name region holds. With product and content design I agree the rule — for generated identifiers, keep the start and end visible because the suffix often tells siblings apart, and keep the full value reachable and copyable. I change the pattern and its spec, add the long-name case to its documented examples and regression checks, then walk every page that uses it, because a lower-level change ripples everywhere.
go deeper
Recall that when a page breaks under real content, the fix goes into the lower-level pattern that failed, not into the page itself.
Explain how to decide which level owns the failing decision, and why a page-level override leaves the defect on every other page that uses the pattern.
Walk through the whole loop: reproduce in isolation, agree the content rule, fix and document the pattern, make the case permanent and check the blast radius.
Consider how a system institutionalises page-found defects: reporting paths from product teams, worst-case fixtures as a release gate, and when an upstream product limit is the real fix.
## The scenario and the trap A cloud provider's admin console lists resources in a table. Real names run up to the platform's limit, and many are generated identifiers joined without spaces. On several pages a name wraps to five lines, pushing the status and the row's actions out of line. The tempting fix is local: shrink the text on this page, fix the column width here, clamp the name in that one screen. That fixes one page and leaves the defect on every other page using the same row. It also creates a **local fork**: a page that no longer matches the system, which the next system update will quietly break again. Brad Frost's chapter on **atomic design** describes the same case: "If a person's name were to wrap onto five lines within the pattern, we would need to address that broken behavior at a more atomic level." Pages exist to find such defects; the fix belongs lower down. ## Find the level that owns the decision | Decision | Level that owns it | Example in this table | |---|---|---| | How one run of text overflows: wrap, clamp or truncate | Atom (the text style) or molecule | Whether any name may exceed two lines | | Which part of an identifier stays visible | Molecule (the resource-name cell) | Keep the start and the distinguishing end | | How columns share width and which column yields | Organism (the resource table) | The name column yields before status and actions | | How much content a region promises to hold | Template (content structure) | The name region holds one to two lines | | The maximum length a name may have at all | Product or data model, outside the system | A limit the product never enforced | The goal is the **lowest level that owns this decision** — not the lowest level possible. Changing the base text style to fix one table would alter every paragraph in the product. ## A fix that sticks 1. **Reproduce in isolation.** Put the real string into the name cell in the component workshop or design editor, away from page-specific context. 2. **Agree the content rule** with product and content design. Generated identifiers often need **middle truncation**, because siblings often share a prefix and differ only at the end. Human-chosen names may wrap to two lines and then truncate. 3. **Keep the full value reachable.** Truncated text must stay selectable and copyable, and exposed in full to assistive technology; how it is revealed on demand is the owning component's decision. 4. **Change the pattern and its spec**, so the rule is documented where every consumer reads it. 5. **Make the case permanent.** Add the maximum-length identifier to the pattern's documented examples and regression checks, so a later change cannot reintroduce the wrap. 6. **Walk every consuming page**, not only the ones that reported it. A lower-level change ripples by design, and a rule that fixes the table may crowd a detail panel. 7. **Record the guardrail on the template**, so the next screen built on it knows the name region's limit. ## Where the method bends - **The fix may be upstream.** If names can be absurdly long because the product never set a limit, the honest fix may be a product rule, with the pattern still coping gracefully with legacy data. - **One page may legitimately differ.** On a resource's own detail screen the full name is the heading, and wrapping is right there; that page uses a heading pattern instead of bending the table cell. - **Blast radius grows as you go down.** A molecule change touches dozens of screens; an atom change touches everything. Senior judgment is picking the level whose change is both correct and safe to roll out. - **Not every page failure is a system failure.** A product team misusing a pattern, such as putting a paragraph in a name column, is a usage problem to fix in guidance, not in the pattern. ## Making the loop routine - Treat worst-case pages as part of the definition of done for new templates. - Give product teams a simple way to report page-found defects, tagged with the level they suspect. - Keep the long-string pages as permanent fixtures, reviewed whenever the underlying parts change. ## The same shape on native mobile A native list row faces the same decisions: how many lines a name may take, where to truncate, how to reveal the full value. The text component's options differ by platform; the decision, and the level that owns it, do not.
- Why middle truncation for generated identifiers rather than cutting at the end?Generated identifiers often share a long common prefix, such as the project and resource type, and differ only in their last characters. End truncation makes a list of siblings look identical. Keeping the start and the end visible preserves the part people use to tell them apart, while the full value stays reachable and copyable.
- The fix to the name cell makes a different page's detail panel look cramped. What now?That is the ripple you walked the pages to find. Decide whether the panel's context is genuinely different, in which case it should use a different pattern, or whether the cell's rule needs a variant, such as a wider two-line mode. Do not reintroduce a page-level override; route the new finding to the level that owns it.
- How do you stop the same defect returning after the fix?Make the failing content a permanent part of the pattern's documented examples and its automated regression checks, and note the limit in the template's content structure. Future changes to the cell or its parts are then tested against the long identifier by default, instead of relying on someone remembering the incident.
saying these in an interview costs you the question
- Fix it on the affected pages with a local override; the component is fine elsewhere.
- Ask users to choose shorter resource names instead of changing the pattern.
- Always cut identifiers at the end, since the start is what matters.
- Any change to a lower-level pattern is safe because it only fixes things.
- Once truncated, users never need to see or copy the full value.