Ask HN: How do you do design-review at your company? | Hacker News Reader

Ask HN: How do you do design-review at your company?

14 pointssamjewell6 comments

We're a product team of 6, in a company of 20 people. We've tried to implement design-review to be like code-review, but we're having limited success. We've talked about:

- Reviewing "every line" of a design - Assigning designs to named reviewers, who should request changes, and then approve - A checklist of criteria the design must meet

Problems we've hit: - Design review is missed entirely before coding starts. - Reviewer barely scratches the surface, and misses huge issues - Most tickets/designs don't say whether review was passed or not

How do you handle this at your company? What tools/processes do you use?

View on HN

Thanks for the comments - they're already very useful.

To explain our process: We have a single designer, and when designs are reviewed it's usually by one of the devs

In the past we've done wireframes (Sketch) and interactive prototypes (InVision) We were frustrated that: 1. Lots of issues didn't surface until we started coding, when a raft of problems/edgecases would appear. 2. It was too easy to ignore existing UI components/css, so that each design featured new component styles and css.

For approx the last month our designer branches from `master` and hacks on top of that to create designs. He then creates a PR for design-review, alongside a spec with some screenshots in Dropbox Paper. Some advantages of this: 1. We get visual diffs from Percy, so we can see what's changed easily 2. We get versioning more easily built into designs (via git)

Then just before development we'll break a story down into tasks / subtasks and log those into JIRA for development. We have trouble with: 1. Letting the designer make changes once the subtasks are created and development has started (devs sometimes chasing a 'moving-target' spec) 2. Design not knowing the current state of development

On your designs, is it just that the user reviews some comps or is it something they can interact with (e.g. InVision)?

In my experience, a lot of issues around a design doesn't actually come out until someone uses it.

The other side is that one reason why code reviews work is that a developer who reviews the code has incentive to pay attention as a bug introduced here may be something they have to fix later. A few minutes now might save a few hours down the line. If your design is only being reviewed by product people and a huge problem is missed, it isn't the reviewer who has to fix it.

> "Reviewer barely scratches the surface, and misses huge issues"

Code reviewers sometimes miss huge issues. Automated testing, and load testing are designed to catch these issues, and even then sometimes things go live and turn into the flaming shit show that we have all lived through.

Review is only part of a full lifecycle.

- Formal usability: This is the big reset. A day or more of sitting behind a one way mirror with an impartal moderator taking users through your app. Your going to find that 7 people will magically bitch about the same thing. The thing you didn't notice, or thought was a bad idea.

- Informal usability: if your doing something risky, or questionable, don't be afraid to bring a few users into your office and run testing yourself. It isn't as clean as formal, but your going to get a lot of the same insights at a much lower cost.

- Testing and behavior tools: find some and integrate them into your site. User testing.com, Crazyegg and good old google analytics funnels are you friends. These are the "automated tests" of UI design, and you need to take time to do good analysis of the results.

You have to build up the tools an infrastructure around reviews, have the hard conversations, where legitimate critiques are taken seriously. It isn't just one process your putting in place its a whole culture change.

The company I am currently with is similar in size to yours, with the same ratio of product members vs others. We don't exactly do design reviews, instead, we have a very talented VP of Marketing. He is the one that approves or redesigns things that the product team creates. This is very helpful as he has been here since the beginning and always keeps up with the latest design and user experience trends.

Might look into having someone take ownership of the design on your team. I don't think this is the most efficient method of attack, but it does work while the company is small.

To be able to help, it would be great to get to know a bit more about your aims and the current process:

- What do you hope to achieve by the design-reviews? What would be, e.g., a huge issue which is missed?

- In which form are the designs delivered? (Photoshop files, Specs, Interactive Prototypes…)

From what you describe, it seems to me that people might be unsure about what they should do and how they know that they did a "good" review.

Not sure if this is what you are looking for, but both Usertesting.com and Userzoom.com seem to have relatively robust processes built in...

Reply on news.ycombinator.com