I just finished reading Thomas Wendt’s wonderful book, Design for Dasein. I recommend it to anyone who practices, or just is interested in, experience design. Wendt’s ideas have profound implications for rethinking and improving our approach to designing experiences. They also have profound implications for how we think about DevOps, and its relationship to design, and how that relationship impacts the nature and purpose of digital business.
Design for Dasein introduces what Wendt calls “phenomenological design thinking.” This is a new approach to design that expands the designer’s attention beyond creating things that people use, to encompass thinking about the ways in which things influence, interact with, and are influenced by how people experience the world. Phenomenological design thinking reflects two key insights about the role of designed objects in peoples’ lives. First, designers create possibilities for use rather than rigid solutions. Wendt cites the example of using an empty coke bottle to hold open a door in an old, crooked apartment. By itself, the bottle wasn’t heavy enough to keep the door from swinging shut, so he filled it with pennies. At that point, the bottle suddenly had three overlapping uses: containing and drinking soda, holding opening one’s bedroom door, and storing spare change. Wendt’s point is that the designer does not entirely control the object’s destiny. That destiny is co-created by the designer and the user.
Second, Wendt points out that designed objects aren’t just passive targets for human usage. Instead, through the very act of being used, they change the user and the user’s world. The impact of smartphones on our personal behavior and our social relationships is an obvious example of this phenomenon. In the process of being used, solutions change the problem space for which they were designed.
As I interpret it, phenomenological design thinking undercuts the notion of designers as gods who create stone tablets to be handed down to grateful users. Users, as well as the world that is the context for their usage, become co-designers. They don’t necessarily redesign things themselves (Thomas didn’t melt down his coke bottle to make it into a door stop). They do, however, change the meaning of a solution by influencing how it is used, for what purpose, and in what context.
To me, phenomenological design thinking implies the need for what I’ve begun calling “continuous design.” Continuous design takes the view that design is never done. Instead, it becomes a continual, circular process of designing, producing, using, and learning. The usage of a design becomes the input for its redesign, and for the design of new things. We can see a crude version of this process in the history of the iPhone. Its wild success caused other companies to enter the market. Their creation of larger-form-factor phones forced Apple to abandon its attachment to the iPhone’s smallness. They responded by advancing the state of so-called “phablets” with the release of the highly regarded iPhone 6+.
Continuous design of physical objects faces certain friction-generating constraints: cost and availability of materials, manufacturing plant retooling, etc. Digital design escapes physical-world constraints, but encounters its own. The constraints that remain involve a) the design process itself and b) the digital delivery lifecycle. DevOps arose to reduce constraints within that lifecycle. As such, I would claim its most powerful value, and perhaps even its essential purpose, is to enable continuous design.
Lean UX is a methodology that addresses the constraints within the design and development process. It takes the view that design needs the ability to quickly, continuously iterate its way toward quality solutions. Phenomenological design thinking challenges digital service organizations even further. We can’t fully evaluate, or even understand, the meaning of a design until it’s being used in real environments by real people. In other words, the only place you can complete the testing of your design, or understand what needs to be designed next, is in production.
DevOps provides the missing link that connects Lean UX to phenomenological design thinking in order to create continuous design. It serves to minimize friction and maximize knowledge, by optimizing flow, feedback, and continuous learning between design, development, and operations. From a phenomenological design thinking/continuous design perspective, DevOps can only be fully successful to the extent that it loops information about users and their world back to design. Continuous delivery of application code is necessary but not sufficient. The M for “monitoring” in CAMS is critical. Furthermore, that monitoring has to go beyond infrastructure monitoring. It needs to incorporate behavioral monitoring.
The need for phenomenological feedback (information about how users are experiencing the designs we release) implies the need to infuse design and DevOps into each other. It’s not enough for designers, developers, and system administrators to talk, collaborate, and share tools. They need to embed each others’ sensibilities within themselves. The people who build and operate production monitoring systems need to understand the kinds of feedback that designers need. Furthermore, designers need to treat operations as part of their design problem. Continuous design relies on augmenting product or service functionality with designer learning. Releasing the output of a design process is the beginning, not the end.
If Thomas Wendt and I are right (and assuming I even understand his book properly), a deep integration across design, development, and operations is critical to digital business success. My underlying thesis is the idea that digital business does not sell products, or even services, in the traditional sense. Instead, they sell continuous design: the ability to engage in continuous conversation with customers by creating designs in response to users’ experience of the designs they’ve already created. As Esko Kilpi put it in his excellent blog post on the Internet of Things, “the effectiveness of an offering is related to how well it packages the learnings from past activities.”
Editor’s note: This post was originally published on blog.ingineering.it and appears here with permission.