The notion of digital systems being built around what people say they actually need, rather than technocratic dogma, is a very good principle. It avoids the creation of digital white elephants, or systems that are out of date before they process their first byte. Hence the concept of the 'user' as a central part of the service, and the 'user need' which defines how the service ought to be designed.
When the Government Digital Service was set up, as disruptive in its approach as the technology it often favoured, government suddenly realigned itself with the gospel according to agile and the user was king. We needed the adjustment, but like all pendulum swings it can be taken too far, or dealt with in too simplistic a manner. It is also worth noting that there is nothing new about the concept of giving the customer what they want. Since the late 1990's PRINCE2 methodology (itself a synthesis of previous good practices) has preached that good project delivery relies on defining customer expectations at the start. Of course it was Steve Jobs who said that the customer does not know what they want until Apple invents it!
The methodology of user focused design also falls over when it loses sight of its initial radicalism and gets too focused on doctrine (again). I'm afraid it is human nature. It was the theologian, D Vance Havner who, when describing the evolution of religious movements coined the idea of the 'Man, Movement, Machine, Monument' cycle. The original radicalism, becomes the new norm and is then zealously defended by its acolytes, despite clearly being obsolete.
I am not saying the idea of the user/user need is obsolete, but we are in danger of losing our way again unless we consciously take a step back and review how we approach identifying the user and the user need in our systems. I have some experience of tech professionals holding up the totem of the sacred user need to bulldoze through substandard, even lawfully risky, services; precisely the opposite of what is intended.
For example: a certain technology programme developed a new single platform that provided its customers with a secure environment for each of its customers. This allowed each customer organisation to control and protect their own information but share it easily with any other organisation using the platform through link sharing. So far so good. However, the tech folk then wanted to set up a chat service, which - to cut a long story short - exposed every customer on the platform to a breach of data protection law. When I pointed this out, I was told that the user need demanded it, as if that was justification enough to ignore legal requirements, that the law and I should stop standing in the way of progress!
The following story (and I have many other examples) exposes some common blind spots:
1) The user can too often be thought of in very simplistic terms as a person sitting in front of a screen writing documents and emails, but everyone who has an interest in the process is a user. We need to consider the inter-connectedness of people and processes.
2) The user need can all too often be narrowly defined as what the person (sitting in front of the screen) wants/needs to do a task easily. Being compliant with the law is also a user need, even if it is one that the user themselves may know nothing about. We need to think about cause and effect, not just in straight lines from a to b.
3) Both user and user need are often considered in purely transactional terms: e.g. 'I need to be able to move x from a to b to achieve corporate happiness'. But it's no good if a financial system suits the accountants well, but is painful and difficult for everyone else. We need to consider the user need in terms of its place in the sum of all its parts: one part of a whole system.
When designing systems to process data and information, we need a more three-dimensional mindset and holistic thinking: we should think about
Interconnections;
Cause and effect;
What the whole system is seeking to achieve;
The aggregated effects, the synthesis of change; and
Relationships, not just between people in the process now, but also in the past and the future.
This is part of what is known as Systems Thinking. The above examples are some of the more relevant concepts. Without this sort of approach taking us to the next level of radicalism all we will do is engrain the bad habits that are already there, and perhaps create some new ones. There's a lot of writing about systems thinking on the web, but here is a really accessible explanation with some great diagrams: https://medium.com/disruptive-design/tools-for-systems-thinkers-the-6-fundamental-concepts-of-systems-thinking-379cdac3dc6a
When I designed the information management processes and systems for Cabinet Office I knew I would have to ask people to do things they did not want to do, that would actually create a bit of effort for them. I knew that for them to accept what I was asking them to do, they would need to understand why it was necessary, what the benefits would be for them, what risks would materialise if we didn't succeed. There was a user need but it was unexpressed, unknown to the users themselves. Adopting a three dimensional approach to system design means that the system itself is agile, resilient, and sustainable, but vitally is still focused on the user and the user need. If you think this is odd, let me ask you this: before we had smartphones, who missed them? More about that in a future blog.
People who create information are connected via an invisible thread to the other people who will use it in the future. We do not know what the impact of it will be. The aggregate effect of the information being created at a particular period in time is generally unknown to the people creating it. I don't know how historians of the future will access the government's digital records, but I do know they will want to do so. This is why, when designing digital systems to manage information we need to think about the whole system, the users and the user need in all three dimensions.
So, will the real user please stand up!
