A Gripe About Users? You! Out of the UX club! Now!

To be clear, this is not really griping about users… but is instead a gripe about the way that businesses handle contact with users, and the way that they research and prioritize future work.  The users are merely the intermediary in this particular gripe.

To clarify further, I’m not talking about the kind of software that you’re generally familiar with, like MS Word, Google Chrome or Adobe Photoshop…  I’m talking about the kind of software that most of you will probably never see.  Enterprise software.  Software bought by businesses, rather than by people.  Software used by interchangeable cogs in corporate machines, rather than by people (or, given how the software works, that’s how it often seems).

So… what’s the gripe?

Well, I’m afraid I’m going to be a bit long-winded about explaining it, and start by explaining a couple of other things first.  Things that relate to how users complain, where they do so, and what happens as a result.

First, users complain when things don’t work or when things crash.  In these cases, users complain in the form of support requests or helpdesk tickets.  This results in bugs or defects (or whatever the company calls them) being raised in whatever tools are used for such things.  Usually there’s an urgency based on how quickly a fix would be needed and a severity based on what the impact of the problem is.  This is good and proper, and results in work to rectify the problems being scheduled and fixes released in some way.

Second, users complain when functionality they want just isn’t present.  In these cases, users complain in the form of an RFE  – a Request For Enhancement.  This will go through a process to see if enough users want it to justify the development time, and then it’ll be entered into an appropriate work scheduling tool, with a priority based on how many users want it and a “size” based on how many person-hours it’ll need.  This is good and proper, and results in work being done where there’s an appropriate amount of demand.

Thirdly, users complain when a piece of software works, but in an obtuse, counterintuitive, unresponsive or otherwise hostile manner.  In these cases, users respond by grumbling a bit and maybe swearing a little.  Or a lot.  Occasionally, they’ll raise a bug too, but it’ll get logged as low priority because, when it boils down to it, the user managed to get the job done.  Or they’ll raise an RFE… but it’s unlikely to get prioritized because the feature already exists.  As a result, pretty much nothing will get done.

What does this mean?

This all means that users learn how things work, and so stop bothering to complain about the painful stuff unless it’s the software equivalent of a leg falling off.  We never get to hear about pain, or about early symptoms… only about the moment that the patient fell over and died.

Obviously, this makes addressing the non-fatal problems a little more awkward.

Surely user testing is the answer?

Sure, it helps.  But only if the problems that are found can get prioritized and get some development time allocated to them.  What tends to happen is that the problems get identified, and then get logged as bugs or RFEs, which promptly get prioritized exactly as explained above.

If you do user testing, you create an expectation with those users that things will improve.  If you then don’t act on what you find, you’ve failed to deliver on an expectation, and that’s bad.

So how do you get anything done?

As you might have guessed, a large chunk of my professional life is spent around those third types of complaints.  So I’m pretty familiar with the “we agree it’s a complete dog, but we’ve got more important things to do than fix it” answer.  It can, on occasion, be a touch demoralizing.

So you have to find other ways to get work done.  Ways to sneak it in under the radar.  Like keeping a record of tweaks you want to make in a part of the UI and sneaking them in next time something else is being done in that area.  A bug in an area with ropey UI?  Fix the bug and tweak the UI at the same time – commit it all at once.  A bit of new development that requires some new UI?  Where’s the jump-off point that leads to it, and can we rework that jump-off point at the same time?  Can we push the work back up the navigation architecture to the layer above and sneak some extra changes in at the same time?

The problem with sneaking work in like this is with QA (Quality Assurance).  If you’re stretching development work beyond it’s original scope, you’re also stretching them – probably even further.  By taking slightly longer to develop something slightly better, you’re invariably squeezeing your testing time further and putting more load on that department.

A trivial change in the UI has to be tested in many environments, and with many different kinds of input – both good and bad. The load a UI change puts on a QA department can be exponentially greater than the load it puts on development.  If it’s extra work being squeezed in to improve the user experience… that’s work that QA may not have budgeted for, and so it makes things late and gives UX a bad reputation for delaying things.

What needs to change?

I think we need a new model for handling the third type of user complaint that I mentioned above, or we need to adjust the criteria for prioritizing them.  The problem is that we’ve spent so long conditioning users to an environment where it’s not worth complaining about mere pain – only about the aforementioned “limb dropping off”.  They’ve become so used to nothing being done about things being cumbersome and awkward that they’ll suffer in silence rather than complaining.

So two things need to change:

  1. As mentioned above, software companies need to make a viable route for handling “this works, but is like crawling through barbed wire” issues.
  2. Software companies need to then prioritize those issues and allocate development resources to them.

When those two things happen, UI developers and User Experience professionals may start to lose some of their reputation as interfering troublemakers.  Until then, we’ll probably have to keep sneaking work in under the radar, making everything late in the process like the meddling troublemakers we have to be.