Creating a Design-Friendly Process

In the last chapter, we saw how many of the professionals who have offered to help with interaction design have not succeeded. We have examined usability testers, industrial designers, and others who have tried and failed to solve this problem. Currently, there is no group of any size in the industry that can solve it.

As the ranks of interaction designers slowly grow, keep in mind that fostering a design-friendly process is more important than hiring the most talented designer. The most important thing is to make a commitment to take time out for design before you code. Finding the most brilliant designer in the world will do no good if the product is going into beta next week.

For example, many software dynasties have been established on the backs of very young, very inexperienced programmers. They were likely given a free hand with programming issues, and the pairing of immense responsibility with immense authority can often be a crucible for creating greatness. The same forces apply in interaction design. If someone is given the responsibility for product quality, and she is given authority equal to it, she will often rise to the challenge regardless of her experience. If you take a suitable person and give her full control over the quality and behavior of a product, you will have a much, much better product than if you don't. The problem is with the process, not with the people. Of course, all things being equal, it is always better to get an expert with relevant experience. However, if experts are in short supply or not in the budget, using less-skilled practitioners is better than just letting the programmers run loose.

What does it mean to be a "suitable person?" The most suitable would be someone without an interest in the construction of the product and with the detachment to put himself in the user's place. This could easily be a programmer, but certainly not one of the programmers who will have to build this particular program. That imposes too great of a conflict of interest.

Where Interaction Designers Come From

Still, you have to choose someone to do your interaction design. After you start to look for them, you will find frustrated interaction designers already present in almost every high-tech company: technical writers who have programmers coming to them for help thinking things through, product managers with bookshelves full of interface-design books, usability testers who talk about getting involved in development earlier in the process, marketing managers who point out that they purchased the stereo with the fewest buttons, programmers who do very little coding but whom other programmers ask to work with. In fact, after it becomes known within a company that a project will start with a design phase before the coding begins, someone is sure to step forward and ask for the assignment, saying that she wants to be the person held responsible for the quality of product.

When you hire full-time designers, good applicants might or might not bill themselves as interaction designers. You need people with a general understanding of technical constraints and a passion for design, but you can find people like that working in many different environments and with widely varied backgrounds. In hiring people for my design studio, I ask people to respond to a design problem as a test because I know that their resumes can vary dramatically. At my studio, I have several designers with backgrounds in technical writing, software project management, tech support, and graphic design. Many of my designers have degrees in the humanities, but I also have designers with degrees in physics, architecture, computer science, and industrial design.

Experience in tech support or documentation provides designers with perspective in thinking about typical users' needs. Software product managers know about the needs and concerns of programmers in the development process. Graphic and industrial designers have a passion for design elegance and skills to produce it. Designers with a humanities education who have worked in high tech combine a knowledge of technology with an ability to articulate their thinking.

Building Design Teams

A discussion of how one organizes and runs a design team could easily fill a book of its own. In this book, I have touched on some design methods in order to make clear what I mean by "design," but I have not attempted to lay out an entire design methodology. However, my experience running teams of designers at my studio suggests a few key principles.

Keep the teams small. In order to progress, the designers need to share the same vision. I assign a team of two or three designers to each product, supported by occasional help and contributions from a few other specialists. In complex projects, the design might reach a point at which the product has a few distinct interfaces. At that point, you can split up the problem and put it into the hands of a few different teams. Before that point, too many cooks spoil the broth.

Insulate the team from managers and programmers. Early in a project, the designers need to talk to the other people working on the product to formulate a clear statement of the problem and define their personas. After that point, they need independence to follow some blind alleys before they reach their best solution, and they need privacy to do that effectively.

Assign a design communicator responsible for documenting the team's work. All team members will contribute to the documentation, but someone needs to own it in order to make it most effective.

Allow the team time to compose its thoughts. Late in the project, when the fundamental problems have already been solved, it is wise to go to your design team for answers to specific questions. Early in the project, the team needs to think things through carefully and present its reasoning as a coherent whole. When my studio does a full framework for a client, we provide a document and present our designs with informal checkpoints as needed. In the first presentation, we frame the problem, present the personas, and articulate the problems that the design must solve. In each successive presentation, we describe the design of the product in greater detail.

With a managed process, centered on design instead of on programming, companies can avoid riding a high-tech tiger. They can know in advance what their users will like and how to provide it to them. They will know when the development process is done, and the various disciplines will have a common, and specific, vision to rally around.