Design Is a Process, Not a Methodology

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:

1. “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….
2. “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.

The Process of Design

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.

Discovery Phase

“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:

1. Learning about your users
2. Modeling your users
3. Analyzing your users’ tasks
4. 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?

Step 1: Learning About Your Users

“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 painpoints 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

Step 2: Modeling Your Users

“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.

Step 3: Analyzing Your Users’ Tasks

“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:

1. Identify your target users’ tasks, focusing primarily on their high-priority tasks.
2. Decompose those tasks into their constituent subtasks.
3. 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

4. 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.

Step 4: Eliciting and Defining Clear Product Requirements

“Requirements definition connects the dots between research and design…. Your ability to see through the eyes of the personas and clearly define needs before seeking solutions will provide tremendous value in product definition.”

—Kim Goodwin

During product definition, your user research, data analysis, user modeling, and task analysis let your product team take a user-centered approach to defining and prioritizing product requirements. Every design process should start with clear product requirements that determine the scope of the product your team will design and build and define what capabilities, features, and qualities your product must have. These product requirements include the following:

• business requirements—These requirements have their basis in strategic business goals for your product. Defining the business requirements for your product is primarily the responsibility of your organization’s business leaders and/or the product manager on your product team. Business requirements should answer these questions:
  
  • What is the product vision?
  • Are we solving the right problem?
  • What business goals must the product satisfy?
  • What is the product’s revenue model?
  • What is the timeline for the product’s release?
  • What are the time and budgetary constraints for the overall product development effort and, in particular, for your design effort?
• market requirements—Your organization’s product strategy and business goals and your product’s place in the competitive marketplace dictate what capabilities, features, and qualities your product must have. Defining the market requirements for your product is primarily the responsibility of the product manager for your product. Market requirements should answer these questions:
  
  • What is the product’s essential functionality? What features must it include to compete in the marketplace?
  • What other possible features might the product include? What are their priorities?
  • What differentiates the product from other similar products in the marketplace?
  • For an existing product, what features have customers requested?
  • What information does your organization want to communicate to users?
  • What information does your organization want to obtain from users?
  • What technologies must the product employ? With what other products must it be compatible?
  • What standards of performance must the product achieve?
  • If the product is a software product, for what platforms is the product to be developed?
  • Is the product a standalone product or part of a product suite?
  • What user assistance or documentation does the product require?
  • What training and technical support will the product require?
  • For what international markets is the product to be developed?
• user requirements—These requirements have their basis in your user research, data analysis, user modeling, and task analysis. If your primary responsibility is the interaction design for your product, you should work collaboratively with the product manager on your product team to define user requirements for your product, basing them on a deep understanding of your primary and secondary target users’ goals, desires, needs, and tasks—and for an existing product, your awareness of the painpoints users are experiencing with your product. Satisfying these requirements is essential to developing a product that can succeed in the marketplace. Ensure that your product manager always states user requirements in terms of capabilities, not design solutions. User requirements should answer these questions:
  
  • What capabilities and features must your product provide to satisfy your target users?
  • What must your target users be able to do using your product? What workflows and tasks must your product support for your target users to be able to accomplish their goals efficiently?
  • What needs, desires, and preferences must your product satisfy for your target users? What qualities must your product have?
  • What information needs do your target users have? When do they need information? How should your product provide the information they need, when they need it?
  • What data must your product enable your target users to provide or create and save?
  • What kinds of data objects should your product let your target users manipulate?
  • Are there different user roles your product must accommodate?
  • Do your target users require your product to be customizable and/or personalizable?
  • What standard of usability must your product achieve?
  • For an existing product, what painpoints does your product redesign need to address?
• technical constraints—Because your design solutions must satisfy technical constraints, they limit the possible design solutions for your product. The product manager and/or system architect on your product team are responsible for defining these technical constraints. Be sure to find out what technical constraints you must consider when designing your product. These technical constraints may cover the following:
  
  • database constraints
  • technology constraints and requirements
  • performance requirements
  • operational requirements
  • maintainability requirements
  • reliability requirements
  • safety requirements

One example of a technical constraint that often limits the improvements designers can make to existing software products is their database structure. With the time pressures of getting a product release out, developer’s may be reluctant to restructure a product’s database, because of the complexity of handling existing dependencies. This is why it is so important to do a thorough objects and actions analysis during conceptual modeling, taking into account the necessary attributes of each object. When initially designing your product’s database, if your development team correctly identifies and creates all of the necessary data elements, it’s much less likely they’ll need to change the database structure later on—unless requirements change significantly.

Defining clear product requirements that are based on good user research and analysis ensures that your product team builds the right product to meet your users’ needs—a product that has potential for success. Ideally, as the person responsible for interaction design, you’ve been involved in the product development process from its inception and have had a voice in defining these product requirements.

The strategic vision and requirements for your product define the design problem for which you’ll devise a solution during the Design Phase. Once your product team has established the scope of the next product release and has defined clear product requirements for the product your team will design and build, you’re ready to begin the design activities that occur during the Design Phase.

Design Phase

“The recognition and understanding of the need was the primary condition of the creative act. … Only when you get into the problem and the problem becomes clear, can creativity take over.”—Charles Eames

By the beginning of your Design Phase, your entire product team should have a thorough understanding of business, market, and user requirements for your product, the opportunities that your organization’s technological innovations present, and the budgetary, scheduling, and technical constraints for your product development project.

During your Design Phase, you’ll follow an iterative design process through which you’ll gradually refine your concepts and designs, creating progressively more detailed designs and higher-fidelity prototypes. Conceptual modeling lets you look at your product’s concepts, workflows, features, and language from a user’s viewpoint. During ideation, you’ll rapidly generate sketches of possible ideas for workflows, layouts, and interaction models, evaluate the pros and cons of each design approach, and refine your best design solutions. Once you choose your best solution, you’ll design it in full detail—creating mockups and specifications or prototypes. At any stage in this iterative design process, other members of your UX team can evaluate your designs through design reviews and/or usability testing, and you’ll revise your design to incorporate their feedback. I’ll discuss the following Design Phase activities in depth:

5. Developing conceptual models
6. Solving key design problems through ideation
7. Doing detailed design

Step 5: Developing Conceptual Models

“A conceptual model … [expresses] the concepts of the intended users’ task domain: the data that users manipulate, the manner in which that data is divided into chunks, and the nature of the manipulations that users perform on the data. It explains, abstractly, the function of the [product] and what concepts people need to be aware of in order to use it.”—Jeff Johnson

Once you understand your target users’ current tasks and workflows, it’s important to do conceptual modeling before diving into ideation and detailed design. Conceptual modeling is a preliminary design activity that helps your product team see your product’s concepts, workflows, features, and language from your users’ viewpoint and envision, define, and design products that are simpler, more consistent, and easier for users to understand.

During conceptual modeling, answer these questions about the product you’re designing:

• What concepts from your product’s task domain must its user interface reveal to users? How do these concepts inform your product’s workflows?
• Are there new concepts that are specific to your product? Do you need to devise new, innovative workflows for them?
• What language should your product use to communicate these concepts?
• What business goals must your product satisfy for your organization? How can your product’s workflows support these goals?
• What functionality must your product provide? How do the relationships between different types of functionality impact your product’s workflows?
• What tasks and task sequences should your product’s user interface present to users? How would you describe these in the form of task scenarios? Where and in what order should your product present them? How are they interrelated?
• What design patterns are characteristic of your product domain? Are there
  standard workflows for this domain?
• What settings must your product provide? Where should this functionality
  reside within your product’s workflows? What are the appropriate defaults for these settings?
• What data do your users need to create, view, and edit with your
  product? What other actions do users need to perform on their data?
  Do these tasks require separate workflows?
• Are there other data sources with which your product must be compatible?
  What forms of data output should your product provide? How do the
  sources and outputs of your product’s data impact its workflows?
• Is there functionality for which your product should provide shortcuts
  to support users’ key tasks? Would this necessitate your providing different workflows for
  the same functionality?

Developing Conceptual Models

Conceptual modeling is often a collaborative process, involving
various people on a multidisciplinary product team. During conceptual modeling,
you can help your team to develop a shared understanding of your target
users’ mental models of their tasks, the planned scope of your product’s
functionality, and the primary workflows and task scenarios for your product
domain. Then, based on this understanding, you can develop the following:

• a high-level conceptual model—Create
  a diagram that clearly illustrates the overall structure
  of your product’s user interface—showing its key components and
  content areas—and represents its primary workflows as you want users
  to perceive them.
• task scenarios or storyboards—Write
  high-level, narrative descriptions of all essential tasks for your product’s task
  domain—or draw storyboards that represent them visually. These are the tasks your target
  users must be able to perform using your product.
• objects/actions analysis—Analyze
  what task-domain objects your product must present to users—including
  data elements and tools—and the actions users can perform on or with them. Organize these objects into either
  
  • a type hierarchy—Organizing objects by type shows the similarities and relationships between them, reveals their natural groupings, ensures consistency in the representation of objects and actions in your product’s user interface, and can simplify your product’s interaction models.
  • a containment hierarchy—Organizing objects according to which objects contain other objects provides a clear structure for your product and natural groupings for its features.
• product lexicon—Develop a lexicon of terms for the objects and actions your product presents to users. Doing this helps ensure consistency in your team’s use of terminology.

Benefits of Conceptual Modeling

“The designer has an obligation to provide an appropriate conceptual model for the way that the device works. It doesn’t have to be completely accurate, but it has to be sufficiently accurate that it will help in both the learning of the operation and also dealing with novel situations.”—Don Norman

Developing a high-level conceptual model of a product domain and expressing its tasks—either verbally or visually—are essential parts
of the conceptual modeling process. Together, your conceptual model and task scenarios enable you to create efficient workflows
and task-oriented groupings of features. Efficient workflows ensure users can successfully complete their tasks—in
the sequences in which they normally perform them—and accomplish their actual goals.

Once you’ve defined a conceptual model for your product, the nature and scope of
the product your team is developing become clear, your developers can begin developing its underlying technology, and you have the foundation upon
which you can build your product’s workflows.

Most of the work of envisioning a product’s workflows occurs during conceptual modeling and ideation, the next stage in the process of designing a product.

Step 6: Solving Key Design Problems Through Ideation

“Good designers relentlessly generate lots of ideas
and open-mindedly consider alternative solutions. At no time are good designers
frightened to entertain a crazy, competing, or uncomfortable idea.”—Karl
Ulrich

Now that everyone on your product team understands your target users’ current task flows and conceptual models, you’re ready to envision product workflows and interaction models that will enable users to more efficiently and effectively perform the tasks that let them achieve their goals.

During ideation—which, like conceptual modeling, is typically a highly collaborative process—everyone on your product team
has an opportunity to communicate requirements and constraints and contribute
design ideas. Ideation involves rapidly generating many different possible
workflows and user interface design solutions and capturing them by sketching
designs on easel pads or whiteboards or in notebooks.

To facilitate idea generation during ideation, explore these questions with your product team or UX design team:

• How should we reveal concepts that are unique to our product’s task domain? Are there appropriate metaphors for these concepts?
• Do we need
  to devise innovative interaction models for new features that are specific to our product’s task domain? Or can we borrow interaction models from other task domains?
• What design elements from another type of product—like mobile phones, consumer electronics devices, games, or cars—might be applicable in this product domain?
• What benefits would an innovative interaction model provide? Are those benefits sufficient to warrant the resulting inconsistency with either other products in the same domain or similar features in other products in different domains?
• How should our product’s user interface best represent the functionality it provides? Are there existing design patterns we can employ?
• For what features should we employ standard design patterns rather than innovative interaction models?
• What user interface elements or interaction models would best facilitate users’ changing certain settings our product provides?
• How can we facilitate users’ learning our product?
• How can we make our product’s user interface more consistent—both internally and externally, with other products?

Once your product team has generated lots of good ideas, you can ask them these kinds of questions to help them improve their ideas:

• How can we refine our ideas?
• Can we combine any of our ideas?
• What do certain ideas have in common?
• What differentiates certain ideas?
• How can we simplify a particular idea?
• On what assumptions is a particular idea based?
• How can we make an idea better address specific requirements?

Evaluate the pros and cons of each proposed design solution, iteratively refine your team’s best ideas, then decide
which solutions to design in detail and develop.

Note—I’m not generally a fan of formalized ideation processes like brainstorming. Though
they are sometimes helpful when working with very large teams or on projects with many stakeholders, they’re
not usually necessary for close-knit product teams that have constructive interpersonal
dynamics and whose approach to working together is truly collaborative. That said, the next time I find myself in a situation that calls
for such a process, I’d like to try Mike Myles’s collaborative parallel design approach, which he’s
described in his UXmatters article, “Using a Collaborative Parallel Design Process.” It
seems to be a very balanced approach that both stimulates team members’ creativity
and ensures collaboration, while avoiding being overly controlled or constrained. In fact, in some ways, it mirrors the informal ideation process I follow
when working collaboratively with product teams.

When doing ideation with a small, highly collaborative product team, comprising people who are neither inhibited nor intimidated by criticism, I actually prefer to receive and offer immediate feedback on ideas. In such cases, I find that hearing the pros and cons of each idea along the way is highly stimulative of creative thinking, resulting in our leveraging early design ideas to devise even more possible design solutions, coming up with better solutions that solve the problems participants have identified in solutions we discussed earlier, and in the end, producing more highly refined design ideas.

From ideation, you’ll move forward to your detailed design activities with basic design solutions for your product’s primary
workflows, as well as some common interaction models and layouts for its key user interfaces—solutions
for which you already have your team’s buy-in. During detailed design, you’ll create a coherent product design solution that incorporates all of
your team member’s best ideas.

Step 7: Doing Detailed Design

“User interfaces should be designed iteratively in almost all cases, because it is virtually impossible
to design a user interface that has no usability problems from the start. … Iterative
design is specifically aimed at refinement based on lessons learned from
previous iterations.”—Jakob Nielsen

Good interaction design is an iterative process that starts during ideation with sketching and continues in progressively greater detail throughout your
Design Phase. Once your product team has agreed on some basic design approaches during ideation, you’ll evolve and elaborate on them
during detailed design, continually refining your interaction design solutions by optimizing workflows and interaction models, and creating design artifacts that communicate them effectively.

During detailed design, you’ll determine all of your product’s workflows and solve the full range of interaction design challenges your product presents, devising a holistic design solution that satisfies all of the requirements your product team defined during requirements definition. Throughout detailed design, you’ll work closely with your product development team to ensure your designs take full advantage of technology opportunities and observe all technical constraints.

When creating your design artifacts, you might choose to create flowcharts that illustrate the overall structure of your product’s user interface, as well as its primary workflows. You might create wireframes that define your product’s key components and content areas and show its primary workflows. You can annotate your flowcharts or wireframes to begin to capture design details.

You can provide comprehensive and detailed specifications—for either your entire product or particular features—in interaction design specifications that describe your product’s user interfaces, workflows, interaction models, and behaviors, including low- or high-fidelity mockups that show its screens. (Since my previous column, “Specifying Behavior: With an Example Menu Behavior Specification,” discussed how to communicate interaction design in detail, I won’t delve deeply into that topic here.)

Alternatively, you can develop interactive prototypes, with either low- or high-fidelity interactivity, and show how your product should behave. However, when developing prototypes, you still need to describe your user interface to some degree, writing specifications that fill in details you haven’t implemented in your prototype to ensure your development team doesn’t make any wrong assumptions about your intent.

Another alternative for communicating your interaction design solutions, usage scenarios describe the step-by-step procedures users can follow to accomplish their tasks using your product and incorporate screen images representing those interactions.

Once first drafts of your design artifacts are complete, you can present your design to your UX team in a design review meeting, so other members of your team can provide feedback. Ideally, your UX team should thoroughly evaluate your design solutions by doing expert reviews and/or usability testing. You’ll iteratively refine your designs, incorporating the feedback you receive from your peers and through usability testing into your design artifacts.

Key members of your product team—representing each discipline, including product management, marketing, product development, quality assurance, and documentation—should thoroughly review your design artifacts and provide detailed design feedback on your design solutions—perhaps on a wiki. Some key team members may choose to have others in their discipline review your design artifacts and provide feedback, then compile their team’s feedback for you. Be sure to encourage them to call any information that is missing from your design artifacts to your attention.

Once you’ve assessed their feedback, incorporate all changes with which you agree into your design artifacts. Then invite key members of your product team to a review meeting, so you can discuss any open issues regarding your design solutions or your design artifacts. Your design artifacts must adequately serve the needs of the product developers who will follow them in building the product, quality engineers who will use them in creating their test plans, and user assistance professionals who will employ them in both creating their user assistance or documentation plans and in writing Help or users’ guides.

In response to all of this feedback, you’ll make further refinements to your design solutions. Once you and your product team are satisfied that you’ve devised optimal design solutions—within the constraints of your product development project—all stakeholders
will approve your design artifacts for implementation.

Development Support

During the Development Support Phase, an interaction designer’s continuing involvement on a project ensures that the product team stays focused on your users’ needs throughout the product development process.

Step 8: Providing Development Support

Your iterative process of design refinement should continue throughout product development—as developers discover they need additional design details or yet another status or error message. You should be available to answer any questions your developers might have about your specified design solutions, resolve any design issues that arise during development, and clarify or amend your design artifacts as necessary. This ensures your product gets built as you designed it—according to your design specifications and other design artifacts. Plus, keeping your design artifacts in synch with the product under development lets quality assurance engineers and user assistance professionals rely on your design artifacts in planning and doing their work.

If your product team discovers it was overly ambitious in defining goals for the current release or a particular element of a design solution proves to be more difficult to implement than initially expected, the development project’s scope might change. In such an event, you’ll need to revise your design solutions and artifacts to reflect the project’s diminished scope.

During Development Support, you should also instruct the user assistance professionals and other content developers on your product team in the use of your product’s lexicon. Marketing and User Assistance should always describe your product using the same terms.

As increasingly functional builds of the product become available during product development, your UX team may do additional usability testing. At this stage, if testing reveals show-stopping usability issues or usability issues such as terminology issues that require only simple fixes, you’ll need to do another round of revisions on your design solutions and artifacts. However, most of the usability issues you discover this late in the product development lifecycle won’t get addressed until a subsequent product release.

The Development Support Phase culminates in your product team’s delivery of a high-quality product that meets users’ needs and is easy to learn and use.

In Conclusion

In this column, I’ve described an effective, user-centered product design process that encompasses the following steps:

1. Learning about your users
2. Modeling your users
3. Analyzing your users’ tasks
4. Eliciting and defining clear product requirements
5. Developing conceptual models
6. Solving key design problems through ideation
7. Doing detailed design
8. Providing development support

In my next column, I’ll embark on a multipart series that discusses the essence of interaction design. 

References

The American Heritage Dictionary of the English Language, Fourth Edition. Orlando, FL: Houghton Mifflin Harcourt Publishing Company, 2009.

Best, Kathryn. Design Management: Managing Design Strategy, Process and Implementation. Lausanne, Switzerland: AVA Publishing, 2006.

Cox, George. Cox Review of Creativity in Business: Building on the UK’s Strengths. London: British Chancellor of the Exchequer, December 2005. Retrieved July 18, 2010.

Design Feast. “Thoughts on Design.” Retrieved July 18, 2010.

Dictionary.com. Retrieved July 18, 2010.

Goodwin, Kim. Designing for the Digital Age: How to Create Human-Centered Products and Services. Indianapolis, IN: Wiley Publishing, 2009.

Hackos, JoAnn T., and Janice C. Redish. User and
Task Analysis for Interface Design. Indianapolis, IN: John Wiley & Sons,
Inc., 1998.

Johnson, Jeff. GUI Bloopers 2.0: Common
User Interface Design Don’ts and Dos. 2nd ed. Burlington, MA: Morgan
Kaufmann, 2007.

Mok, Clement. Designing Business: Multiple Media, Multiple Disciplines. Rochelle Park, NJ: Hayden Books, 1996.

New Zealand Trade and Enterprise. “Michael Smythe, Creationz Consultants.” Better by Design. Retrieved July 18, 2010.

Nielsen, Jakob. “Iterative
User Interface Design.” useit.com.
Paper originally published in IEEE Computer, November
1993. Retrieved July 18, 2010.

Random House Dictionary. New York: Random House, 2010.

ThinkExist.com. “Albert Einstein Quotes.” Retrieved July 18, 2010.

Ulrich, Karl. “Design a Solution.” Fast Company, December 19, 2007. Retrieved July 18, 2010.