We all know about a widespread practice of code review between developers. Are there any companies left without it? Guess not; evidently that’s a must-have.
Most design teams I worked with also have a similar design review practice: before presenting the new UI design to me (the manager) they either must undergo art director/head designer’s review or present and discuss it with the whole design team or group. Or both: public discussion and art director’s review.
Also frequently developer teams show their implemented interfaces to designers before releasing the code to production for last-minute corrections.
What I found very useful is to ask developers to review the designs before those are considered final and moved to development. So the cycle gets complete:
- designers review other designers before completing the design stage
- (this is the new stage) developers review the designs before beginning implementation
- developers review other developers’ code before shipping/merging designers review the new UI (not the code, obviously) before release
Developers’ review of the design will help to ask important questions before investing any resources in code:
- is this design at all possible to implement? Discuss the existing legacy, frameworks’ limitations, availability of data designed to fill the interfaces, potential trade-offs like high load, whether other components of the system are compatible with the future features
- where may the difficulties appear? Discuss corner cases and how to work with them. This is the moment to check for ‘no network’, ‘download error’, ‘empty list’ screens and the like: progress bars, synchronous or asynchronous page loading, additional prompts how does the new design fit the product? Maybe something similar is already being resolved by other means
- what are the success metrics and how exactly the data will be gathered and analyzed? It is also important to discuss at the very beginning as sometimes simple metrics are not so simple to count
As you can see from the list of questions, in fact such review meeting is not just for developers to attend: it requires the whole product team, including QA, product management, DevOps, analytics, copywriters, marketing staff and whoever else will be involved. Full attendance will allow the team to prepare for their part of implementation process beforehand and thus save precious time to market.
I wouldn’t advise to combine this review meeting with the project presentation (where I as the manager present the new product/feature to the team, describe the goals and plans and show mockups/designs), as people usually need some time to look and think before coming up with ideas and doubts. Bot both these meetings (or conferences, or mail threads, or however team communications work in your environment) are the right place to ask questions and share insights.
The main idea here is: the earlier everybody sees what’s ahead, the better they will be prepared.
Latest comments (1)
Yes. You're also articulating a tenant of change management; you must first raise awareness before you can ever expect acceptance of a change.
One of our designers recently recorded a video and audio walk through of their design. The combination of them explaining things and some subtle editorials really helped me frame my follow-up questions.
That video walk through allowed each team member to watch asynchronously and begin assembling their thoughts. And from there we can have a more focused synchronous conversation; allowing introverts to think then speak and also providing a forum for extroverts to think out loud.