What I've Learned From Sitting in on Design Reviews

A few years ago, I started attending design reviews. Not because it was required, but because I kept running into a pattern: I'd build a feature exactly as specced, and then we'd discover in QA that the design didn't account for some technical constraint or edge case.

Sitting in design reviews early changed that. But it also taught me things about product thinking that I never would have learned from code alone.

What I Bring to a Design Review

As an engineer in a design review, my job isn't to critique the visual design. It's to raise questions the designer might not have considered:

Data states. The mockup shows a feed with 10 items. What does it look like with 0 items? With 1 item? With 1,000 items? What about loading states and error states?

Text overflow. The mockup shows "John Smith." What happens when the name is "Muhammad Abdullah Al-Rashid"? On a 5-inch phone in a right-to-left language?

Performance implications. "Can we add a blur effect behind this card?" Sure. But on low-end devices, real-time blur can drop the frame rate below 30fps. Let's discuss alternatives.

Animation feasibility. "The card should expand smoothly when tapped." What does "smoothly" mean? 200ms? 400ms? What easing curve? Does it need to be interruptible if the user taps again mid-animation?

These aren't nitpicks. They're the questions that, if left unanswered, become bugs or compromises during implementation.

What I've Learned From Designers

Intentionality

Good designers are intentional about every pixel. The spacing isn't arbitrary. The color choice has a reason. The hierarchy of information reflects what users need to see first.

I've started applying the same intentionality to code architecture. Every public API, every parameter name, every error message should be deliberate.

User Empathy

Designers think about the user's emotional state. "The user just failed to submit a form. They're frustrated. The error message should be helpful, not clinical."

Engineers often write error messages for other engineers: "HTTP 422: Unprocessable Entity." The user has no idea what that means. I now write error messages as if I'm helping a friend who called me confused.

Iteration

Designers expect to iterate. The first version isn't the final version. They show early work, get feedback, and refine. This is something engineers can learn from. Shipping a rough version, getting feedback, and improving is often faster than trying to build the perfect version on the first try.

Consistency Matters

Design systems exist because consistency reduces cognitive load. Users learn patterns. If every screen uses the same button style, the user knows what's tappable without thinking.

The same principle applies to code. If every repository follows the same pattern, every engineer knows how to read it without thinking. Consistency in code, like in design, is a form of respect for the reader.

The Reviews That Go Wrong

The worst design reviews I've attended were ones where engineers showed up to say "that's hard to build." Difficulty isn't the designer's problem. Feasibility constraints are useful feedback. Vague complaints about difficulty are not.

The best design reviews are conversations. "Here's the design. Here's what's tricky. Here are three ways we could handle the tricky part. Which one best preserves the design intent?"

That framing turns the review into a collaborative problem-solving session instead of a negotiation.

Why Every Engineer Should Attend

You don't have to attend every design review. But attending one per sprint for a few months will change how you think about the software you build. You'll start asking "what does the user see?" before "what does the code do?" That question ordering makes better software.