Giving and receiving feedback is the proving ground for how well you’re working with your developers.
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 – 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’ll list in this piece.
Let’s begin by discussing feedback within the team, then explore receiving feedback from users.
Sharing Feedback With Developers
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’re 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.
1. Treat Developers Like Stakeholders
Apply the same principles of collaborating with stakeholders to your developers. For starters, this means treating them – and their opinions – with respect. You may not always see eye-to-eye, but you have to at least recognize that they may know things you don’t.
Take this a step further and apply the same strategies to developer interviews as you would if they were stakeholders. This means eliciting their “gut feelings” – 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.
Photo Credit: “VFS Digital Design Mexico Intensive.” Vancouver Film School. Creative Commons.
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’s best for the project.
For more details on how to gather the best feedback from stakeholders – and by extension, developers – read Kim Goodwin’s insightful checklist of interview questions, especially her recommendations for interviewing engineering stakeholders.
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’s doable and what isn’t, 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.
2. Encourage Proper Communication Skills
Don’t 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, but we’ll reiterate some key communication tactics here:
- Critiquing is a conversation, not a command – Critiques should be the start, not the end. Good feedback inspires conversations and possibly enables brainstorming. Allow both sides to exchange their opinions, and look for a common middle ground, if it’s available.
- Phrase feedback as a problem, not a solution – For example, “The ease-in animation doesn’t feel as smooth as it should, which can impact conversion rates since it detracts from the feeling of sophistication,” is a lot more constructive than something like, “Make the animation ease in at 400 ms, and use the exact colors in the prototype.” Perhaps there’s a technically nuanced issue that just arose during implementation, and phrasing feedback as a problem opens up a discussion that may satisfy design sensibility and feasibility.
- Probe with follow-up questions – To help developers articulate their feedback or pushback, try asking additional questions. The end goal is to hear honest opinions, but this doesn’t come naturally to some speakers. Dustin Curtis suggests asking three questions to accurately isolate the heart of the criticism. We’ve found his advice to be pretty realistic, since you don’t want to start playing the question game and just keep asking “Why?”
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.
3. Express Ideas in a Practical Way
How you explain your feedback – not just in phrasing, but in context – will affect how it’s 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’s terms so everyone can understand.
Photo Credit: “VFS Digital Design Mexico Intensive.” Vancouver Film School. Creative Commons.
Another rule that’s always helpful is to explain a point in the context of its implications on the user.
For example, you could waste your breath talking about how vertical alignment is off by a few pixels, but you’d 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’ll find people’s ears perk up once you connect design reasoning with business implications.
Collaborating with User Feedback
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’s feedback is by far more valuable than the rest: the user.
Collecting user feedback through usability testing and research is essential for the success of your product, no matter what you’re building. The internal team members could sit and theorize about the best methodology all day, but none of it matters until it’s verified by actual users. Whether for validation or new insights, it’s best to get your answers straight from the source.
1. The Usability Testing Process
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’re looking for their input in two areas:
- Suggestions on the existing plan – Have them review the plan for any potential improvements, especially in the phrasing of the tasks. At the very least, showing them the test beforehand will give them a deeper understanding of the core tasks the system must support.
- Target data previously missed – Developers may bring to light areas in which they need data, or at least would like some questions answered. Give them the opportunity to request certain data from the test before it’s already over.
Once it’s time for the actual testing, why not invite the developer to join in (if the tests are moderated)?
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 “leader” beforehand, so you don’t confuse the user with two competing authority figures.
If you’re on a budget or strict timeline and can’t do onsite tests, we’ve compiled this list of our favorite usability testing tools for conducting remote user tests with multiple users simultaneously:
For more usability testing resources, check out this list on Crazy Egg, and this general guide from Mashable.
2. Collaborative Testing Activity: Rainbow Spreadsheet
As a way to strengthen team bonds and produce better feedback, Google UX Researcher Tomer Sharon recommends creating a Rainbow Spreadsheet, an observational sheet that lets multiple team-members record their interpretations of the test in real time.
Starting with a Google Docs spreadsheet listing each user, encourage your team (our yourself, if they’re 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.
Photo Credit: UXPin for Yelp design usability testing based on exercise suggested by Tomer Sharon
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.
3. After the Testing
Once the testing is completed, properly collaborating on the results will allow everyone to process them more accurately.
The first step is allowing everyone access to the results. This means uploading all relevant documents – reports, graphs & figures, media such as videos of the tests, etc. – into a shared cloud folder if that’s available. If not, a mass email or even photocopies will do.
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, one study of 44 usability practitioners showed how the presence of a second evaluator increased problem detection by 30-43%.
4. “Cheese Day”
Collaboration doesn’t end once the usability test results are compiled and analyzed. In an article for UXmatters, Roy Man explains the practice of “Cheese Day,” inspired by gaming leaders Blizzard.
“Cheese,” by his definition, is any UX annoyance that’s not quite a bug. Bugs are dealt with swiftly and without debate, whereas cheese is a little trickier and requires some thought. That’s 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.
Photo Credit: “Team Building & Leadership w LawNY…Rochester, NY. Canandaigua, NY (16).” Michael Cardus. Creative Commons.
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’t so black-and-white as they are with bugs, varying perspectives across the team will be most beneficial.
Remember to uphold the same feedback guidelines while discussing and critiquing potential solutions.
Takeaway
Collaboration extends beyond a mere division of labor.
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.
Be respectful of others feelings when giving and receiving feedback, and work together when conducting usability research and beyond. Having the same goal isn’t enough: collaborating to meet that goal will give you the best chance for success.
If you found this article useful, check out the free e-book UX Design Process Best Practices. 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.
