Design peer reviews to support our team growth

April 12, 2019 - 4 minutes read

I always hope to see my teammates collaborate more. Now that we are at a stage of faster growth, more fellow designers are going to join us and it felt like a good timing to push forward this all peer-review strategy.

It’s never too late.

We’ve been a team of 4 designers for the last 2 years, including 2 product / 2 visual designers. Collaboration & Review have been naturally there as soon as the team got 2 product designers, but it’s never been a thing across the entire team, probably due to the fact that some of our designers are working remotely, bringing communication issues. But to be honest this was just an excuse to delay something we could have implemented earlier..

Furthermore, now that the team gravitates around a common Design system, having a review strategy prior to push anything within this shared library definitely sounds like something we should have by now.

Peer Design Review?

No tricks, it’s about reviewing each other’s design outcomes. Simple, engineers have been doing this forever.

We aren’t reinventing the wheel, just using a method that will help us at different levels. To understand what’s at stake let’s go over the 5Ws to get what this means for designers to adopt such workflow:

Why do we need peer review?

To have an objective opinion on design decisions and outcomes;
To backup designer’s decisions and responsibilities by involving another expert in the process;
To secure a shared, inter-connected Design System that affects dozens of products;
To force ourselves into better collaboration and knowledge sharing;
To enhance the overall quality of our Design outcomes, of course.

Who can review or ask for a review?

Review naturally involves human subjectivity, which can bring more problem on top of the one we are trying to solve.. It is important that Reviewer and requester share the same expertise and level of understanding in order to get pertinent feedbacks;
Both must be part of the Design team, further review from PM or Engineers will happen anyways, but this specific peer design review have other purpose and a strong focus on Design.

How does it work?

By being as objective as possible, carrying an unbiased judgement;
By being open to critics, obviously; 🙃
Ideally by regrouping and going through the feedbacks in person after giving some time for the reviewer to go over what she/he needs to check and comment;
By securing some time every week in order to review each other’s work (in practice this is key, things won’t happen magically otherwise);

What are we reviewing?

Everything with a significant impact on either our system or a product;

A major update prior to be sent to Product team;
A new component, a new version of a component, a specific review prior to merge to our Design System;
A new concept or strategic review at early stage;

When is the right time?

At the final stage of a Design iteration, regardless the degree of refinement (strategic/concept or specific/product levels);
Prior to share a significant update outside of the team (PM, Devs, PR, Partner…);

(Hidden) Expectations

We started peer reviews for many good reasons listed above, but there are also a couple of other things I expect to see through this review process.

Knowledge sharing should naturally influence our team balance. Collaboration will trigger communication which hopefully should also bring designers to share their process, findings and good practices. 🤞

Faster Production should also be seen in the long run as we are rising issues earlier in the Design process. This potentially can reduce partner’s feedbacks which are much more difficult and time consuming to fix as it usually involves more communication and people in the loop.

Team bonding, of course.. is one expected outcome in the long run. After understanding that critics are always positive insights and that taking time to help another teammate is a pretty rewarding process too.