In an applicant-tracking tool's design system, pipeline cards and the candidate side panel no longer line up with the page grid; how do you diagnose and fix it?
answer
- overlay the grid first
- fixed widths inside fluid spans
- container inset shifts content
- nested regions, different gutters
- the layout owns spans
basics
~20 sOverlay the grid and find where edges leave the column lines. Usual causes are hard-coded component widths, containers whose inset shifts content, nested regions with different gutters and spans that forget inner gutters. Let layouts own spans and components fill them.
solid answer
~50 sOverlay the page grid in the design file and in a development build, then note every edge that leaves a column line. The usual causes: **hard-coded widths** on cards, which stop matching their span when the window changes; **container inset** that shifts nested content off the lines; a **nested region** such as the side panel using its own gutter; a **fixed-width panel** taking space without the remaining area being re-gridded; and span arithmetic that forgets the inner gutters. Fix the system, not the screens: **layouts own spans** and components fill whatever span they are given, with minimum and maximum widths rather than fixed ones; nested grids inherit the page gutter; a fixed side panel sits beside a main area with its own column grid; and span rules are documented per window size. Then guard it with visual tests at several widths.
go deeper
Recall that components fill the span the layout gives them, and that spans include their inner gutters.
Explain the usual causes: fixed widths in fluid spans, container inset, nested gutters and carved-out fixed panels.
Demonstrate the whole loop: overlay, measure at several widths, trace to layout or component rules, fix once, and guard with visual tests.
Discuss where the system should demand strict alignment and where a documented offset is the better trade for product teams' speed.
## Start with evidence Misalignment reported as "it looks off" needs to become a list of specific edges. 1. **Overlay the grid** in the design file and in a development build of the pipeline board and the candidate profile. 2. **Test several widths**, including just inside each window-size boundary, because many alignment problems only appear at some widths. 3. **Record each edge** that leaves a column line: which component, which side, by how much, at which width. 4. **Look for patterns.** A constant offset points at an inset or gutter mismatch; an offset that grows with width points at a fixed width inside a fluid span. ## Tracing symptoms to causes | Symptom | Likely cause | Fix in the system | |---|---|---| | Cards drift further off the lines as the window widens | card has a hard-coded width inside a fluid span | cards fill their span, with minimum and maximum widths | | Content inside the side panel sits a constant few units right of the line | panel's own inset added on top of the grid | align inner content to the grid or apply one documented offset everywhere | | Panel's inner columns do not match the page's | nested region uses its own gutter | nested grids inherit the page gutter | | Main area's columns are squeezed and uneven | fixed-width panel carved out without re-gridding the rest | fixed panel beside a main area that carries its own column grid | | A card spanning 3 columns is narrower than a header spanning 3 | span computed as columns only | span = columns plus inner gutters, defined once | ## Fixing the model, not the screens - **Layouts own spans.** The page layout decides that the side panel spans 3 of 12 and the board 9 of 12; components never decide their own width. - **Components are fluid inside a span.** A candidate card fills whatever width it is given, with a minimum width below which the layout must change the span, and a maximum width above which it stops growing. - **Nested grids inherit the gutter.** When the board lays out cards inside its 9 columns, it uses the same gutter as the page, so card edges fall on the page's lines where the arithmetic allows. - **Fixed panels are explicit.** If the candidate side panel is a fixed width, the grid is defined for the remaining main area, rather than pretending the panel is part of a 12-column page. - **One offset rule.** Where a container's inset cannot be avoided, the system states whether content aligns to the grid or to the container's inner edge, and applies that rule everywhere. ## Documenting the rules - Each page template lists its regions and their spans for every window range. - Each component spec states whether it is fluid within its span, and its minimum and maximum widths. - The system publishes the grid's numbers once, used by design files and code alike, so a gutter cannot quietly differ between them. ## Preventing regression - Add visual tests of the pipeline board and candidate profile at several widths, including just inside each boundary. - Keep a grid overlay available in development builds, so engineers can check alignment while building. - Review new page templates against the grid before they are used by product teams. ## A note on trade-offs Perfect alignment of every nested edge is not always achievable: a card's inner text cannot sit on the page's column line if the card has an inset and a border. The aim is that alignment is **deliberate**: either on the lines, or offset by one documented amount, never offset by a different amount on every screen. Recruiters scanning a board of hundreds of candidates notice inconsistency long before they notice a consistent offset. ## What usually goes wrong with the fix - **Patching screens.** Nudging each misaligned card on each screen fixes today's screenshot and breaks again at the next width or the next new screen. - **Matching the design file's width.** Copying a measured width from a design drawn at one window size bakes the drift back in. - **Checking only two widths.** Alignment that holds at the smallest and largest widths can still fail in between, where fluid columns have stretched but spans have not changed yet.
- Why should a component not set its own width in a grid-based layout?Because the right width depends on the span the layout gives it, which changes with window size and context. A hard-coded width matches its span at one window size only and drifts everywhere else. Letting the layout assign the span and the component fill it, within a minimum and maximum, keeps edges on the column lines at every width.
- How do you combine a fixed-width side panel with a column grid?Treat the panel as outside the grid and define the column grid for the remaining main area. The main area then has its own column count, gutter and margins, and its content aligns to those lines. Pretending the panel occupies some of twelve page columns leaves the rest with uneven, squeezed columns.
- Should text inside a bordered card line up with the page's column lines?When it can, yes. When the card's inset and border make it impossible, choose one rule, such as aligning content to the card's inner edge, and apply it everywhere. A consistent offset reads as intentional; a different offset on every screen reads as a mistake.
saying these in an interview costs you the question
- Nudge each misaligned card on each screen until it looks right.
- Components should hard-code their widths to match the design file.
- A fixed side panel can simply occupy three of twelve page columns.
- Nested regions should pick their own gutters to suit their content.
- Alignment only needs checking at the widths in the design file.