Friday, November 16, 2012

Design Critique

I had the pleasure of participating in a design critique panel this week for a class at the University of Minnesota's School of Design. Seven groups of students presented their screen wireframes for a scheduling application for Emergency Medical Technician students.

There was a wide disparity in preparation and design artifacts presented. Some of the student groups had clearly thought through many possibilities, while some seemed to be gaining clarity on the scope of their effort. There were digital prototypes and pencil sketches, with varying degrees of fidelity.

What I learned from them:
  • There are some really creative, thoughtful designers coming up in the industry. It was fun to see the different approaches for the same problem.
  • Presentation preparation can really make the difference in acceptance of ideas. There were some great ideas that were not presented well, either visually or verbally, and the lack of preparation was a real drawback.
  • Some of the groups seemed collaborative, but several seemed to be struggling with consensus within the team about the best design approach. This is a real drawback in presentation, as well.
  • While I am a proponent of rough sketches (especially in the Agile world where I work), the people who had high-fidelity wireframes were often easier to understand and follow. It's always a trick to find the right level for the timing of the conversation. It may be that they were farther along in their thought process, as well, and therefore better able to convey the concept.
  • If you are designing for a specific platform, you need to understand design conventions of the platform.
  • The students were good at defending their choices. It's important to have a reason based on research, even if you change your design later because it doesn't test well.
  • A defense based on their own conversations with users would have been more compelling, but no one mentioned what they observed, or knowledge of the data, as being a reason for any design choice. Effective designs aren't based on heuristics alone; you need to understand the domain, users, and usage scenarios as deeply as you can.
  • If you don't take notes during a critique, it appears you don't value the input of the critic.
  • I would like to do design critique for a living. Wouldn't that be fun?