What Designers Know

This essay was published in the first issue of Distance, a quarterly journal of design and technology. The publication was initiated and edited by Nick Disabato, the author of Cadence and Slang. The journal featured many notable participants such as Benjamin Jackson, Vitorio Miliano, Cassie McDaniel and Francisco Inchauste.

The paragraph numbers exist to facilitate citation, as only 2 of the many forms Distance appeared in had actual pages. The paragraph numbers and footnotes here match the original publication.

Editor Nick Disabato

Keeping research pervasive

I’m always surprised by how many things we know. We train keyboard shortcuts into our muscle memory. We continually learn tips, tricks, and insights from bosses, mentors, and colleagues. Instructors drill ideas into us at school. Over time, we cultivate taste: we know what looks cool and what doesn’t. We know how to persuade people and garner attention. We can help people remember things. We can sell toasters. And the things we know aren’t limited to what we’ve been taught – we also know what we’ve read, recorded, and experienced. We’ve seen great ideas succeed and fail. We remember the expressions on people’s faces when they first see our work. We’ve learned the right way to present our work, and the right people to present it to.

Strange, then, that we always begin our projects with a research phase, as if we know nothing, as if the problem hasn’t existed in some other form, as if the client has all the time and money in the world. To be fair, all projects have unknowns. Nobody likes surprises, and sometimes, research reveals important things that we never knew before. But what about the vast majority of our projects? Or the vast majority of the problems that we solve within a project? I’ll wager you or your colleagues have seen these problems before – and there’s a fair chance that the solution is documented elsewhere in some form.

If research is budgeted, scheduled, and properly conducted, it can be a tremendously valuable activity. It can provide feedback on all of the things we make. But when research is poorly conducted or poorly applied, it can leave the client with the idea that research is expensive and not worthwhile, and that hurts us all in the long run.

Because we already know a great deal, we can move research from a step in the design process to an ongoing, agency-wide activity: we can adopt a distributed research model. This model would result in better, more focused work, allowing us to spend more of our energy on specific issues relevant to the project at hand. It would also help us meet deadlines, because we can capitalize on the experience of the designer and community while maintaining a good relationship with the client. In this essay, I’ll describe how research is built and distributed across teams, and how it can benefit all of us to focus on institutional knowledge.

The context

I work at a cross-platform agency for web design, print design, corporate identity, and enterprise CMS development. Over the past few years, I’ve focused on speed in designing for all types of clients. Faster implementation creates something useful today, rather than something perfect tomorrow, while sacrificing as little as possible in quality.

We’re a small firm, with a total staff of ten. Given the size of our team and the demands of our clients, projects rarely contain a traditional research phase; instead, “research” becomes an ongoing conversation during design and development. For example, an international manufacturer of wireless devices required specialized websites for their developers and sales partners. Building on our experiences with similar businesses, we created a design that addressed most of their objectives, so we could achieve the site’s primary goal in a short timeframe. They were startled by our fast response, but as we took them through our designs, they were pleased with their accuracy and utility. The project led to an opportunity to design their corporate website.

While they expected a research phase with far more preliminary work, we drew from our own personal experience instead. Exhaustive research and analysis were replaced with simple conversations with the client. Our approach would be refined during its implementation, and even the refinements came from our prior experience. After going through this process a few times now, we’ve learned a new way of doing things. We trust our existing knowledge and experience, we keep our research and knowledge at the top of our minds 1 as we design, we organize our research so it’s easily available to everyone, we structure the company so people collaborate across disciplines, and we keep the client involved through every step.

Before I explain this further, though, a few words on the history of design processes.

The current way: the Research First Model

As designers, we usually talk to our clients and colleagues in terms of a design process, or a particular way of moving from ideation to execution. It’s something that typifies design activity on all kinds of projects, and this practice is taken very seriously. In some cases, organizations value their processes so much that they have even copyrighted or trademarked them. 2

In How Do You Design?: A Compendium of Models, 3 Hugh Dubberly describes over 80 design processes. Many of them are quite similar, usually variations of the 4d model: define, design, develop, and deploy. 4 Indeed, design activity can’t take place without some definition of the problem to be solved and how we might go about solving that problem. These parts of the design process are generally covered by research and analysis.

In Generic Work Process Version 1.0, 5 Bas Leurs et al. define the elements and cycles “…of the methods and techniques which can be used throughout the user-centered design process”. The process begins with research and analysis, and progresses through conceptualization, design, development, and implementation.

A pattern emerges after enough time. Research plays a part in establishing credibility: it moves design decisions away from personal preferences, easing client relations in the process. Research functions as a lubricant, reducing friction around contentious issues and providing consensus among designers, developers, and clients. The upshot is that a clearly defined result, commonly understood facts, and relevant data make design discussions easier. Project stakeholders can move from debates of personal preference to decisions based on comprehensive understanding.

The Research First Model is based on several assumptions:

  1. We’re confronting a unique problem. We may confront problems that are unique to us, because we haven’t yet been asked to solve them in our own careers. But most problems have probably already been addressed by someone else. The fact that we may not be able to find an existing example doesn’t necessarily prove this assumption true, as it’s hard to know the things that we don’t know. 6

  2. There are many unknowns for both client and designer. In this case, people think the problem domain is so unfamiliar that undiscovered information will have a critical bearing on the project’s outcome. Although it may be true that something unknown could change the solution, this represents the exception, not the rule. For the vast majority of problems, the broad approach has already been discovered.

Design patterns help address this. 7 For example, if the user needs to “view data items from a potentially large set of sorted data that will not be easy to display within a single page”, we can display that list across several pages by implementing pagination. 8 If the “user wants to find or submit a particular piece of information based on a date or between a date range”, we can provide a calendar picker. We might need to change the way these patterns are implemented, but they provide us with a solid foundation. In situations where there doesn’t seem to be an existing pattern, it’s best to finish applying patterns in other parts of the project, and then return to the original problem and work on a customized solution in context.

  1. We design in a vacuum. Design doesn’t exist outside a context of business requirements. We’ll often discover that a client has many processes that work against a design solution, or that their organization is factional, or persistently infighting. The project changes because the research problem attains greater clarity, and suddenly we’re consulting on issues far more broad than the design of only one thing. When a project’s resolution acts as a “pipeline to your corporate soul”, 9 designers are suddenly confronted with far broader questions about their work.

  2. No previous research has occurred for this type of problem. Design process has been an area of study since the 1920s, and the subject of significant interest since WWII. 10 Interest in HCI and UX has existed for as long as computing itself. 11 The Web led to an explosion of research around what we practice. Common interactions adopt common, useful, and effective solutions. Through repeatedly applying these solutions, they become subtly refined over time. We don’t need to conduct any cognitive science research to discover them; all we need to do is figure out what’s been done before, and adapt it to the problem at hand. And along the way, we may find ways to improve them.

  3. There is enough time and money to conduct research. When it comes to institutionalizing research, an agency is its own worst enemy. Agencies emphasize research when upper management creates the budget for it. Likewise, if clients believe they need to focus on research, they’ll choose a research-focused agency. Freelancers or small boutiques may not be able to justify this cost, or they may not be able to successfully sell research to their clients.

  4. There are enough qualified interview subjects to conduct research. Even if there’s enough time and money for a formal research project, there may not be enough help from the target audience. This assumption is based on the existence of enough qualified, easy-to-find participants who can be guided by an experienced professional. Recruiting qualified researchers and participants can be difficult, especially for small firms. 12 In situations with tight timelines and poor resources, this issue can be circumvented through guerrilla-style research techniques. 13

  5. We can know everything relevant there is to know about the problem. This assumption justifies most research effort: the idea that we can discover and analyze all of a project’s relevant information. Though reassuring, this is a dangerous line of thinking that chases an impossibility. How do we ever know when we know “enough”? Horace Dediu refers to this as the Analyst’s Paradox. 14 Research is required, of course, and more research can lead to better analysis and decision. However, more research also means more time and money are expended before we can take action. At some point, we must always base our recommendations on a degree of informed intuition. Where do we draw the line?

Over the course of my career, I’ve seen many ways that the Research First model has worked against us. In one such instance, a client asked us to redevelop their content management system with customer-facing web pages that would be designed by a partner agency. The project repeatedly stalled, as both the client and my firm waited for the agency to conduct research and create ux deliverables. While waiting, we restructured the cms and familiarized ourselves with the existing content model, so we could determine how it could be modified.

As the other agency generated content requirements and wireframes for each type of page, we also called the client’s sales team and listened to the frustrations that they and their prospects currently faced. This simple act of “research” was really just a practical conversation, and it resulted in a lot of useful knowledge that we shared in team-wide meetings. We used our research to critique the other agency’s work, both confirming good ideas and pointing out problem areas. Surprised by our feedback, they frequently requested extra time to revise their work.

Subsequent meetings confirmed our previous discoveries. When the client finally approved our work, they provided the caveat that subsequent visual design would be subject to significant time constraints, which heavily narrowed our scope in the interest of meeting our deadline: hardly the outcome we meant to obtain.

In this example, of the seven assumptions that I previously outlined, all of them were disproven.

This experience isn’t unique. I’ve disproven these seven assumptions in many different circumstances, across many kinds of project. Time after time, deploying a proven pattern for a particular problem, asking questions, and comparing findings with known examples has resulted in effective, useful, economical solutions that provide robust foundations for a project’s future.

A New Approach: the Distributed Research Model

Knowing all of this, I propose a new way of working in an agency: the Distributed Research Model. Distributing research throughout an organization provides it with a cultural identity that can set a strong precedent for the future, while aiding its capability to solve common problems. Mule Design’s Mike Monteiro describes a similar model: 16

We don’t do research before we start designing, we do research as part of designing. This is an integral part of the design process. It cannot be taken away, otherwise you have not designed anything.

Even without dedicated research staff, we have consistently benefited from the following values:

Research helps everyone

Research can have many consequences beyond its ability to influence design decisions, and sometimes our research benefits people in other roles more than our designers.

Caveats

This approach doesn’t prohibit research: it simply generalizes it, and tries to spread internal knowledge as widely as possible. Instead of making research a discrete step, we need a pervasive culture of research.

You still need to discover what problem you’re going to solve. But your experience and general knowledge can serve you well; research can be simple, limited in scope, and far more economical than we commonly perceive it to be.

Concluding thoughts

In my experience, research works at its best as a pervasive, ongoing, and informal effort. Research is useful and appropriate in small focused doses, when it ceases to be a phase in and of itself. This helps build client confidence, which in turn develops your organization’s reputation as thoughtful and practical.

The Distributed Research model is:

To spread research with the client’s interests in mind, your business processes have to be flexible and your contracts must be well-written, allowing you to successfully arbitrate what should happen if things go wrong. But we’ve found that clients are generally happy, even relieved, to move at our speed, because we can quickly provide them with useful solutions and they can adopt a more hands-on approach.

My experiences may be different from yours. You may have worked in situations where projects have appropriate budgets or less constrained timelines. If that’s true, I congratulate you. See if you can’t use some of your time to research more, or to share more of its results across your organization. Increasing internal knowledge will always help a company, and we all stand to benefit from a culture built around sharing and collaboration.

  1. More thoughts on this notion are available at Paul Graham, The Top Idea In Your Mind.
  2. For example, Landor’s process once hinged on its proprietary Brand Driver™. See also Landor, “Capabilities: Brand Driver”, Landor.com (web archive version).
  3. Hugh Dubberly, How Do You Design? A Compendium of Models. Also see Models for a range of design processes.
  4. For one such example of the 4D model, see Services, MyProgrammer.
  5. Bas Leurs et al., Generic Work Process
  6. This leads to a phenomenon known as the Dunning-Kruger effect. For more on this, see Errol Morris, The Anosognosic’s Dilemma: Something’s Wrong But You’ll Never Know What It Is (Part 1), The New York Times
  7. Pattern libraries are a collection of repeatable solutions to common design problems. Inspired by the framework set forth in architect Christopher Alexander’s A Pattern Language and The Timeless Way of Building (Oxford University Press), design patterns can apply to programming (Erich Gamma et al., Design Patterns [Addison-Wesley]), user experience design (Jennifer Tidwell, Designing Interfaces [O’Reilly]), and many other fields.
  8. Yahoo!, YUI Pattern Library, ,a href="http://developer.yahoo.com/ypatterns/navigation/pagination/item.html">Item Pagination
  9. Alan Cooper, The pipeline to your corporate soul, Cooper Blog
  10. Vannevar Bush, As We May Think (PDF), The Atlantic via MIT
  11. For example, Richard Saul Wurman coined the term “information architecture” in 1974, almost a decade before the introduction of the personal computer. See also Richard Saul Wurman: The InfoDesign Interview (original link deprecated)
  12. The best participants for these studies have rarely, if ever, participated in one already, so they can use a product with few preconceptions about its utility. Fortunately, tools now exist that try to find a way around this problem, such as Bolt|Peters’s Ethnio.
  13. See also Cennydd Bowles and James Box, Undercover User Experience Design (New Riders); Jakob Nielsen, Guerilla HCI, useit.com; Jakob Nielsen, Discount Usability: 20 Years, useit.com; and Todd Zaki Warfel, x, (Rosenfeld Media).
  14. Horace Dediu, The Critical Path, Episode 12: Back to the Future, 7:01
  15. We certainly had, and we were able to suggest solutions and patterns that we had used before.
  16. 16. From the podcast Let’s Make Mistakes Episode 3: Making Things for People, 13:20. (currently unavailable online)
  17. We don’t have dedicated project managers in my firm, so our team leaders and client contacts collect and distribute our research instead.
  18. Don Norman corroborates this point in his Core77 essay Act First, Do the Research Later, Core77.com; and in Why doing user observations first is wrong, jnd.org.