By The webdev team recently welcomed Jonathan Thirlwell as our UX developer. This role is an entirely new one for our team, and for web development more broadly at UniKent. Up until now web development has tended to consider the needs of only one user: the commissioning customer.
We’ve become increasingly aware that we need to design web based systems around the users who will use those systems. This might seem obvious, but sometimes things move slowly. To this end, we created the new UX developer role.
I felt it’d be good to get a fuller grasp of what user-centered design entails. Developers can end up obsessing about technical areas at the cost of the bigger picture. Even if we’re not specialists in design, I feel all good developers should have a good grasp of design and what it is we’re ultimately trying to achieve.
coursera.org
To this end I decided to try out the coursera.org course Design: Creation of Artifacts in Society. This is a great – and free – 8 week course covering the basics of design. It’s actually a UPenn course, run by Karl T. Ulrich. His free book on design is worth a read.
The course follows a weekly cycle of video lectures, reading, doing some practical design work, and peer-reviewed assessment. All students need to keep a website of their work. I decided to set up a tumblr blog which has some general design stuff on it too.
I’ve focussed on product design as my project on this course, because I thought it would be fun. However exactly the same principles apply to web design.
The rest of this post is an outline of some of the things the course has covered after two weeks.
The problem definition
Problem statement and the “5 whys”
We need to define a problem before we can solve it. As a first step we need an initial problem statement which we can then refine by asking a series of “whys” (generalising the problem scope) and “hows” (precising the problem scope).
Note that you don’t have to ask 5 whys. You can ask, say, 4 whys and a couple of hows. The important thing is to ask questions around your original statement to get a broader problem scope.
This process gives us a hierarchy of problem definitions, ranged from specific to general. It gives a clear overall scope of the problem as a whole.
User needs
User needs are the things which when met will close the design gap.
We can describe 4 types of need:
- must-haves – normal satisfaction if met; low satisfaction if not met. [a car needs a steering wheel]
- indifferent – normal satisfaction whether met or not. [I don’t care whether a car has a CD player because I don’t listen to CDs]
- linear – satisfaction increases linearly as the need is more exactly met. [I’m a bit happier if this thing costs a bit less]
- latent – high satisfaction if met; normal satisfaction if not met. [I coped just fine without an iPhone, but now I have one I love it]
Must-have and linear needs are important, and they provide users with that most crucial of things: a design so good they don’t even notice the design.
However latent needs are in some ways the most important and interesting, because fulfilling them causes delight and surprise in the user. These are the types of need which users have not fully articulated. They may or may not have noticed these needs. But either way, when these needs are fulfilled they will ellicit the greatest satisfaction from the user simply because they were not expected.
Collecting user needs
- 1–1 sessions are more efficient than focus groups.
- you need at least 10 interviews for effective (90%+) coverage of user needs.
- 5 interviews gives about 80% coverage of user needs, so is often good enough.
- observe someone using the artifact, and don’t be afraid to ask questions to ellicit more information. eg. “why did you just do that?” or even “what would make using it a better experience?”
Listing user needs
- list needs not solutions! (even if the user suggests a solution, list it in terms of the need).
- do not over-generalise the need. Try to remain faithful to exactly what the user specified (unless they specified a solution).
- list needs in groups, with a primary need heading each group. The primary need can be user-specified, or generalised from the needs in the group. Think of it as a ‘headline’ need.
- mark latent needs in some way eg with !
Summary
I wanted to find out a little more about the process of design (as opposed to just making web pages look pretty). To this end I decided to try a free design course, offered by coursera.org. After two weeks it’s been a great course, and has taught me to think about user needs, how to collect them, and how to quantify them.