I admit this is not the most flattering name, but luckily there is only a circumstantial link between drug and computer users! However, it is the most descriptive term for people who use or consume your product or service. Clients and customers who pay are important stakeholders, but ultimately it is the users who decide if the technology, the website or the app. are fit for purpose or not. Of course a user may also be a colleague or the customer, but for the purposes of this module they wear a single hat, i.e. role. Role-playing is an important concept and tool in developing IT systems.
One of the reasons that this IT element is about users and not for example, customers, is the recognition of users as specific persons-of-interest in software development and technology-related projects. There is also a rich language and set of techniques that exist, including:
- Use Case
- User Story
- User-Centric/Centred Design (UCD)
- User Interface (UI)
- User Experience (UX)
- Usability/Usability Engineering/Usability Testing
- User Acceptance Testing (UAT)
- [User] Acceptance Criteria
This module will explain all these terms briefly and put some of the related activities into context of a typical project System Development Life-cycle.
Early and often
Actual or prospective users should be recognised early and often in product and software development, starting, for example, with interviews or focus groups, segmentation, or by creating personas of your target user group or typical users. Marketing, user representatives or proxies should be able to help with this, or at the other end of the range you could embed users in the project/change team itself.
Such multi-disciplinary teams and an approach called JAD or Joint Application Development sounds perfect doesn’t it? However, there are pitfalls; for example, it’s almost as dangerous to assume that you (an interested outsider) knows what is needed than trust implicitly the opinions, prejudices and world view of one person. An expert cake maker may only know how to make one type of cake!
Sometimes creating new and better things means temporarily forgetting, or parking, known operational or design problems and perspectives to encourage creativity and challenge convention and the status quo.
I’ll tell you what I want, what I really really want!
And herein lies the biggest challenge, understanding and documenting user needs and wants so that they can be designed and realised. The disciplines of requirements elicitation & analysis and the role of the Business Analyst are covered elsewhere, but here I will mention two particular user-centric techniques that can help.
Use Case is really a mis-translation of User Case and provides a simple visual representation and a structured textual description of how a user interacts with the system/process/device under consideration. One of the benefits of the technique is that it focuses on what the user does and what the end results or benefits are, rather than the detail of how the system meets the need.
Similarly a User Story starts as a simple statement or narrative of what a user in a particular capacity (role-based) wants to do or achieve and why, i.e. as a rationale, which leads to one or more User Acceptance Criteria that need to be met. In this way separating the what from the how provides an important first stage in a traditional system or product development cycle. Dealing with solution design – the how – comes next. User Stories are much-used in Agile-type methodologies because they are simple and quick to produce.
Here is an example in each style…
Both Use Cases and User Stories can provide a useful verification point whereby the customer or other stakeholders (could also be users) get to say what they want to get out of the whole exercise without actually seeing it or experiencing it, although this can be a very difficult concept to grasp without a clear process and guidance from IT and change experts.
Which leads neatly on to…
I want one of those
User-Centred Design, or Human-Centred Design, is a framework and set of processes and techniques built around the continual iterative testing of assumptions (e.g. what is the product, who are the audience, and how will it be used), as well as early design prototypes and the end-product itself. We have mentioned some of these techniques already, including personas, Use Cases and scenarios, an extended narrative akin to a User Story.
At each stage participation and collaboration is needed so that the user’s tasks, expectations and limitations are at the centre of the endeavour.
The user’s needs drive the design, not the other way around.
This process is particularly important where there is a User Interface (UI) or man-machine interface, which is almost always, even a seemingly automated hidden activity will need visibile components such as reports/Management Information and administration facilities, or will touch users indirectly. How a user interacts with the technology is key to how effective it is, and ultimately its commercial or operational success.
Prototyping has become increasingly important in IT, borrowed from hard engineering disciplines, its often easier to see, play with and kick the tires of an approximation or simulation of the finished product. More than the appearance of the thing, in usability testing we are interested in User Experience or UX (not to be confused with Customer Experience/CX!)
UX is important enough to be represented by its own IT element, but briefly, usability testing may include the formal assessment, by observation, of:
- How well does the product/software/website meet its stated aim & objectives? (i.e. functional requirements)
- Is the speed/performance/throughput acceptable? (some of the many possible types of non-functional requirements)
- Is the interface familiar, intuitive and learnable, with or without training?
- Is there appropriate feedback to the user on progress, including expected and unexpected outcomes?
- Is it usable in a range of normal and unusual conditions?
- Is it accessible and usable by the intended audience, including specific limitations such as colour-blindness, lack of mobility, high ambient noise or poor light etc.?
(These last two broadly fall into the category of Accessibility)
- Can all the above be improved in the next iteration/version/release, and how?
One of the last things you do is carry out a User Acceptance Test (UAT), a slight misnomer as User Testers are seldom end-users, they are more likely to be the person who commissioned or is the paying customer of the product, UAT might also be carried out by an expert test function. The key thing about UAT, whether formally scripted or not, is that it should simulate what a real User might do – use and misuse – in as close to operational conditions as possible (otherwise called live or production). This internal alpha testing might be extended further to beta test in some controlled external environment.
I hope you’ll agree users are quite important…!
(c) 2015-16 IT elementary school