I often wonder if the idea of user needs has become somewhat misunderstood when it comes to designing government services for citizens.
There's no user need for that
I was first alerted to this a few years ago when I was working on the proof of concept for what I was calling the Budgetron (a piece of work I never got around to finishing, that's had a few similar iterations using the same basic concept of moving sliders up and down that I've similarly never really got around to finishing…), and I thought it would be handy if as well as the tool linking to the budget for that specific year, it would also help the long term usefulness of the tool if it could link to the most recent budget, whatever year it was. The obvious way to do that in the context of a web content management system is for there to be a short url /budget which is always set to point to this year's budget. In any capable CMS it would take less time and effort for an administrator to do that than it would take for somebody to complete the paperwork asking the administrator to do it. It seemed like a simple, reasonable, and sensible request, so I was quite surprised on asking for it of the GDS Twitter account that not only did they say no, they said no in such a tone which suggested there was something wrong with me for even daring to request it - a debate ensued, which basically boiled down to their stance being 'we won't do this because there is no user need for it'. The fact that there was I, a user, expressing it as a need for a piece of work I was doing, and also in the debate expressing other examples of other users who might also have a similar need for it, didn't seem to count for anything.
Their website, of course, they get to decide what they will and won't implement according to their own internal design system, but it did seem something of a shame that what seemed like a simple, sensible request was so forcefully dismissed.
The London Transport example
Not long after this I was at UKGovCamp, the annual unconference event for people who are interested in how the public sector does digital stuff. I was in a session, and recounting this story a friend responded with the example of London Transport - nobody in the early 2000s was particularly clamouring for contactless ticketing options on the London Underground, and then the Oystercard was introduced. Can you imagine London without the Oystercard now? Once it was mainstream and fully understood in London, everybody wanted an Oystercard for their town.
My point here is that when we talk about user needs, we should be careful not to fall into the trap of restricting our thinking to only that which the user is explicitly asking for - if no user is explicitly asking for contactless ticketing for public transport, that does not mean it does not exist as a user need.
The chain of user needs which ultimately led to contactless ticketing on public tranport might have flowed like this:
As a passenger on public transport,
I need a ticket,
So that I can pass through the barrier.
This is the core, and frankly boring need.
As a passenger on public transport,
I need some prepaid tickets,
So that I don't have to queue up at the window every time.
This led to those funny little hexagonal tickets you could buy from machines at bus stops in London for the buses, and in other towns and cities it led to day tickets which you could buy in packs of five or 10 and scratch the date off for the day you're travelling.
As a passenger on public transport,
I need a durable product, that I can top up electronically and wave at the barrier,
So that I have more options for paying in advance and can pass through the barrier more quickly.
We're getting there; this essentially is the need which expresses what the Oystercard is for.
But wait!
As a passenger on public transport,
I need a durable product, that contains money, that I can wave at the barrier,
So that I don't have to worry about topping up.
We've moved on from the Oystercard now - we can pay for our travel just with our contactless bank cards, or indeed watches and phones.
But wait!
Is this actually the user need which truly represents what users want when travelling around on public transport?
Bread and roses
Waving your bank card at the railway station barrier before it allows you to pass through represents what I'm henceforth going to call a bread user need; all the user stories expressed above and their associated solutions fulfil basic requirements of demonstrating to the barrier that you have paid for a ticket to allow you to get on to a train.
Too often when documenting our user stories and user needs, we stop at the bread. I say don't just give us bread, give us roses too.
What actually is the real user need here? Or rather, what goes beyond the user need and gets towards the user aspiration? Or rather, having established the bread user needs, what might the roses user needs be?
As a passenger on public transport,
I need the travel validation system to already know I have a permit to travel as I transit through the station,
So that my journey from street to platform to train to platform to street is as smooth as possible.
All the previous user stories and accompanying solutions are included in this user story, but whilst those user stories end with the solutions they beget, this user story still gives us plenty of places to go. We have delivered pre-paid paper tickets, we have delivered a pre-paid electronic ticket, and we have delivered the ability to use your bank card as a ticket. Each of those solutions are steps along the way to making the user's journey through the public transport system as smooth as possible, and as technology and imagination develops we can continue to deliver more steps to achieve the ultimate goal.
You've been at railway stations at busy times when a big train has just pulled in, I'm sure. Even though everybody has their paper tickets and their bank cards and their watches at the ready, it's still quite slow progressing through the barriers at this time. This, of course, is because the barriers are closed, and they open individually for a person passing through, and then close again.
Making it smooth
And yet, even though a rhetorical 99% of the people passing through those barriers have valid tickets to do so, the process of passing through them, the system for letting people transit between the street and the train is predicated on an assumption that 0% of the people have valid tickets - thus creating a bottleneck at busy times, especially when at least 10% of those 99% of people who do have valid tickets have glitches with them in some shape or form.
So that my journey from street to platform to train to platform to street is as smooth as possible.
What if rather than issuing users with ticketing which has to be placed in close proximity to the reader, we introduce the option of electronic ticketing which has a wider field of view? I used to work in a building where the doors to the private area opened automatically as we approached them, triggered by the presence of the RFID device as part of our ID cards, we didn't have to wave anything at a reader, it just worked.
What if rather than having gate doors which are shut which take time to open to let the person through and then close immediately after, we replaced them with turnstiles which simply unlock for the person with the validated ticket, allowing them to keep moving rather than having to stop?
But since 99% of people passing through ticket barriers have tickets anyway, what if instead of the system being one of defaulting to gates, or barriers, or whatever which by default are closed and cause a delay to those passengers, we create a travel validation system which by default is open, allowing passengers to pass freely - as smoothly as possible - which only (safely) closes when an unvalidated passenger tries to pass through?
Now to be clear, this post isn't a post about fixing public transport (it'd be nice if somebody reading happens to work in the Public Transport Digital Service and is prompted to bring it up with management, though…), my point here is that when we're gathering the requirements for our own new or upgraded digital services, documenting the user needs and writing the user stories, we should continue to work past the obvious bread needs and keep working on determining the roses needs; we should remember what Henry Ford apparently didn't actually say about what most of his customers would have wanted (faster horses) in our user stories, leaving space to create better solutions - whether that's now as part of this round of development or deferred as an avenue for future further development - than the obvious solution which fulfils the obvious need. We should think beyond the user needs, and anticipate what the possible user aspirations are when specifying, designing, and building our services.