Design @ Warp Speed (?)
As I have been engaging with more and more organizations about their #DesignOps, a constant theme has been emerging. It shouldn’t be surprising to anyone that one of the core pressures design teams are facing is speed. As much as my favorite thinkers/speakers on agile methods would like to suggest, agile methods combined with business pressures have worked to increase the pace of business to new extremes.
The big issue here is that design is seen as slowing down the company. If it isn’t slowing it down, it is being asked to change how it works so as to not be a bottleneck. Then the question is …
“How much do we change design practice before it is not design any longer?”
Digital Transformation has done wonders to accelerate development to warp speeds. Our ability to empower developers to program, test, and deploy through automated orchestration of infrastructure is beyond impressive. I don’t know computer science or engineering well enough to comment on if there have been negative impacts to the quality of development because of this disruptive change, but I can speak to the push for speed as a designer.
Like I said, I can’t speak to the activities of development. I assume there is something akin to architecting and planning that needs to go on in development to ensure that systems are robust, secure, performant, etc. Maybe that is now a turnkey process, or so componentized as to be made almost commodity.
Design is different. Design by definition is to plan. It is 90% a planning activity. Planning is not part of a deployment process. It is not part of a production process. Design is also not particulate. Yes, there are patterns. But the value of patterns is how they fit into a whole. It is called a Pattern Language because the value of the patterns are not in being language, but like words in a sentence and paragraph, their value is in their combination and their combination is not easy, nor can it be done quickly.
Composition takes time.
Design is different. Design is not constructive. Design is de/re-constructive. Meaning, we construct, deconstruct, and reconstruct. If it iterates in any sort of constructive/additive way it is moving from blurry to sharp or low-fi to high-fi. It is not geared towards adding onto the system after a certain amount of scale. Think about adding rooms onto a house after the original design was constructed. At a certain point there isn’t anything you can do to sustain additions safely. The same is true for design. Architectures whether informational or transactional break quickly as scale increases.
Design is different. Design is not fully codified. Not all the elements of design are convertible to text, or at least not to readable text. The ability to test is not always doable in the code, or in the rendering of the code itself. This isn’t just because of the images, but also because of the nature of experience. You can’t test success purely in an automated fashion. People need to use it and their use needs to be contextual and observed. Analytics alone can’t tell you more than something is broken. It can’t tell you how it is broken, or how to fix it.
Design is different. The value of design is less in the production of artifacts and more in the way designing is used as a method of synthesizing insights and framing problem spaces by which artifact/form design decisions can be made. The easy part is in the making of those design decisions. The hard part is creating the problem framing in which the decisions are made.
While design can have a cadence with a regular rhythm; while it can be chunked into small work (with effort to find the break points); there are limitations to how small you can make things, and how consistent you can keep that rhythm before the value of how design works gets diluted. Further, what are the chunks trying to achieve? What is their purpose? As noted above, the fact that design works best as a deconstructive practice is doable in small chunk cadences, but not in a way that is synchronized along the same vector as the constructivist model that most development works on.
For these reasons and maybe more, I’m concerned that we are changing design to the point where design is no longer designing. Design can be done at some level of pace, but the philosophy of many in development that continuous delivery is the best from of continuous learning places an operational burden on design, making design something other than designing.
It can be said that this evolution is just natural part of the Transformation in the Digital Age, but I’m most concerned that we are evolving our practices but we do so in reactionary ways, with unintended consequence, where unlike real evolution, we are pressed to select out our most valuable components. My ride into the realm of DesignOps is precisely focused not on slowing down (per se) our work, but on doing all we can to make sure we intentionally design into our future the best parts.
