As we at Wily Technology started a major project to create a new, replacement software system to serve our existing and desired future users, we realized it was important to describe these users, their goals, and the situations that they could find themselves in while using our software. Armed with a concrete list, we could discuss uses within and outside the company, and we could prioritize (and just as importantly de-prioritize) which user goals we wanted to meet and in what circumstances.
All of the people involved in this user description and prioritization effort had been in contact with many users over many years in our roles as product managers, senior engineers, user interface engineers, sales engineers, customer support, and user training. The project’s goal was to meet the needs of existing and emerging users in the domains we were already serving, so we decided specifically not to undertake new outside user research. We would occasionally ask others with lots of time spent with users to evaluate our descriptions or fill us in on missing or recent insights. If our project goal had been to make software to serve a user or goal we did not already have this deep understanding of, we would have initiated various kinds of contextual inquiry, market research or other investigation.
I describe the steps we went through below sequentially, but in fact we would often revisit and revise things we had done before and then, following those revisions, make changes to things described later in the process below.
Early on, we enumerated of the actual and desired or potential users of the software and enumerated well over a dozen. We divided the list into a few primary targeted users, a few secondary users (who we would keep in mind and perhaps make small changes for), and the rest were users who we were not going to make any design decisions to support. We knew that we were undertaking a large effort, and one way we wanted to mitigate risk and ensure we got the most value out of the design work was to pick the users we believed were most important to serve and leave the others to be served specifically or explicitly later.
For our most important users, and for people who wouldn’t necessarily use the software but would be important in making the decisions to purchase and deploy the software, we created narrative descriptions of the value that each would get from deploying and using the software. We created what we thought was a compelling case for each of them to decide that their life would be better if they deployed and used the software. While this activity may sound like a marketing or product management activity, as interaction designers we would need to deeply understand the buyers and users so that our designs would satisfy their needs as well as the needs of the primary users. We understood that the product needs to capture interest and be sold before it would be used.
We created a flow diagram of the kinds of things we knew people had to do with the software and the order in which these activities would typically happen. It included things like: deploy data collection agents, deploy management server, set up management server integration with operations workflow management system, notify of a problem, provide diagnostic information for a problem, notify of a management server problem. There were several dozen of these fuzzily defined capabilities, uses, tasks or goals. It was for us an early way to think about the things that people and the software had to do to help make early estimations and decisions.
In the examples that follow, I only describe information that is widely understood in the industry. During our design work we dealt with roles and goals that were (and still are) only emerging in the industry, but I have omitted them because they are proprietary and confidential.
For each of the primary and secondary users, we enumerated a list of goals. For example:
Technology Specialist
- Diagnose the cause of a problem
- Verify that a problem is fixed
Management Software Administrator
- Install and configure data collection agents
- Install and configure central management software
Business Application Owner
- Know the status of production applications
Operations technician
- Route production problem promptly with all required information
For each of the primary and secondary users, we also described the targeted skill set and experience that we would design for. An important goal of the project was to reduce the skills required in order for people to even learn to use the software, so we set user targets that had what we thought were the minimum skills that should be required for each goal, and we would design the software so that the user in that role working to achieve that could would be successful without significant additional education. For example, whereas with the current software, to achieve certain goals you might need to be an experienced developer, we set a design target that the user would need to understand certain concepts and how enterprise computers worked generally in order to achieve their goals.
We prioritized those goals, and we decided that some of them we would not attempt to meet in the project we were working on.
For each goal, we enumerated a list of situations. For example:
Technical Specialist
- Diagnose the cause of a problem
- While a certain kind of problem is happening in production for a certain kind of system while in one location
- Just after another kind of problem caused a production outage that happened earlier for an another kind of system at another location
- While a certain kind of problem is happening in production for a certain kind of system while in one location
We didn’t try to enumerate every combination of variables for each goal, but to cover all the relevant factors that would affect how someone would use the system in at least one of the situations.
Again, we prioritized the situations and decided that some of them were not in the scope of the current project.
At this point we did not describe what any user would need to do when they found themself in one of these situations. We were vigilant about describing the problems we were trying to address separately from how people or our software would need to behave to achieve their goals.
We knew that our users work with colleagues to achieve their goals, so we wanted to describe archetypical collaborations. We made informal diagrams of people in the roles and the information or requests that typically passed between them.
A subset of what a diagram for Technical Specialist – Diagnose the cause of a problem is shown here.
A subset of what a diagram for Management Software Administrator – Install and configure central management software is shown here.
These are just sketches of fragments of the diagrams, meant to give an idea of their form and content. For our most important collaborations, we included all the relevant roles (whether we were target users of ours or not) and the main interactions between them. When a number of collaborations involved mostly the same roles, the roles were arranged identically, so that the different content of the collaboration arrows could be the focus of attention. These diagrams gave us a compact and accessible way to describe the kinds of interactions among people within which it would need to work. They also gave an alternative (visual rather than textual) representation of the goals and situations and helped relate the users, goals and situations to one another.
At this point we’d done about as much of modeling or describing users as we thought would be useful. We were faced with the important question of how to go from thoroughly understanding users, their goals and the contexts in which they work to designs and then working software, starting with a clean slate.
We thought we could probably come up with something somehow, but because of the large number of people involved and the urgency to get clarity quickly, we looked to interaction consultants. We were fortunate to engage Cooper to start with what we had done and then develop with us what we were calling a “global interaction model” and they called an “interaction framework”. (See Creating the interaction framework for more on that process.)
We were pleased that in this case (the first time for Cooper, as I understand), they would work on the interaction framework engagement without first doing their own field work. The believed that with our experience with users, our identification of emerging roles that didn’t exist on organizational charts at the time, our voluminous enumeration, prioritization and diagrams of users, goals and situations, they could be successful so long as two of the team that developed the user description material would participate on the team with them, under their direction essentially full time. A colleague and I were pleased to work with the Cooper team.
Among the first things the Cooper team did was create two tools that they use in their work and presentations: clear personas and a few of the most important context scenarios.
We took the role descriptions that we made early on and added a bit of relevant concrete individual detail and names and we had “persona placemat” depicting in full name, face picture, succinct primary goals and succinct background our primary and some secondary users. For example: “Sandy Mindon (with a plausible stock photo) is a Operations Technician; Sandy when something goes wrong, Sandy needs just the information needed to prioritize and route the problem; Sandy doesn’t want to be bothered with routine events; Sandy works part time and is in as associates’ degree program at a local technical school.” These persona descriptions did help people learning about our target users say things like “ah, yes, I know someone like Sandy” and “Sandy would approach that situation this way.”
Cooper also worked with us to distill our hundreds of situations among all our users’ goals into a handful of context scenarios. Each context scenario was a single series of steps to achieve a goal, without reference to any particular product or functionality. This was a new activity for us. We had worked studiously to avoid saying what the system or any user would need to do. Here we were beginning to be specific about what it needed to do, but without implying or entailing any specific feature.
With Sandy, the Operations Technician to Route a production problem, for example:
- Sandy is doing some routine work in the Operations Center.
- A page arrives at the same time a work item appears in Sandy’s work queue
- The work item has all the information that Sandy needs to look up in the procedures guides to route the work item and prioritize it.
- Sandy also sees that the work item has all the information that the procedures guide says is required before it is routed.
- Sandy routes the work item as directed by the procedures guide.
- After some time has passed, Sandy gets reminded that the item has not been resolved and needs to be checked.
- Sandy checks about the item finds that progress has been made and it appears to be nearly complete.
- Minutes later Sandy notices that the work item has been marked completed.
- Sandy follows the procedures guide to verify the problem is resolved, marks it verified, and Sandy’s work on the incident is finished.
These context scenarios served a number of important purposes:
- building and recording a shared understanding of what the most important uses of the software would be in a compact, accessible way,
- being an important input to the creation of interaction designs (the form and behavior of elements of the system),
- giving life to the personas for people just learning about the users’ goals,
- being the basis for explaining interaction designs, and
- being the basis for demonstrating early versions of the software.
- After creating our small early set of context scenarios, we added a few more later in the project to help explain things that were clear to people intimately involved in the project but not clear to newcomers or outsiders.
After these early days of the project, we revisited and revised our user descriptions very little. They proved to be quite stable and held up to scrutiny during and after the project.
Carl Seglem Portfolio
Resume
Big Data, Enterprise, and Complex Systems
Lean & Agile
Mobile
Patents
Carl Seglem Portfolio 