Notes from Google Chrome talk

At BayCHI’s monthly talk last night, we heard Glen Murphy, lead (only?) designer for Google’s Chrome web browser explain their process and challenges. Quite a fascinating internal look at this specific team’s design process (Murphy made a point to clarify that each design team at Google functions differently per their dynamics and goals, etc.). Below are my key takeaways.

  • No design documentation (ie, specs); instead the approach was “mockup as spec”, given the tight loops of trust and feedback among the core team elements: design, engineering, and product management. Engineers used the mockups as the source for prototyping and implementation.
  • Each member of the team had a mix of skills, including coding/designing/business sense, etc. so no one person was focused on just one thing as their speciality. Each was able to contribute to the other’s relevant area/domain.
  • Chrome was created for the purpose of “speed” and “reliability”, which I personally imho found a bit dubious (couldn’t G team have just collaborated with Mozilla to make Firefox faster and more reliable for Google apps?).
  • No wireframes created in their process; went straight to pixel perfect mockups–all mockups were “fully formed” in Murphy’s words.
  • The three major elements in consideration of each design iteration and sketch were: interface, graphics, and platform (meaning the platform guidelines for Windows XP/Vista).
  • Each tab was treated as an isolated instance of Google Chrome, for better stability/performance. Murphy sez, “we were basically creating a tabbed window manager”.
  • The tabs were one of the critical elements from a UI POV as well as branding, became the central identifying element of the interface. Did over 1600 iterations of the tabs in Photoshop, trying finicky levels of radius details, etc.
  • Talking about the Omnibox (combined Search bar and Address bar) as the second critical feature of Chrome, Murphy described various iterations of what should appear when a user typed a word or phrase combination. Tried out lots of options in mockup and implementation. Ultimately used user feedback, but did what engineers “felt right”.
  • What’s coming next for Chrome: extensions (but do it in a graceful, seamless way, aesthetically and functionally) and openness, which Murphy admitted he didn’t have alot of experience in as a designer, dealing with the challenges of design open source software UI, and allowing users the modify, etc.

Overall I was struck by two things:

1) How the reliance and insistence on pixel-perfect mockups from the get go parallels Apple’s UI design approach from what’s been described in the media…no wireframes or paper prototypes, etc.

2) How Murphy kept using the words “feeling” and “felt right” quite often in his talk to describe design decisions and rationale. Really speaks to the fact that alot of interaction really has to be just done and judged by your own phenomenal experience of it. Does it feel right or not? He did mention the obligatory user studies and quantitative evals but seemed to me, imho, that he took that as just data points, not necessarily wedded to all that, instead relying upon his (and the team’s collective) experience/wisdom/judgment to make design decisions.

Leave a Reply