When a product fails, we know that somewhere, someone “got it wrong,” sometimes several someones and sometimes at several points in the development project—but WHAT we got wrong isn’t always obvious.
In 2000, I joined a team that was developing a strategic web-based system. The system’s marketing advantage was to provide salary benefits to employees without incurring unacceptable administrative overheads.
Employees would self-manage their benefits package and carry most of the administrative load. However, the pivotal user of the system was the administrator.
Employees would submit a request for a pre-tax payment. For example, to purchase a notebook computer. The administrator would review, and grant or reject the request. At each pay run, appropriate amounts would be deducted automatically from the employee’s pre-tax salary.
The process was straightforward but the administrator’s context was not. Legitimate benefits would be tax-free. Illegitimate benefits and benefits that exceeded specified thresholds would incur taxes at the highest tax rate.
Administrators would want to deny claims that incurred tax penalties for the employee or the company. For example, purchasing a notebook with pre-tax salary was only legitimate if the notebook was purchased for business use and if only one was purchased in the financial year.
Administrators would also be under constant pressure from employees to grant requests. They needed to make informed decisions.
When I was writing Help for the grant benefit request form, I realised that the administrator needed to access the benefit history of the employee to decide whether or not to grant the request.
The benefit history was not accessible from the form but I’d seen the history use case in the project documentation. I suggested that a history query link be added to the form.
A history lookup was not possible for Phase 1. Why? Because when time and cost pressures had caused the project to be downsized, project management had deferred the history use case to Phase 2—in the words of the System Architect, “the use case is TECHNICALLY INDEPENDENT and deferring implementation won’t affect the Phase 1 deliverable.”
Put the mathematics of the decision in a wider context. Abandoning one little use case saved several hours of programming, integrating, and testing but without a history lookup, the administrator’s task, making an informed decision about a benefit request, was almost impossible.
Task is an interesting word. In this project, as in many other situations, technical and user interface designers took task to mean what people do. Once analysis had identified and documented what users would do and what dependencies existed between what users would do, all decisions were driven by the definition of the set of do’s (use cases).
The French existentialist, Jean-Paul Sartre, also focused on doing. He claimed that people are what they do, not what they think they are or what they want to be. Philosophically, Sartre may have a point but what people do goes beyond visible actions, as Malcolm Gladwell constantly argues in his book, The Tipping Point. (Malcolm Gladwell, 2000. The Tipping Point: How Little Things Can Make a Big Difference. London, Abacus.)
For Gladwell, context is the powerful determinant of what people do and he emphasises “the power of context” in the social events and research he describes.
For example, he recounts the behavioural study by Princeton University psychologists, Darley and Batson. Seminarians were invited to give a talk on campus. Some were asked to speak about religious vocation and some about the parable of the Good Samaritan. On the way to their talk, they were confronted by a man in agony and distress.
As each seminarian left to go to their talk, some were told they were late and some that they had plenty of time. Of the group who thought they were late, only 10 percent stopped to help the man in distress. Of the group who were told they had plenty of time, 63 percent stopped to help.
So many elements were at play in the engagement context: motivation for joining the priesthood; the compelling parable of the Good Samaritan who put himself in danger to help someone in distress; and the emotive sight of another human being in agony; yet the overriding determinant was whether or not seminarians thought they were late.
Two contexts were at play: the got-to-hurry-I’m-late context and the plenty-of-time-I’ll-arrive-early context. The contexts were the primary determinants of what happened—not demographics, not vocational motivation, not principles.
How does the power of context relate to a project that failed to deliver a successful, user-driven solution for managing salary benefits?
In two ways.
First, in their traditional requirements gathering, the team explored their audience and their audience’s goals, in much the same way as is currently promoted in goal-oriented, persona-based design methodologies.
The mistake they made was to analyse and document their users apart from their tasks. What Malcolm Gladwell emphasises again and again is that actors, their context, and their acts cannot be separated.
Later, because the project followed a rigorous, use-case driven methodology, the non-existing, real-world association with context meant that when implementation plans were revised, technical management had no understanding of the importance of the history lookup.
The profiling of an audience only provides a framework for the real analysis. For each task, their context—their objectives, their performance environment and their agenda of priorities, assumptions and expectations—accounts for their behaviours and outcomes.
When we reviewed the lessons learned from Phase 1, I suggested that, in Phase 2, contexts be fully defined for all real-world user tasks and that each use case be linked to its real-world contexts. The real-world contexts could then be used as the determining reference for project decisions.
But nothing is new under the sun. A real-world, user and task focus is the theme of many of the books and papers we read in our own professional space.
Our profession also has thinkers and methodology proponents who have developed techniques and processes that apply context insights to the design of systems, documentation, websites, and e-marketing communications.
For my part, The Tipping Point reminds me that context is the momentary combination of the user’s world, the user’s agenda, and my artefacts so I continue to focus on structured ways of capturing context insights and applying them to the design of the deliverables I produce.
Phase 2 did not eventuate for our company. We lost development responsibility and management changes occurred within the client company. I understand that the system lives on somewhere and has a presence in the marketplace.