The Timeless Scalable Design Process Part 2

Part 2: A scalable process

First a quick recap of our first blog post: In our previous article we addressed common misunderstandings about the design process specifically: what it does and where is takes place in the software creation process. The key takeaways from that article are:

1. A strong design process doesn't limit creativity—it unleashes it
2. Many design projects mistakenly enter the software development lifecycle too late, missing crucial early opportunities
3. Design processes should be scalable and adaptable to different contexts
4. Understanding how design fits within the broader software creation ecosystem is essential for maximum impact

We especially addressed the myth that Agile was the design process or the place where the design process occurs in software development. A good design process starts when the software project starts: with business planning the goals and scope of a design challenge and continues throughout the business planning process and scales to the context of the challenge, even when the challenge changes in mid-flight. What enables this scalability? What is then, this design process? In this post we will cover some of the various visualizations and an overview of this scalable design process.

Scalability in the Design Process

First let’s address scalability. How did I apply scalability to the design process? Especially, a process which has almost never been scalable by being too dependent on a certain method or technique or has over compensated by being vague (think the double-diamond). The simple answer: this process came from a synthesis of the design processes I have practiced, from my close collaboration with the design community (Hugh Dubberly, David Siegel, Micheal Arent, the late Richard Anderson, etc.) from the design theory I have put in to use and the many other design processes I have read about. What this materials encompasses is the subject of my fourth post. This post and the next will centers on what all of these processes and theories have taught me. 

What I learned was certainly not: which methods or which techniques were ideal for the design process. Because in my experience, there are hundreds of variations of methods and techniques, even something seemingly so plain as a usability test, prototype or user interview has numerous permutations. It is not the phase of the process that determines what method or technique you employ or how (what flavor) to employ it. 

So then, what does determine what methods you should use and when? And can you present whatever that is in the form of a process? Because if you can answer that question, you have a scalable design process.  What happens to the deign process when you remove methods and techniques from the process? What is left over? The answer to that question is the goals of each steps of the process plus the context of design project. My conclusion is there are three things left over:

1. The Phases of the project
2. The goals of the project
3. The context of the project

The phases are synthesized from experience and theory. The goals are from applied design theory and the activity of design management experienced from me, many of my colleagues, and the design community. The context of the project is captured in deliverables of some kind. So, a scalable process will list the phases of design and what are the goals of that phase, and then provide a method of capturing the context of the design. These 3 factors will empower the designer or design manager to make the right choice of what methods and techniques shall be employed. To that end, I will discuss the process steps first then a little time on th goals and then in post #3 go deeper into the goals and deliverables.

The design process

So, what is the design process? One thing this isn’t, it isn’t a prescription of methods or techniques. It is outside of the scope of this process to proscribe what design skills you must excel at, quite the opposite; because in order to be helpful, a design process must scale to your needs not the other way around. Every designer is unique and has their own approach, so the process enables, not restricts, your creativity. The process structures your work so that you have the best chances of delivering a successful design. 

One problem with the design process is it’s surface simplicity, which leads the inexperienced designer to think the process is itself simple or even simplistic. Yet, when one digs deeper into what the needs of each step are, one sees the design process is complex and multi-dimensional. Some, like the designers of the Bauhaus, saw it as an all-encompassing process so that the end product of a design process was considered a “gesamtkunstwerk” or a holistic all-encompassing work. 

One example of design’s complexity, is the sheer variety of stakeholders that must interact with the design process in order to be successful: developers, product managers, subject matter experts, customers, marketers, ending in a segmented user population are just among the most basic stakeholders. Another example of this complexity is in the very nature of the design process: being both iterative and sequential at the same time. Iterative because design’s manner of working centers on iterating on generalizable concepts that are validated into ever finer-grained detailed designs. Sequential because a business or organization must have a functioning design by the end of a project (however amorphous that ‘end’ may be—more on this later).  It is also a combination of two processes, not one. The first one is design as a noun, a project process that is a sequential yet iterative process, something difficult to accurately capture (but we will try below). Secondly, there is the process of design as a verb, designing and its actions that drive the project process. The designing process follows the way one practices design thinking. And it’s there one encounters one of the true demons of design.

The enemy of the design process?

There is one demon in the story that we now introduce, that is the polar opposite of the design process and that is the Random Walk.

The random walk is when a user just does whatever they feel like to suite their own purposes or desires in order to finish a project with low quality and make money. This kind of claptrap design is unprofessional and feeds only the ego of the designer. 

However, like all good demons, the random walk has an essential, positive side to them. The random walk is also an expression of the unique take on the world by the designer, without which a design becomes soulless and mechanical. An obligation of the design process is not to eliminate the random walk. Instead, a design process restrains and focuses that random walk to the goals of the design challenge. So coming from the ego of the designer, the random walk is an expression of the complex demands of the design solution, for which no formula exists on how to get there. No forms can be filled in to substitute for this inspirational step. The random walk becomes the essential characteristic of the design process where  designer truly gets to shine. So when does this random walk occur in a design process? 

Design Thinking (the simplified version)

The random walk does not occur just any old time, but rather the walk is a tool wielded by the designer during the  way a designer thinks. The simplest representation of this design thinking is a simple feedback loop of Observe-Reflect-Make. A designer can observe and reflect analytically based on data, behaviors and other observations. But their reflection is not data-driven and definitely not data-determined design; but rather a data-informed and inspired random walk prompting the designer to make something or iterate on something. After this creation step the designer again observes the effects of this new design. These feedback loops comprise way of design thinking.

These feedback loops are meant to take the design forward ever narrowing in on its goals as seen in Figure 3.

And during these feedback loops, though they may look simple, a complex network of information is ingested, understood and worked out into a design. An example of the complexity that goes into a design is reflected in Figure 4.

Ingesting and making sense of this complexity requires the strong analytical skills of a good designer. How they then translate that input, they use any number of techniques or methods, the decision to utilize them is a combination of analytical and inspirational. The usage of the method or technique is the controlled random walk of the designer. And sometimes a random walk is the bridge between two methods, where method one is a clear output and method two a clear input. In this case, the random walk is the designer’s inspiration to get from point a to point b. In a disciplined framework of the design process this random walk becomes a weapon the designer wields and not uncontrolled unprofessional randomness. 

The controlled random walk is the engine that moves the most inspiring the design process forward, or rather further along on its journey, since it is not always forward but always a further step in the learning process.

Recursiveness in the design process

As remarked above, the design iterations don’t always drive forward: they can go backwards or sideways. These iterations are learning models. And learning more can revise past assumptions, add nuance to a previous truth, and require a reiteration of work already done. Figure 5 is a representation of a serial design process of seven steps. The steps are not important, we’ll cover those later below. For now it is important to see that Figure 5 shows the strong impetus of the project to go forward to the next step. But what Figure 5 also shows is how previous steps inform those that have gone before and often will trigger re-understanding and reevaluation of past work. 

The ultimate goal of the design processes is to go forwards to deliver designs that engineering can build and release in software. But the path to get there often means, having to repeat or iterate on previous steps. It’s the natural order of learning.  For example, in a process steps above, the designer learns something new and reaches a goal to move on to the next step. But for example, in say the “Define” step you can learn something new, with stronger more specific information that invalidates something learned, say trade off or a design direction made in the “Acccept” step. That new information in define not only influences the next step, Ideate, but would also trigger reiterations on previous steps thereby updating and improving the work already done. This does not mean the previous Accept step was “wrong” as it was necessary to produce this more improved knowledge learned during the “Define” step. Revisiting the "Accept" step rarely means completely starting from scratch, assuming good design practice was followed. More often it will result in a refinement that needs to be recorded and related to the revised designs. Of course, it must also be acknowledged that new information could lead to a designer completely changing their mind and to start a fresh with a better understanding of the challenge than they had before.

A scalable design process brings you faster to a complete design slower to an initial one

The magical aspect of the design process is that not only does this process assure great design, but despite the iterative nature, this process actually works faster than when a design process is not followed or is sub-optimal (usually too pragmatic or our ever-infamous pure random walk). Without the process one designs themselves into a corner and evaluations come across as random lessons as evaluations quickly reject designer assumptions. These rejections without a process do not make a clear way forward. This results in patchwork where one is assured of a change but not an improvement. This always results in two things: first without a process it is quicker to show impressive looking pixel perfect designs and that impresses unsuspecting stakeholders. But secondly, it also starts a process of wheel-spinning as problems come up and fixes just create new problems.  With these patch fixes the pixel perfect delight is transformed into a Frankenstein’s monster of design that impresses nobody. Worse yet, this wheel spinning results in rework not just for the design but also for the engineer, who will not thank you for that extra work.

Furthermore, following this process-less scenario, as the designs flail about to find some acceptance or usability, the work will come across as random and unprofessional. Consequently, developers, product management and other stakeholders often lose faith in these designs (and designers) and will often come up with their own competing designs. Because as development goes on, and new unexpected problems emerge, without any process driven conceptual credibility, the resulting design changes are reactive and become more and more inconsistent. These designs are increasingly indefensible to engineers and other stakeholders. Often, the designer in such a project is left to whine because they cannot justify their designs in face of alternatives. These designers then complain to other designers about these rogue designs without understanding their own culpability in how they came about.  One benefit is it becomes immediately apparent when this type of design project will end.

Following the scalable design process, on the other hand, will assure a solid footing for design is established at once. This more deliberate approach to design, means visualizations will actually occur quicker with concept maps and other conceptual visualizations; however, the initial designs will take a little more time than without a process. In such a project the interim conceptual deliverables keep the stakeholders actively engaged and follow the process and don’t experience the slower tempo of the initial design. Moreover, those resulting designs, based on a solid concept, will be more durable and subsequent designs will not be random reactions but answered by an established conceptual strategy. Then the tempo of subsequent deliverables then accelerates compared to the process-less scenario. Because, any new designs, as well as new challenges to unexpected problems, will be completed quicker with more agility and durability and in a direction based on your established strategy, so no Frankenstein’s monster emerges. The designs will also have an internal consistency with the earlier designs, showing to engineers and other stakeholders you know what you are doing (not to mention delighting your eventual customers and users). Moreover, in a scalable process, engineering and other stakeholders are involved in the concept, also assuring their ideas are heard and appropriately incorporated. The resulting designs will also be lower risk (more thoroughly strategized) and higher quality (based on a strategic concept of your making).

Consequently, stakeholders will be quite happy as they witness both your professionalism and your designs acumen. Moreover, seeing your professional decision-making, your other stakeholders will respect your credibility as a designer, consequently your designs have a better chance of being faithfully reproduced by developers.

What is this magical process? The rest of this blog post will cover the overview of the process and its steps, the next blog will explain these steps in a more detailed manner.

An overview summary of the scalable design process

For a detailed explanation of how we arrived at this process please read the fourth blog post (the next one is about these steps in detail) about the timeless nature of this process, this section points out what the design process is and how it scales. Many may recognize one of the more popular visualizations of a design project process, the double diamond, popularized by, among others, the Design Council:

However we wonder what utility is this visualization, for whom does it serve? The double diamond is really more symbolic representation of the design than an actual process. It does seem to make the design process easy to understand: you diverge in discovery, you converge in define, then you diverge again in develop and converge again in deliver. There are hints or arrows and a left to right motion that suggests both the passage of time and the end of a project. It remains abstract enough that it is easy to read but too abstract to be able to do anything with it, except to discuss as we are now doing. It’s also a little dated in two aspects. First is its traditional reliance on the design process as an isolated activity: it ends in the delivery of a design. But in modern software creation, that’s usually exactly where a new form of design takes over in earnest. Some designers solve this problem by tacking on a third diamond to include the building process. But given the iterative nature of design, with its multiple concepts, etc. this process vitality, is missing in the double or even triple diamond. Likewise, the diamond is an image of two boxes when good design is exactly the opposite: thinking outside the box. The process is also dated in its terminology, for example the term “Develop” is ripe for confusion with the software development process. Even the former president of the Design Council agrees that the diamond no longer represents the true dynamics of the design process. This diamond approach no longer accounts for the true nature of design int he 21st century.

Instead, we propose a design process should account for more than just 2 cycles of, seemingly, equal weighted converges and divergences. Furthermore, a good design process is an aid to the designer and their stakeholders: making the design process clearer and more transparent. The transformative nature of good design is magical enough without making the process itself anymore mysterious than necessary. This means there is a single design process but not necessarily a single visualization of it. Instead, visualizations can vary based on the goal they wish to perform: do they help narrate a story of the general design process? or help explain design theory? does it help plan a project? does it create a design budget? or even manage the design process? A good design process should be capable of all those things and being represented as such as well.

We also prefer a design process that also explicitly mentions the beginning state in which a design process begins and the state in which it ‘ends.’ In order we may incorporate our process the definition of design by Herbert Simon, and others, where design takes an existing state and turns it into a preferred or more optimal state. A design process based purely on the definition of design would look simpler but not ideal, something like this image:

So, if we explode that design black box and add a more modernized version of the design phases to something like this:

This proposed process will be explained in greater details in the next blog, Blog 3: “The steps of the design process explained.” For now, we’ll suffice for the purposes of this overview with these general definitions of the phases.

1. Existing state — the current state of a product or situation before the design process begins
2. Discover — exploring and defining the design challenge
3. Concept — defining the solution to the design challenge
4. Detail — creating a detailed design from the conceptual design
5. Deliver — creating and delivering assets iteratively with engineering and other stakeholders
6. Preferred state — the desired end result (not the ending state after design)

These phases taken together form the core of the scalable design process. We see in the next blog post on the details the specific features that make this process scalable.

Now, let’s now look at some alternative visualizations of the same process that serve different purposes so we can understand this 4-phase approach. These are just examples, there are many visualizations possible, limited only by the needs or the imagination of the designer.

The image above shows a project understanding that seems time-limited and  boxed to go from one step to the next in a waterfall fashion. This helps to give an easy to understand story of a design project, especially for non-design stakeholders. To help give that image an even more pronounced look of a design project or a project proposal, the image below (Figure 9) is augmented with the addition of links to 2 documents: one a sales or project proposal, the other the requirements on which that proposal is made. Moreover, under each step activities that the designer proposes to conduct as well as an estimate of the necessary manpower resources needed to execute the project.

The project above is clear, concise and has a definite end and a definite cost. But design is rarely like that. A proposal that begins based on one understanding of the problem, changes as the challenge evolves. As learning increases the scope expands or contracts, the dimensions can multiply as understanding becomes more nuanced. 

For example, it is often unclear when design actually starts except in a specific project context. Ideally design begins at the start of a project but often design is called in the middle of a process where design needs to play catch up, and a good process should support that phenomenon as well. Lastly, the preferred state of the Herbert Simon definition is, as we stated above, a relic of the time when design was finished and clearly separated from its creation. When the chair design was done, and it was time to hand it over to manufacturing. Today’s design takes place in a backdrop of continuous software delivery where the end of design is a very vague and often arbitrary decision. This situation begs for a different kind of design process visualization, one where the start can be arbitrary as can the end. Hence my preference for this visualization based on the Golden Spiral or Fibonacci Sequence.

 In the diagram above, each step takes place in the context of a circle, which itself represents a design iteration or feedback loop from the current or past design work including input from other stakeholders. The diagram moves in a concentric circle that can continuously get smaller and smaller. This shows symbolically that over time, as we learn more, the scope of this design process scales to be smaller and more refined as the process comes closer to its target. This refinement continues in an ambiguous journey reaching ever closer to a state 2. That process of continual refinement is until market or other factors change requiring more design input, in which case a new “State 1” is created, and the process can begin again. This is not a failure of a of design, quite the opposite it is the triumph of an open iterative design process with the agility to adjust to new information.

Managing the design process

In the last section to this post, we discuss how this process mentioned above can be managed. Managing a design process means tracking the design phases. At the highest level you list the goals you need to attain for your design process. The goals listed are the universal goals that need to be attained regardless of the scope or context of the design process. For example, in figure 11 below, the main goals are listed for each other phases. An example of a universal goal, you see the first entry under the “Discover” phase, is the goal “Understand the design challenge.” This is a universal step as not understanding the design challenge would make designing the solution impossible. In Phase 4, assuming one is delivering designs to an Agile development process, it is essential to include backlog management to Phase 4 to assure timely delivery of the correct design assets.

What one does not see in Figure 11, is any mention of the design deliverables to meet those goals nor the design activities to create the deliverables. This is what makes the design process scale so easily. You add those activities that you have time for as appropriate to the project. Given a large scope and enough resources, a phase can take a month, or a week, or a day or even a single conversation if that is what is needed. This choice of activities and deliverables are not just project-context specific; but also specific to the experience and talents of the designer. To prevent the “to a hammer every problem is a nail,” syndrome, it is important for the designer to know about many different tools and techniques for solving the same problem. This allows the designer to pick the right tool to solve the project specific challenges.

Likewise, the display of the activities and deliverables we see in figure 12 below shows in a serial fashion what will happen and when. But by including dates, one can go back and revise previous activities with a new revision, and add a new activity to the previous phase. These new activities could be needed to support integrating the new knowledge into previous work; or the activities might be needed to acquire supplemental knowledge needed. In the example below, some new information gained in the Detail phase is triggering a revisit of the conceptual modeling and some related deliverables, all which have a new date given in red to call attention to the new addition to the project. In this way, the project management shows a serial momentum. But without using strict time representations like a Gannt chart, popular in most project management software. Here, the designer is free to update the design process progress in a more holistic fashion: using the project proposal as the guide and reference for updating and managing the project. This approach also allows revisions to the future dates as well without completely redrawing a time-based project plan which can often get out of synch the more one needs to fuss with them.

So, this concludes our overview of the scalable design process. The design process is a structured approach that enables creativity and ensures successful design outcomes. It involves iterative and sequential steps, incorporating feedback loops and controlled random walks to refine concepts. A scalable design process allows the designer to balance speed to completion with the need for thorough exploration, by letting them analyze the project and its goals in order to plan the right effort for the project, ultimately leading to compelling and successful software designs. A scalable design process also ensures great design and faster progress compared to unstructured approaches. It involves initial conceptual work, engaging stakeholders, and establishing a solid foundation for subsequent designs. This process-driven approach leads to more durable, consistent, and agile designs, ultimately resulting in higher quality and lower risk products.

A scalable design process involves four phases: Discover, Concept, Detail, and Deliver. This process, which can be visualized as a golden spiral, emphasizes iterative refinement and adaptability to changing market or stakeholder needs.

Effective management of the design process involves tracking goals and activities, allowing for flexibility and continuous improvement. The details of these four steps is the focus of our next blog post.

If you want to stay informed when the next article will be published please fill out and send us the form below.

Let’s look at the example used by Sangeet Paul Choudary. Sangeet talks about the primary goal of innovation as solving problems customers have.