Posted by: Helen Walters on September 23, 2008
While many eyes are trained on Mountain View for the official release of the new G1/Android phone from Google and T-Mobile, I got an insight into Google’s design process from the company’s VP of Product Management, Sundar Pichai, and Group Product Manager, Brian Rakowski. These two spearheaded the launch of Chrome, a browser I’m truthfully still getting used to, but whose design certainly adheres to the company’s overarching philosophy of superficial simplicity disguising sophisticated functionality (for an indepth look at Chrome’s development, check out this really fine Wired article by Steven Levy.)
A problem that has beset engineering and technology-driven companies in the past is the disconnect between its various departments. Engineers dictated what should be done thanks to what could be done, technologically speaking. They then handed the ideas over to designers who were charged with making sense of it all. The disconnect often resulted in poor products, annoyed engineers and frustrated designers (and, ultimately, often, displeased CEOs.)
Clearly, Google is also rooted in engineering, but in its case neither technology nor aesthetics has a superior role. Instead, engineers are as invested in the design as in the functionality. As Rakowsi put it: “It’s an integrated approach where engineers are responsible from start to finish.” Such continuity ensures that aesthetics and functionality are one and the same. I’ve written before that sometimes the results aren’t as visually sophisticated as they could be, and some designers might feel that they’ve been left out of the equation altogether, but the logic of the approach is hard to reproach.
“Design is integral to everything we do,” said Pichai firmly. “We don’t say ‘here’s a feature, here’s a spec, now go and build it.’ We design it, we build a prototype and we make it real… Every pixel in Chrome represents countless discussions and people agonizing over the right decision.”
Of course, that agony is balanced by Google's obsession with data analysis, which is harnessed for the design approval process too. "A lot of our design is opinion driven but we do usability testing to make sure what we're doing is well received," said Pichai. "We don't go with something just because someone feels strongly about it, if the data says people aren't clicking on it."
By way of example, the pair pointed to the download manager toolbar, which caused them real problems and which required many trips back to the drawing board. The issue: How to resolve the tension between a single user's different requirements. Should the toolbar interrupt, to alert a user that the file is all present and correct? Or should it sit quietly in the background? Given that at various times, a user might prefer either result, the design solution wasn't initially clear. "We couldn't get it 90% right," remembers Rakowski. "The design needed to be flexible enough to support all of the potential different uses."
Their answer took on board complaints/feedback/suggestions from early users and was both simple and radical. Now, a large arrow briefly points to the downloaded file at the bottom left of the browser screen. It's there when needed, you know it's there, but it doesn't interrupt your work flow. It's an elegant solution -- that works.
Chrome isn't perfect, but Pichai and Rakowski are probably more aware of that than most. Even now they're working on adding new functionality, such as autofill, as well as on versions for Linux and Apple (those should come "early next year," they say.) But that's the thing about an evolutionary design process: the best is always yet to come.
What comes next? The BusinessWeek Innovation and Design team of Michael Arndt and Helen Walters chronicle new tools for creativity and collaboration, innovation case studies in both the corporate and social sectors, and the new ideas that have the power to change the way things have always been done.