Framework and Scenarios
After we at Wily Technology started a major project to create a new, replacement software system to serve our existing and desired future users (see my brief accounFIXME and user description story for more context), we faced 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 had been 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. Creating context scenarios in the user description work were the first tangible steps we had made toward defining how the system should look and behave.
For us at my company, this seemed like the “magic happens here” part of a diagram, and while we were hopeful that Cooper could deliver on their promised schedule (and they seemed confident they could), we were nervous. And excited to finally bring form to our and our users’ needs. A number of the design and engineering groups attended a modified version of Cooper’s Interaction Design course, customized for us, so that the team would understand the process that we were going through and what they could expect and what different deliverables were meant to do.
For the sake of starting to explain the process we used, let’s start with a context scenario for Sandy, the Operations Technician to Route a production problem:
- 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.
For each step in the context scenario, we would enumerate the data involved at each step and be more specific about the actions that users and the software (and sometimes other systems or people) needed to do. In this case, for each step in the scenario we enumerated the data needed (time, affected systems, among others) and the actions (get information from management system to work item system, for example).
We also had to keep in mind the constraint that often the integration between our software and operations center software could be difficult to change, so we needed to ensure that there was a way for messages from the new system to be passed in the technical format of the currently deployed systems.
As in the user description story, I describe the steps we went through sequentially. While we would occasionally revisit and revise things we had done before and then, I was pleasantly surprised that there was very little re-work to do during this part of the project.
In all these stories, I only include a subset of widely-understood user information and designs. We in fact created a number of interactions that we believe are novel, useful and non-obvious, and patent applications have been filed on a number of them. Other design information has been omitted from here to respect confidentiality agreements, often marked with ellipsis or generic terms.
Let’s turn to a more interesting scenario, Technical Specialist (Alex Kibuto) – Diagnose the cause of a problem. Here each context scenario step is followed by the data and functional needs.
- Alex gets notified of a problem in a system he is responsible for diagnosing
- Same data needs as Sandy, above,and no new functional needs
- Same data needs as Sandy, above,and no new functional needs
- Alex engages the management system
- No more data needs, functional need to quickly and easy get to the parts of the management system useful to him
- No more data needs, functional need to quickly and easy get to the parts of the management system useful to him
- Alex gets oriented to the time, affected systems, and other information that the system makes available.
- Those items need to be displayed prominently
- Those items need to be displayed prominently
- Alex begins to explore the data, comparing it over time, with other systems, among other options.
- Those data need to be available to compare, and comparisons need need to be made in a variety of ways.
- …
- Those data need to be available to compare, and comparisons need need to be made in a variety of ways.
- Alex concludes that the problem is within a system on which this one depends; he notes this and involves a specialist in the other system.
- No new needs here.
- No new needs here.
- After the other specialist confirms and resolves the situation and explains this, Alex verifies that the system is back to normal and notes that.
- …
- …
- Alex makes the notes in the work item system and marks the incident resolved.
Cooper’s Goal-Directed Design approach to this is well-described in their Interaction Design course, so I won’t repeat all of the activities here. (Kim Goodwin’s Designing for the Digital Age describes the process in detail.)
After getting specific examples of the kinds of actual data that Alex might encounter, focusing on the typical but recognizing unusual circumstances, too. and after spending hours at the whiteboard with this and a number of other scenarios, we came up with a framework-level screen design along these lines:
Note that this design is deliberately sketchy. It doesn’t have all the detail that will eventually be designed, and by choice sketchy lines and letters are used to indicate that this is not a finished design ready to build. (I forget who said it, but this approach lines up with the advice that you shouldn’t communicate any more precisely than you’ve thought. At this stage our thinking was at least clear enough to indicate basically what needed to be where in relationship to one another, but not clear enough to get actual text, labels, colors, sizes, etc.)
In addition to the sketch, we needed to be able to explain enough to the developers about how we ideally thought the form and behavior should be in enough detail for them to say “that means this and that are true” and either “yes, we can do that” or “we can’t do it within our estimates as you described because this part is costly, what about this other way.” At this point we were trying to get the overall screen- and “rectangle-level” form and behavior fleshed out enough to have confidence that the design, when built, would meet user needs, and that it was buildable within project constraints. In some cases, though, where there was complex detail (as in several sections of the Investigator), we needed to do more detailed design work than this rectangle level to have confidence that what we envisioned would fulfill the users’ needs and be buildable within project constraints.
By the time we were done with the Interaction Framework phase, we had a set of sketches that we could use in conjunction with our context scenarios to explain how users would achieve their goals with the new system. While many people who saw the materials were filled with questions about the details, the main feedback that we got was along the lines of “yes, I can see how that would be useful and straightforward for our target users and I can imagine us building, selling and supporting (lots of) that.”
Impressively, Cooper came in on time and budget (after their budget being negotiated down by a few days). At the main presentation of the interaction framework with the personas and scenarios, there was some communication difficulty. As we talked about that after the meeting, the Cooper folks explained that as they warned in the beginning, cutting those few days would reduce the time spent documenting and crafting communication, which is exactly what we saw. Since there were in-company people on the project, the knowledge was there to improve the communication after that presentation, but it was a hassle. I was even more impressed that exactly what Cooper said they wouldn’t get to as well as they wanted was exactly what was difficult in the end.
In the end, the main solution to the communication problems was to present the framework only in the context of scenarios first, before talking about any of the design ideas and trade-offs that were made to get there. This was the clearest lesson I’ve experienced of the power and usefulness of communicating design with scenarios.
Detailed Design
In the major project to create a new, replacement software system to serve our existing and desired future users (see my brief accountFIXME for the context), after we had described the users and built an interaction framework (above), we needed to get to detailed design where every user-facing detail was described in enough detail for it to be built and tested by the engineering organization.
In all of our detailed design work, followed essentially the same process that we did in the framework building: for each step in a context scenario, we would enumerate the data involved at each step and be more specific about the actions that users and the software (and sometimes other systems or people) needed to do. At this level of detail, though, we would be exhaustive rather than exemplary in our enumerations. We would also consider constraints or boundary conditions such as the largest supported environments or initial installation.
We worked with many of the same communication techniques as the framework building, such as whiteboards and presentation software. In order to capture more detail, though, we generally augmented that with prose, pseudo-code, condition matrices, flowcharts, Alistair Cockburn-style Use Cases and whatever seemed the most expedient way to convey the information so that it could be built and tested by the engineering organization.
I’ll describe a few of the problems, approaches and design solutions for Investigation and Managing the management system itself below.
Investigator
Here is a framework sketch for the Investigator (the same as the sketch above):
There were many important interaction design problems to solve in this screen, as it is by far the richest and most complicated of all the screens in the system. I describe just a couple of the design challenges and approaches below.
Systems Browser
Because of the large number of systems that may be managed in an environment and the complex interrelationships of those systems and the limited amount of space on screen, we had to devise a rich and compact way to browse or navigate all those systems and to focus on elements that are most interesting.
We concluded the a presentation in the form of a hierarchy, but with the ability to move through all the data and interrelationships in any meaningful order was the best approach.
Further, we concluded that highlighting anomalous data about any particular system alongside it in the display would bring attention to it so that problem-finding would require less effort and go more quickly.
Based on this work, U.S. Patent 7,860,860 Navigation of interrelated hierarchies for application performance data was issued.
Sentence builder in legend
Because of the limitless variety of views possible in the center pane (including any data about any application at any time), we devised a combination of feedback about what was shown and control to change what is shown in the center pane.
Beginning users wouldn’t have to worry about how the legend worked as a control, but simply make selections on the areas surrounding the center pane and the graphical display and legend would update to reflect the selection.
In the sketch, “gubry” and “ixkd” utilizations were selected on the left and shown in the center pane as two superimposed time series.
Once a user wanted to refine what was shown in the graph in an incremental way, they could manipulate the legend to change the display. The approach we used for this was a natural language sentence manipulator where the elements of the sentence could be changed or removed and new elements could be added.
In the sketch, the asterisks next to the terms in the legend are sketchy indicators that each of these words is also a control. (In the Visual design work, below, a more elegant system of indicating control elements was designed.) Activating the control would generally permit removing the item, changing the item or adding a new item like it. Activating the “ixkd” control in the legend, for example, would show a control that would permit selection of a different application.
Based on this work, U.S. Patents
- 7,979,267 Specifying a subset of dynamic inter-related data and
- 7,966,172 Natural language tool for specifying a subset of dynamic inter-related
data
were issued.
Managing the management system
The administration window as we envisioned it is comparatively unglamorous and utilitarian. Nothing fancier was called for in the prioritization of user needs, as illustrated in this sketch.
This screen follows the common approach of a set of tabs for different settings, and each tab has its own layout, perhaps with selections in one part of the screen affecting others. Of course in the detailed design phase, we enumerated the actual data and behavior needs to get the list of tabs, and the content and actions on each tab pane.
In all these stories, I only include a subset of widely-understood user information and designs. We in fact created a number of interactions that we believe are novel, useful and non-obvious, and patent applications have been filed on a number of them. Other design information has been omitted from here to respect confidentiality agreements.
Visual Design
In other sections of my portfolio and case stories, I described the redesign of a systems management application. We decided to engage Cooper to do the visual design work that needed to be done to fulfill a variety of needs.
The software had to be useful and usable, and there were some specific usage needs that had to be considered in the final visual design. Designs needed to work in grayscale, as screenshots were often printed on monochrome printers by users. Designs also needed to take into account that some people have varieties of colorblindness.
From a marketing and sales standpoint (and to some extent as an issue of pride), the software needed to appear contemporary and appealing, in contrast to the dated and flat appearance of the software it was meant to replace.
From a corporate branding standpoint, the software needed to fit in with and support the company’s brand image, including use of colors, inclusion of logo, and overall impression along the lines of competence and authority without stuffiness.
Early on the visual design team spent a good deal of time with materials from our marketing department and with the interaction framework and some of the detailed design work. These were supported by meetings to answer questions and check emphases, then by preliminary studies of a few possible approaches to the overall visual style of the project. One of those was selected and the detailed visual design work proceeded in earnest, producing documentation and image files that the development team could use to make what had started out as boxy and undifferentiated become clear and appealing. There were a number of gratifying “wow!”s as early demonstrations incorporated the visual design into the software.
Unfortunately, I don’t have permission now to include images from the visual design specifications.
Compact status display
During our detailed design work, we concluded it would be useful to have a way to display in very little space the most useful information about a system so that problems were immediately and effortlessly discernible and with a little attention, a few more useful bits of information were also available. We had prioritized the information we believed should be included and figured out what we believed was the optimal size for the displays. We made a couple of our own display systems to explore possibilities and, to an extent, prove to ourselves that what we wanted to do was possible in the space available. The results, while we thought useful, were off-puttingly ugly.
We went through all this with the visual design team and after a few meetings and iterations, we ended up with a compact status display that was useful and met the visual design goals of being attractive and fitting in with the brand.
A few of the most important contributions from the visual design team in this area were:
– a simple, compact, recognizable system for labeling and displaying the multiple data series so they could be easily discerned with little effort and no ambiguity,
– displays that immediately attracted attention when there was a problem, with no effort and no user training, and
– all of this with an attractive, professional finish.
There were certainly objections:
– the display was too complicated, and
– the display showed things some people didn’t care about or didn’t understand,
were some of the most common.
We considered all of these and still believe that the displays met the need better than any proposed alternative (that we or anyone else proposed). I won’t go into the thinking here about each of the objections. I will say, though, that when I read Malcolm Gladwell’s description of early objections to the (ultimately quite successful) Aeron chair in his book Blink, I though that we could replace the words “Aeron chair” with “new compact status display” and have the story read just the same. Unfortunately the project did not get far enough to find out how useful and appealing the designed display was in the real world, and it hasn’t made it into shipping product as far as I know.
However, based largely on the analysis described above, a monitoring display with about two bits of information has been included in the shipping product.
Sentence Builder
As I describe in more detail in the detailed design Investigator section, above, we needed a way to both provide a legend for the center pane display and to manipulate the display. There were other places in the interface where users need to specify things like which things they want to search for or what action to take when an alert condition is triggered.
The approach we used for these needs was a natural language sentence manipulator where users could changed existing elements of the sentence and remove and add new elements.
We needed to show things like:
- that an item could be changed,
- that it was possible to add and remove items,
- that a required element was missing, and
- that multiple words were together one item (e.g., “tabular display” vs “time series”),
all while not interfering with the alternative use as just a display.
We went through these needs, along with a number of scenarios from which we distilled the needs and illustrated the tools use with the visual design team and, after a couple of iterations, ended up with a system that met these needs.
The visual design solution involved approaches including:
- use of underline treatment to indicate that things could be changed and linking multiple words together,
- use of bold and/or italic to indicate what was required or unspecified,
- small and light (unobtrusive) but clearly discernible iconic controls (such as a plus sign) within the sentence indicating that additions could be made at various points.
Center pane
We needed ways to enable comparisons among monitoring and management data collected and stored in the system.
We provided the visual design team with a number of exemplary data series in rough display form, and they responded with visual treatments of the data that both enabled comparisons easily and fit with the context the data would be displayed in (the Investigator, with its many surrounding data displays) and fit with the overall visual design goals.
The visual design team provided a few alternatives, such as light lines or text on dark backgrounds and the opposite. All of them seemed clear and appealing and looked consistent with the overall visual design of the system. The interesting thing about this part of the project was how much different each alternative appeared out of context versus how it appeared in the context of the Investigator. Dark backgrounds made it appear that you were looking through a port hole in the Investigator to sunken or distant data. Very light backgrounds seemed to stick out and appear harsh. For what appeared to be a relatively common and straightforward task (figuring out the treatment for graphs), it turned out to be more work to get something that fit in with the rest of the design.
Carl Seglem Portfolio
Resume
Big Data, Enterprise, and Complex Systems
Lean & Agile
Mobile
Patents
Carl Seglem Portfolio 