Love him or loathe him, Gordon Ramsay makes engaging television. He parachutes into a failing restaurant, insults the food, berates the owners and swears lavishly. Despite resistance from the owners, Ramsay’s combination of insight, intensity and insult eventually brings the most intractable of people to heel.

At least, until recently.

In Episode 82 he finally met his match: Samy and Amy Bouzaglo, the owners of Amy’s Baking Company in Phoenix, Arizona, refused to take any more criticism and sent Ramsay packing.

The show includes clips of Samy swearing at customers and Amy belittling an employee; and the owners’ more recent behaviour has been a masterclass in how not to use social media to defend your brand. Even though some scenes were probably staged for the cameras, what I found interesting was Ramsay’s comment about the owners: “They are incapable of listening,” he said.

But I wonder if this is any surprise, given Ramsay’s confrontational, win-lose, feedback style.

We can learn from Ramsay’s failure, and also from his previous successes. Here are 12 ways to provide constructive feedback to design teams so they listen to what you have to say.

G is for game plan

Before you report back your findings, prepare. Make sure you’ve fully understood the users of the system, the context they’ll be using it in and the business goals of the system. It would be embarrassing if you criticise a web app for not working properly on a mobile device, only for you to discover that the intended audience will use it exclusively on a desktop. Samy's early comment that "Chef Ramsay is coming to tell the people how good the food is here" underlines the importance of having the stakeholders on board with clear and accurate expectations up front. There was anxiety ahead of Ramsay's visit with lots of preparation: the owners clearly wanted to 'pass' the test. In the same way, as a UX consultant, no matter what you say, people will think they are being evaluated.

O is for objective

It’s not about what you like or dislike. Just because a web site doesn’t have infinite scroll or a mega menu or another design pattern that you’ve grown to love, it doesn’t mean that it’s wrong. It’s unlikely the system has been specifically designed for you, so be sure to frame your criticisms from the perspective of the system’s users, who may love a system that you personally hate.

R is for the root of the problem

To his credit, Ramsay doesn’t blame the waiter when the food is poor — he looks to see what’s going on in the kitchen. If you discover a large number of “obvious” user interface bloopers, this might point to the fact that the design team need to get a UI designer on board. Or perhaps the design team don’t know who they are designing for, so they need personas. Often the designers are constrained by what the project owner (or marketing team) has mandated, and that's where the true problem lies. So it's useful to learn the history and 'peel back the layers' to discover how a system came to be this way. Providing this level of strategic insight helps you go beyond the tactical and helps the design team plan a course of action.

D is for data

Usability evaluation has a great advantage over other evaluation methods, which at best provide guesses about what the user is thinking. This is because usability testing provides real user data. With real data, you can move the discussion from what designers think users want to how the data should be interpreted. You can achieve this by describing the two measures that will justify any design change: the task success rate and the time spent on the task.

O is for opening

When you open your presentation, begin by soliciting the views of the design team: what do they think are the strengths and weaknesses of the system? Simply saying “Before I start, what do you think needs improvement?” is a simple way to help the design team get in the right frame of mind. This helps the design team appreciate that it’s the system that’s being critiqued, and not them. This can help the team to feel less defensive.

N is for nice

"Be nice" is often missing from the Ramsay arsenal but in the show he did start out by praising the great cakes in the display, and the spotless kitchen. Begin by highlighting the strengths of the design: no matter how bad the system, there’s always something that you can compliment. People are more likely to listen to your criticisms if you first tell them something positive about what they’ve designed.

R is for resolution

Design teams don’t want problems — they want solutions. Designers are more likely to listen to your fault finding if you provide one or more potential fixes, ideally with a mock-up showing how the revised design should look. Gordon Ramsay often redesigns the menu, creates new dishes and even redecorates the restaurant. An easier approach in a design review is to simply provide a screenshot from another system that works in the way you recommend. This also helps demonstrate that you’re not “judging” the work, but you’re working with the design team to improve the system.

A is for actions to take immediately

Of course you need to provide long-term, strategic insight, but nothing beats a set of practical, pragmatic suggestions for what can be fixed quickly. This will lead to immediate improvements in the user experience and help you demonstrate the value of your insight. And this in turn makes it more likely that the design team will implement your longer-term suggestions.

M is for make a list

Usability evaluations typically uncover dozens of usability issues and it’s hard for non-experts to appreciate which ones need to be fixed first. So prioritise your findings. Does the problem occur on a red route? Is the problem difficult for users to overcome? Is the problem persistent? Use the answers to these questions to tease out the critical problems, and present these as a list of the “Top 6 issues” (or whatever) that need to be fixed urgently. An alternative is to prioritise the findings by estimating the return on investment of design changes: calculate the cost of fixing a usability issue and the cost of keeping it.

S is for specific examples

As your Math teacher used to say, show your working. Simply saying “the design is inconsistent” is likely to be taken as an opinion. Instead, provide explicit details of where design inconsistencies might lead users to make mistakes. When you report back, include specific examples, such as the participant’s verbatim comments, the specific route the participant took through the system, and marked-up screen shots.

A is for audience

Don’t be tempted to “report back” by throwing a report over the wall — or its virtual equivalent, sending it by email. It won’t get read. Instead, get face-to-face with the design team. Not only does this make it more likely that the design team will listen to your comments, this also gives you the opportunity to tailor your feedback. For example, designers want practical help on solving problems, so provide them with screen shots and suggested solutions. Managers are more concerned with how the issues relate to business problems, so identify management’s definition of “success” and address those concerns. That way you are more likely to obtain support and backing for your findings.

Y is for Yada yada yada

Don’t beat about the bush or describe the issue in a way that only experts will understand. Some UX professionals tend to have a poor habit of speaking their own language rather than using the language of business. For example, I constantly see heuristic evaluations that label problems by the heuristics a user interface violates instead of expressing problems in easily understandable terms. So be direct and cut the fluff — exactly how Gordon Ramsay behaves (although perhaps without the colourful language).

All your hard work in running a usability study will come to naught if the design team fail to make any changes to the system. The report back is your opportunity to make your findings stick. Remember the GORDON RAMSAY 12-point plan for your next design feedback session. And if you still get resistance, maybe then it's time to walk away.

Acknowledgements

Thanks to Philip Hodgson for useful comments on this article.