Designing outside-in

Since the activities of designing and planning are encountered so many times in an Agile process, and since we're considering plan and design synonyms, let's look more closely at the process of design.

I'll take a more narrow definition of design that might exclude fine art. From the Merriam-Webster on-line dictionary I find a definition of design that reads "to devise for a specific function or end."

At it's heart, the act of design involves combines 3 parts research and analysis, 1 part creative decision making, 1 part construction, and 3 parts testing and validating. Those aren't exact measurements.

Given some sort of problem space, one where there's an opportunity for a new or better solution, the designer will start by understanding that problem space. That's the research and analysis part where she'll better understand that "function or end" she's devising for.

Where the designer doesn't have past experience, explicit research is necessary. If the designer's been hired to by someone else and is unfamiliar with the problem space, he may need quite a bit of research to understand that space.

Where the designer might be immersed in the problem spaced on a daily basis, that immersion may take the place of research. She may have lived the problem she's devising a solution for.

Given that understanding the designer can think of several possible solutions. She'll make this solution more tangible by expressing it in words, pictures, or other models that help him more clearly imagine how using this invention might solve the problem. If the solution is difficult, time consuming or expensive to construct, she might devise more sophisticated ways to model the solution, to more effectively validate that the solution might be a good one before sinking time and money into building it.

Given several possible solutions, she might select one or more of those solution to construct. But, for this first one, the craftsmanship of the construction isn't quite so critical - not until she validates that the solution is a good one.

With the solution in hand, she'll then attempt to use the solution to see that indeed meets it's objectives - is suitable for that "specific function or end." With some solutions this might be trivial, with others this could be time consuming. If she's not the person who will eventually use the solution, she'll need to take it back to those who will for them to evaluate. She'll need to collect their feedback to understand how effective the design solution is. She may need to observe them using and rely on her own observations. She may want to observe them using it simply to take pride in her creation.

But the designer taking pride in their creation at this stage is often short lived. The solution likely needs changes or correction to make it as effective as it could or should be. Corrections may be minor changes in construction. Using or observing the use of the solution often reveals information she didn't know at the time the solution was devised. She'll add that information back to what she knows about the problem space. If there's enough new information, she may go back to ideating over different possible solutions. The whole process repeats.

This is an iterative process. Iterative at every level. Research and analysis may repeat. Ideating of solutions and modeling those solutions may repeat. Building possible solutions might repeat. All these thinks might repeat until the solution really is suitable for its specific function or end. That is suitable enough given constraints of time and money.

Still the designer has a nagging feeling that there's still a better solution out there yet to be discovered - one even more suitable for it's purpose.

Use requirements to break a design process down

In the simple design process I've described there are a lot of decisions to be made – decisions about best possible solutions, construction decisions, decisions about how to adjust the design after evaluation. At the very top of this set of decisions is the first one that identified the specific function or end that we're devising a solution for.

The term "requirement" is a sometimes useful, and often troubling word in software development. To quote Alistair Cockburn from an aside conversation: "A requirement is a relationship to a decision: If you get to make or change the decision, it's design to you; if you don't get to make or change that decision, it's a requirement to you."

In software development, the process of devising a solution to meet a specific purposes often takes a number of people, and a fair bit of time. Each individual may know some information, and devise a part of the solution, then hand that part off to someone else to continue with the design, building, and evaluation of the solution. When we hand off our made decisions to someone else, we label them our "requirements." These requirements give the next person in line suitable information about the problem space they have to ideate within.

As we move from very high level business goals for a product or project through to the details of what that product will specifically look like and do, we have thousands of individual decisions to make. All of those decisions are tested or evaluated against what we know about the problem we're solving. It could be a high level problem like "what sort of features would appeal to stock portfolio managers in our new portfolio management software?" or a low level problem like "should the edit feature be accessed with a right click from the mouse, a button, or a menu choice?" All of these decisions are made based on what we know at the time. All of these decisions are made by a variety of different people at a variety of different times.

Once written down and agreed upon, all of these decisions can be thought of as requirements.

The process of arriving at those decisions is a process of design.

Capturing requirements as made decisions

Once design decisions are made, they can indeed be written down, or captured. If we understand these as decisions, it's useful to capture who made these decisions and based on what information. This context around the decision helps the next "decider" in line make better decisions

Traditional software requirements engineering, if there is such a thing, focuses on the activities of elicitation, analysis, specification, and validation of requirements. And then on managing the resulting requirements as they change throughout the product's development. Terms like seem elicitation imply that people already know the requirements; we need only draw them out. Terms like analysis seem to imply a methodical process of the breaking down of large things into their simpler parts. Neither term adequately describes the process of creatively inventing a number of possible solutions then deciding precisely what to build from among those solutions. Traditional requirements approaches, while useful at giving us notations for expressing requirements and mechanisms for managing requirements, are light on approaches to help us invent, decide, and design.

The iterative and incremental nature of Agile development approaches distributes the events of deciding and evaluating throughout the development lifecycle and out to more team members than other more traditional approaches. This makes understanding how we effectively make and validate these decisions more important.

It's important to note here that we're talking about the decisions made on the outside of the software - the decisions about what to build, how it looks, behaves, and then validating how effective the software is for it's intended purpose. A software developer strictly involved in the building of software might consider these requirements, since to him they are the made decisions he'll consider as context for his subsequent design work. But, we now understand those requirements as a product of design.

A software requirements gathering and management process isn't going to help us with designing, so let's look at a software design process.

A User Centered Design Process

User Centered Design, or UCD, identifies a general software design approach and within it a community of software designers. At it's heart is the idea that designers study the users that will be using the software and the work they do then make and validate design decisions based on that study. This sounds sensible especially since most of the software we build will eventually fall into the ands of these users.

You can identify a UCD process by its emphasis on users and use, and the emphasis on the usability of the finished solution.

Within an organization practicing UCD you'll find the research done on users and usage distilled into concise, consumable models. A user model such as a User Persona might show a photo of an archetypal user and describe details about that user relevant to design.

You might also find descriptions of use in the form of textual narratives describing the user at work with a proposed piece of software, a User Scenario or . Likely you'd see pictures drawn of proposed software user interface, [low fidelity user interface prototypes]]. Often these pictures are sequenced together along side a User Scenario to tell a pictorial story of the use, a storyboard. These are all part of modeling the potential solution.

Finally you might find live users participating in tests of user interface prototypes or the finished software itself. This is how UCD practitioners validate their solution is fit for the purpose it was designed for.

These are all useful techniques that make UCD an effective design process to plug into software development.

The User Centered Design Process Isn't

Just as it's important to understand that Agile Software Development describes a class of methodologies and not a specific one, User Centered Design describes a class of design approaches - not a specific design approach.

The term User Centered System Design was first used in Norman & Draper's 1986 book of the same name. The book brought together a collection of papers on human computer interaction design and emphasized the common theme of leveraging users to create the most effective software design. Dropping the "System" from the title left us with User Centered Design and that name stuck.

The Missing Manifesto

The term "Agile Software Development" was invented fairly recently (2000) and is backed by the brief but useful Agile Manifesto that gives everyone describing and practicing Agile development approaches a common understanding to leverage. User Centered Design doesn't benefit from the same sort of manifesto. There seems to be a common abstract understanding of what UCD means, but individual practitioners might resolve the specifics differently.

Various specific UCD approaches have arisen over the years; Carrol & Rosson's Scenario-Driven Design, Holzblatt & Beyer's Contextual Design, Constantine & Lockwood's Usage-Centered Design, Cooper's Goal Directed Design, and many others. With an emphasis placed on specific design approaches described by each of these authors, it's made it hard to arrive at a clear understanding of what the common ground is for User Centered Design approaches.

Garrett's model successfully generalizes a UCD design process

In The Elements of User Experience (2004), Jesse James Garret deviates from other author's tacks of giving a specific approach to User Centered Design and describes a useful model for looking at the general activities done in UCD. He describes a model divided into five planes where each plane represents a scope of design concern. For each plane general types of activities are suggested along with some suggestions on when activities in one plane might occur relative to activities in another plane.

Let's take a closer look at the planes of this model.

The Surface Plane

As its name suggests the surface plane describes the surface of the software, its specific user interface. This means everything we see and click on in the user interface, its color, exact placement, the fonts and size of text used, etc. We'd use visual design techniques to describe the surface of our software. For example a well designed ecommerce website page would be pleasant to look at and make it easy to see the items I'm interested in and the information about them that helps me make a buying decision.

The Skeleton Plane

The skeleton lies just below the surface. The skeleton describes roughly the layout of the software - the placement of buttons, menu bars, form elements, lists of information etc.. A skeleton might be visually represented as a wire-frame user interface drawing. An interaction designer might build this wire-frame by arranging the elements in the user interface to optimally support the tasks that will be executed by the applications users. A page for eCommerce website would likely place the item or items I'm looking for at the center of the page, and provide on each page a way to view elements in a shopping cart, or search for other items. The skeleton describes the consistent useful placement of all these page elements.

The Structure Plane

The skeletal user interface exists in some overall structure. While the skeleton would describe placement of elements in the screen, the structure would describe navigation from one screen to another. An interaction designer or information architect might create structure to arrange functions and information in the software to best support the activities the users will be engaged in. For example moving smoothly from shopping to checkout in our ecommerce site is the responsibility of good structural design.

The Scope Plane

In the scope plane we make a dramatic shift from the design of the software, the tasks and activities that design supports. For our ecommerce site the people using it participate in the activity of shopping. They'll have specific tasks like browsing for items, searching for specific items, buying those items, and tracking their orders. We might also decide it's important to save previous customer addresses so they can be chosen when placing an order because it helps that process go faster. This changes the task of entering an address for an order to choosing a previous address. That's good. And that's a scope decision.

The Strategy Plane

In the strategy plane we'll look at the goals for the organization paying for the software to be built. We'll then look at the prospective users of the software and their goals when using the software. Having a good understanding of all these goals allows us to determine what features are in scope. For our ecommerce site we might come to understand that we're selling an item that is a one-time purchase. We expect users will spend time making a buying decision then, upon deciding, quickly purchase the item. If we were selling big-ticket items that they weren't likely to purchase again choosing previous addresses to ship to may in fact not be a feature we'll need.

Move from General to Specific

The model divides concerns into five planes from general to specific. Under that is the implication that we'll resolve general stuff before we resolve specific stuff because the specific stuff is based on the general stuff. Strategic choices inform scope. Scope choices inform software structure. Structure choices inform each screen or page's skeleton. The skeleton provides the foundation for the visual design. At each plane, specific User Centered Design approaches might offer specific thoughts and techniques for dealing with that plane's concerns.

After introducing the model Garret appropriately advises that the activities and decision made for each plane not be resolved before the next plane's activities begin. In practice work will be going on in several different planes simultaneously. Garret does advise not finishing work on one plane before work done in its preceding plane's work is complete. For example fixing scope on the software before strategic goals for the software were understood would be a bad idea. Or fixing the navigation structure without knowledge of the features the software will have might yield bad results.

General to Specific Planes and Snow to Eskimos

Moving from general to specific is a common approach used in traditional requirements approaches. The three layers of requirements commonly referred to by requirements engineers are:

• Business Requirements,
• Functional Requirements, and
• System Requirements

We can see that Business Requirements maps pretty cleanly to Garrett's Strategy plane. The Scope plane maps to Functional Requirements. But when we reach System Requirements, Garrett uses three Planes; Structure, Skeleton, and Surface to divide up design decisions around the physical appearance and behavior of software.

There's a linguistic myth that Eskimos have hundreds of words for snow because they are around it enough and concerned with it enough to have different concepts and names for different varieties of snow. Although that old myth isn't true, and cross-country skiers likely have more words for snow, the concept here is what's important. If your primary focus is on a particular area, you'll create richer vocabulary to discuss that area.

Garrett's model is on user experience as it relates to software, so it's understandable there are more planes in his model in the area of describing the system than in a traditional requirements model. In fact your organization may use some sort of progression for moving through its requirements. Take note of how many layers it has and in what particular areas. You may find the areas where there are more layers point to the areas of biggest concern.

The important concept here is that that when deciding what specifically to build, there are dependent layers of decisions that move from more general to more specific.

Garrett's advice still applies. It's inappropriate to attempt to resolve all the details in one level of requirements before proceeding to the next level. For example proceeding to functional requirements may help us clarify our business requirements. Since we know requirement is the word we place on a handed off decision, we can more accurately say: beginning discussion about functionality can help us confirm our decisions on business objectives.

Plan is a Synonym for Design

At this point you might be starting to see some similarities between Garrett's outside-in model and the Agile development's outside-in. When looking at the Agile development lifecycle we see lots of plans made at varying degrees of detail. The closer we get to actually building features, the more specific the plans get. Similarly, in Garrett's model, the closer we get to the surface plane the more specific the information gets. The various levels of Agile planning start to mirror the various levels of design concern in Garrett's model. If we understand plan to be a synonym for design, then there might be something going on here.