We usually speak of software and Web sites as being composed of features, and indeed they are, just like my face is composed of features. We also understand that a feature typically corresponds to a task undertaken by a user. Over time this model has demonstrated a modicum of success in delivering viable products. We are discovering, however, that for software and Web-based systems, a product that is merely viable to sell is not necessarily a desirable one to use, and is thus quickly outpaced by those that offer even a slightly better experience, despite possibly being less feature-laden and even significantly less powerful.

A feature typically also exhibits a one-to-one relationship with a unit of work. It is the basic unit of measurement for gauging what can be done, in how long, for how much money. Since features roughly correspond to tasks, it follows that if we figure out the tasks, we'll figure out what features to implement. Then if we make those, we'll have something we can sell. Sound reasonable?

Almost. In order to be implemented, a feature has to be pretty specific. Furthermore, between a feature and the corresponding task that a person wishes to accomplish is any number of distinct interactions — possibly zero, possibly many. Lastly, people almost always perform tasks for a purpose, that is to achieve a goal. Features that do not specify interactions are unclear and lead to wild cost overruns. Tasks without goals are meaningless. Most importantly, none of this excursion makes much sense if we neglect to consider that we're doing it for the benefit of people. If we fill in these blanks, we get the following, unbroken line:

People ⇨ Goals ⇨ Tasks ⇨ Interactions ⇨ Features

By creating a model that begins with people, we can refine our understanding successively until we arrive at precise definitions of the features we wish to implement. Moreover, we can trace a given feature all the way back to the person who we can expect to make use of it. Most urgently, we can use this method to establish how to prioritize our projects so that everything we release completely serves somebody, rather than half-serving everybody.

And if it isn't already obvious, we can apply this understanding far outside the scope of information technology projects, into every aspect of our relationship with customers and users, from messaging to offerings to support. It may even make sense to weave it into our organizational ethos. Indeed, a body of knowledge like this might already exist, in whole or in part, for purposes other than IT projects. If it doesn't, such a project would be an excellent place to start.

A Potent and Economical Asset

One of the nicest parts about this research is that it is fairly inexpensive to produce and comes together relatively quickly. It demands neither a significant capital investment nor a cast of thousands. A single person working for a few weeks is often sufficient, though it is useful to have another on hand for the occasional sanity check. No matter how big the project, however, this step will never keep more than a few people busy at a time.

Below are a few specific artifacts that make up part of this research, which enable us to stand in the place of the people we're trying to help and focus directly and with great precision on what will accomplish their goals.

Business Ecosystem
A model of the ecosystem describes the generic types of entities that interact with your business. We may include specific individuals and organizations where appropriate. A complete depiction of the ecosystem surrounding your business will include a diagram showing each entity and the nature of the relationships between them, as well as any necessary annotation. The ecosystem provides a clue as to which people within these entities will make suitable personas.
A persona identifies goals by creating a fictional person who can exhibit them. A persona takes a form similar to a character sketch for a story. Fictional people are much less fickle, much more patient and much cheaper to work with than real ones, though we adapt personas either directly from real people or infer them by examining the ecosystem. Rather than just make everything up, we will support them with ethnographic research, which will entail varying degrees of involvement, depending on our budget. It is essential, however, to get whatever information is necessary to make a realistic and believable persona, since they are the linchpins of the rest of the design process.
A scenario is a short written narrative that employs one or more personas in specific tasks. It need only comprise a few paragraphs, as its purpose is to flush out one or more interactions. We can write numerous scenarios, mixing and matching our roster of personas to highlight the full complement of interactions that occur around the entire project. The aggregates of these interactions are also known as touch points.
User Experience Sketch
A user experience sketch is the result of any inexpensive way of getting the first glimpse of how specific interactions might look and behave. It acts as a preliminary definition for a set of features. For something like a graphical user interface, this can be as simple as a pencil sketch depicting the placement of various buttons and widgets. For more complex interactions, we might create storyboards and paper prototypes to get the information we need. Whether we perform even more exotic activities, such as build Lego or Plasticine models, or perform a skit in front of a videocamera, the intent is to weed out the bad ideas and hone in on the right ones as quickly and cheaply as we can. This might not sound much like hard work, but it is terrifically effective in defining where to spend the serious money in implementation.

It is important to recognize that not a single one of these artifacts needs to be married to any particular technology. In fact, they are arguably more valuable if they stay technology-agnostic. The most specific items, the experience sketches, need only be concerned with the current generation of technology. The personas and especially the ecosystem could last as long as the organization, with few if any changes. To invest in this body of knowledge is to create a widely-applicable and long-lasting framework for understanding products, services, customers and users, as well as the organization itself, its stakeholders and its affiliates.

A Special Case for the Web

The artifacts above are concerned chiefly with interaction design, which is the design of how people interact with, in our case, software systems. While the Web is certainly composed of software, its reason for being is to connect and transport pieces of information intended to be consumed by people, which we typically call content. Despite the tremendous push for companies to create Web applications, and browser vendors to support them, the World-Wide Web is and will remain primarily a channel for content. This is a fundamental and inextricable part of its design.

Since the experience around a Web site hinges on its content, no interaction design can support it, no matter how stellar. Indeed, it makes little sense to delve too heavily into user experience before sorting out what is called the content strategy. A content strategist could no doubt make great use of the first two artifacts I mentioned above, the ecosystem and the personas, which outline the people in the system and their goals.

So, Before Diving Into Code…

…let's look at what we can do to get our product closer to right, closer to the first time. Let's focus on committing only to optimal, long-lasting solutions, and not hobbling ourselves with rushed or arbitrary decisions. Let's do this by flushing out every idea quickly and cheaply as soon as it arrives, and only keeping the ones that work. Let's remember that features are meant to serve people, and that people are the principal focus of development, not features. In so doing, we'll give everybody — our stakeholders and programmers, but especially our customers and users, a break.