Blog

5 Tips for Conducting a Software Design Review

Here’s another of my answers on Quora:

I assume you’re talking about internal cross-functional review meetings, not expert heuristic reviews, brainstorming sessions, design studio workshops, or presentations to clients. In this kind of meeting, you have some sort of design specification or prototype and are seeking team feedback and possibly signoff. I’ll talk about user experience design reviews because that’s what I know best.

 

General Logistics

– Aim for 2 hours maximum per meeting, with up to 2 meetings per day.
– Start the meeting by recapping requirements, product goals, or some other form of problem statement.
– Aim to cover everything twice: A very quick run-through of the whole spec to get the big picture, and then slowly through each page.
– If possible, make your quick run-through describe functionality in terms of user tasks. Introduce context scenarios and explain how your design would be used in those scenarios.

 

Purpose of the Meeting

– Do say what kind of feedback you’re hoping to get out of the meeting. Typically this will be to assess that the spec is clear, that the design meets requirements, and that it is feasible to implement. Your guidelines will be ignored though, and I’ve found that it’s usually faster to just address whatever comments come up than to make a big deal about whether they are the right kind of comment.

– Your priority should be to understand objections and questions, not necessarily to answer them. People will come up with questions you haven’t thought about and “helpful” suggestions that barely make sense. It’s OK to note them and look into the issue after the meeting when you’ll have time to carefully craft a diplomatic reply.

 

Chairing and Note-Taking

– As a designer, never try to chair your own design reviews. Always have a chairperson whose job is to keep order in the meeting, make sure everyone has a fair chance to be heard, and keep the meeting moving along in a productive direction. This is a hard role to fill because the person should be seen as neutral, but must know the project well enough to fully understand the conversation. Having an effective design review chairperson can make the difference between a project that completes in a reasonable time and a project that everyone wants to quit.

– You, the designer, should take notes on the feedback and decisions for your design, & circulate your notes promptly after the meeting. Bring a printout of your design spec to write notes on, and don’t be afraid to ask the meeting to pause for a minute or two while you catch up on notes. I find that it’s best for the project manager to take notes on action items that arise for people other than the designer, such as technical issues that need investigating by developers.

– Keep three running lists: “Questions for management”, “Questions for users”, and “Parking lot (interesting ideas that we won’t pursue at this time)”.

Listen graciously and thank everyone for their input. People always want to leave a meeting with the feeling that they were listened to and understood.

 

Leave a Comment

Your email address will not be published.