Contextualizing an outside in process

Let's make this process a bit more tangible by using a story that describes an outside in process and names then contextualizes the techniques used in it.

The stories told here are about real people and their behavior on real projects that I or someone I've collaborated with closely has participated in. In spirit of the old '60s television crime show Dragnet "the names have been changed to protect the innocent."

If in the context of this book or any other book on software development someone tells you a story about a perfect project where everything is done right and everything goes well, don't believe it. In fact when I sat down to write this, I'd hoped to tell a single story about a single project where every recommended technique was used, every model was built, and everything did go well. But, in the real world that just doesn't happen. And, it never has for me. So, doing what any good software person does, I started to make up a story. A good friend was quick to point out to me that this was in fact lying, and people would see through it. Of course he was right.

In an attempt to tell true stories that place these techniques and models in context, It'll take a few small stories about several projects that effectively use some of the techniques described in this book. I will avoid mentioning too many of the gory details of which there are many. While these yucky project details may be interesting, they don't help frame the use of these models and techniques which is the real goal.

Dog-Fooding

The expression "eating your own dog food" is often used when we ask someone to follow their own advice particularly when in pertains to using something they've built or a technique they've authored or recommended. We'll start dog-fooding by using recommended techniques here in this book.

One of the modeling techniques recommended in this book is the User Scenario. (You can tell it's a referenced technique because the word is bold and in a different color. Throughout this book you'll see that convention.) A user scenario describes in literal detail a particular user engaged in a particular activity. A well written scenario reveals the goals and motivations of the user that compel them to pursue a particular path through the system. It's an effective tool for placing the functionality you chosen to build in your software into a real world context that readers, and listeners, can understand. I'll contextualize the models and techniques used is this book using a scenario written at a business level - let's call it a business scenario.

Project Paint More

Project Paint More demonstrates effective collaborative design and iterative development. However, it also leaves us with a warning that basing design on hearsay and assumption, and not effectively validating throughout development can result in unforeseen consequences.

The Context

Paint More is a largish chain of retail stores that primarily sells high quality paint to home owners, interior decorators, and paint contractors. Paint More purchased package point of sale and backend inventory management software POS Co. While that software had lots of great features, it didn't have any features that allowed the easy sale and management of tinted paint. Of course those sorts of features were important to Paint More. So they paid POS Co. some additional money to add functionality into the software to allow the selling of standard and custom tinted paint, including the printing of a label to go on each paint can.

POS Co proceeded as they had normally proceeded: minimal requirements were gathered for the functionality of the software, a price was set, and a delivery date was agreed upon. The development team began development using minimal requirements to proceed.

Designing the solution

Identifying users and usage

The POS Co. development team, project and engagement managers familiar with the work committed to Paint More participated in collaborative work sessions to construct a simple user role model to represent their understanding of the types of users using the software and a simple user task model to understand the type of work those users needed to engage in when using the new software. These models were quick to create using CardStorm to get ideas on the table to brainstorm User Roles and User Tasks directly on to index cards so they could be quickly Filtered and Prioritized then placed into models.

After building the models, the development team had a good idea of who would be using the software, their goals, and the work those users would perform using the software.

Designing the user interface

Clustering user tasks by affinity - similar tasks done by similar people at similar times - allowed the team to identify Interaction Contexts, an abstract way to refer to screens or pieces of screens that support specific user tasks and then using those interaction contexts they built a simple navigation map to show how a user might navigate from place to place in a user interface.

Given the understanding of what screens existed in the user interface, and how navigation worked, the team created Low Fidelity User Interface Prototypes by drawing them on poster paper. There weren't many screens, and the UI wasn't that complex, so this was a pretty quick activity.

All this work was done using Card Models in collaborative work sessions or by Pairing in front of a whiteboard. It was fast to do. In less than a day the team had an understanding of how the functionality might look and flow.

Planning the development

To plan development so they could show working software as quickly as possible, the team used user tasks to build a Span Plan, a simple planning model that helped the team identify the smallest set of user tasks necessary to span the entire business process. Using Story Thinning Guidelines, the team talked about the thinnest bit of functionality that could be implemented to allow a user to succeed at the tasks in the span plan. These bits of functionality were used as the User Stories for planning the next iterative development cycle. The team didn't feel it necessary to identify stories much past the next two week iteration. Using these thinned stories, they'd be able to see the entire business process, all necessary user tasks, executable on the screen in two or three weeks.

Building the software

The development team began iteratively building the software using the thinned user stories. Throughout the development process the team did a lot of ad hoc design pairing and modeling. A few weeks into construction, the basic paint tint application was visible. To make progress transparent, it was time to schedule a Stakeholder Review. This would allow stakeholders to review progress and make any course correcting suggestions.

The team wanted the software to look its best and behave well, so a few days before the review, the team gathered together in a conference room for a collaborative user interface inspection. The UI inspection resulted in a number of changes to the UI to improve usage, and in locating of a number of functional bugs to repair prior to the demonstration.

These issue were prioritized during the inspection, then the team went back to work fixing uses. After a couple more collaborative user interface inspections, the software was looking and feeling pretty good.

When the time came for the stakeholder review, it was held electronically using software to share the desktop. The entire team was in attendance in a conference room where the application was projected on to the wall. Team members from the POS Co. development team controlled the software using the mouse to click through the new functionality they'd built.

Stakeholders were impressed at what looked like pretty rapid progress. But, they did have some of their own issues to bring up. Those issues were noted by the team to resolve. In particular stakeholders were puzzled by what looked like poorly developed features. Specifically things like screens with all of their fields, but without validation, or pop-up selections not yet working. The team had to explain their approach of implementing Thinned Features – more features thinly to allow the validation of the entire workflow of the system as early as possible. Paint More hadn't seen this sort of approach before, but agreed to reserve judgment on it's effectiveness until delivery time.

Releasing the software

Development continued up till the release date. As the release date drew near, instead of whole new features being added, existing thinned features were refined and improved from the thinnest task support built early, to more full featured smoother working task support in the areas that needed it the most.

The tester on the POS Co. development team used the Task Model to create Usage Centric Tests - tests which allowed her to assume the role of the user pursuing a goal in the system. Repeatedly testing this way resulted in a few feature additions and changes to make usage smoother. While the functionality seemed to work well, a lingering concern was building over performance. The application's performance felt a little sluggish.

An implementation team prepared for release into a couple pilot Paint More stores. As part of the preparation all of the thousands of existing paint colors were loaded into the database. When the day came to go live, a couple team members were at both store locations to observe end users using the application, and to make sure there weren't any problems.

The first release wasn't a complete disaster, but it certainly couldn't be labeled a success. The software performed much slower than expected. Maybe it was the network speed, maybe it was all the additional paint colors in the database - maybe both. Whatever the reason, the team members on site winced as they observed users trying to work with the very slow application.

As they watched they also observed clerks using the application in ways they hadn't anticipated. They'd built an application that allowed a cashier at a paint store to sell a can of tinted paint at point of sale. While ringing the can of paint, the cashier could print out a nifty label for the top of the can giving the formula to mix the paint, and details the customer could use to re-order more of the paint at a later time. As the reader of this story, you may have already detected the problem.

Customers didn't want to pay for paint before having the can of tinted paint in their hands. Since the formula to mix the paint in the computer system and printed on the handy label wasn't available till the paint was in the process of being paid for, cashiers had a problem. They quickly improvised a solution. They'd start a point of sale transaction, look up the color, print the label, then cancel the transaction and go mix the paint. Sometimes a single open transaction would be used to look up many colors of paint for many customers so labels could be printed and paint mixed. This certainly wasn't the method of use the POS Co. development team had planned on.

This usage adaptation was causing other problems. In a retail environment, many cancelled transactions are often seen as a possible sign of theft by cashiers at point of sale. Well, now canceled transactions likely meant Paint More staff needed to print labels. The label printing part of the application had the capability of printing the customer's name right on the label - which was handy for identifying cans of paint in will call. However, when a transaction was started for the sole purpose of looking up paint colors and printing labels, the transaction was not identified with a customer - and labels all carried the useless customer name of "cash sale."

POS Co. team members standing a few feet away from Paint More cashiers could see them pounding at the keyboard - as if they keys weren't working. Then they'd finally move their hand to the mouse complaining under their breath. It seems these cashiers didn't want to use the mouse, and the keystrokes they'd expected to use weren't working in the new paint tinting addition to the software. The team hadn't anticipated this either. Nor had this detail emerged in the on-line Stakeholder Reviews where they software was controlled with the mouse by the POS Co. development team.

The team saw these performance and functional issues first hand. No one needed to report a bug or issue. Already the minds of team were spinning with possible solutions. The memory of employees struggling to use their software was forefront on their minds.

Reflecting on what went wrong

After returning back to the office the team sat down to do consolidate and compare their notes in something like collaborative data consolidation. Using this understanding they sat together for a post delivery reflection session to look back at and discuss what had happened. The team had been pretty confident they'd built a solid application. They'd designed considering their users and goals. They'd built a task model that had taken into account the proposed workflow. They'd continuously reviewed their solution using collaborative user interface inspection and with stakeholders during stakeholder reviews. What went wrong?

The team agreed that if they'd observed users in context before the initial user role and user task modeling, they'd likely have known about the problems with not allowing users to print labels before ringing up paint at point of sale. They'd also have been sensitive to the desire for keyboard only usage of the application. They'd have understood Paint More users and the use much better.

They were puzzled that stakeholders from Paint More hadn't detected these problems, but since it had been a while since any stakeholder had worked actively in a paint store, that might make some sense. And the on-line demonstrations didn't allow stakeholders to actually touch the keyboard or experience the paint tinting product in the context of using the entire POS system to sell paint.

The team agreed that in the future they'd also involve end users in the Collaborative Modeling Sessions to try to be aware of more details that only someone immersed in the daily use of the software would know. They also decided that performing some lightweight usability testing - observing real users using the software to meet their goals - in addition to Stakeholder Review would help identify problems.

Performance was another problem issue. The team agreed that in the future they'd need to test the application using a more accurate representation of the real data, and over a network and on a computer system that reflected the actual environment users would be working in. As part of contextual observation, the team agreed that capturing details about location of use in a location profile would be effective.

Finally both Paint More and POS Co. needed to have some discussion. The functional requirements and delivery schedule had been met, but clearly there were still issues to resolve. Who'd pay for the additional time to fix the software? Was this no one's fault, or everyone's fault?

Ultimately Paint More and POS Co. arrived at a financial agreement, and the team using information collected from on site contextual observation started on a battery of work to change the software to fix it functionally and resolve performance issues.

The team took its own advice and during development of the new features constructed early working versions of the software that could be tested over a wide area network using the full set of data. Team members then went on site with end users to perform lightweight usability testing directly with end users to observe their usage of the proposed new designs and get direct feedback and ideas from users. Several iterations of this sort of testing resulted in both improved usability, and faster performance.

Years after the final delivery of this software, Paint More considered this project one of their most successful.

Takeaways

Making decisions about functionality based on assumptions about the users, context of use, and workflow along with a lack of rigorous validation during development resulted in a delivery that wouldn't work for Paint More. Observing users directly, and adding lightweight usability testing into the validation cycle improved the quality of the resulting design decisions to ultimately make the product a success.

The Ingredients

If this were a recipe – although it may not be an ideal recipe for success - some of the models and techniques used here include:

Observe users in context	technique
Observe users in their place of work engaging in the activities you intend to design software to support.
User Roles	concept
A user role names a type of user engaged in reaching some goals with a system. A user may change roles as they change goals. For example upon finding something interesting in an on-line website a "casual browser" might change to an "impulsive buyer" or a "skeptical comparison shopper." Use the form "thing-doer" to help name roles. For extra credit use the "adjectived-thing-doer" form to capture important characteristics of the user in the role name.
create role model	technique
unable to find value for field: create role model.thumbnail
Represent work people perform as tasks	concept
An action taken by a person that while it may have a simple objective that would indicate success for that action, the action itself in undertaken in pursuit of a larger goal. Name tasks without implying the task must be performed a particular way or be performed using a particular tool to allow choices about the tool and its design to be made later.
Create a simple task model	technique
Using a visual, spatial representation show the relationships that number of user tasks have with each other. Use a task model to understand the breadth and nature of work that the candidate users of a system might engage in and identify tasks that may cluster into interaction contexts in a proposed software user interface.
Create a location profile	concept
Name and describe the relevant characteristics of the physical place of use for a piece of software. These characteristics will help to better make decisions about the software that would work effectively in this location.
Interaction context	concept
An abstract area within a piece of software where the user of that software might navigate to perform a set of related tasks. Use an interaction context to name and organize areas of the software around similar tasks performed by similar people at similar times.
Construct navigation map	technique
Using a visual, spatial model, represent how users of a system might navigate from one interaction context to others. Use a navigation map to understand the structure of a piece of software.
Construct low-fidelity user interface prototype	technique
Use pencil and paper, whiteboard and marker, or other quick tools to visualize how users might use a piece of software to achieve their goals using some set of tasks.
Plan incremental software releases in system spans	technique
A visual representation showing the workflow, dependencies, and necessity of user tasks that span a complete business process. Use a span plan in support of release planning to help identify a holistic set of tasks to support in a proposed software release.
Plan incremental software releases in system spans	technique
A visual representation showing the workflow, dependencies, and necessity of user tasks that span a complete business process. Use a span plan in support of release planning to help identify a holistic set of tasks to support in a proposed software release.
Thinned feature	concept
A proposed software feature for development that while it supports a user achieving a task using the software, does so in way that's cheaper to implement. Use thinned features early in the development of software to allow more software to be built and evaluated at a high level quickly.
Feature thinning guidelines	concept
Feature thinning guidelines help identify characteristics of a feature that may deferred or removed making the feature lighter, simpler, and faster to develop. Use feature thinning guidelines to thin proposed features during release planning, and choosing and designing specific work to iteratively develop during iterative release development.
Conduct collaborative UI inspection	techique
As team, gather to evaluate a stand-in user's interaction with software under development. Use collaborative user interface inspection to quickly identify usability issues and functional errors in the software. These inspections also serve to familiarize a team with the users, usage, and functionality of software under development.
Conduct lightweight usability testing	technique
Directly observe users attempt to achieve goals using working software, or a user interface prototype. Use lightweight usability testing to quickly identify usability issues or to validate design choices in software being designed and under development.
Review product progress with stakeholders	technique
Periodically review software under development with stakeholders of the software. Use these reviews to reiterate the business goals of the software, the users using it and their goals, and to demonstrate new functionality that supports these goals. Stakeholder reviews keep your decisions and progress visible and allow for the collection of valuable feedback.
Model using index cards	technique
Using index cards or sticky notes to collect and represent ideas, spatially arrange and manipulate these ideas on a table top or wall to model, explore, and better understand these ideas. Use card modeling concepts as a foundation for other modeling approaches. Using card modeling in a collaborative work session helps involve participants and better build their connection with and understanding of the results.
Collaborative work session	foundation
Meet in a small group, usually 4-8 people, to collaboratively collect, consolidate and model information.
CardStorm to get ideas on the table	foundation
Brainstorm directly onto index cards or stickies. Use CardStorming to quickly move through brainstorming to filtering, prioritizing, and modeling.
Filter and prioritize ideas	foundation
Given a large number of ideas written on index cards or stickies use filtering and prioritizing to reduce the number of ideas to the most critical or divide into categories to deal with category by category. Use filtering and Prioritizing techniques ahead of modeling to control the size of the model or after modeling to identify important parts of a model.
Paired Work	foundation
For activities that require a fast effective problem solving work supported by one or more people to allow that activity to proceed faster. Use paired work to support activities such as user interface prototyping, user scenario writing, persona building, or writing software code.

Putting it all together

The remaining sections of this book deal with specific areas of design and development. The beginning of each section explains its purpose and place in the design and development process. Then concepts are explained that will be leveraged in the techniques found in the section. And within each section is a short story to help contextualize the techniques found in the section to help you put it all together and better understand the context that you'd apply a particular technique.