At Unboxed, we are passionate about user centred design. But what is user centred development?
As its name suggests, user centred design involves users throughout every stage of the design process. Practitioners rely on prototyping, user research sessions and other techniques to find out directly from the end consumer what they need from the product and service. Often, multiple iterations take place, with frequent user testing at every stage.
One expression that is less commonly heard is ‘user-centred development’. As opposed to designers, software developers are often thought of as one stage removed from the end user, with their role limited to carrying out the instructions and ideas originated by their designer colleagues.
However, as I mentioned in an earlier blog post, all sorts of problems can happen when developers and users are distanced from one another. This can clearly be seen in the Horizon scandal, when the bugs reported by post office operators were filtered through layers of management rather than being the product of iterative development.
Software development is an odd kind of job. At one level, we need deep focus time, where we can focus on the challenge of how to translate a real life scenario into one that a computer will understand, and also zoom in on the detail of how exactly to tell the computer to follow these instructions.
Developers themselves can often be so task focused that time spent in meetings is a distraction, and many posts have been written about ‘freeing’ developers from meetings. It can also be tempting for delivery managers and product owners to look at the bottom line of costly developer time and focus on metrics such as feature completion or even lines of code written as a benchmark for how efficiently developers are spending their time.
Developers should prioritise user needs
However, it is also crucial for developers to consider user needs, rather than simply implementing what a designer instructs them to build. It is logical that designers and user researchers may spend more time with end users than developers will, but it is invaluable for developers to see how people use their applications and to build the kind of relationship where they can understand friction points and identify software bugs.
Some software projects operate in such a way that writing the actual software is done at a distance (either metaphorical or geographic) from the users the application is meant to serve. Research and designs are fed back from the design team, who instruct developers to build a product from wireframes or similar, often without the context of why a particular feature needs to be built.
While agile practices such as Three Amigos (aka Power of Three) can assist developer understanding, they are far more likely to involve a product owner or business analyst than the actual person who will be using the software.
This can create real problems when it comes to developers understanding exactly what they should build - or in understanding and reacting to bugs that are reported by end users of the software.
Having developers present at user testing sessions, or at the very least, recording these sessions so that developers can play them back in their own time can be a powerful tool in aiding developer understanding
It is crucial for developers to consider user needs, rather than simply implementing what a designer instructs them to build
The lightbulb moment
In my own working life, before I was a developer, I used a very customised content management system in my day job. The system worked intermittently under very heavy loads which caused system failures and buggy behaviour, and these often happened out of core working hours, when there were no developers around to observe what was happening.
While I was forced to become very adept at accessing system logs to feed back what was going on, the moment that proved to be a turning point was having a developer sit with me while I worked, to observe what was happening.
Within about five minutes, he immediately identified the problem and the bug was fixed within a day or so. Because it was something that was observable only in the Production environment, it could have taken many months for this to have filtered back through bug reports and layers of administration between me, the end user, and the development team.
Resolving conflicts of interest
Agile software development heralded a new way of building products and services, but as this insightful blog post by Thoughtworks - written ten years ago but still current today - highlights, there can be conflicts of interest between product owners and users. Agile practitioners abide by principles that include “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and “Working software is the primary measure of progress.”
This can mean that developers can be tempted to focus on the customer rather than on user needs, and because on many projects we are more likely to come into contact with product owners than the people actually using the system, this can lead to a disconnect between the person who wants the project delivered quickly and cheaply, and the person who has to suffer the consequences of these decisions.
At Unboxed, we address this conflict in various ways, including:
working with a product owner who is also a hands-on user of the software
involving developers in user testing and research where possible
encouraging an open dialogue between developers and end users, so issues can be easily reproduced and prioritised
Our experience shows us how valuable it is for developers and designers to work together. Yet even more powerful is the relationship between developers and the users who ultimately have to live with the systems we architect and code.
