Definitions of Terms
First, let’s get clear on what I mean by these terms: design, process, and methodology versus method. (For those you who are not as fascinated by the nuances of the English language as I am, please feel free to jump ahead to “The Process of Design.”)
What Is Design?
Because there are so many applications of design in our modern world, people look at design from many different perspectives when attempting to define the term. Design is both a verb—the process of design—and a noun—the product of design, as Kathryn Best notes in her book Design Management: Managing Design Strategy, Process and Implementation:
“Design describes both the process of making things (designing) and the product of this process (a design). … The activity of designing is a user-centered, problem-solving process….”—Kathryn Best
In this column, I’ll focus on the process of design. While Best has provided an apt definition of design, let’s consider some other good definitions. Kim Goodwin’s Designing for the Digital Age gives this definition of design:
“Design is the craft of visualizing concrete solutions that serve human needs and goals within certain constraints.”—Kim Goodwin
Ivan Chermayeff, cofounder of Chermayeff & Geismar, a New York graphic design firm said this about design:
“Design is directed toward human beings. To design is to solve human problems by identifying them, examining alternate solutions to them, choosing and executing the best solution.”—Ivan Chermayeff
In the Cox Review of Creativity in Business, Sir George Cox, former Chairman of the UK’s Design Council defines design as follows:
“Design is what links creativity and innovation. It shapes ideas to become practical and attractive propositions for users or customers. Design may be described as creativity deployed to a specific end.”—Sir George Cox
Michael Smythe, winner of the DINZ (Designers Institute of New Zealand) Outstanding Achievement Award for 2004, gave this definition for design:
“Design is an integrative process that seeks resolution—not compromise—
through cross-disciplinary teamwork. Design is intentional. Success by design simply means prospering on purpose.”—Michael Smythe
In his book Designing Business: Multiple Media, Multiple Disciplines, Clement Mok provides this definition:
“Design, in its broadest sense, is the enabler of the digital era—it’s a process that creates order out of chaos, that renders technology usable to business. Design means being good, not just looking good.”—Clement Mok
For the context of this article, here’s my definition: Design is the creative process in which we use our intuition and analytical ability to understand the opportunities and constraints business goals, competitive markets, customer needs, and technologies present, then envision, communicate, and realize practical solutions that meet customer needs and create business value.
What’s the Difference Between a Process and a Methodology?
Now, let’s explore how a process and a methodology differ from one another and why process is the right word for the activities we do when designing. Why does this matter? When communicating with clients or coworkers, designers must communicate clearly, in simple terms. Our goal should always be clarity, not trying to impress people with big words—especially when they’re the wrong words.
Why Is Design a Process?
According to Dictionary.com, the primary and long-standing sense of the noun process is “a series of progressive and interdependent steps by which an end is attained” or, more particularly, “a series of operations performed in the making … of a product.”
Thus, a process is holistic in nature and is devised with a specific goal in mind. While different organizations employ product design processes that are similar in many respects, their processes also differ in some ways. A product design process must be flexible enough to meet the needs of both a particular organization and a particular project. It’s just one part of a larger business process—an organization’s product development process. To achieve specific business goals within a particular context, we often adapt our product design processes to some extent. For example, as an independent consultant, the activities I’d include in my design process and the way I’d approach them would differ somewhat depending on what user research resources were available for a project or whether a software development team was doing agile development rather than taking a waterfall approach.
User-centered design is, by nature, an iterative process, so what we discover through user research and usability testing often dictates the way a project should proceed. Thus, design is a flexible and evolving process, not a codified method—which is probably the word you were looking for if you called design a methodology—or a precise recipe you should follow on every project to ensure success. While an effective design process does provide a framework within which you can work, there’s usually some need for improvisation along the way when designing products.
Why Is Methodology the Wrong Word for Design?
The Random House Dictionary defines a methodology as “a set or system of methods, principles, and rules for regulating a given discipline….” The American Heritage Dictionary of the English Language defines the two main senses of the term methodology as follows:
- “A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods….
- “The study or theoretical analysis of such working methods.”
Dictionary.com gives this definition of the suffix -ology: a “branch of knowledge, science.”
So, a methodology is a body of knowledge comprising the principles, guidelines, best practices, methods, and processes relating to a particular discipline such as interaction design or user research. Design patterns are an important part of interaction design methodology. A methodology is a much broader concept than a process. Interaction design methodology is much more than the activity of design.
What’s the Difference Between a Methodology and a Method?
The Random House Dictionary says the word “method refers to a settled kind of procedure, usually according to a definite, established, logical, or systematic plan.” The American Heritage Dictionary defines a method as a “procedure, especially a regular and systematic way of accomplishing something” or “the procedures and techniques characteristic of a particular discipline or field of knowledge….”
Dictionary.com makes the distinction between these two terms clear: “a method is a way of doing things; a methodology is a set or system of methods.” The American Heritage Dictionary of the English Language also provides the following usage note:
“Usage Note: Methodology can properly refer to the theoretical analysis of the methods appropriate to a field of study or to the body of methods and principles particular to a branch of knowledge. In this sense, one may speak of objections to the methodology of a geographic survey—that is, objections dealing with the appropriateness of the methods used—or of the methodology of modern cognitive psychology—that is, the principles and practices that underlie research in the field. In recent years, however, methodology has been increasingly used as a pretentious substitute for method in scientific and technical contexts…. … But the misuse of methodology obscures an important conceptual distinction between the tools of scientific investigation—properly methods—and the principles that determine how such tools are deployed and interpreted.”
In UX design circles, the increasingly common use of the term methodology in lieu of method is likely the result of our close association with colleagues who are user researchers and software engineers. While researchers usually use methodology appropriately, that American Heritage usage note definitely applies to the way some software engineers use the term.
Achieving optimal design solutions requires an effective design process that provides a framework within which designers can consistently deliver high-quality work. To the greatest degree possible within the constraints of a particular product development effort, this should be a user-centered design (UCD) process, but such constraints also require that it be a flexible process. As Figure 1 shows, a complete product design process—or what I call a UC3D Lifecycle™—comprises three phases: Discovery, Design, and Development Support.
“If you want to push design into new areas, you have to work closely across the boundaries of people’s trades and professions. If you know the questions to ask, you can pull out the expertise.”—Jeanne Gang
During the Discovery Phase of a product design process, your focus is on understanding the strategic goals for a product development effort; learning about target users’ characteristics and the tasks they’ll perform using your product through user research, user modeling, and task analysis; and eliciting and defining the product requirements that bound the design problem you’ll solve. I’ll discuss these key Discovery Phase activities in depth:
- Learning about your users
- Modeling your users
- Analyzing your users’ tasks
- Eliciting and defining clear product requirements
During the Discovery Phase, get answers to these questions to develop a deep understanding of the product design project on which you’re embarking:
- What is the product vision?
- How does the product fit into the organization’s overall business strategy?
- What are the business goals for the product?
- How big is the market for the product, and what share of the market can it win?
- What is the revenue model for the product?
- What are the assumptions on which the product strategy is based?
- When is the planned product release to occur? What are the market constraints that affect its timing?
- What is nature of the competitive marketplace for the product?
- What is the expected impact of the product on the organization’s brand value and position in the marketplace?
- What competitive products already exist in the product’s domain? What products are the leaders in innovation and market share? What are their strengths and weaknesses?
- What differentiates the product from other products in the marketplace?
- Who are the key stakeholders, subject-matter experts, and members of the product team, and what are their roles on the project?
- What type of product development process does the product team intend to follow? Agile or a more traditional approach?
- How many engineers are on the development team that will build the product you’re designing? What are their skills?
- What are the risks for the product development project?
- Who is typically involved in decisions to purchase the product?
- Who are the product’s target users?
- Do people in different roles need to use the product?
- What customer needs, desires, and preferences must the product satisfy?
- Are there innovative product concepts or technology innovations the product can leverage? If so, what opportunities do they present? Or is incremental or evolutionary improvement the goal for the product release?
- What are the product requirements?
- What capabilities must the product have?
- Do your customers require the product be customizable and/or personalizable?
- What workflows and tasks must the product support?
- What information needs must the product address?
- If there is already an existing product, what is the historical background for the product and its design? What are its known usability problems? What are customers complaining about or requesting?
- Are there existing user experience design guidelines you must follow?
- Are there corporate and/or product branding guidelines that will dictate some aspects of the product’s look?
- What technical constraints must you consider when designing the product?
- What are the time and budgetary constraints on your design project?
“Several research methods can provide data upon which we can build user archetypes. … We can aggregate and synthesize user research—of many shapes and sizes—to form audience segmentations that encapsulate sets of characteristics, needs, and behaviors.”—Steve Baty, from “User Research for Personas and Other Audience Models,” on UXmatters
Because a good product design process is essentially a user-centered design process, user research should ideally provide the basis for a product design effort. However, the degree to which design can rely on rigorous user research and sound data is subject to an organization’s resources—including people with expertise in user research, time, and money. Therefore, designers must be flexible in obtaining the best data that is available to them.
The primary goal of conducting generative user research is to elicit qualitative data that enables your product team to develop a product that meets users’ needs. When your team is defining a new product, user research helps you identify unmet needs your product can satisfy and define a product that can win success in the marketplace. User research lets you understand potential users’ mental models, the terminology they use, the context of their work, how they currently perform their tasks, and what opportunities exist for better supporting their tasks.
When conducting user research for an existing product, you can learn more about the characteristics, needs, desires, and preferences of your users. You can also assess how well you are meeting users’ needs by ascertaining their perceptions of your current product, identify usage patterns for your product, and determine how usable your current product is. Find out what pain points users are currently experiencing with your product, so you can fix them in the next release.
In my opinion, user research is best performed by user researchers who are experts in generative user research and/or usability testing. (Since this column is focusing primarily on activities that are typically the responsibility of interaction designers, I refer you to the many excellent articles UXmatters has published on the topic of user research.) However, if you are an interaction designer on a UX team that does not include any user researchers or the user researchers on your team don’t have the bandwidth to work on your project, it may be necessary for you to do your own user research—assuming there’s time and budget for you to do so.
But what if there is no time or budget for user research? If you’re working on an existing product, you may need to rely on whatever product data you can gather from such diverse sources as customer feedback, trouble reports from the technical support database, and analytics, and whatever employees of your organization who have direct contact with users can tell you about them—including technical support representatives, market researchers, sales representatives, and business development managers. If you’re new to the product team, do an expert review of the product to determine its usability issues and opportunities for improvement.
For a proposed product, consider doing a competitive analysis of other products in the same domain—or, at least, some overlapping domains whose products bear certain similarities to your product. Try to find out about users’ and the press’s response to competitors’ products. You could do an expert review of competitive products to assess their strengths and weaknesses. Perhaps there’s some pertinent academic research that could provide some useful data.
Do whatever you can to gain an understanding of your users. Use your intuition to put yourself in your users’ place. Empathy with your users can take you a long way toward designing what they need and want. Once you truly understand your users, this understanding provides a sound basis for modeling your users.
“The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honors the servant and has forgotten the gift.”—Albert Einstein
“The most important model is a set of personas, which are user archetypes that help you make design decisions and communicate your rationale. Each persona represents a set of behavior patterns and goals. By designing for these archetypal users, you can satisfy the needs of the broader range of people they represent. Every product decision can be tied back to the personas.”—Kim Goodwin
Once you’ve obtained the best data possible about your product’s potential or actual users, your product team can collaboratively develop user profiles or personas—which are fictional user archetypes that are representative of your target users.
User modeling begins with an in-depth analysis of patterns in the user data you elicited during user research. Based on your analysis, you can develop a set of clearly differentiated user profiles or personas that represent a few important classes of users whose goals and needs you intend your product to serve. Each user profile or persona in the set embodies a specific class of target users who
- have common roles, goals, and motivations
- have similar skills and characteristics
- share common mental models
- work in similar contexts
- share a similar range of behavior patterns
- typically perform certain tasks
When developing user profiles or personas, answer these questions about your product’s target users:
- Who are your target users?
- What are their motivations and goals?
- What tasks do they typically perform? How frequently?
- What are their mental models of their tasks?
- What differentiates different types of users?
- How many user profiles or personas should you create?
- Who are the primary target users for whom you’re designing your product?
- Are there secondary target users whose needs you want to accommodate and require only minor changes or additions to your product’s feature set?
- What features make your product useful to your target users?
- Are there other types of users whose needs are met by the features that satisfy your primary and secondary target users?
- Are some types of users edge cases whose needs you should not consider when designing your product?
- What user needs, desires, and preferences must your product satisfy?
- If your product is to satisfy these needs:
- What is the appropriate scope of its functionality?
- What key usage patterns and tasks must it support?
- What information needs must it address?
Benefits of User Modeling
It is essential that all the members of your product team have a common understanding of your target users’ characteristics and needs. Through developing user profiles or personas, everyone can gain this common understanding.
The user profiles or personas you develop during user modeling help you analyze your product’s task domain from your users’ perspectives and provide a sound basis for assessing user requirements during requirements definition. User profiles or personas facilitate communicating with stakeholders and other members of your product team about specific types of users and help build consensus. They also help ensure your entire product team stays focused on your target users’ needs throughout the product design and development process. You can use your user profiles or personas in prioritizing bug fixes, developing product documentation, and marketing your product.
“Good design happens only when designers understand what users are trying to accomplish—the users’ goals and tasks—and how the users think about their tasks—the users’ conceptual model of the work and tools.”—JoAnn Hackos and Janice ‘Ginny’ Redish
Understanding user goals and the task domain the product you’re designing will support provides the basis for designing its workflows—a key element of product design. You can gain that understanding through doing a thorough task analysis. Ideally, you’ll be able to base your task analysis on good data user researchers on your UX team have elicited from potential or actual users. But when there is no budget for user research, it’s sometimes necessary to cobble together your domain knowledge from whatever information you can glean about target users’ goals and tasks from your competitors, academic research, and your organization’s Marketing, Sales, User Assistance, and Customer Support teams.
During task analysis, you should answer these questions about your users’ goals and tasks:
- What goals do your target users need to accomplish? (Focus particularly on the goals of your primary target users—and make sure they’re actual goals rather than accommodations users have made to their existing tools and processes.)
- Why do your target users need to accomplish these goals?
- Do different users have different roles and goals and, therefore, perform different tasks? How do users in these roles interrelate?
- What tasks do your target users currently perform to achieve these goals?
- How do your target users currently perform these tasks—whether they’re using your product, a competitor’s product, or working in the real world? What tools do they use?
- In what contexts are your target users working?
- What are your target users’ mental models of their tasks?
- What terminology do your target users use to describe their tasks and data?
- In what sequences do your target users perform their tasks? What are the relationships between different tasks?
- What are your target users’ high-priority tasks? These include
- tasks that are important to users’ successfully achieving their main goals
- tasks users perform most frequently
- What are your target users’ information needs?
- What information do users need to successfully complete each task?
- How do they use the information that results from completing each task?
- Would it be possible to automate certain tasks or steps and eliminate the need for users to perform them?
Conducting a Task Analysis
Here’s a brief overview of the process of conducting a task analysis:
- Identify your target users’ tasks, focusing primarily on their high-priority tasks.
- Decompose those tasks into their constituent subtasks.
- Break down each task and subtask into step-by-step procedures, or task flows—each of which typically comprises the following:
- inputs to a procedure
- cognitive processes
- actions on objects
- decision points
- results of the procedure
- Determine how you can refine or redefine your target users’ current task flows to improve their efficiency or better support your users’ goals.
Benefits of Doing a Task Analysis
The understanding you gain from doing a task analysis can help your product team determine the appropriate scope of your product’s proposed feature set when defining requirements—or, if you’re working in an agile context, the user stories your product must support. Task analysis informs your design of new workflows, interaction models, and layouts for your product’s user interface during conceptual modeling, ideation, and design.