“Pain points”

rose-with-thorns-e1503969619357.jpg
“A pain point by any other name…”

“Pain points” is a UX term of art referring to steps in a process or workflow that users typically dislike, find problematic, or even seek to avoid or work around.

Basically all UX practitioners understand that this idiom doesn’t necessarily mean the user literally experiences pain, only that the user finds some aspect of the experience to be negative and, presumably, desirable to change or eliminate.

Pain points can of course be very serious, for example if an emergency worker has to spend an extra minute fidgeting with a tricky latch in order to access some life-saving piece of equipment.

But due to the nature of UX work, the vast majority of pain points identified in user workflows are trivial: they are sometimes little things that irk or inconvenience people (e.g. having to orient a key a certain way so it can be inserted into a lock), and other times they are problems most people are not even aware they have until there is a solution (e.g. many people say they did not realize being disconnected from the internet while out and about was a problem until they owned a smartphone).

Does the use of this dramatic-sounding phrase introduce or reinforce a bias on the part of the UX practitioner? Specifically, I am referring to a bias in which we are inclined to escalate the stated seriousness of problems, or to solve problems that did not need solving. I’m not sure whether this is happening; the names we give things are important and transformative—but sometimes they aren’t. The aforementioned escalation could be happening for plenty of other reasons, but this doesn’t rule out bias resulting from our language being one of them.

So, I often add scare quotes to the term “pain points” as a way to exercise caution and remind myself not to become biased.

Advertisements

Personae, then and now

The first personas I ever created were based on a template I inherited. I was really just filling in blanks, except I redid the graphical portions of it. The original graphics had vertical sliders to show levels of some discrete qualities of the users. I replaced these with horizontal sliders in order to downplay the relationship between those qualities, because at a glance it erroneously looked like the curves created by the array of sliders had meaning. I determined this was less of an issue with horizontal sliders.

On subsequent projects, I created new persona formats for increased scannability, graphics that were more direct and transparent, and content categories based around information I knew my team and I would want to refer back to. This turned into an ongoing internal challenge: the quest for a more useful persona, one that isn’t just a perfunctory artifact designed to be shown once on a slide in a presentation to stakeholders, but an actual tool the UX team will use throughout the development of the system.

To do this we had to consider what kinds of information about users we likely need at a glance 1 month, 3 months, 6 months, or 2 years into a project. Some information might be useful now but not later, or later but not now.  Because of the way personas tend to get used by the business, we leaned toward information that was immediately useful near the beginning of a project but made sure to fortify it with content that would continue to be useful later on as reminders of important high-level information.

That’s where we started to get into things like work culture and values. To be honest, the best way to represent that in something like a persona is a challenge I’m still thinking through and have ideas about. It’s something I’d like to continue to work on in upcoming projects.