Dynamic Prototyping with SketchFlow in Expression Blend: Design Process
- A Typical Design Process
- What About Agile Processes?
- Further Reading
Workflow, process, patterns, and methodology are simply a way of life; we typically take advantage of some formalized practice to aid the projects to which we toil and the resulting products we launch. This is especially true of projects or endeavors that involve technology. And, if technology would stay put for a minute, we could reuse the patterns from the last successful project—alas, technology is a constant of change. How do we keep up? Pick the "right" methods? Learn and adapt?
- As a rule, software systems do not work well until they have been used and have failed repeatedly, in real applications.
- —David L. Parnas, Ph.D.
For several years, the tech industry has become fascinated with failure; stories of failure, learning from failure, and celebrating failure. This is not at all coincidence. As technologists, we are bound to an eternity of failed attempts, in part because of the nature of business and management, the current software used that can't keep up with what we are tasked to do, but more importantly, the complexity of what we are required to create has exponentially increased. Humanized interfaces, gestural touch technology, and intuitive, predictive, user experiences; this is cause for revolution in every facet of how we think of and execute on ideas.
So now what? How can we expect to change what has historically been a frustrating, pride-swallowing battle? A journey back in time, to how other industries successfully built products in a time of disruptive change, is a great start. The industrial innovation surrounding the mass production of cars, the advent of advanced innovation in architecture practice, and the engineering books that document the techniques used are all ripe for exploration.
It may sound odd to seek-out groundbreaking design processes from a nearly 20-year-old engineering reference but we can learn quite a bit from The Mechanical Design Process by David Ullman.1 Design process for engineers has been explored, tested, and documented in vast detail, because of the high overhead—production cost, expense of manufacturing, and considerable time to take product to market. The following are a few powerful examples of the engineering process that have been adapted to both the design and software engineering process. Most importantly, Ullman discusses why the prototyping process is so critical to our work. To whit:
- Whenever possible, organize the talent around the project.
- Exact measurements or outcomes are not important when prototyping a proof of concept; it's a learning tool.
- Build it twice: once to fail and second to succeed.
- Don't plan for a set number of prototypes. Take what is learned from the first prototype and apply to the second. Rinse, repeat.
- The more complex the function of the product, the longer design prototyping will take.
- Reduce the problem you are trying to solve with the product into one inclusive statement.
- Every phase of product design is iterative; requirements included!
- The human requirements ARE functional specs.
At its most basic level, we can describe the design process as it relates to sketching and prototyping with the following model.
Figure 2.1 The preceding lessons simplified in a bubble chart.
But the act and discipline of design is more nuanced, and it's about far more than aesthetics and surface elements of a given solution or artifacts—in fact, what many folks outside the profession of design consider design to be is only scratching the surface.
Creating the form or appearance of an object or artifact is certainly a part of the design process, and it's often referred to as graphic design, visual design, or communications design. Because it's the most visible and tangible output of design, it perhaps pushes aside some of the other realms of design that are also critical.
Fundamentally, design process is about developing and communicating insights. There are two major influences that we think are important when it comes to the idea of sketching and prototyping.
One is focused on the work of Roger Martin and his thesis around how organizations need to seek validity versus reliability.2 Martin's work resonates specifically around our need to balance incremental innovation through refinement of existing knowledge with the need to enable breakthrough innovations—essentially the difference between a version 2.0 product or service versus something nobody has seen before, or thought they needed.
Typically, many organizations focus on developing evidence for future product needs based on past outcomes. They use a limited number of objective variables to remove judgment and bias from decisions to support innovation, along the lines of "Our customers told us they want this" or "This is what everyone else is doing, and they are successful." Martin characterized this type of substantiation as reliability (looking into the past to make an informed judgment about the future). Designers are often called upon to focus on substantiation based on future events. This means that they use a broad number of diverse variables. Using processes that integrate judgment and that acknowledge the reality of bias is what design processes are used for. They are needed because most organizations make decisions based on facts, or what Martin called reliability. Design operates more in the mode of validity, often asking people to take a leap of faith, and the insights and recommendations can't always withstand the scrutiny of reliability.
At this point, you may be thinking that it's because those insights may not matter if they can't be backed up with reliability, but the reality is that we make decisions based on validity every day: It influences the cars we buy, the people we choose to spend our time with, and the type of phone we buy. Tapping into the gestalt that motivates those decisions is what design thinking and design processes are engineered to facilitate.
Martin characterized the difference in skill sets between designers and business decision makers and their propensities via something he called the predilection gap.3 Organizations that are successful at innovation often have folks that are grounded in theories and practice that value both reliability and validity. Organizations that skew toward reliability often have difficulty innovating or recognizing good ideas. Organizations that skew toward validity often have a hard time getting their good ideas into the marketplace. It's actually possible to be good at both of these things and not have folks that can serve as translators between these two schools of thoughts as well. The result is often paralysis in an organization.
Figure 2.2 A sketch that illustrates Martin's theories.
So, if we can acknowledge that design can be more than just about aesthetics and form and that validity is an important component of innovation, what's the process that designers use to enable success?
Although there are multiple books on this subject, and some of the names may change, the typical process that designers go through is fairly straightforward. If you ever hired a product design or innovation firm, you would most likely be exposed to a process such as this—or it would at least be the process applied to solving your problem. If you were to explore the techniques being applied in academia around design education and strategy, you would also find that these are the techniques that many designers are being exposed to in graduate and undergraduate education when it comes to learning about "design thinking." Here we'll use some examples from one of the author's previous work under Professor Vijay Kumar at the Institute of Design at the Illinois Institute of Technology.
Figure 2.3 An example of the steps and non-linear nature of a design process taught at the Institute of Design by Professor Vijay Kumar.
A Typical Design Process
Design processes are about a journey of discovery. There are numerous techniques that can be applied to each stage of the design process, and each stage is designed to build on the other. Design-driven innovation is different from business- and technology-driven innovation in that is starts with a focus on understanding your customers or users first versus starting with a technology or a business.
Figure 2.4 The journey that occurs in a design process around design innovation and how it differs from business and technology innovation.
Most design processes contain the following steps. For large projects, it can take weeks or months to go through all of these phases, but talented design planning teams can also accomplish these steps in a matter of days for focused efforts. Here's an overview of what those processes look like when we follow the techniques and practices that the Intitute of Design employs.
Definition and Intent
Design process starts with an idea or, more often, a hypothesis—something you are trying to prove or disprove. This definition state is where designers state their intent, or where the business process is framed and where a research plan is hatched.
Figure 2.5 Some definition efforts begin with an attempt to capture a snapshot of a landscape that influences a problem space. This is an example of a product mapping completed for a Portfolio Planning Class at the Institute of Design.
Research
The second stage of a design process is focused on research; it can take many forms, but one key difference from the typical "stakeholder" interviews and secondary research that we might be familiar with is that this research typically takes the form of what is often called contextual or ethnographic research. Direct observation and anthropological techniques are often used.
Figure 2.6 Insights or observations from contextual research are often clustered or cataloged at collection or soon after. This is an example from an Understanding Users Class at the Institute of Design.
Analysis
The next stage is really one of analysis: processing and organizing all the data that you've collected. Often one of the biggest challenges for designers is not coming up with ideas, or collecting them, but figuring out which ones are the most important to pursue.
Figure 2.7 Even designers use spreadsheets from time to time; here we see a morphological sort of data and attributes derived from primary research. This is an example from a Design Analysis Class at the Institute of Design with Professor Vijay Kumar.
Synthesis and Ideation
This is at the point where most people think the design process begins, and that is around the phase of synthesis or ideation. This is the point in the process where we start to develop and flesh out some of the themes and memes that come out of our analysis process. It is also the phase where tools like SketchFlow can start to become useful.
Figure 2.8 In this example from one of the author's student work, analysis of data enables us to identify competencies for a sample customer. This is an example from a Design Strategy Workshop at the Institute of Design with Professor Vijay Kumar.
Figure 2.9 Affinity mapping helps designers and business makers uncover new opportunities. This is an example from a Design Strategy Workshop at the Institute of Design with Professor Vijay Kumar.
By looking at competitor offerings and matching them with a different company, teams can uncover new business opportunities. Here is an example of student work of one of the authors; it was identifying competencies and needs that would allow for a new business to be created, which would deliver new value to an existing customer segment.
Planning
Have you even been frustrated when you ask someone for an estimate and a plan and their first response is, "It depends." We often roll our eyes at consultants and companies that suggest a six-week project to figure out what the real price of a project may be. But the reality is that for complex problems that require breakthrough innovation, if someone hasn't gone through a process of research, analysis, synthesis, and ideation, the estimate you receive will be useless or wildly inaccurate. Another way to think about this is that solving hard problems is, well, hard. If it were easy, we wouldn't need to go through all these steps, and we would always make smart choices all the time.
Conceptualization and Prototyping
Many traditional processes have this phase, and it's often called a macro or high-level design process. It's often the stage where we plan out a slice of a project or develop multiple initial concepts to help us drive toward our final decision. For many people who don't use a fully realized design process, this is often where SketchFlow might first be used.
Figure 2.10 In this example from one of the author's student work, we see an encapsulated design process that features intent, a problem statement, conceptualization, and a potential solution. This is an example from a New Product Definition Class at the Institute of Design with Professor Chris Conley.
Figure 2.11 Another example of the same encapsulated process. This is an example from a New Product Definition Class at the Institute of Design with Professor Chris Conley.
Production and Implementation
This phase is often known as a micro or detailed design process. In many cases, a designer might not even have been engaged until this stage of the process with a mandate to "Make it pretty" or "Make sure our customers love this"—which may be an impossible task by this point. SketchFlow and technologies like WPF and Silverlight offer a powerful combination when using SketchFlow and a design process because they allow a designer's work and vision to translate seamlessly into the development process.
Sensing and Feedback
Great products are never really finished until they are abandoned. New releases, features, and innovations follow the lifetime of a product or service. Good design processes acknowledge this and ensure that a mechanism is in place via process or technology to capture, judge, and act on feedback and insights that are collected over the lifetime of product. Just as SketchFlow is a great tool to use at the beginning of a project, its utility can also be realized to support shipping projects and services that need to evolve.