|see related comic|
Doug Bowman’s departure from Google for Twitter sparked a lot of heated discussion this week. In a brutally honest post, Doug cites Google’s restrictive data-driven engineering culture for stifling design innovation.
Most of the follow-on conversation has been partisan — some defending Doug’s position, others saying that Google has it right, regardless of how designers feel. My take is that both stories are incomplete.
The underlying problem is that design is a holistic discipline while data-analysis, applied dogmatically, is a reductive discipline. When the two coincide, serious friction can ensue. But far from vowing to never interact, these two disciplines need each other tremendously. The designer brings perspective that helps to organize experiential systems at all scales, while quantitative metrics are key for validating decisions. The problems arise when analysis is treated as the primary driver for invention — that’s like setting a measuring tape on a drafting table and expecting it to design spectacular architecture — rest assured, the genius is not in the tape. To best illustrate this point, I’m going to put on two hats…
From the engineer’s standpoint, quantitative metrics are an obvious must-have. Used well, they offer an impartial mechanism for tracking how code/design changes affect performance. That said, you must understand that design is really a kind of multi-variate optimization of extreme complexity. Even taking a simple layout with that contains two columns with borders and background colors, the possible mix of colors, borders, column-widths, layouts, etc is combinatorially enormous. Engineers familiar with large-scale optimization know that it is often computationally impossible to explore the entire space, so different optimization strategies are deployed to explore promising subsets. These strategies include straightforward approaches like max-descent and more radical ideas such as simulated annealing and random restart to avoid getting trapped in local optima.
Think of your designer as a guide in this multi-variate optimization process. A good designer has been all over parts of the territory a dozen times on various projects and has studied the design patterns and techniques that help in different problems/situations. Because of this, he or she has intuition on how to approach a problem, just as an experienced software architect has intuition on software design approaches that provide different benefits/drawbacks. Don’t think of this intuition as some sort of “design mystique” — or as designers forcing their “opinions” through because of their “artist-soul” or anything like that. A talented designer is similar to a senior architect because they both will help you avoid configurations/combinations that are just not viable.
Their designs are holistic, just as many good software architectures are holistic. To illustrate this, imagine if you proposed a new architecture and your team insisted that for testing, you isolate just a section of the schema change to “see objectively” how it improves things. For a small change that might be fine, but it won’t work if your new architecture was designed holistically, wherein the schema change was connected to a new messaging system and storage approach. It’s absurd to test the one piece out of context because it’s part of a holistic design, and no subcomponent will yield the benefit of the full design. Given this, think again about Doug’s comments about border thickness and 41 shades of green/blue.
OK, first off — design is not the same as art. In teaching seminars, I’ve often said that “Art is about freedom while Design is about constraints.” Among the key constraints is the performance of your design, especially with respect to how it impacts your product and your business. While metrics may be scary to some, becoming familiar with different evaluation techniques and knowing which to employ is the hallmark of an experienced designer. Beyond the bread and butter usability lab evaluations which folks in the UCD/HCI communities have grown up with, there are a bevy of quantitative metrics from A/B testing, market/competitive research, data-mining, etc that are enormously useful tools.
The key is to extend your design process beyond the drawing of pixels, vectors, and boxes-and-arrows, to the design of the system within which your work is produced and evaluated. If you are comfortable with a wide variety of evaluation techniques, you’ll know which techniques will help clarify key design decisions, and which techniques will just waste time and energy only to produce noise. Instead of resisting evaluation of your design, you’ll appropriately lift the conversation up to the level where you are discussing and proposing the right methods of evaluation.
This attitude won’t turn a company’s culture around overnight, but by being the type of designer who knows how to stand up for his or her designs in a variety of situations and prove them (with data), you’ll raise the value and respect of the discipline within your organization. You’ll also quickly shake off the impression that designers are just there to present their “opinions” or spread “design-mystique.” Design is there to make amazing, powerful, delightful things, and absolutely — that making can be measured. It’s knowing the right sort of measurement for the situation and learning techniques to represent your work powerfully to different disciplines which will make all the difference.
The interplay of all disciplines (engineering, design, research, marketing, sales, QA, product, legal, customer care, etc) is where the magic happens. Metrics are an absolutely critical interface between disciplines, but when wielded and controlled by only one discipline they can greatly limit the potential of the others. Doug’s goodbye letter paints a picture of exactly this type of dysfunction. A company that empowers only engineers will primarily produce engineering innovation — a company where all disciplines are represented can innovate in several spheres at once.
This is easy enough to say, but hard to do. That’s why Luke Wroblewski and I have been teaching a course for designers on this topic. It’s been taught around the world and in several familiar venues (UIE, IA Summit, Involution Studios), and it speaks to how designers can make intelligent use of data closely coupled with design thinking to raise their strategic influence within an organization. If you’re interested in finding out more, or are a design manager/director who would like a version of the course taught at your organization, contact me here.
“The underlying problem is that design is a holistic discipline while data-analysis, applied dogmatically, is a reductive discipline.”
Very well said. When you get too caught up in the minutiae of a design it becomes very easy to lose the big picture. Having the data to support design is great to a point.
I can see how a designer like Bowman could wear down over time. If I was in that situation I would find it an exciting way to design at first but would get very tired of defending every decision.
Also, the comic made me chuckle
Hey, guys, nice article! I discovered your site a couple of years ago…back when you came out with the HCI rap song *awesome*!
It’s comforting to know that there are other designer-engineers (designeers?) out there who find that they wear both hats, and strive for excellence at both. I look forward to being a regular reader of your posts.
I am not surprised by Bowman’s comments at all because his situation is the norm of the industry. It’s a sad thing, but the power and level of control over the medium of software precludes any business from true cross discipline innovation. Embattled designers are reduced to eking out some semblance of process, our only light at the end of the tunnel is a fierce, drawn out, in the trenches, one-off success. It’s usually an accident rather than a process
For the most part, a software tech company cannot achieve company wide transformation from the bottom up, it’s not possible because it’s not something written into the bottom line. Tech businesses are extremely volatile entities even once they “emerge” from the startup period, they remain short term oriented, flakey. This is because enterprise or share-holder interests are intentionally short term, so a company that caters to them exclusively can never achieve the organizational discipline to institute a process of innovation. Thus tech companies are continually putting their brands at risk, and designers are inherently tormented in working for them. It takes design leadership from the top to institute some semblance of process, otherwise designers remain destined to accidental, one-off successes in an ongoing war to rationalize user needs with a completely irrational and tyrannical ownership over the means of production.
Hi Tom, Really interesting reading; thanks for the insight. I added a link to this on a BusinessWeek blog post I wrote on the same topic: http://blogs.businessweek.com/innovate/next/archives/2009/03/google_design_o.html
I had a friend who *was* a designer at Google, who reported that during a confidential job satisfaction survey at the company, while 80% of the overall employees were satisfied at Google, only 20% of the designers were.
On the other hand, as a designer I’ve often come into conflict with other designers over my ‘pragmatic’ approach taking into account engineering realities. And also from engineers who believe that designers need to stick only to design and leave the implementation details to them.
Your course sounds fascinating and insightful… makes me want to write more myself on this topic.
“That’s why Luke Wroblewski and I have been teaching a course for designers on this topic.”
On that note, I recently discussed the approach Tom & I take with this course in an interview for the User Interface Resource Center:
Great article and great course. My number one takeaway was the concept of “response-able” vs “responsible”. All too often designers assume the role of victim - ‘I never get invited to meetings’, ‘no one cares about design’, etc. Part of being a successful designer is not assuming that others are “responsible” for your success. Designers need to become “response-able”, locating and leveraging data that will help increase the visibility and impact of their work.
BTW - I’m a designer who happens to believe designers whine too much.
I’m glad to see “dogma” mentioned. Yes!, the “magic” is at, and only at, the intersection of our respective disciplines. When we don’t recognize the value of each others contributions we fail, perhaps paradoxically, in our own capacities.
We have to recognize, soberly, that the drives and modes of thinking of engineers and designers are quite different. Yet, as with science and art in general, we are looking to answer essentially the same questions.
Google is simply a technology-driven, engineering-oriented company. As such we should temper our expectations, as designers. Their motives and goals are not unlike ours, however, even if their methods are very different.
So to both designers and engineers: collaboration is collaborating when the weather isn’t good, when people don’t always collaborate back, and with people who simply look at a problem from an opposing point of view. Including one that says, “trust machines and numbers, not people.”
Also we should recognize that morale at The Googleplex is at an all-time low for a wide variety of reasons, many of which have nothing to do with design approaches.
Tom, fantastic article. I’ve been heading down the same path, trying to get my arms around how we might do a better job of integrating user experience and web analytics. Here’s a link to a presentation I’ve given a couple times this month on the topic (I’ve cited you here): http://www.slideshare.net/lrosenfeld/marrying-web-analytics-and-user-experience
Many thanks again; I was excited and inspired to read this.
I am a copywriter, and I work for a company (Atom, Israel) that has developed a family of CMSs (WSCraft) with the “designer-to-designer” approach. The system concept is aimed (between other goals) at solving exactly the controversy brought up in your essay. Lots of thanks, great work!
Levothyroxine 150 mcg.
Compare levothyroxine liotrix. Levothyroxine sodium for dogs. Compare levothyroxine thyrolar. Levothyroxine.
Ahhh, I miss the good old days and would really like to hear another HCI rap.
OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?