I’ve been writing up user-requirements as part of a suite of light-weight documents in an agile project environment. Part of my concern about this project has been the developers’ use of (a version of) the extreme programming methodology, but without rigour in their documentation. In fact, the vendor has even suggested that their previous clients have often asked for no documentation at all!
Part of any system is the documentation of what you built and why so that someone can come along later and maintain the thing you’ve built and even build upon it if required. It’s all part of good risk management.
Nervous about the lack of documentation, and not wanting to sink everyone in paperwork, I suggested that we develop the following as a minimum set of documents:
- User-requirements: primarily ethnographics and personas
- Business requirements: predominantly user stories and business process maps
- System requirements: including volumetrics, loading, security standards
- Information Architecture: wireframes, site structure and interaction design
- A prototype: fully functional and made by the developers
The user-requirements, surprisingly, was the hardest document to create because its normally a part of my IA and I normally create it first rather than at the end of the project.
When doing personas and user-requirements, I first start to look at them in workshops where I ask participants to describe who the users of the system are in general terms. Usually, I write up this list of archetypal users on a whiteboard and then go through them, one-by-one, with the audience, asking people what they think this archetypal person needs. One persona per piece of butchers paper is usually enough. Giving them a name is also a good way to get the ball rolling, as is drawing a cartoon picture of them, and having a bit of fun.
Creating personas up-front in this way helps to shape the rest of the thinking about the system. Again, in workshops, whether doing card sorting or drawing up a eutopian front page for a website, I challenge participants thinking and ask “do you think Bob the Newbie will understand what you mean when you say X”?. At the end of a workshop we have requirements, site structures and page designs that are created with Bob in-mind. As a result of this process, Bob often becomes a living person with references to him throughout other internal communications about the system.
Unfortunately, I was starting at the end with this project, so articulating the need for documenting the users of the system when there was already a prototype was a little difficult to sell. What made it all the more difficult was that certain user archetypes represented a specific person in one specific role. Putting a cartoon face to a persona was difficult bcause someone would invariably say, “but isn’t that just Joe Smith who does that role”. For some on the project, they couldn’t get past that last fact. It meant that my use of personas wasn’t going to be as effective as it normally is.
In the end, I had to rely on documenting groups of requirements and lessening the focus on personas. What I developed was the following list that made up the bulk of the user-reqirements documentation:
- Work behaviour: Will people have ad-hoc interaction? Will they use the system in a way that mirrors batch-processing? Do the system’s functions, therefore, need to be small and modular and able to be quickly completed, either in a batch or at point-of-need when there are competing priorities and other work distractions to contend with?
- Socio-economic factors: If people are from a low socio-economic background they’re not going to have the latest hardware and may not have broadband internet access. How will this impact on how people use your system?
- Economic factors: Do the users have enough money if they’re expected to outlay money in order to be able to use the system? E.g. new hardware or new software? Even the expectation that a system will require 128-bit encryption to secure data has implications for what browsers people will be allowed to use and therefore what PCs they will need
- Computer experience: Do users have a relatively low-level of computer literacy? Will they require hand-holding through the system’s processes? Will you give them a Help Desk as a result or are you going to need context sensitive help?
- Usability requirements: If you’re expecting users will have low-levels of experience with technology and the high-levels of competing work priorities your system is going to need to be intuitive and able to be used without the need to consult a manual in the first instance. Vision impairment
Will some users need support for scalable fonts due to vision impairment? We have an ageing population after all, and I’m seeing more font-rescale widgets in IA reports these days. Can you influence employing scalable rather than fixed font-sizes in the cascading style sheets of the system?
- Accessibility needs: Australian legislation requires that information made available to the public is accessible. Does the system ensure 24/7 availability and does not preclude access to those with cognitive, physical, or other disabilities? Time zones
Does the system need peak-uptime availability across Australia, across the USA, or across the world due to the users’ working behaviour?
Critical Reporting Periods
Some of my clients work in government and so the Minister’s Office tends to call them late in the day with questions for the Minister. The system’s performance, therefore, is critical between 3pm to 6pm.
- Information needs: Competing priorities on likely task completion, including work and home influences, are known to impact the ability of users to remember information from one screen to the next. The information architecture, therefore, accommodates this user need through ensuring that page titles reflect hyperlink titles to reinforce where the user has come from and where they are intending to go. This removes the guess work by users having to remember where to go and where they’ve come from. Contextual Help and Error Messaging
Being able to complete complex tasks requires that your system offers help at the point-of-need, rather than offering a manual that users need to browse through in order to find answers to their questions.
Does your system offer contextual help on each page? When users enter incorrect information are logical and plain-English messages are offered to ensure users are able to complete the task at hand with as little interruption to their task as possible?
On a side note, I find manuals quickly get out-of-date and people just tend to print them and leave them on their shelves. At least with contextual help you can do your bit to safe a few trees.
- Support and training requirements: Should users require assistance with the use of your system do you need to establish a help desk service? Do you need to identify processes to gather questions from users and frequently asked questions compiled that will assist your system administrators identify future needs for support, whether through formal training, or enhancement of the online help facility?
Answer these questions and write what users will require under these headings, based on research and observation, and it’ll give you a good standing for ensuring that the users needs, as well as those of the business, are met in your system.
M
Posted by magia3e 
Posted by magia3e 
Posted by magia3e 
