Understand the Problem Before Designing Solutions

Everywhere you look nowadays, you see people writing about the importance of design, and how user experience (design) is the key to success, particularly in ecommerce. Increasingly, however, I’m seeing websites that are harder to use and (mostly) seem to be more interested in looking flashy (prioritising form over function) and keeping the user engaged with the website, rather than helping them to do what they want to do.

At least part of this problem comes down to a lack of appropriate analysis during the development process. This strikes me as somewhat perverse, given that It has long been accepted that the first steps in developing most systems should involve understanding the task at hand, e.g.,:

  • Understanding the problem situation. This is the first step in SSM (Soft Systems Methodology, e.g., see Checkland & Scholes, 1999).
  • Understanding who the users will be. This is the first principle of designing for usability (Gould & Lewis, 1985).

Understanding the problem situation

One of my old bosses frequently used to say that system performance was about particular people, doing particular tasks, in a particular context. If you want to understand the problem situation, you therefore need to spend time and effort analysing these different aspects of the system, and how they interact and are inter-related.

Some years ago we worked withJimmies Hospital in Leeds (Baxter et al., 2005) to help them develop a new system for use in the neonatal intensive care unit.  It took us several months to understand the problem situation. This involved attending meetings, visiting the unit, talking to the people who worked there, and carrying out background reading. It was only when we understood the language staff routinely used to describe their work that we could we go on and properly analyse what they did in more detail, and generate rich pictures—another very useful concept from SSM—to represent this.

Understanding who the users will be

First, designers must understand who the users will be. This understanding requires directly studying their cognitive, behavioural, anthropometric, and attitudinal characteristics, and by analysing the nature of the work expected to be accomplished. (Gould & Lewis, 1985, p. 300)

Understanding and organising everything that you need to know about your users is a similarly non-trivial task. There is usually a lot that you need to know about your particular users, so we suggest organising this information based on the ABCS: the Anthropometric, Behavioural, Cognitive, and Social factors (Ritter, Baxter & Churchill, 2014). We added social factors to take account of the fact that most work is now performed by teams of people.

So what?

If you don’t understand the problem situation, and who your users will be, your design solutions are likely to make the user’s life harder than is necessary. In other words, you’ll be providing a user experience that is less satisfactory than it could be.

If you don’t spend time understanding your users,  you can end up assuming that they are just like you. In other words that they have the same knowledge, skills and attitudes as developers. This explains why you can still hear developers describe users as “stupid” (or worse) when they watch them wrestling with their system to try to make it work.

Take the case of shopping. Most people, most of the time, go into a shop to buy one or two things—the main exception being grocery shopping—and then move on.

When you look closely at many commercial websites, however, it quickly becomes apparent that the developers aren’t supporting what the users are trying to do. Or, at least, they aren’t doing it in the best way possible. Instead of just helping the users to buy what they want and then move on, the developers employ a gaming style model of motivation: they try to keep users engaged with their site in an effort to get them to spend more money. This is why you see recommendations along the line of “people who bought X also bought Y”. Many of us have fallen into that trap and ended up buying something that we didn’t really want (or need) in the first place! The developers also provide a streamlined checkout process, reducing it to the minimum number of clicks so that users have less opportunity to think about what they’re buying, and whether they really need it or not. On top of that, the developers hide the sign out button, so users have to search the website to find it.

Take-home Message

Understanding the problem situation, and who your users are, will give you a solid foundation for designing solutions that will lead to the appropriate user experience for their particular situation. This is true for all (technology based) systems, not just websites. So, for example, in safety critical systems—air transportation, medicine, nuclear power etc.—you provide your users, first and foremost, with a safe user experience, rather than necessarily a good one!


Baxter, G.D., Monk, A.F., Dear, P.R.F., & Newell, S.J. (2005). Using cognitive task analysis to facilitate the integration of decision support systems into the neonatal intensive care unit. Artificial Intelligence in Medicine, 35, 243-257.

Checkland, P. & Scholes, J. (1999). Soft Systems Methodology in Action. Chichester, UK: Wiley.

Gould, J.D. & Lewis, C. (1985). Designing for usability: Key principles and what designers think. Communications of the ACM, 28 (3), 300-311.

Ritter, F.E., Baxter, G.D., & Churchill, E.F. (2014). Foundations for Designing User-Centered Systems. London, UK: Springer.