Interview: How the design process works at Google Analytics

 – posted November 27th, 2008 by Brian Donohue     Comments (4)

As soon as you work on developing a website or web apps in a large organisation, you usually can’t but help think, “Surely there has to be a better way to build this stuff.” So many meetings, so many requirements and design documents, the pain of testing, and the inflexibility to focus on actually creating a good design — they all contribute to a process that feels bulky, cumbersome, and long winded.

When I was at the Google Analytics Summit a couple weeks ago, the lead user experience designer for GA, Doug van der Molen, gave a presentation to the group about some in-development features. Google is a massive organisation, I thought, wouldn’t it be great to find out how they’ve tackled this ubiquitous development challenge?

Seeing the chance to peek inside the design process at Google, I grabbed Doug after his talk and recorded this impromptu interview.

Part 1

Part 2

Highlights from the interview

Brainstorm design options

Doug gets brought into the development process early on, and quite quickly he creates 3-5 concepts that are “concrete enough so we know if the feature is headed in the right direction or not, but not too detailed where I’m bogged down where these pixels go”. Sometimes they continue to build up the different options until it’s clear which direction they want to go.

My 2c: This is a great way to force people to talk about something concrete, rather than thinking everyone agrees on a point when in fact they all had different ideas in their head. But I think the critical piece is forcing yourself to come up with different design solutions. Visual designers do this often, but I think UX designers rarely do this is more than at a very high-level prototyping. Something to try to emulate.

A design spec without words

I think most UX designers would be envious of this part: Doug tries “not to write down anything…because engineers respond better to pictures”. The handover process is “an interactive process with the engineer”, who sits directly across from. This “proximity is critical…at least one of the most important” components of the process.

My 2c: I agree this is the ideal world — where the UX designer and the developer can iterate quickly right at their desks. The developer can say — “This won’t work, how about…”. But actually implementing this at most large organisations would require major cultural shifts. It seems the critical piece that Google does right is to let small, focused teams work on products.

Interestingly, this verbal and visual design spec is a common theme in agile UX processes. This quote is from Desiree Sy’s paper on Agile User-Centered Design:

Prototype demonstrations and daily conversation have largely replaced detailed documents such as usability test reports and UI specifications when communicating with the product team. Documents are now written for interaction designers, to record a history of design decisions.

Frequent user testing

The GA team has a dedicated researcher, who uses both qualitative and quantitative techniques. For some designs, they don’t use any user testing. For others, they have a couple rounds of testing, either remote or by brining people into Google. The critical point from their perspective is that you can’t just show the user any data. “Seeing fake numbers is meaningless”. You have to use the participant’s real data. That way you can tell not just if the new feature is usable, but if it’s actually useful.

No personas

Though they did a lot of research for GA version 2 (which launched in May 2007), “personas just never came out”. Despite this, it sounds like Doug has implicit personas in his head, as he described the application as having “different layers” which “set expectations right”. New users should get basic analytics insights immediately, while the more sophisticated features, like advanced segmentation, are a  “tucked away” so they’re not “in your face”.

The bottom line - the GA design team is surprisingly agile

Much has been written recently about trying to incorporate UX design into agile development process. (See Alan Cooper’s presentation, this Cooper blog post, UIE’s two articles, Desiree Sy’s in-depth article, and Jakob’s view on it). In this context, the GA team is a good case study for the ideal relationship between the UX designer and the developer. What seems critical is the organisational structure — small, multi-disciplinary teams working closely together (both literally and figuratively).

In most organisations, there’s often a big gulf between the designers and the developers. The design specification serves as the bridge between those silos. But in Google’s case, the bridge isn’t just a document, it’s an ongoing conversation, which is a much better way to encourage the small but vital iterations that distinguish great products from merely average ones. And of course, it doesn’t hurt to have hugely talented people at both ends as well.

Categories Design, Web analytics

Comments Closed | Trackbacks Off | permalink