How to conduct an effective design review

Many organisations already have processes in place for conducting design reviews. Some use on-line change and issue tracking tools as part of the process; others a paper based. Some convene meetings, others circulate documents. Good processes allow some latitude for different types of designs at different maturity levels. If there is an organisational process in place already, use it.

Generally it's a good idea to circulate the review material to the reviewers a week in advance of the review to give them time to read it, then get everyone together to talk through the issues raised in a meeting. If a physical meeting is impossible or undesirable, it can also be done by teleconference or webcam; although it's hard to beat the feeling of actually being together when working on a team. Review meetings should go no longer than 2 hours, or brain-fade sets in and productivity drops. This generally works well with reviewers' schedule, since a morning and an afternoon review meeting still leaves time to keep on top of email and other tasks during the day.

Some development processes have formal design reviews which last for a week or more, spaced every year or two during long projects. I prefer making review an integral part of the process, and reviewing each part of the design when it is at the appropriate maturity level, which means before too much dependent work has been done using the information. The formal design reviews then become meta-reviews at which the review status of each major part of the design is clarified, and the major issues presented to senior management.

During the review meeting, start on page 1 and working through to the end. Good design material is “front focussed” and “top down”, in which case this approach naturally tends to encounter the most important issues first. As each issue is resolved, the designer notes down what needs to change in the design. Attention during the meeting should be paid to issues in accordance to their relative importance. Spelling errors and typos should take the least time, if mentioned at all; often these can be dealt with off-line and skipped altogether in the meeting.

In cases where one or more of the reviewers have not read the material under review, it may be necessary to have the designer actually read through the document out loud. This generally works quite quickly when there are no issues to discuss. Ideally it's best to establish a culture where everyone prepares for reviews by reading the material because they see “other people's” reviews as central to the success of their own project.

I suggest a slightly different approach to code reviews, although many of the same principles apply.

---

Social Bookmark this page: