Throughout almost all of my technology career I’ve been involved with making sure the requirements are specified and implemented well for the products and projects I’ve been responsible for. But in the past few years I’ve been increasingly involved in discovering user needs, as distinct from requirements. I’ve also come to understand that they are in, many ways, more important.
Comparing requirements with needs is instructive, and Rimonov’s tower of activity is surprisingly helpful here, even considering its age. When asking about needs we are asking bigger questions of our users. We’re asking about their lives, how they work, the forces that act on them, what they want to achieve not just with our products but in their work and lives generally. Questions about needs are bigger questions. Requirements seek answers to questions at a low level. They seek to answer questions about what data users want to see, how they want to see it, what actions they want to take with it, how they want to balance security and convenience, and so on.
Asking about needs also requires speaking more to people. In the earlier part of my career, when I considered only requirements, I spent a lot of time putting myself in the mind of the user and creating the requirements myself. You can’t do that with needs, though. Different people have different views on life, different forces acting on them, and only by speaking to many people can we get a rounded view of people’s experiences, and then choose what to act on.
Needs speak more about user experience—the whole experience—and less about the user interface. User needs encompass the bigger questions about what problem in people’s lives we are going to seek to solve. It guides us in our language, how we communicate what we’re doing, what support we offer, what features and capabilities get prioritised in the product (and in the user interface), what’s easier to do and what’s impossible to do because it isn’t core to the particular users’ problem we’re trying to solve.
For example, compare Google Docs and Microsoft Word. Both are (what we used to call) word processors, and in terms of the features most people want to use they have near feature-parity. But they address very different needs. Docs is primarily about collaborative working; Word is primarily about creating a document that looks exactly the way you want it to look. Collaboration works better in Docs; precise crafting works better in Word.
Requirements are important, but to deliver the best value to users it’s important to ensure we understand users’ needs well.
niksilver.com 