In the UK the Government has sought to improve digital service design by focusing on users and their needs rather than more traditional requirements driven approaches. User research is at the heart of a project’s discovery or inception phase and follows through subsequent alpha and beta phases. The user researcher is a clear an distinct agile team role responsible for coordinating and planning multivariate experiments and presenting findings to feed into user interaction design and stories.
Agile user stories that adopt the common template of
As a <user role> I want <user goal> So that <user reason / benefit>
help capture user needs by stating the user’s goal and reason of each story. It seems easy to equate user need to user goal and satisfy user researcher’s suggestions.
There are a few traps that may trip you up though. Let’s consider a simple login service as many sites have them. If you are not using OAuth and need to enter a site username and password for authentication then you likely have a typical user story:
As a registered user I want to enter my credentials So that I can login to the service
User research adds some acceptance criteria:
SCENARIO User enters an incorrect password and attempts to login GIVEN user has entered an incorrect password AND user has entered a valid username WHEN user requests login THEN user is told their password is incorrect
And the site’s security users demand:
GIVEN user has entered a incorrect password AND user has entered a valid username WHEN user requests login THEN user is told their username or password is incorrect
It’s just a small difference but to a true user who may use the service infrequently or is logging in from a different device that does not remember credentials it’s a frustrating experience. Which is incorrect – username or password? The service must obey the security needs the penetration testers say or they won’t pass the system acceptance test. A hacker may be trying to find valid usernames and if they are told the truth about credentials they can harvest them easily.
So what’s missing here is a better way to capture the user needs and design a less frustrating user experience. Let’s start with the user stories:
As a registered user I want to know when my credentials are incorrect So that I can login to the service easily
Also we’ll include other users:
As security officer I want to hide knowledge of incorrect usernames or passwords So that hackers can't guess credentials easily
Or if you prefer one technique is to recognise and represent malicious users with stories as threats and design specific behaviour to counteract:
As a hacker I want to discover valid usernames So that I can use a registered user's account to gain access to the service
So now we can see there are three types of user with conflicting user needs. Unfortunately for the real user many web sites prioritise security user needs and don’t recognise or deal with the conflict. Cyber security is trump card.
Is there a better way? Let’s have another look at the login story to see where the problems lie.
As a registered user I want to know when my credentials are incorrect So that I can login to the service easily
From the real user’s perspective they have registered at some point and set up an account. They may or may not have entered the correct username / email address but they think the service should tell them if it’s wrong. Users may not realise that without a correct user name the service can’t validate the password although it’s obvious to the analyst and developers. User research can pick up on these aspects and lead to a better user story:
As a registered user I want the service to help me when my credentials are incorrect So that I can recover my username or password if I forget them
Here the user journey changes to scenarios that can help real users discover what they have done wrong. Instead of “You have entered an incorrect username or password” the service offers ways to retrieve forgotten username or password and by so doing establishes the persona rather than assuming any. Obviously this needs more effort and care to keep the security officer happy that no vulnerability is being introduced.
