At the recent Gartner Symposium, I attended a session by Gartner Research Director, Magnus Revang on why user experience (UX) is hard for IT to deliver and what to do about it.
What is UX?
There are about 27 definitions of user experience out there, which goes to show that even the experts can't agree on what it is that needs to be delivered.
Revang gave delegates the following one:
User experience includes all the users' emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviours, and accomplishments that occur before, during, and after use. [ISO 9241-210, 'Human-Centred Design Processes for Interactive Systems]
According to him, companies often get the goal
wrong. When it comes to getting people to sign up for a newsletter, for example, why is it that the form you need to fill in is so lengthy and intimidating? The goal is clearly not to get people who are interested in the content to sign up, but rather to populate the CRM system. If the goal was simply to get signups for the newsletter, the form would be short and quick and easy to fill in.
A good user experience should not be the goal, says Revang - it doesn’t make you money. User experience is rather a means to attain business value and helps you to reach
your goal. It isn't the goal in itself. He says the goals in IT today are increasing, but you can’t measure user experience without knowing what outcome you want to achieve.
Why is it hard to deliver UX - especially for IT?
Revang says there has been a decline in routine tasks and jobs thanks to automation through IT. However, our workloads haven't decreased as a result. In fact, we are doing more work than ever today but we're doing more non-routine work. Non-routine work's goal is not automation but rather empowerment, he says.
IT is good at automation, but not necessarily good at delivering solutions that empower people. That's because IT often applies large, complex engineering to systems that need to be human-centric, simple, relevant, and non-leading. CIOs and IT managers need to remember that users need to be empowered and therefore they need to listen to users and find out what they need. Tesler's Law of the Conservation of Complexity
The user had to deal with complexity because the programmer couldn’t. But commercial software is written once and used millions of times. If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalising the user to make the engineer’s job easier.
Basically, there's a choice: are you incentivising developers to simply develop features and collect data? Or are you incentivising them to develop software that’s easy to use? Do you want the complexity to be exposed to the user or to the system?
The consequence of adding a feature
This leads to the adding of features. The cost of features is astronomical, says Revang. He used the example of Netflix which doesn’t have advanced search – it added the feature which probably took months to develop. However, that one feature was at the expense of all the other features that were already there. As soon as the advanced search feature was added, the other features were irrelevant and underused. So Netflix decided to remove the advanced search feature. Just like that.
When considering adding features, remember that you have the user on the one hand and the system on the other:
|One more thing to misunderstand||One more thing to maintain|
|One more choice to make||One more thing to test|
|One more thing to read||One more thing to monitor|
|One more failure waiting to happen||One more thing to consider|
|One more distraction||One more thing to build and deploy|
What do we need to start doing?
User experience is done by multi-skilled teams which can comprise of a developer, a front-end developer, an interaction designer, a graphic designer, an information architect, a content strategist, a copywriter, and editor, and SEO specialist, an analyst, a business developer, a scrum master, a product owner, and a project manager.
He is is of the opinion that no one can do it alone - it all happens in teams. For development, you need a user researcher, an experience lead, a visual designer, a front-end developer, an interaction designer (how things flow and behave), and a content strategist.
When it comes to the design process, you need to follow the steps of discovery (find out what users want), synthesis, prototyping, construction, and refinement.
Revang says it's extremely hard to find good UX examples but after a lot of digging, he showed delegates the best example he could find: the UK government portal
During the 2008 financial crisis, the UK government had to cut budgets, so developers were given more autonomy to create the site.
What came out of that was a simplistic site that is incredibly easy to use. These were the design principles:
- Start with needs
- Do less
- Design with data
- Do the hard work to make it simple
- Iterate. Then iterate again.
- This is for everyone
- Understand context
- Build digital services, not websites
- Be consistent, not uniform
- Make things open: it makes things better
He closed off by giving delegates some final recommendations:
- Define what good UX is before you start
- Do user research
- Follow a design process
- Focus on quality over quantity
- Use data to inform design decisions
- Make teams accountable, but also increase autonomy
In the end, remember that good design can never rescue a bad service.