Finding Design’s Intellectual Value
From ACM Interactions / Nov— Dec 2015
Thrown into the swirling currents of digital product development — either at an agile startup or a corporation “going lean” — designers must work with a variety of commercialized concepts that typify current design practice. Yet these concepts raise doubt, if not outright suspicion, about truly cultivating design depth and forethought in that practice. Validation, metrics, sprints and spikes, filing project tickets — all with an enthusiastic “bias to action” to “move fast and break things.” Woo!
For new practitioners emerging from a steady diet of HCI theories and behavioral frameworks debated amid college discussion groups, this all may be somewhat jarring. For veterans in the field, it’s a matter of quick adaptation to new, albeit buzz-wordy, models of thought and vocabularies that seem a bit newfangled … and roughshod. It all suggests a dependency that infects our daily discourse with project participants, weakening our sense of design’s intellectual value: the nuances of thought, analysis, and comprehension; a robust perspective informed by deliberation and plurality. Decide it now and move fast! But why? And what impact does this language have on a team’s approach in terms of enabling design, writ large, beyond pretty pixels and specs for a minor point release?
I’m not naive — at least, I try not to be! Product development is an operational context obsessed with maximizing efficiency and expediency, where decision-making with inadequately digested data is simply a natural state, a basic given for anybody involved, whether a pixel-pushing associate or a strategically savvy executive. The popular models of Lean and Agile (and their variants) package methods of rapid experimentation and programmatic execution into an expertly collaborative way of making nimble progress, predicated upon learning from actual users and improvising the execution based on those lessons (i.e., sandbox prototypes, modularized features, etc.). Awesome! Great ideals, a wonderful spirit of improving the path to successful products for eager customers — I love it! Hey, it’s way better than the traditionally sluggish, bureaucratic, silo-based “waterfall” methods of the past that were far costlier & riskier, often resulting in products nobody would buy or use; truly the ultimate failure of all. (And not in a good way!)
However, amid the mechanics that underlie such a system and the zealous devotion to such concepts, the richness, depth, and intellectual value of true “design thinking” are at risk of becoming lost. Indeed, I’d suggest that the constant absorption of the Lean/Agile ethos into how we function as people promotes a kind of anti-intellectualism against design, subverting the value of having trained, educated designers in the first place. I realize that’s quite a provocative view, so let’s take a closer look.
One issue involves the notion of how “the tools we make also make us,” which implies we get caught up in the ethos of the tool, which in effect changes our behaviors to conform to the tool’s capabilities-and limitations. Web-based systems (and their mobile counterparts) that operationalize Agile, such as JIRA and Basecamp or Asana, become the dominant way of thinking that pervades a team, shapes a culture, and affects how people talk about their work. Every veritable design-centric topic or complex feature discussion simply becomes “file a ticket” or “prioritize a request.” Is it a P1or an S3? Who knows? Until then, a particular matter of flawed design (badly placed controls, illogical labels, confusing flows) doesn’t exist! That’s silly. How can this system enable collegial, even salon-style debates on the assumptions or forecasts about a feature or its ability to support a persona’s lifestyle or evolve a business model? Indeed, such systems can become systematic prisons whereby the promise of creative ideas, which need the “conversational lubrication” of debate, are trapped and never seen, ushered along for the sake of triaging tickets and optimizing velocity levels — which are supposed to be techniques for coping with the madness of development in the first place!
Another way in which design’s intellectual value is being subverted is the language, used in grossly simplistic ways that do not even begin to scratch the surface of deep intention and significance.
Here are a few examples that drive me crazy (and perhaps you too!):
- Validation. This buzzword of Lean has become the instant de facto phrase encompassing everything from “we explored some ideas with users” to “we have proved this beyond a doubt to be an absolute truth that will guarantee billions of dollars in profits” — umm, yeah right! Indeed, implicit in this single word is the unrealistic expectation that a novel concept has been proven scientifically to be a fundamental truth or law-which couldn’t be further from reality. All user testing involves demonstrations (not proofs) and degrees of articulated feedback, with nuances around context, utility, disposition, and culture. Those nuances must be sussed out with agreed points of tolerances, trade-offs, and so forth.
- Design sprints and spikes. These phrases from the Agile world refer to two- to three-week compressed timeframes for focusing on specific features based upon stories and points (more on those later). Dashing toward a finish line like Michael Johnson (in gold Nikes, no less) set by a “scrum master” with a fully specified design is probably not the best way to deliver a design that’s well-considered and effectively evaluated, where nuances of argument can be discussed around multiple viable options. A variety of layouts or interaction models represent different postures about users, their habits, and their worldviews.
- Stories. This one always cracks me up. Every JIRA ticket is either a story or an epic. Sadly, we’re not talking about Harry Potter or Gilgamesh. In the normal world of human beings, a story is a narrative involving agency, context, dramatic incident, and some resolution, with consequences. Yet the misappropriated story lingo is just a feature request tied to a use case, which is simply an arbitrary moment in time when a PM felt they would like to use this feature for themselves. Where is the careful analysis around the where, when, how, and five why’s worth of investigation, framed by a scenario and a persona?
When daily design practice is grounded in such mechanics & language, it shapes how designers reflect upon and conduct their work. Where are the original aims of design depth and forethought? They get lost in the simplistic rigors of daily operational habit. As a result, there is a pervasive turn against the intellectual value of design thinking. A huge risk is rushing toward delivery against some predetermined schedule or output without carefully assessing critical matters that affect ordinary folks:
- Issues of privacy, trust, security, and identity — beyond arcane legalese EULAs that nobody reads but accepts anyway, or convoluted product settings (let’s face it, Settings pages are digital analogues of the kitchen junk drawer!)
- Errors, failures, troubleshooting — beyond the simplistic error dialogue and Web link to an esoteric help manual
- Feature prioritization and indexing or architecting content — beyond just point releases and constant updates that confuse or annoy as changes progressively roll out.
One of my former UX colleagues likes to say, “Good design takes time.”
This means there needs to be some conceptual and temporal space carved out for reflection and argumentation, which helps designers find a pragmatic yet aspirational balance of what is best for the business and customer. This cannot be frantically thrown together! Rather than being a waste of time, the process allows the rich texture of design discussions on values, merits, theories, and frameworks to come to the surface. This not only helps designers arrive at options and criteria for decision-making, but also provides a solid basis for the judgment necessary for good decisions.
I’m not talking about academic pontificating or spending months twiddling on esoterica. But when discussions descend into personal likes/dislikes or “I think …” due to artificially compressed deadlines, there’s a missed opportunity to bring everyone’s attention to ideas around how a tool “present at hand” differs from one “ready at hand,” which can greatly affect the initial first-time user experience — just to suggest one situation I’ve faced recently.
So how do we get the intellectual value of design back into the rhythms of product development?
Let’s make a committed effort to create that space for nuanced argumentation, balanced discourse, and teasing apart critical issues related to the product and business, with an eye toward the philosophy, psychology, sociology, and anthropology of what we’re making and giving to our users. Respond to tickets and requests with a demand for a sensible, facilitated conversation and a firm itemizing of various thresholds and criteria. Hold those “beer sessions” (or whatever your drink of choice) to loosen up the dialogues and summon the muses. Amid the rapid-fire intensity of sprints and the dreary mechanics of tickets, let’s keep up the battle against the pseudoscience of “Lean validation,” pushing instead the exploration of real stories around actual people and credible contexts, thus insinuating the deeper humanistic values that are the foundation of design’s intellectual value. Our customers expect it, even if they don’t realize it.
Copyright held by author. The Digital Library is published by the Association for Computing Machinery. Copyright © 2015 ACM, Inc.
Originally published at https://interactions.acm.org.
