Design Process

I’m still surprised every now and then when I meet designers and design leaders who dislike or discount design process. Thankfully, there are still many designers out there who do believe in process, but for the non-believers some typical arguments go something like this:

• Process kills or stifles creativity
• I don’t need process to tell me how to do my job
• Process creates too much administrivia and overhead
• Process is inflexible and can’t handle the dynamic nature of a project
• Process doesn’t scale well to handle small or large projects
• Process evolves or is redefined too often making it difficult to maintain and apply
• Design process does not integrate well with product development processes

The first and most important point I’d like to make is that the arguments presented above can be true! I too have experienced first-hand many projects managed in ways that give credence to the arguments above.

Next, let’s simply acknowledge that whether you like or dislike it, process is inescapable. Simply put, as soon as you do activity A then B, you just created or followed a process of A then B. Now, you may not have planned it or communicated it, but the moment you did it, it became real, subject to critique, and best of all subject to learning and improvement.

So, while I have learned, experienced and refined many processes, do I have one to share with you; perhaps one that addresses all arguments and converts non-believers? No, I don’t, but I have something better! First, however, let’s look at why or when process fails.

Process Breakdown

Process is defined as “a series of actions directed toward a specific aim.” We could envision this in the following way:

We have a series of actions, A through F, grouped by the specific aim or goal towards which each is directed. For example, actions A then B are performed to achieve goal 1.

Now, is it possible to define just one design process and apply it universally? Could there be one set series of actions, one constant process? The attempt to define and apply a one-size-fits-all process leads to many of the arguments against process. Every project is unique with differences in such factors as stakeholders, requirements, constraints, team members, skills, time tables, etc. To ignore these factors and subject a team to a cookie-cut process makes it awfully easy to believe and understand such arguments against process:

• Process kills or stifles creativity
• I don’t need process to tell me how to do my job
• Process is inflexible and can’t handle the dynamic nature of a project
• Process doesn’t scale well to handle small or large projects

So, if good sense prevails then we take the relevant factors into account to create a custom process (plan) tailored to the project. Furthermore, experts in a particular field can easily define multiple ways of achieving the same goals. They can keep the goals the same and simply change the series of actions:

The fact that this is possible and reasonable tells us a couple of important things:

1. Defining who does what, where, when, and how (i.e. the series of actions) can change.
2. Why the actions need to be taken does not need to change; the goals can remain constant!

So, does being flexible and dynamic to create custom processes address all arguments? While it addresses the arguments against a constant process, it unfortunately creates different arguments against a dynamic process:

• Process creates too much administrivia and overhead
• Process evolves or is redefined too often making it difficult to maintain and apply
• Design process does not integrate well with product development processes

Unfortunately, having a dynamic process seems to lead to one set of arguments, while forcing a preset constant process onto a project will lead to another set of arguments. It seems like a no-win dilemma in which we need the process to be both constant and dynamic!

The Better Solution

Imagine if we could compile all the various design processes and analyze them at a high enough level to then extract the common goals. We would end up with a series of goals instead of a series of actions:

The series of goals is a concept with a name… it’s called a “framework.” Framework is defined as “a set of ideas [or goals], principles, agreements, or rules that provides the basis or outline for something intended to be more fully developed at a later stage.” So, in other words, we can start with a set of common goals (framework) and then later more fully develop a series of actions (process) to achieve those goals.

Now, we solve our dilemma not by trying to define a single process to be both constant and dynamic, but by having a constant common framework filled with dynamic processes:

The key to making this work, of course, is to…

1. Define a great framework by identifying those high-level goals that are common to all your design projects, and
2. Have access to a great collection of actions (tools and methods).

I envision the relationship between framework and process in the following way: Imagine having a toolbox full of various actions, methods and techniques like user interviews, creating personas, brainstorming, flowcharting, wireframing, storyboarding, etc. Experts can pick, adjust, and sequence the right actions to fit the given situation/project and to achieve each phase or goal of the framework:

This may sound crazy or perhaps too idealistic, but I’ve seen it in action and it works. A great example comes from Industrial Design (ID). ID teams within Microsoft have defined a common framework with phases (or milestones) and goals. Every project uses the same basic framework, but the experts on a given project decide what set of actions to take, when, and how to achieve the desired goals for each phase of the framework.

A Great Framework

A well-defined framework has the following benefits and characteristics, which address many of the complaints against process:

• Framework is like a default plan outline. It’s a head start in planning a process for a specific project since the key phases and associated goals are already defined.
• Process becomes the activity details used to fill the various phases of the framework and achieve the goals of the phases.
• The framework does not prescribe a set of actions (i.e., it does not tell you how to do your job).
• The process used within the framework is dynamically created, enabling scale, customization, and creativity.
• A consistent framework can be more easily integrated into a product development process.
• A framework can make it easier for new team members to come up to speed when joining a new team.
• A common framework used across teams and organizations will make it easier for cross-organization collaboration and communication. Designers from different organizations can easily share project status by first saying what phase of a framework they are at and that in itself will speak volumes.
• Tollgates can/should be created at key points within the framework (e.g., end of each phase). At such points, team members share important information and how goals have been met so that stakeholders can give the project a “go”, “conditional go”, “recycle”, or “stop” decision. Tollgates offer predictable and necessary communication points between team members and key stakeholders, a clear record of work and decisions, needed decisions at the right time, and much more (e.g. of a tollgate based project from Ohio University mechanical engineering).
• The framework is a form of communication, as is the process you define to fill it. It can provide a way to set and manage stakeholder expectations. In other words, who’s doing what, when, and why? Whether you communicate the low-level details of a process or the high-level goals of a framework depends on your audience. The stakeholders may be your immediate team members, all of whom need to align and ensure everyone is going in the same direction. Likewise, other stakeholders will be partners (e.g. developers) with whom you need to coordinate and synchronize based on dependencies. Lastly, another group of stakeholders will be management and decision makers who need to understand the big picture.

The key point is that dynamic details are important to team members, but to management a consistent and predictable set of phases should be communicated with understood goals. A seasoned co-worker of mine shared some great insight with me, saying that without line of sight to some basic work-flow and associated deliverables, management will have difficulty understanding what they’re looking at in any given moment. For example, if you’re early in the design you may be showing them a UI wireframe, but they have no idea how to assess it and give the right type of useful feedback. While you want them to understand the basic layout and flow, they may be stuck on various placeholders used to simply convey general intent (e.g., wording, clip-art, colors). Not knowing the general progression from low to high fidelity design, upper-level decision-makers may not understand where you are in that progression, it’s purpose, and what’s yet to come. So, yes, it may take some time and effort to effectively communicate the framework, but the consistency of it makes it easier for management to learn and remember. In the end, I guarantee that using the framework as a way to set and manage expectations will save more time and effort in the long run.

Example Frameworks

Your goal is to create and use a single framework for your department, but to be successful and offer the right value I’d recommend starting with other established frameworks and customize as needed to fit your industry, your company, and your general product development culture/process.

If your in the business of designing products and solutions for human use, then there already exists a well established design framework called user-centered design (UCD). This particular framework can be represented in different ways, but all basically stay true to the same UCD philosophy and tenets. For example, the Usability Professionals Association (UPA) shows one they refer to as a model. Here’s another great example from David Travis of UserFocus, who has a great framework for user-centered design presented in The Fable of the User Centred Designer and his book E-Commerce Usability: Tools and Techniques to Perfect the On-Line Experience:

I took David’s framework and updated it to better reflect key stages of product development and labeled each stage of the framework using a mnemonic, UCD6: diagnose, discover, define, design, develop, and deploy.

The entire framework is divided in two:

• Gray stages are about “Build the Right Thing“
• Red stages are about “Build the Thing Right“

With such a framework in hand, you can fill it with the appropriate tools and methods.

Additional Reading

ISO 9241-210 is an incredible reference (9241: Ergonomics of human-system interaction, Part 210: Human-centered design for interactive systems):

ISO 9241-210:2010 provides requirements and recommendations for human-centred design principles and activities throughout the life cycle of computer-based interactive systems. It is intended to be used by those managing design processes, and is concerned with ways in which both hardware and software components of interactive systems can enhance human–system interaction.