User-requirements tools: Want Maps

When you want to document business needs it’s usually done as a requirements document of some kind containing things like context diagrams, process maps, and use cases. The frameworks surrounding these artefacts typically result in a good picture of what the business needs in order to do its job. In waterfall projects, users are involved in assessing the end-product and then receive training if there’s some gap in usability.

The issue at hand (putting on my psych hat) is that training only serves to equip people with skills but it does not change their behaviour. Ultimately, if any system doesn’t work in the way that people like to work, if they find it un-usable, then they’ll develop work-arounds so as to not have to use it. No amount of training will help in such a situation.

I’ve found this behaviour in numerous projects over the last decade. I recall one in particular where the business had a reporting requirement and asked its end-users to enter data on a quarterly basis. End-users delivered the data in all sorts of formats — Excel, tables in Word, faxed paper reports, and even written by hand and posted. I was asked to help deliver requirements for a web-based system that would deliver a more streamlined process of collecting the data.

I employed a user-centred design approach, one very similar to the one that forms part of ZenAgile, and what I found was rather interesting. When I incorporated analysis of end-user behaviour — wants, needs, attitudes and capabilities — I discovered that while the business wanted a reporting system the end-users wanted something to assist with their business management. As I proceeded down this path of analysis the underlying user behavioural reasons why reporting was so hard from a business perspective became obvious.

Firstly, I documented each of the user types as a Persona. This is technique that documents an archetypal representation of a user type on a single A4 piece of paper.

I then began to collate the users’ requirements and noted the following themes:

• There was no governance for quality control of reporting — so people just did what they felt was the minimum with no one to really enforce a standard quality for reporting
• There was no knowledge framework — so no one understood what they needed to do and how they needed to do it
• There was no universally accepted way to do reporting — so people just did what they felt would be acceptable

What I didn’t have, though, was a good way to represent these issues. So, I developed the “Want Map“.

A Want Map is a tool that takes the needs and wants of Personas and groups and categorises these human-centric issues visually with each of the speech bubbles starting with “I want …”.

I’ve found it a powerful method of showing project stakeholders what the human issues are so that:

• Risk strategies can be put into place
• Pain-points can be addressed by new system features resulting in higher-levels of system adoption and ease of transition to business-as-usual
• A higher level of traceability is had between users’ needs and system features
• You don’t have to write ‘the system must be usable’ as a system constraint (non-functional requirement) — you now know exactly how to make the system ‘usable’ through creating system features that support the issues in the Want Map

Ultimately, using Want Maps gives me specifics regarding how to align the end-user, human issues with the business requirements to produce a more ‘usable’ system. For this project in particular, I could begin to state requirements like:

• The system must deliver support for end-user processes (for example, in this case, managing the budgets of their programs)
• The system must collect data ‘invisibly’ based on end-user behaviour in day-to-day business processes
• The system must collect FAQs (a knowledge-base) to help all users know what to do and when
• The business must create and reinforce a governance framework to help assure a high-quality of data is collected

For those engaged in Agile projects, Want Maps ultimately assists in transition of users’ needs/wants into Story Cards as the first part of sprint planning.

Overall, Want Maps are now part of my ZenAgile way of working. When collecting requirements for your project using Want Maps will help enable your project to focus on the user as the beginning of the project which results in all activities being aligned to Agile and Lean philosophies — ‘does this add value to the end-user’.

M

Advertisement