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.
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.
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.
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.
…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.