5 reasons why being too positive can harm UX design

Tom Corser
Interactive Mind
Published in
3 min readMar 3, 2015

--

It feels great to be told that something we’ve done is good, has worked, or has achieved something. Everybody enjoys a pat on the back. In fact, positive reinforcement can be a far better strategy than negative chastisement in motivating a workforce (or training a dog, incidentally). We react very well to praise.

Not all praise is helpful, however.

Previously, while contracting on a high-profile service design project, I began to notice a culture of unwarranted back-slapping. Regular company update meetings gave way to hearty ‘aren’t we doing well?’ rhetoric. Particularly after a user testing feedback session — relatively shaky insights could be spun into great successes;

User clicked the intended button? High-five!

User progressed through the test flow mostly unaided? High-five!

User didn’t close the browser and upturn the desk in sheer frustration? High-five! Drinks all round!

The problem was, areas where the user experience might have been greatly improved were being forgotten amidst the ‘hurrah’s!’. Almost as if one positive insight could discount the two or three not-so-positive insights.

Designers remained satisfied they’d done the job well enough. Developers delighted in the fact that they wouldn’t have to revisit a feature because, well, ‘it worked, right?’. Product owners agreed to sign the work off and looked to the next feature. The team were losing perspective on what work was necessary to make the service the best it could be, because they were convinced it was great already.

Let’s be clear, identify successes. Just be careful that they don’t supplant any further questioning or become the foundation for sticking with a flawed hypothesis.

5 reasons why sugar-coating information will harm your design project:

1. It stifles learnings. ‘Three users proceeded through the flow without major issue!’ — but what about the other two who didn’t get it at all? And how do you define a ‘major issue’? Does the whole team understand that definition?

2. It can oversimplify analyses. If test insights are communicated as generalised statements — ‘it worked’ or ‘it went well’ or ‘they mostly got it’— we fail to call attention to the specific elements that made it work (or not, as the case may be).

3. It can be misused as a basis for inaction. If nothing has disrupted the status quo, why should the wider design and development team expend any further effort into making it even better?

4. It makes failure twice as hard to deal with. Too much baseless optimism can make it difficult for your team to accept any major change of course — including shutting down the project.

5. It fuels egos. Egos are out for themselves, not the betterment of UX. If they are told their design/ build was a success too often, they’ll become defensive and deny anyone that says otherwise.

There are more productive ways of communicating the status of the project or test results to the wider project team:

Remain neutral. Communicate successes, communicate failures. Don’t embellish either with unnecessary hyperbole and exaggeration. Encourage good work, but make sure it’s genuinely worthy as measured against design goals.

Be proportionate. Give some perspective to your feedback. Perhaps use a severity scale or traffic light system — red for ‘address immediately’, amber for ‘pay attention to it’, green for ‘passed’.

Be specific. Feedback on the efficacy of specific design elements and their actions, not the design or project as a whole. This will actually help to provide focus for improvement.

I get it. It’s easy to become so engaged in nurturing a project to fruition that we create the environment for it not to be questioned. In fact, more dangerously, we can set out to ‘prove how good it is’, subtly orchestrating user testing sessions to ‘validate’ what we already think about it. Reporting back to the team later on, we might cherry-pick small triumphs and mask less positive analyses to maintain morale — especially if the project has a lot at stake. This can actually be counter-productive. Balance your feedback.

--

--