A team built a cloud console's instance detail panel from a design editor's inspect mode and shipped fixed widths and raw colors; what went wrong, and how would you fix the handoff?
answer
- a measuring tape, not a contract
- one frame's geometry at one width
- resolved values versus named roles
- hand-drawn layers carry no link
- annotate rules, walk through together
basics
~20 sInspect mode reports one drawn frame's geometry and resolved values, not intent: whether a width fills, which token a color plays, which component a layer is. Build designs from linked library pieces, annotate resize rules, and review handoff together.
solid answer
~50 sInspect mode is a measuring tape. It reports what one frame measured — its width at the size it was drawn, offsets, and the resolved value of each color and text style — and, where the designer used linked library components and tokens, their names. Here two things failed. The engineers read a measured width as a fixed one, because inspect cannot say whether the panel is meant to fill, size to its content or clamp between limits. And the colors came through raw because layers were drawn by hand or detached from the library, so there was no name to show. The fix sits on both sides: build screens from linked components and tokens so inspect surfaces names; **annotate layout rules** (fill, fixed, minimum, maximum, what scrolls); mark off-system pieces; and hold a short handoff walkthrough where engineers list what they would otherwise guess.
go deeper
Recall that inspect reports measurements of one drawn frame, and that a component or token name beside a value matters more than the number itself.
Explain why a measured width says nothing about fill, fixed or clamped behaviour, and why detached or hand-drawn layers can only show raw values.
Diagnose the failure on both sides — design built off-library, engineering trusting numbers and snippets — and propose proportionate fixes: linked components, layout annotations, off-system markers and a walkthrough.
Weigh how much handoff ceremony a system should require against the cost of guessing, and where tooling, auditing and lint should carry the load instead of people.
## What inspect mode actually reports Most design editors offer an **inspect mode**: select a layer and see its measurements and styles, often with generated code. It is genuinely useful, and it is easy to over-trust. For any selected layer it typically reports: - **Geometry** — width, height and position, measured in the frame as drawn. - **Distances** — the gap between the selected layer and its neighbours. - **Resolved styles** — the color, type size, weight and radius the layer renders with. - **Names, when they exist** — if the layer is a linked library component, or its values come from design variables mirroring tokens, a good inspect view shows those names alongside the values. - **Generated code** — a snippet translated from the layer's properties for one platform. Everything in that list describes **one drawing at one size**. None of it describes a rule. ## Diagnosing the detail panel The panel shipped with fixed widths and raw colors. Working backwards: 1. **Fixed widths.** The designer drew the panel at one screen width. Inspect reported that width as a number, and the engineer implemented the number. Nothing in the handoff said whether the panel should fill the remaining space, keep a width, or clamp between a minimum and a maximum. 2. **Raw colors.** Inspect showed color codes rather than token names. That usually means the layers were drawn by hand or **detached** from the library component, so the link to a named value was gone — or the engineer read the value and ignored the name beside it. 3. **Copied snippets.** Generated code reproduced absolute sizes and literals, and it looked like a shortcut. The root cause is that the team treated inspect as the **specification**. It is a measuring aid; the specification is the set of decisions — which component, which token, which rule — that the drawing only illustrates. ## What inspect cannot tell an engineer | Engineer's question | What inspect shows | What must carry the answer | |---|---|---| | Is this width fixed or fluid? | One measured number | Layout annotation: fill, fixed, minimum, maximum | | Which token is this color? | The name only if the layer is linked; else a code | Building from library pieces; annotation when off-system | | Is this the system component or a lookalike? | Layer name, if the designer kept the link | Linked components; explicit off-system marker | | What happens at other widths? | Nothing | Resize rules; frames at key widths | | What happens with long content or no data? | Nothing | Behaviour annotations | ## Fixing the handoff Fixes land on both sides of the handoff: - **Build designs from the library.** Screens assembled from linked components and token-backed styles make inspect show names, and turn *what value?* into *which piece?* - **Annotate layout rules explicitly.** For each region: fills, keeps its width, or clamps; what scrolls; what happens below the smallest supported width. On native mobile the same annotation answers how the panel behaves on a phone versus a tablet. - **Mark off-system pieces.** A deliberately new element is labelled as such, so a raw value in inspect means *new* rather than *mistake*. - **Hold a short walkthrough.** Designer and engineer spend fifteen minutes on the screen; the engineer lists every value they would have to guess, and each one gets an answer or an annotation. - **Change the engineering habit.** Read the names before the numbers; reuse the coded component rather than pasting generated code; ask when inspect shows a raw value that looks like it should be a token. ## Keeping the process proportionate Not every screen needs a ceremony. A screen built entirely from existing components with standard layout needs little beyond the names inspect already shows. A new layout, a new pattern or anything with custom sizing earns the full annotation and walkthrough. Two neighbouring practices catch what slips through: auditing the shipped screen against the design, and lint rules that reject raw values in code. Neither replaces a handoff that states intent in the first place. The goal is not a handoff with zero questions; it is that every question gets asked before the build starts, while the answer is a sentence in a design file, rather than discovered in review, when the answer is a rework ticket.
- Should engineers use the code snippets that a design editor's inspect mode generates?Rarely as written. They are generated from drawn layers for one platform and reproduce absolute sizes and literal values. In a system codebase the right code is usually one coded component with a few properties. A snippet can hint at an unusual value for a genuinely new piece, but it never substitutes for the component the layer represents.
- How do you tell whether the defect started in the design file or in the implementation?Open the design: if the panel was built from linked components and token-backed styles and inspect showed their names, the implementation ignored them. If layers were hand-drawn or detached, inspect could only show raw values and the handoff failed first. Often both need fixing — the design practice and the habit of trusting numbers over names.
saying these in an interview costs you the question
- Inspect mode is the spec; if the numbers match, the build is right.
- A width measured in the design should be implemented as a fixed width.
- Code generated by a design editor's inspect mode is ready for production.
- A raw value in inspect always means the design system lacks a token.
- Guessing a value is fine as long as it matches the drawn frame.