![\"image03\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/10\/image034.jpg\")
<\/p>\nGiving and receiving feedback is the proving ground for how well you\u2019re working with your developers.<\/p>\n
First off, how you communicate criticisms to each other, and to what degree these criticisms are implemented, is right away a marker of how well you collaborate together. On top of that you have feedback from others \u2013 most importantly the user. How you work together to prepare, conduct, and then analyze your usability tests is also telling of your compatibility. Luckily, neither of these aspects of feedback are set in stone, and you can make large leaps forward by using the best practices we\u2019ll list in this piece. <\/p>\n
Let\u2019s begin by discussing feedback within the team, then explore receiving feedback from users.<\/p>\n
Ideally, because of the same business goals, a designer and developer should be able to share and incorporate critique without incident, just another mechanism of a well-oiled machine. However, the reality is that we\u2019re all only human, and feelings and egos make sharing feedback a little messier. On the bright side, there are some simple strategies you can follow to ease communication and achieve the best results, all while remaining human.<\/p>\n
Apply the same principles of collaborating with stakeholders to your developers. For starters, this means treating them \u2013 and their opinions \u2013 with respect. You may not always see eye-to-eye, but you have to at least recognize that they may know things you don\u2019t. <\/p>\n
Take this a step further and apply the same strategies to developer interviews as you would if they were stakeholders. This means eliciting their \u201cgut feelings\u201d \u2013 What are the real opinions and thoughts on a project? How do they feel about it deep down? Pushing this line of questioning will yield a lot of usable criticism and maybe even inspire some creative solutions. <\/p>\n
<\/p>\n
Photo Credit: \u201cVFS Digital Design Mexico Intensive.\u201d <\/i>Vancouver Film School<\/i><\/a>. <\/i>Creative Commons<\/i><\/a>. <\/i><\/p>\n Another shortcut to building trust is to assure them some answers are off the record. Feedback is only as useful as it is honest. Alleviating the pressure of repercussions will allow your developer to speak candidly. This will open up a lot of doors about potential risks and genuine criticisms, both of which, while unpleasant, are what\u2019s best for the project.<\/p>\n For more details on how to gather the best feedback from stakeholders \u2013 and by extension, developers \u2013 read Kim Goodwin\u2019s insightful checklist of interview questions<\/a>, especially her recommendations for interviewing engineering stakeholders<\/a>. <\/p>\n As Goodwin suggests, you might find that some developers treat designers cautiously due to their previous experience of implementing near-impossible designs purely for the sake of originality. She makes an excellent point in recommending that instead of asking what\u2019s doable and what isn\u2019t, ask what is difficult and why. That slight tweaking of language can ease the minds of developers who might otherwise feel pressured to committing so early in the product development process. <\/p>\n Don\u2019t take smooth communication for granted. Expressing oneself to others is a skill that not everyone has, in which case it must be learned. We discuss this aspect of collaboration in detail in our Design Collaboration for Enterprises: Book I<\/a>, but we\u2019ll reiterate some key communication tactics here: <\/p>\n Feedback sessions should feel casual, not like an interrogation or a court hearing. The same people skills apply at a product team meeting as they do at a cocktail party. <\/p>\n How you explain your feedback \u2013 not just in phrasing, but in context \u2013 will affect how it\u2019s received. One basic rule is to avoid too many details or lingo that may confuse each other. Designers and developers oftentimes speak different languages, so try to express your ideas in layman\u2019s terms so everyone can understand. <\/p>\n Photo Credit: \u201cVFS Digital Design Mexico Intensive.\u201d <\/i>Vancouver Film School<\/i><\/a>. <\/i>Creative Commons<\/i><\/a>. <\/i><\/p>\n Another rule that\u2019s always helpful is to explain a point in the context of its implications on the user. <\/p>\n For example, you could waste your breath talking about how vertical alignment is off by a few pixels, but you\u2019d just risk having the gravity of the point being misunderstood. However, if you explain the same point as misalignment of content affecting readability (which affects time on site and therefore conversions), other stakeholders will start to pay attention. You\u2019ll find people\u2019s ears perk up once you connect design reasoning with business implications.<\/p>\n Each member of the team brings their own specific expertise, which means each member can provide feedback vital to the entire project. However, one person\u2019s feedback is by far more valuable than the rest: the user.<\/p>\n Collecting user feedback through usability testing and research is essential for the success of your product, no matter what you\u2019re building. The internal team members could sit and theorize about the best methodology all day, but none of it matters until it\u2019s verified by actual users. Whether for validation or new insights, it\u2019s best to get your answers straight from the source.<\/p>\n Collaboration must begin before the tests even start. As soon the plan for the test is completed, you should share it with your developer for their personal feedback. You\u2019re looking for their input in two areas:<\/p>\n Once it\u2019s time for the actual testing, why not invite the developer to join in (if the tests are moderated)? <\/p>\n This first-hand observation will help them understand the user more fully, and give them the chance to pose questions directly. Just remember to select a single \u201cleader\u201d beforehand, so you don\u2019t confuse the user with two competing authority figures. <\/p>\n If you\u2019re on a budget or strict timeline and can\u2019t do onsite tests, we\u2019ve compiled this list of our favorite usability testing tools for conducting remote user tests with multiple users simultaneously: <\/p>\n For more usability testing resources, check out this list on Crazy Egg<\/a>, and this general guide from Mashable<\/a>. <\/p>\n As a way to strengthen team bonds and produce better feedback, Google UX Researcher Tomer Sharon recommends creating a Rainbow Spreadsheet<\/a>, an observational sheet that lets multiple team-members record their interpretations of the test in real time.<\/p>\n Starting with a Google Docs spreadsheet listing each user, encourage your team (our yourself, if they\u2019re too busy) to write observations in the left hand side. As your team notices these concerns in your user, they need only to fill in the colors accordingly.<\/p>\n Photo Credit:<\/i> UXPin<\/i><\/a> for Yelp design usability testing based on exercise<\/i> suggested by Tomer Sharon<\/i><\/a><\/p>\n The colors make the results more comprehensible, especially to non-designers. The downside, though, is finding a time in which everyone can participate. If your company prefers a more formal report, you can always create one afterwards, using this as a summary document. <\/p>\n Once the testing is completed, properly collaborating on the results will allow everyone to process them more accurately. <\/p>\n The first step is allowing everyone access to the results. This means uploading all relevant documents \u2013 reports, graphs & figures, media such as videos of the tests, etc. \u2013 into a shared cloud folder if that\u2019s available. If not, a mass email or even photocopies will do.<\/p>\n The more differentiation in the viewpoints and expertise areas of those analyzing the data, the less bias the interpretation will have. As Alla Kholmatova explains<\/a>, one study of 44 usability practitioners showed how the presence of a second evaluator increased problem detection by 30-43%. <\/p>\n Collaboration doesn\u2019t end once the usability test results are compiled and analyzed. In an article for UXmatters<\/a>, Roy Man explains the practice of \u201cCheese Day,\u201d inspired by gaming leaders Blizzard. <\/p>\n \u201cCheese,\u201d by his definition, is any UX annoyance that\u2019s not quite a bug. Bugs are dealt with swiftly and without debate, whereas cheese is a little trickier and requires some thought. That\u2019s why he suggests holding a cheese day, where designers, developers, and everyone else on the product team gets together to take care of these outstanding issues. <\/p>\n Photo Credit: \u201cTeam Building & Leadership w LawNY…Rochester, NY. Canandaigua, NY (16).\u201d Michael Cardus<\/a>. Creative Commons<\/a>.<\/i><\/p>\n A month before the scheduled Cheese Day, create a open document in which anyone can record potential usability issues. On the actual cheese day, gather everyone and set to work correcting each item on the list. Since solutions aren\u2019t so black-and-white as they are with bugs, varying perspectives across the team will be most beneficial. <\/p>\n Remember to uphold the same feedback guidelines while discussing and critiquing potential solutions. <\/p>\n Collaboration extends beyond a mere division of labor. <\/p>\n Everyone doing their individual jobs may be the bare minimum, but the real benefits of collaboration appear when the team improves how they socialize together. In this sense, people skills may be just as helpful on the final product as technical skills. <\/p>\n Be respectful of others feelings when giving and receiving feedback, and work together when conducting usability research and beyond. Having the same goal isn\u2019t enough: collaborating to meet that goal will give you the best chance for success.<\/p>\n If you found this article useful, check out the free e-book UX Design Process Best Practices<\/a>. Learn the most useful UX processes and documents. Written based on our own experience in planning, designing, and testing UXPin in the past few years.<\/p>\n2. Encourage Proper Communication Skills<\/h3>\n
\n
3. Express Ideas in a Practical Way<\/h3>\n
![\"image01\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/10\/image015.jpg\")
<\/p>\nCollaborating with User Feedback<\/h2>\n
1. The Usability Testing Process<\/b><\/h3>\n
\n
![\"Startup](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/10\/people-office-group-team-2.jpg\")
<\/p>\n\n
2. Collaborative Testing Activity: Rainbow Spreadsheet<\/h3>\n
![\"image00\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/10\/image0010.png\")
<\/p>\n3. After the Testing<\/h3>\n
4. \u201cCheese Day\u201d<\/h3>\n
![\"image04\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/10\/image046.jpg\")
<\/p>\nTakeaway<\/h2>\n
![\"blog-book\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/10\/blog-book1.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"