Organizations employ a design-up-front approach because they believe they will avert risk and manage change. Reviewing a nice big stack of well-rendered mockups created in a high-end graphic design program can give stakeholders that feeling that whatever comes out the other end of the production pipeline in 6 months, it is going to be ready for customers to use and return on investment. The reality is that most of the time, 3 months past the release deadline, the design is outdated and the business has changed enough to make most of the design irrelevant.
And the quality isn’t what was expected: Stakeholders actually start using the thing now that it’s built, and the design is not as easy or enjoyable to use as everyone hoped it would be. It’s not anyone’s fault. After all, we can’t truly evaluate usability when the mockups are on an overhead projector, 20 feet (6 meters) beyond our reach.
If the organization is structured across work cells organized around specialties, the design-up-front approach is a necessary evil. In order for work cell B to begin, work cell A must complete their work and have it signed off by a superior. Or worse yet, a committee. The problem with this working style is that it takes a lot of time and energy to communicate problems, opportunities, and react to unforeseeable events. Bureaucracy sets in, and suddenly the focus is not on the product anymore, but on the rules of a process. And the most acerbic ingredient gets added: Us vs. Them mentality. Poor quality can be blamed on another work cell’s inadequate hand-off. The chain of blame continues all the way up to the ultimate customer, their finger pointing directly back at the company.
Design and analysis occur at all points in the software lifecycle. Every step, every stage, and every phase. While we may have work steps early on in product development that appear to be exclusively analysis and design, this is ultimately a consequence of not having tangible product in-hand at those early stages.
Experienced software designers know that when something actually behaves and functions—a prototype—it will invariably receive more buy-in and support from stakeholders than static renderings. People can tell when a tangible object is real and when it is fake, when it will sell and when it will not. The conversations shift from picking apart color values, and whether something should have a gradient behind it, to conversations about product behavior and how well that maps to what customers expect and desire.
Departing from a culture of design-up-front requires a fundamental shift in organizational behavior. Behavioral change requires a new framing for thought. A framing that counteracts design-up-front behavior is a term called Continuous Design. Also known as evolutionary design or emergent design, Continuous Design allows organizations to continuously take advantage of opportunities to improve a product or service.
To act in the present, the organization must live in the present. Wishful thinking, pre-planning meetings, and special committees to research special initiatives fall to the wayside; mockups and design phases are seen as blockers to real progress. These things become muda (non-value generating activities). Transparency of information is paramount. In order to act in the present, we must be aware of the present. Face-to-face communication and cross-disciplinary collaboration foster a culture of transparency and learning.
In software development, the need to continuously deliver working software increases as companies engage customers in new and innovative ways. The organization must prioritize this capability as a core value in order to learn about customers and iterate rapidly. Sometimes we need to change direction in a more radical way if we discover what we’ve built isn’t valuable.
Change of this nature is often spurred by catastrophic, transformative events: A negative catalyst. The positive catalyst occurs when someone in the organization sees a better way to work and spreads the word, generating excitement and inherently changing culture.
To be effective, the idea has to be simple. I believe the idea of continuously delivering well designed product to our ultimate customer is a pretty simple concept.
This is the first of many articles to come that will illustrate perspectives on continuous design, lean thinking, and user experience.
What others are saying about Continuous Design:
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.