Thursday 23 May 2013

UX decision making the right way

I'm currently in a bit of a bad mood, unfortunately we've had feedback from client on some work and they want to make some changes. The changes aren't too major in scope, in fact they probably will only take about 10 minutes to implement due to the highly CSS-centric approach I've taken to build the Web App.

The problem isn't the complexity of the changes...it's why the changes are being made.

The web app (sorry, got to keep it vaguely abstract, no pics!) utilises a soft pastel colour scheme, to be complimentary to the brand's colour scheme, while also using some striking colours to help emphasise certain user actions. A stronger green colour is used when a section is complete, and a somewhat jarring orange is used when there is something that still needs attention.

These choices on their own are not good usability per se, but combined with clear and concise labelling that gives the user an indication of the intent of such a coloured object, and the use of icons to further emphasise such intent, the colours can form part of an ongoing subconscious indicator that will hopefully gravitate the user in to quicker choices for their navigation and an ease of finding their next task on the page.

To reinforce this colour scheme we also use the same colour scheme in the form validation that is done at login, and with strong visual cues on the homescreen of the web app.

The choice of how to use colour was very considered, and the relationships between colours too. The overall goal was to make the app pleasant to use throughout the day, but also to really highlight where there was an interaction or message that needed immediate attention.

The client has changed their mind from the initial advice of "This isn't customer facing, brand colours don't matter" (and I can't say whether this is just poor communication on behalf of the people I work with, or the client truly changing their stance) to "I want everything blue"

Now, I don't mind the idea that things should be blue. It's awkward if everything is a shade of blue, and we definitely lose some of that easy subconscious filtering of information that a striking colour affords. I wouldn't choose to do it, but if there was a good reason to do it I wouldn't stand in the way of it. Alas, it seems I dug too deep in requesting that someone requests information on why this change is desired, and now the elements that were orange, a clear contrast, have gone from being a lighter shade of blue than the other blues on the page, to actually grey.

GREY. The universal colour of inactive and disabled elements on the web. To add insult to injury we already use grey in specific use cases on the app...yeah...when the button or interactive element needs to be present but clearly defined as non-interactive!

I feel strongly that we have gone through the right process in deciding our colour scheme, unfortunately something has happened in our communication with the client that means a veto has come from upon high. Even more unfortunately there is no context or reason to that decision...and since they pay the money no-one is willing to challenge it.

I'm no expert, I try to make the best decisions I can with my colleagues...UX isn't a science. What it is, however, is testable. It's a shame that our relationship with the client appears to be such that we're going to miss out on the one opportunity to actually nail this particular disagreement to one side or the other...user testing!

We could easily give a sample of those that are intended to use the application, potentially even those that aren't, a set of tasks to do on one colour scheme, and a different sample the same tasks with a different colour scheme. We could record if there are any difficulties in the perception of the app, we could also measure the time taken to perform the tasks. Through then asking each sample to do the same again with the opposite colour scheme we can then also measure the change (if any) in productivity through the app compared to their first run. Productivity should improve as their experience with the app has grown, but we can check for differences in how usage speed changes, perhaps most importantly we can ask each group how it felt to move on to the second colour scheme.

If one is better we should have a clear indication through watching our users perform the tasks that the transition from one colour scheme to the second created greater comfort, while the other transition caused more confusion.

This kind of decision making should be standard when we make decisions that are challenged by a higher power for undisclosed reasons. If they are unwilling or unable to provide reasoning for their request then the only sane way to provide the best solution is to test both solutions and determine an optimal solution.

So why are we so afraid to do this? Is the client going to hate us for having proof that we're doing the most efficient thing with their app? It may seem stupid, but if a difference in colour scheme improves productivity by 5 seconds across a day, on a three day week, with 100 employees, that saves 21 hours worth of employee time through the year, or another three days of work. Not a significant saving perhaps in that example, but a saving none the less. Is the client going to be outraged at us providing this saving?

Be it fear of annoying the client, the want of an easy ride at work, misaligned loyalties from within your job description...how many bad decisions are being made in the process of capitulation that can and should be easily and amicably resolved to the best solution available, regardless of who came up with the best idea?

1 comment:

  1. "Just because your head is bleeding, doesn't mean you should stop bashing it against the brick wall".

    A great read Lee, thanks.

    ReplyDelete

Got something to say about my post? I'd love to hear it!

Try to keep it civil, I don't delete comments unless obliged to or feel the thread is getting too out of hand, so don't make me do it.