
Ask HN: How do you do design-review at your company? - samjewell
We&#x27;re a product team of 6, in a company of 20 people. We&#x27;ve tried to implement design-review to be like code-review, but we&#x27;re having limited success. We&#x27;ve talked about:<p>- Reviewing &quot;every line&quot; of a design
- Assigning designs to named reviewers, who should request changes, and then approve
- A checklist of criteria the design must meet<p>Problems we&#x27;ve hit:
- Design review is missed entirely before coding starts.
- Reviewer barely scratches the surface, and misses huge issues
- Most tickets&#x2F;designs don&#x27;t say whether review was passed or not<p>How do you handle this at your company? What tools&#x2F;processes do you use?
======
samjewell
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

------
mead5432
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.

------
zer00eyz
> "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.

------
Ryanb58
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.

------
simulo
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.

------
fapi1974
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...

