Defining the Project

Examining the problem shouldn't be a solo activity. As much as designers like to think so, they aren't all knowing and all seeing. Designers need input and other points of view from clients, stakeholders, colleagues, teammates, and others who have maybe thought about this situation (or similar situations). Designers typically get this information from two places: the design brief and stakeholder interviews. (Designers can, of course, get input from users too; see Chapter 4).

The brief is a document, usually from the client (or an internal business manager or unit hereafter referred to as a client), but it can also be created by the designer from information culled from the stakeholder interviews. It should lay out the reasons for employing the designer (the problem) and often it may make suggestions for the solution as well. The brief is an excellent starting point for gathering information. Briefs can contain such information as brand considerations, technical constraints, expected timetable and deliverables, detailed goals of the project, and contact information for major stakeholders.

Also in the brief, designers usually get some insight into what the client thinks will make a successful project. This likely won't be spelled out; it may just be a throw-away line like "We want to make the new application fresh" embedded within a 50-page document filled with complicated business and technical goals. But if the designer meets all those goals but creates a conservative design that doesn't address the client's desire for "freshness," the client will be unhappy.

The brief should be only a starting point in discussions about the project. Indeed, the brief could raise as many questions as it solves. What exactly does making the application "fresh" mean? That's where stakeholder interviews come in. Stakeholders are clients who have a particular interest in, and influence on the outcome of, the project.

Stakeholder interviews (Figure 2.1) are usually one of the designer's first tasks on any project. The interviews are the client's chance to tell the designer why the client thinks that the project is needed. As stated earlier in this chapter, these reasons may be mistaken, and the designer should feel free to challenge them. The problem may not be what the client thinks it is.

Figure 2.1. Stakeholder interviews allow the client to explain the business goals of the project.

iStockphoto

Stakeholder interviews work best when they cast a wide net, so designers should take the time needed to conduct them well. The designer will want to interview not only those who are sponsoring the project (that is, putting up the money and resources), but also those in the organization who will be affected by the project. Often, people lower on the organization chart have deeper insights into the parameters of a project than those higher up. For example, consider a redesign of an application through which customers contact customer service. Although the project may be sponsored by the chief information officer and run by the director of customer service, the designer would be remiss if he or she didn't speak with the people who actually work with those contacts: the customer service representatives.

Business Goals

It's always the goal of an interaction designer to balance the goals of the business with the needs, abilities, and goals of the users. We'll spend considerable time thinking about users later, but stakeholder interviews are the time for the client to tell the designer (or for the designer to probe about) the business goals of the project. Business goals can be anything from hard numbers ("We need to sell 5 million ball bearings a day") to soft, company-brand goals ("We need a more elegant interface"). But again, the designer needs to be careful. Look for the unstated goals of the project. Sometimes, organizations want to use projects for different ends, such as to merge two departments or add staff, and will use the design project as a means to do so. Solutions that run contrary to these unstated goals may be greeted coldly.

By learning about the business goals of the project, the designer should also learn about what the organization will consider a successful project at the end ("We sold 10 million ball bearings today!")that is, the project's success metrics. Success metrics let you take an objective look at a project's result to see what progress has been made toward its goal.

Evaluating success, of course, is much easier for projects with hard-numbers expectations than for those with softer goals. It's sometimes not easy to measure what businesses call return on investment (ROI) for interaction design. If an organization expects a design to meet an ROI goal, the designer needs to be sure some mechanism for measuring success is in place before the design work begins. Designers should have some sort of baseline criteria culled from the existing situation that they can then use to measure the new design against. For example, before beginning the redesign of a Web site registration process, the designer should get some quantitative datanumbers, in other words: "It takes six minutes to register; on an ease-of-use scale of 1 to 5, with 5 being excellent, users currently rate registration as a 2; according to server logs, half the people stop registering after the second page." With this baseline data in hand, at the end of the project, the designer can measure the new solution and compare the new data to the old and also to the goals of the project. If the designer has done the job well, the numbers will likely show it.

Constraints

Stakeholder interviews also help designers understand the constraints of the project. No project is without some boundaries that for business, technical, or time reasons cannot be crossedat least not crossed easily. Constraints can be placed by a number of entities, such as marketing, accounting, management, IT, and of course, users. Sometimes constraints are as simple as the medium in which the project will be created ("We want a Web site" or "We want a new mobile device"). Sometimes constraints are a lot more complex ("We've already sold advertising for each Web page, so you need to design space for that" or "This robot can make only left turns right now and occasionally explodes"). Interaction designers need to capture and document constraints throughout the course of the project, in everything from stakeholder interview notes to wireframes (see Chapter 5). These constraints will often shape the design decisions that are made.

Designers can sometimes overcome constraints by coming up with a brilliant solution that can be implemented only by breaking a constraint, and then passionately arguing for it. For example, say a designer is working on a banking application. During research, users report that they absolutely need to see their account balances on every page to make good decisions. But one of the technical constraints is that the system cannot show balances on every page. What should the designer do? It's a choice between giving users what they need or living with constraints. I hope the designer would argue for breaking the constraint.

Gathering Information

Unless specifically told not to, designers should feel free to consult outside sources as part of the information-gathering process. Thanks to a little thing called the Internet, we now have access to information quickly and easily from many different sources. Designers should make good use of it. Very few projects are in an area that no one has thought about before. Even a cursory search of the Internet, and especially of e-mail list archives, discussion boards, and technical and academic journals, will likely turn up information about the project's subject area, whatever that may be.

As any doctoral candidate can attest, a person can spend a nearly infinite amount of time gathering information. It's important to focus this part of the process on gathering germane information that will eventually find its way into the solution. The goal is to gain general knowledge about the project's subject area (and perhaps related areas), and also deep knowledge about the particular problem that is being addressed. Interaction designers should not only ask the How and What questions, but also the Why questions. Why does this work this way? Why is it important to sell a million ball bearings a month? Why should this application be on a mobile phone? Why questions help designers avoid questions that don't provide much information, such as those that can be answered with a yes or no.

It's a good idea to spend only a fixed amount of time gathering information. Eventually, you need to stop defining the project and actually start designing it.