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:

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

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.

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.

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.

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.

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

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.

The problems confronting the client were not unique. They wanted to make it easier for their customers to get the right information about their software. This is a common problem in our field, and I’m sure the design team had experienced it in similar forms. In fact, their organization ostensibly exists to address this very problem.

There weren’t many unknowns. The sales team already knew most of the problems, and had relayed the information to other team members. This was clarified in phone conversations, where we discovered a disconnect between what users expected and what they experienced. Meanwhile, the design team contacted some of our client’s customers to find out about their experiences. Despite translating through the sales team, we had more accurate information than the other agency’s team did, and because we frequently shared our findings with each other, we were able to act on them more quickly.

The design team’s research didn’t help when it became apparent that our client faced internal criticism. This was compounded by the short timeline that the client’s executives had established.

In fact, previous research had already occurred. How do you connect prospective customers with useful information? What does the prospect need to know before they speak with you? What do you want them to know that makes your product more compelling than that of your competitors? Surely these questions have been answered before, and the other agency’s designers must have confronted them regularly with other clients. 15

There wasn’t enough time, money, or participants to create quality research. Assumptions 5 and 6 became problematic when the design team requested more time for research and analysis, even when the rest of the project was behind schedule. The client was already convinced that the problem had been defined, and they believed that we had sufficient information from our interviews.

Finally, the design team couldn’t comprehensively understand all of the problems that the sales team confronted. Again, substantial information was already available through previous conversations. Although our information wasn’t entirely precise, it was useful enough to act on before the project’s deadline.

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:

Always research. Keep your radar on. Record and share the details of every story, essay, article, and book that you encounter. This builds internal knowledge that more forcefully informs future decisions. Spreading that knowledge also ensures a broader understanding of any research activity.

Always experiment. We try new things as often as possible. We try new design tools, prototyping techniques, visual effects, and programming methods. Sometimes we abandon them because they aren’t a natural fit at the time, but we always leave the door open to revisit them later. Either way, the results are treated as internal research, and they become part of the firm’s general knowledge.

Conduct multiple activities at once. Be wary of projects that don’t allow you to conduct multiple activities at the same time. If a “waterfall” project’s steps contain all previous steps as prerequisite, it probably isn’t the most efficient use of your time and effort. Not only can this impair your speed of delivery, it also makes the project harder to mine for research.

Try to create something that is useful now. If knowledge is widespread in your organization, it builds closer relationships that allow you to work more quickly without second-guessing each other as often. Working quickly allows smaller iterations, which provide more flexibility if things aren’t working. It also places your client in a posture of action: they’re primed to respond to ongoing work, and encouraged to keep up with the project’s momentum, with greater focus on what work needs to be done.

Sacrifice the project’s scope if needed. Rather than sacrifice quality under tight timelines or small budgets, we narrow the project’s scope and adapt any previous work to solve the new set of problems. Usually, narrowing the scope identifies the core problems that must be immediately addressed. But we do this with an eye to the future, so the client has a useful starting point for incorporating the rest of the features at a later time.

There is no spoon. Design processes are flexible, and precedent shouldn’t set them in stone. Take the time to occasionally reevaluate how you work together. Don’t be slaves to any process that takes too long and imperils the project’s budget.

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.

Project managers benefit from all agency activity if they treat it as research. Any progress on the project – good or bad – provides internal research that people can reference for future similar projects. 17

Salespeople, principals, and planners can compare the agency’s patterns of income and expenditure, pointing out where costs are focused in order to manage potential issues before they become harder to handle. They can also get a sense of whether new prospects are exhibiting the same kinds of “symptoms” as existing problematic clients.

Account managers could research opportunities for follow-up projects and refinements after a project has been finished. This applies to all manner of communications, including refining or supplementing publications, or adding additional features to previously launched websites. Ongoing relationships are based on chains of incremental improvements over a long period of time.

Developers can benefit from research as well. For example, in our work for a global enterprise software company, the conversations we had with their sales and technical teams provided crucial insights for the information architecture, user experience design, and visual design that would follow.

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:

Pervasive. Research must happen in every area of the company. Everyone has something valuable to share.

Fast. Research should be handled frequently and incrementally; don’t let it pile up. Both you and your client will feel more confident if you make research a routine action. 18

Repeatable. By generalizing the process to any kind of information and any team member, it’s easy to accumulate a lot of knowledge.

Catalogued. On the other hand, it’s possible to have too much knowledge. Eventually, enough research builds up that it needs to be categorized and curated if it’s going to be of any use.

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.

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.

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)

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.