Putting the user back into the user story

I sometimes wonder why we bother using the term 'user' at all.

Before I started working on government services, the user was rarely considered in the terms many of us have now come to understand.

Yet for everything we've learned about the importance of testing a thing with the users of the thing, there is still a reliance on the user researcher to figure out what needs to be measured.

Testing the code

Developers and testers spend a lot of time considering how to verify code is doing the right thing.

Does X pass the correct data to Y and fire up page Z?

Yes. Great??? ??let's have pizza and beer.

Tests in the programming sense are binary passes and fails to tell us whether all those little ones and zeros are doing what they say on the tin. Code doesn't 'nearly' pass a test; either it does or it doesn't.

Agreed, the user need may be a simple matter of a button doing a thing rather than not doing a thing.

Does the sign-in button take the user to the correct page?

It does? Hurrah!

Still, it doesn't necessarily follow that the sign in experience was a good one for the user.

Testing the experience

When was the last time you composed a user story that asked??? ??quite literally??? ??what needs to be tested with users from their perspective?

That's what I thought you were going to say.

Again, this is where more traditional agile methods falls short of addressing the who and the why.

No amount of test acceptance criteria or unit tests can capture how the user will react to our assumptions about the thing we have built or are just about to build for them.

Be a researcher's best friend

Supporting user research goes beyond taking part in ethnographic interviews, observations sessions or usability labs.

We need to understand what's being measured in the first place, and why. The user story is the perfect vehicle for understanding the challenge the story sets out to address.

In writing the user story, it pays to clearly separate out test acceptance criteria from measurement questions.

Defining experience measurement questions within the body of the story itself can help the researcher formulate appropriate questions into their interview or usability test scripts.

If it works it works, right?

Wrong.

I was recently looking at a beta service I'd not come across before. At face value the public notice page provided a wealth of information, punctuated with many links to relevant information and related services.

The most crucial link??? ??a call to action??? ??was positioned so illogically that I missed content further down the page about stuff I needed to do or know before I did the thing.

While the link may have passed the test of directing the user to another page, it certainly didn't score highly on usability or content design.

By considering the impact on the user before the story was played I suspect very different design decisions would have been made.

??Is the user able to clearly identify the call to action??�

??Can the user spot the necessary information they need before starting??�

??Is the content ordered logically for the user??�

Can you see where this is going?

Question everything, assume nothing

We all have preconceived ideas if the thing will be right for the user. Bias and assumption are natural human behaviours??? ??but we should not be so arrogant as to believe that we always know what's best for users from their perspective.

Having the humility to test design assumptions and embrace rejection (if it happens) can only lead to better services for the people who will use them.

Even if the team have a high level of confidence in the usability of what they're delivering (that's why design patterns exist), it also pays to question whether different groups of users have different experiences.

Circling back to the service I mentioned earlier, it turned out that the call to action link (when tabbed to) caused screen-reader software to spawn a new page, thus preventing a visually impaired user accessing the 'before you start' content below.

One way of looking at it is to treat everything you build as a prototype. We are used to asking measurement questions when testing early concepts with users, so why stop just because something has moved past an alpha stage?

The next time you are involved in writing a user story with an impact on the user interface, stop to consider the user's perspective. Work with the researchers and designers to ask questions, don't just make assertions.