Refactoring UI

Starting from Scratch

A blank canvas paralyzes people because they try to design everything at once. The fix is to start narrow and rough: design a single concrete feature, not an abstract layout, and work in low fidelity before worrying about how it looks.

How to actually begin

• Start with a feature, not a layout: design a specific piece of functionality (like "add a task") rather than a navbar and shell with nothing inside.
• Detail comes later: work in grayscale and low fidelity first, so you decide structure and hierarchy before colors and shadows distract you.
• Don't design too much too soon: sketch a few realistic states quickly rather than perfecting one screen in exhaustive detail.
• Choose a personality: deliberate choices of font, color, border radius, and language give a product a consistent character.

Working in low fidelity keeps you honest. When everything is grayscale, you cannot hide weak hierarchy behind pretty colors, so problems with what matters most on the screen surface early, while they are cheap to fix.

For a PM, the transferable idea is to sequence design like product work: nail the specific job and its states first, then layer on visual detail. Debating brand colors before the core interaction is designed is optimizing the paint before the house has walls.

Hierarchy is Everything

The single highest-leverage design skill is visual hierarchy: making important elements prominent and less important ones recede. Most interfaces that feel amateurish are simply flat, with everything shouting at the same volume.

Tactics for building hierarchy

• Size isn't everything: lean on font weight and color to signal importance, not just bigger text, which quickly gets clumsy.
• Emphasize by de-emphasizing: instead of making the primary thing louder, mute the things around it so it stands out by contrast.
• Don't use grey text on colored backgrounds: pick a color with the same hue as the background but adjusted lightness, rather than washing it out.
• Labels are a last resort: often you can combine a label and value into one readable phrase, or drop the label entirely when context makes it obvious.
• Separate visual hierarchy from semantic hierarchy: an h1 in the markup does not have to be the biggest thing on the screen.

Balancing weight and contrast matters too: a bold, heavy icon next to light text feels unbalanced, so you tune their visual weight until they sit together. Hierarchy is a continuous set of small adjustments, not one big decision.

The PM learning is that clarity is hierarchy. When users miss the primary action or cannot tell what matters on a screen, the fix is rarely more explanation; it is turning down everything except the one thing you want them to see.

Layout and Spacing

Spacing decisions, made one pixel at a time, are where interfaces quietly fall apart. The remedy is generosity and system: start with too much whitespace and remove, and choose spacing from a fixed scale rather than arbitrary numbers.

Rules for space

• Start with too much whitespace, then tighten; crowding is a more common failure than emptiness.
• Establish a spacing and sizing system: a limited scale of steps, so every gap is a deliberate choice from a set, not a random value.
• You don't have to fill the whole screen: give content a sensible max-width; stretched-full layouts often look worse than compact intentional ones.
• Grids are overrated: fixed widths often beat fluid percentage columns that squeeze elements to awkward sizes.
• Avoid ambiguous spacing: put more space around a group than within it, so a label clearly belongs to the field it sits above.

Relative sizing does not scale: as elements grow, their padding and text should not grow in strict proportion, because a button twice as tall with twice the padding looks wrong. Details need adjusting at different sizes, not uniform multiplication.

For a PM, the takeaway is to standardize spacing in the design system. A shared spacing scale removes an entire category of "it looks slightly off" bugs and makes every screen feel like part of the same product without designers relitigating gaps each time.

Designing Text

Typography carries most of an interface's content, so getting it right is disproportionately important, and again it comes down to systems and a few concrete rules rather than taste.

Typographic rules that carry their weight

• Establish a type scale: pick a limited set of font sizes and use only those, instead of arbitrary sizes everywhere.
• Keep line length in check: around 45 to 75 characters per line keeps text readable; full-width paragraphs are exhausting.
• Line-height is proportional: small text needs more line-height, and wide columns need more than narrow ones.
• Align for readability: left-align long-form text, and never center more than a couple of lines.
• Use letter-spacing deliberately: tighten large headings slightly, and add spacing to all-caps text to make it legible.

Two smaller rules add polish: not every link needs to be a bright color (in dense interfaces, weight or a subtle treatment can signal a link without turning the page into confetti), and using genuinely good fonts, even a safe system font, avoids an instantly amateur feel.

The PM learning is that a constrained type scale is a product asset. Locking the team to a small set of sizes and clear text-alignment rules prevents the slow drift into typographic chaos that makes a maturing product feel inconsistent and unpolished.

Working with Color

Color intimidates non-designers, but it too yields to a system. The starting move is practical: reason about color in HSL (hue, saturation, lightness) rather than hex, because HSL maps to how people actually think about adjusting a color.

Building a usable palette

• You need more colors than you think: not just one blue, but a full set of greys, several shades of each primary, plus accent and semantic colors for success, warning, and danger.
• Define your shades up front: create eight to ten fixed shades of each color, so every UI state pulls from a system instead of on-the-fly guessing.
• Don't let lightness kill saturation: at very light and very dark ends, increase saturation so colors do not look washed out or muddy.
• Greys don't have to be grey: tinting greys slightly toward a hue (cool or warm) makes an interface feel more intentional than pure neutral grey.

Accessibility fits the same toolkit: you can hit contrast requirements without ugly color by flipping to dark text on a light tint, or rotating hue and lightness rather than just darkening, and you should never rely on color alone to convey meaning, for colorblind users.

For a PM, the lesson is to invest in a real color system in the design tokens. A predefined palette with proper shades and accessible contrast turns color from a recurring argument into a solved, reusable foundation the whole product draws on.

Creating Depth

Flat interfaces often feel lifeless, and the fix is depth done with discipline. The governing principle is to emulate a single, consistent light source, conventionally from above, so shadows and highlights all agree.

How depth actually works

• Emulate a light source: raised elements get a subtly lighter top edge and a shadow below, as if lit from overhead.
• Use shadows to convey elevation: small tight shadows read as barely raised, large soft shadows read as floating high, so shadow size communicates how "close" an element is.
• Shadows can have two parts: combining a larger, softer ambient shadow with a tighter, darker direct shadow looks far more realistic than a single shadow.
• Even flat designs can have depth: layering solid shades of the same color, lighter on top, darker beneath, creates hierarchy without heavy shadows.

Overlapping elements is another cheap way to create layers, letting a card sit partly over an image or another panel to signal that one thing is above another. Depth, used consistently, guides the eye and signals interactivity.

The PM learning is that consistent elevation is a usability signal, not just decoration. Standardizing a small set of shadow "elevations" in the design system tells users what floats, what is clickable, and what sits behind, reinforcing hierarchy across the product.

Working with Images

Images can lift a design or wreck it, and the difference is usually control. Great photos elevate an interface, while amateur or inconsistent images undermine an otherwise clean design, so image quality is a design decision, not an afterthought.

Keeping images under control

• Text on images needs consistent contrast: add an overlay, lower the image contrast, apply a subtle text shadow, or place text on a solid scrim so it stays legible over any photo.
• Everything has a preferred size: do not blow up small icons, which look crude enlarged; instead place a small icon inside a larger shaped background.
• Don't scale screenshots past legibility: shrinking a full screenshot to fit makes it an unreadable smudge; crop or use a simplified version instead.
• Control the background and beware user-uploaded content: constrain unpredictable images with a fixed container, neutral background, and subtle border so they cannot break the layout.

User-generated images are the hidden trap. Because you cannot control what people upload, you design the frame, not the picture: fixed aspect ratios, a background behind transparent images, and a faint inner border keep even the worst upload looking contained.

For a PM, the takeaway is to design defensively around real-world content. Assuming perfect marketing photos in mockups but shipping a product full of messy user uploads is a common gap; the polished version plans for the ugly image from the start.

Finishing Touches

The gap between "fine" and "polished" is a collection of small details most teams skip. This chapter is a grab bag of them, each cheap on its own but collectively the difference between amateur and professional.

The details that finish a design

• Supercharge the defaults: replace plain default bullets, checkboxes, blockquotes, and links with intentional styled versions.
• Add color with accent borders: a colored top border on a card or a side border on an alert adds personality with almost no effort.
• Decorate your backgrounds: a subtle gradient, faint pattern, or simple geometric shape turns a flat background into something considered.
• Use fewer borders: separate elements with spacing, background color, or shadow instead of boxing everything in lines, which quickly looks busy.
• Don't overlook empty states: design the zero-data screen deliberately, since it is often a user's very first impression of a feature.

The recurring theme is intentionality: default browser styling and reflexive borders make a product look unfinished, and replacing them with deliberate choices signals care. "Think outside the box," literally, by not wrapping every element in a bordered card.

The PM learning is to treat empty states, defaults, and edge cases as first-class scope, not polish to be cut under deadline. These are exactly the moments users judge quality, and they are usually the first things dropped when time runs short.

Leveling Up

The closing chapter is about how to keep improving after the rules. Design taste grows the same way any craft does: through deliberate study and repetition, not waiting for inspiration to strike.

The most useful habit is to steal like an artist: find interfaces you admire and analyze exactly why they work, then try to recreate them. Reverse-engineering good design teaches the specific decisions, spacing, hierarchy, color, behind a polished result far better than passive admiration.

Building a personal library of inspiration, and returning to it when stuck, turns vague "make it look good" into concrete reference. Over time you internalize the patterns and start making the right calls quickly, which is what looks like innate taste from the outside.

For a PM, the lesson is that design literacy is learnable and worth building. Studying why competitor and best-in-class interfaces work makes you a sharper design partner, better able to critique specifically and to recognize when a design is genuinely finished versus merely done.

The Entire Book in One Framework

The whole book makes one promise: polished visual design is a system of concrete rules, not a gift. Start with a feature in low fidelity, build clear hierarchy with weight and color, and let defined systems, a spacing scale, a type scale, a full color palette, replace a thousand arbitrary choices.

From there, depth from a consistent light source, generous whitespace, controlled images, and attention to the unglamorous details, empty states, defaults, user content, do the finishing work. None of it requires talent; all of it requires knowing the rule and applying it.

Refactoring UI is not "have an eye for design." It is proof that most of what looks like taste is really a set of teachable rules, and that a developer who applies them deliberately can build interfaces indistinguishable from a designer's.

10 Most Important Takeaways

• Good design is learnable rules, not innate talent.
• Start with a specific feature in grayscale, not a layout in full color.
• Build hierarchy with font weight and color first, size second; emphasize by de-emphasizing.
• Define systems up front: a spacing scale, a type scale, and eight to ten shades per color.
• Start with too much whitespace, then tighten; you don't have to fill the screen.
• Keep line length around 45 to 75 characters and align long text left.
• Reason about color in HSL, and boost saturation at the light and dark extremes.
• Create depth from one consistent light source; shadow size signals elevation.
• Control images, especially user uploads, with fixed containers and backgrounds.
• Sweat the finishing touches, empty states, defaults, fewer borders, because that is where polish lives.

The deepest idea is that professional design is mostly the accumulation of small, correct, unglamorous decisions applied consistently. What reads as an "eye for design" is really the habit of never leaving a value to chance, choosing every space, size, shade, and shadow from a system, which is something any disciplined builder can learn to do.