Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
User experience professionals often shy away from getting their work critiqued. Why? Perhaps it's because we are unfamiliar with the process or perhaps we are just used to working alone. The fact is, we create deliverables (information architecture, wireframes, requirements documents, discussion guides, findings reports, etc.) that can be improved. As a user experience professional who was trained as an industrial designer, I saw an opportunity to help introduce a traditional design-style critique into our team. This was not meant to replace the formal review process and mentorship program our team already practices, but rather to complement it by allowing other team members to provide feedback on work they may not have seen otherwise. It is time we evolve our processes to make sure that we are putting forth the best work and methodologies possible by adopting techniques from other industries and incorporating consistent critiques in our user experience teams.
There are many benefits to holding critiques. Fundamentally, critiques are an opportunity to improve both individually as a professional and collectively as a team. Having the input of others can help strengthen or provide better direction for the work, enhance team bonding, and become an educational opportunity for all parties involved regardless of level or experience.
Planning and executing a critique successfully does take a little bit of work. A critique is most effective when held frequently and consistently (e.g., once a week) and is focused on in-progress work. A critique can happen at a white board with rough sketches or in a conference room with high-fidelity wireframes.
Preparing for a Critique
It is necessary to do a bit of up-front work to ensure that the critique goes smoothly. This could include preparing a short description of the work you are showing (only provide valuable information that participants will need to know in order to provide relevant feedback). You should also prepare a few focal points or questions to help lead the discussion. Lastly, make sure that you have all the tools necessary such as a note book to take notes even if you are not presenting – you never know when feedback will be applicable to you.
Participating in a Critique
As a presenter, it is important to set the stage for the critique that you want. This is one of the most important steps you can take. If you do not set the stage, the conversation can take a route that is not helpful. If the conversation begins to veer in the wrong direction, you can pull it back on track by saying “This is all really helpful feedback. I’d like to direct your attention to this question …” Remember to stay positive – do not get defensive. Feedback is meant to make the work stronger and is not a reflection on you as a professional.
As a participant, it is important that you remember to focus on what the presenter has asked so that you provide valuable feedback. This is not a time to make decisions. It is a time to offer suggestions or alternative ways of thinking. It is also important that you stay positive as a participant to help the presenter feel comfortable showing their work. Lastly, do not use meaningless phrases, such as “make it more intuitive” – provide actionable feedback by expanding upon a point.
After a Critique
Remember, the critique is a learning opportunity for everyone involved. If there are any outstanding questions from feedback you heard, follow up with the participant. As you implement changes to your work, feel free to call a few colleagues over to have an informal critique. Regular critiques are a way of life for designers. Everyone improves when the group has the opportunity to provide feedback. It needs to be a way of life for UX professionals as well.
Published at DZone with permission of Josh Anderson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.