Use case definition and purpose
A use case is a description of how a person performs a task, describing how they use systems to achieve their goal.
A use case can be used to specify features when making intranet improvements, but often they describe the real-life behaviour of people using your intranet, to demonstrate to stakeholders existing processes (and difficulties).
Use cases are written as sequences of steps, describing the steps people take to complete a task or achieve a goal, without detailing how the systems they use respond. Use case diagrams are not user-interface models or workflow models, even if they can look like process maps.
If you have developed personas, you can link several use cases to each persona, as you might any ‘top tasks’ that you’ve discovered. You might have written scenarios that apply to certain personas and trigger certain use cases. The list of UX research goes on and on!
Developers need to be able to justify features by demonstrating a clear need and benefit, and so often rely on real (discovered) or proposed (expected) use cases. If you have found a use case that takes three systems, two log-ins and eight minutes, you could prioritise simplifying and optimising the process for obvious benefit, if the cost-benefit ratio is clear. Timing a use case from start to completion can provide a performance figure to optimise.
Intranet managers and digital workplace leaders need to espouse new ways of working, demonstrating the benefits rather than merely rolling out and announcing new features. Real-life use cases, when re-written for the different audience, can prove the benefit and explain how to start using the new system. Think ESN over email; think online document review instead of paper review; think holiday self-service instead of holiday request.
Your HR department may have role descriptions. Such descriptions could give you a high level idea about goals. Now, put aside those fictions and go talk to role holders!
People can tell you only so much about their tasks and goals. There will be some things that are so basic that they just won’t remember to tell you. Even horribly complicated and painful-to-complete tasks might be forgotten, simply because people are really good at just getting on with things.
So instead of interviewing people in a strange, quiet room, go sit with them at their desk. Let colleagues chime in with additional details and complaints. Keep asking questions; discover the most common tasks but also discuss rare tasks. Discuss the high value and the low value tasks. Where is the administrative burden? Some people will show you how they have to use several systems to achieve one goal. Even though your focus is only on the intranet you’ll want to listen intently so as to help keep the conversation going, and learn about offline tasks that could be optimised for online completion.
Keep in mind that ultimately you’re trying to have your intranet meet real needs, but right now, you’re in discovery mode, not solution mode. Ask questions, don’t talk about your own plans.
A quick and dirty way to find a person’s pain point (an opportunity to improve a process) is to ask them what tasks or goals fill them with dread? What task do they know will get snagged, hung up, and fail at some hurdle? What task is so mired in bureaucracy that it’s a miracle it every gets completed? What process has too many people involved?
If you can map and then improve that dire use case, you’ll make a difference in people’s work lives. You still have to do the cost-benefit analysis to see if it’s worth it, though.
Once you have the tasks from several roles, you can write several use cases, based on watching and describing how the person completes each task.
Writing and using
The ideal use case might only be a few, terse sentences. However, not every process is highly repeatable; some are barely repeatable with many variables. For instance, a lot of knowledge work isn’t about pressing the same nine buttons in sequence (computers can do that for us). Rather, a lot of work is about making decisions and acting accordingly.
With this in mind, use cases often have to have alternate flows — branches for different choices made by the actor (the person working to achieve a goal).
Writing a single story use case is easy, so you should definitely have loads for your intranet. Writing the alternate flows takes time.
Remember to clearly show whether your use case is a proposed use case (to guide the creation of optimisation of a process or system), or a real use case that describes actual behaviour.
You use personas to explore ‘who it is for’ and you use ‘top task’ and use cases to describe ‘what do they do’ and ‘what do they need to do’.
If you understand the needs of those using your intranet, you can design an intranet that is truly useful.
User research is an on-going matter; it’s not just about relaunching the intranet every four years.
Consider using use cases as part of your planning and as part of your stakeholder management; use cases can demonstrate the:
- poor UX of a system or process (which wastes time and frustrates people);
- improved UX of a new system of process (record the time to complete);
- desired new way of working.
Task model version / use case diagram
The way someone works can be modelled, either by following their steps using an existing process / system, or designing desired steps for a planned process.
Task model use case [PowerPoint; 800KB]
Beware the simple use case, beware the complicated use case.
The example above does not show the branching choices ‘Sara’ could make, such as revising and uploading an original file from her C: Drive or from a shared network. It doesn’t show the review process (which would make another nice use case).
IT system pros may require an exhaustive use case, one that literally maps out everything. But for business purposes, such a complicated use case or task model is not necesary; the details can come later.
Have a collection of uses cases; link them when appropriate; link them to trigger scenarios and the personas who perform them.