The Timeless Scalable Design Process Part 1

Part 1: Dispelling myths and getting on the same page

Veteran Design Planner and Professor, Hugh Dubberly points out the need to study and improve both the process execution as well as the process itself. Indeed, this is one of the essential crafts of the designer: how to strategize their process into a professional practice. 

One truism of our profession should be: “Any design professional who cannot articulate their process and act on it is not a fully professional designer.” But that statement is also not fair to my fellow designers for two reasons. First, because we are under a lot of pressure to be pragmatic and unprofessional from the very people who hire us (whether external client or a design group within a larger company). Secondly, when we discuss the design process we can be referring to two different processes that get conflated:

1. The overarching design process for a specific project, or what I call the project design process. Its purpose is to give a time-bound and confidence-inspiring business proposal. 
2. The design doing process (it’s unfortunate that the term “Design Thinking” has been hijacked to mean something else) which attempts to capture the iterative dynamic of how a designer works.

Any discussion of the design process is fraught with misunderstandings, so this first post is designed to get us all on the same page as to what does it mean to have a design process? 

What a design process is not

Many designers I have spoken with often fear that a process will confine their freedom and limit their creativity. As we shall see, the reality is the opposite: a good design process unleashes your creativity by opening possibilities, not closing them. Moreover, by confronting the designer with the true depths of the design task, a good process forces the designer and their stakeholders to think outside of the box. As I shall also show in subsequent posts, a good design process gives the designer the professional discipline to unlock the real magic of design: to solve problems both sustainably and innovatively to the best of your abilities. 

It’s also instructive to note what a design process is not. As much as some would like, a good design process is not a cookbook or recipe for success. It may suggest a certain rigor and discipline but it is up to the designer to take that challenge and strategize a successful way of doing that. In no way does the process design for you nor tell you what design tools, what methods, or what activities to utilize. Those are all context specific. So in short: a good design process guides the designer and enables them to choose the best solution for the context they find themselves in; but such a process cannot, will not, and never will design for the designer nor tell them how to design. A process will definitely tell a designer what (goals) and when (phases) to do it but not how (which techniques or methods) to do it.

Design Process ≠ Agile

Moreover, there is also a misunderstanding as to where the design process fits in the overall software creation process. Especially equating the design process with Software Engineering Agile methods is a mistake. Further confusing matters is that some companies fit agile approaches to their business management. Because for such companies it seems like everything is run in an agile method but these appearances are deceiving, and they are particularly relevant when understanding the proper role of design in the business or organizational lifecycle. 

Where is the design process used?

As the history of user-centered design indicates (this will be discussed more in Post 3) there is a mistaken assumption that the software engineering process is the software creation process. Software creation is made up of many sub processes that are owned by different softwaremakers. The software creation process is what makes design so complex, multidisciplinary and multicultural. However, there is still a tendency to equate the Agile development process as the software creation process. 

First let’s look at the Agile process and how it usually interacts with design. Many design teams, agencies and consultants often have agile-based design offerings. But these offerings mostly center on sprint asset creation, and sneaking design prioritization in the Sprint Backlog Management to delay the building of certain UIs to allow for some minimal research activities before development is due.

Agile software development process

On close examination of the Agile process above, there isn’t much mention of design nor design process steps or even activities. As mentioned above, many designers usually find ways to fit in with agile development, as seen in the yellow section of the backlog management meetings where some design negotiations can occur. However, that is not exactly a design-friendly process, let alone a good way of practicing design on the fly with the development process. 

When design is force-fitted into Agile it is often front loaded as if the only design activities occur in the beginning of development. Managers will often misuse processes like (Google Ventures') Design Sprints because it seems to tell developers what they want to hear: that design can be reduced to 3-5 days of effort. They'll tout "design sprints" as if a design can be done upfront, when the reality is when such a design sprint is completed, the design is outdated the next day as new information is gained during development. As we shall see in our next post, design occurs throughout both the software development process and the software creation process.

There are two other bad effects of designing during Agile: First, the more a development progresses it starts to build technical debt which also relates to UX debt as designs are imperfectly or only partially implemented. Secondly, almost nowhere does design appear in Agile manifestos and in the versions where it does appear the reference is often to software engineering design not UX design. 

Lastly, as we see below, Agile is only one process of many that are involved in the software creation process. In that image we notice there are many processes that take place before agile in the software creation process. Related design activities are given to the right of each step. As we place the Agile process in the broader picture of the software creation processes, we notice that Agile starts very late. First let’s look at the average Agile software development process.

As you can see with the Marketing process on the right, there are not only many specifically design related steps but some are more recognizably design-oriented than the steps in Agile steps, where the designer is involved but never really initiates a step. For example, the work with Journey Mapping occurs in this marketing step, meaning if design comes along only during Agile, then this map already existed without the necessary input from design, because design came in too late.

The entire process of software development has a multitude of steps that come before agile, where design plays key roles as seen in the diagram below representing the product creation process, of which agile is a member.

The diagram above shows the designer-related steps in yellow so you can see the number of design steps that the designer would totally miss out on if they stuck with just working in Agile.

This is also the reason why many designers working like this, complain that all the key important decisions have already been made.

Consequently, the designer is stuck with a suboptimal set of conditions in which to design; because the design process had been choked off before it could get and give the input it needs to be truly successful.

This image above shows a software product process of a mature organization where the product planning phase is often an entire calendar year. However, this process, like the Design process itself, scales to the scope of the challenge, the maturity of the organization and maturity of the software. Some software processes can even resemble agile because they are sometimes done concurrently in sprint-like schedules even if their activities and management styles are vastly different.

A design process if done right, as we will explain, is one of the few processes that ties all other software creation processes together and make sure they all inform the design that will be guiding concepts in software development. As such the design process is also a coordinating process among many disciplines not just engineering. On the other hand, if the design process begins with engineering, then not only is it too late for design to have its full positive impact on the project it is also too late for a designer to have a satisfactory professional experience. The software creation process, not Agile, is the best way to understand the place of the Design Process, just as it is better to think of stakeholder-centered design instead of just user-centered design as driving that process.

Or put more succinctly: by the time Agile is ready much of the important design work has already been completed.

To help assure a designer works to the fullest of their capacity, and to assure an organization benefits from the full advantages of great design, we will put forth in the following article, the scalable design process.

This design process utilizes the generalizable steps in every design process. This universal timeless design process leverages the hard learned design processes rooted not just in software product creation; but also going back to the early 20th century (though some roots even go back to the renaissance). Like a good ethical product of design, to paraphrase Horst von Rittel, the process increases the number of positive choices for all stakeholders. It does that by building a timeless scalable structure that has always produced the best designs a designer can deliver. Like good design, the process forces you to make difficult choices and ask difficult questions. It enforces a due diligence so that the design process is complex, professional and, of course, thoroughly enjoyable.

What this process is, will be the subject of my next article that will be coming in the coming weeks. 

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