Redline
Artifact
A design annotated with spacing, size, and color written out as numbers, so the people building it don't have to guess.
Why it exists
A design is a picture and code is numbers. Hand over only the picture and whoever receives it measures the screen by eye and estimates. The padding above a button was meant to be 24, it gets built at 20, and nobody notices in the moment. Across one screen the spacing ends up a mix of 16, 18, 20, and 24. Each value looks fine on its own; ten screens in a row look like a product nobody tidied.
The mismatch then repeats as the same conversation at review. The designer says the spacing is off, the engineer asks what it should be, and the answer comes back as "what's in the design." With no numbers in the file that exchange never ends, because both people are looking at the same screen and arguing from different references.
So designers started drawing lines onto the design with numbers beside them. The name comes from the practice of drawing those marks in red. Writing the values costs the person handing off some time, and it removes the range where the person receiving it has to guess. That trade is the whole argument for the artifact: one person spends twenty minutes so that nobody spends an afternoon in review.
What goes in it
Five groups of values get recorded.
- Spacing — the distance between elements and the padding around them. Written as 24 above the button, 16 between cards. This comes first because eyes can't separate 20 from 24 in a picture.
- Size — width, height, corner radius. Not just the number, but whether it's fixed or grows with the content. "Width 320" alone leaves out what happens when the text wraps to a second line.
- Color and type. Color gets a name alongside the value. A hex code on its own means that six months later, changing that color leaves nobody able to find which screens use it. A design token is the unit that gives a color or a spacing value a name shared with code, and when tokens exist the name goes in instead of the raw value. Type needs size, weight, and line height.
- States — the default, hover, pressed, disabled, and waiting-for-a-result states. Hand over one state and an engineer decides the other four, which means those decisions come out different on every screen. One screen dims the button to grey, the next drops it to half opacity, and the product reads as two products.
- What happens as it narrows. Which element shrinks first and which one drops to a second line. Recording the breakpoint, the width where the layout changes, fixes where that switch happens.
Tools like Figma now read the values straight off the design, so drawing lines and typing numbers by hand has mostly disappeared. What the tool covers is groups 1 and 2 and the raw values in group 3. It reads the one state that's drawn, which leaves the undrawn states and the narrowing rules to a person. The work that used to go into transcribing numbers now goes into groups 4 and 5.
Who writes it and who reads it
The designer who made the design writes it. Whoever finished the mockup — the version with real color and type on it — continues into the values, because anyone else can't tell which piece of spacing was intended and which was a slip of the hand.
Three people read it.
The first is the engineer building the screen, who keeps it open while working and transfers values across. What this reader needs is findable numbers rather than explanation, so values pinned in place on the screen beat prose describing them.
The second is whoever checks the built screen against the design. In design QA, where the implementation and the design sit side by side and the differences get found, the redline is what the verdict rests on. Without written values, that review becomes an exchange of impressions with no basis for settling who is right.
The third is a different designer six months later. Opening the same screen and finding out why it was 24 is what stops that value from being changed casually. A number with no reason behind it gets rounded to whatever the newest screen uses.
The occasion for delivering it is design handoff, the whole process of passing a design to engineering. A redline is one of the things carried into that room; saying out loud what's settled and what isn't is the room's other job.
Draw the boundary of what gets annotated in advance, too. When reusable parts and rules are gathered into one reference, component-level values point at that reference rather than being restated. Write the same button values onto every screen and one change to the button puts twenty files out of date at once.
How it sounds at work
"Send me the redline for this screen and I'll have it built today."
With the values settled, implementation is a day's work.
"The spacing values differ from file to file. Can we get these into tokens?"
Values used in the same role are scattered, so they need one name and one home.
"The disabled state isn't in the redline. What should it be?"
An undrawn state becomes the engineer's decision unless someone supplies it.
At Pagedeck, Noa handed off the document sharing screen with token names in place of raw values — a spacing token name where 24 would go, a primary color token name where the hex would go. When the primary color later went one shade darker, twenty design files didn't have to be touched.
Theo, receiving it, first pointed out that the disabled and waiting states were missing. Without those two you get a screen where the save button can be pressed twice. Implementation started after Noa added them.
What people get wrong
The most common mistake is treating redlining as work that tools eliminated. Click into a design and spacing and color appear, so it looks settled. But what the tool reads is the one state currently drawn. A button that can't be pressed, the screen when a list is empty, the handling when text runs very long — if those aren't drawn, they aren't in the tool either. Miss the distinction and the person handing off believes everything was delivered while the person receiving it decides half of it, and the gap surfaces all at once in review.
The second is thinking that annotating every value is the generous thing to do. It looks like less searching for the reader. But restating values already fixed at the component level puts the same number in two places. On the day button height moves from 40 to 44, the reference says 44 and twenty design files still say 40. What belongs in a redline is what the reference doesn't cover and what this screen deliberately does differently.
Where to go next
- Design deliverable
see why this is the first artifact of the handoff stage among four
- Design handoff
what else has to travel with the file
Last updated 2026-09-26