Continuous design, as I define it, is the cross-team collaboration in designing enterprise software at the pace set by application release automation.
What follows is a chronicle, a one-year retrospective by a principal designer who is shaping the user experience of a market-leading product, alongside team members in product management, engineering leadership, and in partnership with solution engineers in the field, as well as customers. The evolution of all these relationships is the journey into continuous design, and the following can be considered a captain’s log left open for perusal.
Captain’s log
Almost a year ago, I described the deliberate transformation of our approach to designing enterprise software, and I likened it to the birth of a new notion. Since then, along the way of developing a new product in the Application Release Automation space, we’ve reached significant objectives, so the challenge now is to renew ambition and improve our current situation.
Often it is easier to identify what to improve in a process, compared with recognizing what has made it successful in the first place. I enjoy the thrill of being at the epicenter of our design process. From this central vantage point, I not only make note of where we can improve next, but more importantly I observe what we’re doing well in order to maintain the habits for designing at high velocity.
Design begins with dialogue
“vAde jAyate tatva bodha” is a Sanskrit saying that means “through dialogue we understand the essence.” It implies we must be open to debate, listening and seeking to understand a truth. How does this apply to designing enterprise software?
Design begins with dialogue. Determining the strategy for evolving the software product, then implementing user experience-based features, are both activities that require ongoing productive dialogue.
We seek solutions as seeking a truth that will reveal itself through debate, listening, hypothesis, experimenting, and iteration. In our design process, we have gotten good at developing a continuing dialogue that quickly leads to solutions. We discuss often. Topics are small. We make decisions fast, and validate promptly. The truth we are seeking will be confirmed during the product’s usage. Thus begins the dialogue with our users.
The relationship of quality and precision
Anyone who has sought to execute a release quickly has invariably experienced making trade-offs and compromises to meet the timeline objective. Reducing scope, yes. Reducing UX quality, no. The cost of eroding the end user’s trust and incurring the chain-reaction of recording complaints is not justified. How does a team execute quickly, but also precisely?
The engineer, statistician, professor, and author William Edwards Deming famously said “Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place.” In software development and delivery, DevOps is the very expression of building quality into the process at the organizational level. But between development and production lies quality assurance, where precision of execution happens not by inspection, but farther upstream at the individual contributor’s level.
Seeing quality through a UX lens
Deming said, “The result of long-term relationships is better and better quality, and lower and lower costs.” What is the “better quality” he speaks of? I interpret this through a UX lens, because in my world the user’s experience is the reality of the product. There are two sides to the coin of UX quality. One is within our control, the precision with which we architect, design, and implement. The other is beyond our control, the perception the user has of our software while using it.
I firmly believe the individual and collective commitment to precision in all facets of making software leads to higher quality in user experience. As I look back over the time spent with my teammates over these last years, melding product management, engineering, and user experience design, I appreciate the profundity of Deming’s statement regarding relationships and quality.
This crystallized for me over the past big feature releases during which designing felt like running the court in an NBA championship playoff, volleying long passes, scoring impossible three-pointers, and finishing with alley-oops. I realize it was the trust in our working relationships that elevated the overall quality of the design of our product, and lowered the cost of course-correction, and re-work. Deming was right.
The climate of your organization
This year at the DevOps Enterprise Summit, Gene Kim and John Ellis held a conversational session on the main stage titled “Beyond the Phoenix Project.” Multiple references were made to Deming’s principles in delivering at speed and quality. What fascinated me from their presentation is the fact that these core principles in manufacturing are still foundational to the competitive outcome we seek today in enterprise software.
Personally, one of my favorite Deming references is: “Research shows that the climate of an organization influences an individual's contribution far more than the individual himself.” I relate this to design practices and processes from the standpoint that many individuals contribute to the design of the user experience outcome, and this is precisely achieved through the climate in the organization. The ethos that best allows meaningful contribution is blame-free relationships, continuous learning, openness to debate, listening, and seeking to understand the essence of a solution through fast feedback loops.
The core elements of continuous design
In this captain’s log, my last entry on this year’s journey toward continuous design describes not the arrival at our destination, but at one of its checkpoints. The enterprise software industry has discovered that the heart of DevOps beats according to the attitudes of the individuals working in both Dev and Ops. When an organization successfully educates and trains its departments to align in values and incentives, then a culture emerges that guides individual contribution. At the same time, designing an evolving product in the most efficient and accurate manner depends on the culture in your organization.
The essential requirements for effective continuous design are:
- The organization’s leadership communicates the role design plays in their strategy for creating value and being competitive in their market position.
- All product-related teams have a common understanding of the standard of quality the design outcome is to have in the hands of their customers.
- All individuals who contribute to shaping the design outcome have a common knowledge of the business underpinnings that inform design decisions.
Continuous design grows most naturally from…
- Developing discussion themes early to allow ideas to mature and incubate
- Scheduling short and focused discussion sessions with a selection of individuals
- Cultivating egoless interactions and supportive engagement
- Aligning goals that are synergetic
- Reinforcing the accountability of each individual for delivering quality
Establishing this foundation in the organization removes the friction points that typically arise between teams who engage in the design process without common knowledge of how, where, when, and why design decisions are made. The effort of continuous design ought not be in the power struggles Alan Cooper clarifies in his design training class. The exertion, instead, is inspired and sustained through optimized communication. This journey is toward a horizon.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
