Interview: How the design process works at Google Analytics

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.


  1. Great interview, Brian. You’re a natural: more Parkinson than Pat Kenny.

    And some great insights: documentation a last resort; communication, proximity, trust, and great people: the essence of great design; marriage of design with technical – iteration and cooperation – one adding to the other. Great stuff.

    Question? Would Google’s design process – as described here – work with crap people and low trust levels?

    Another question: can this process be generalised to extra-organisational design relationships? In Google, everyone’s working for the same collective goal: better software. But if a 3rd party was providing this design expertise, would the same process work? I.e.: Can we scrap documentation? Can we just talk and sketch and talk some more? Then tinker, then iterate, then talk some more and iterate some more. Would clients be happy with that?

  2. Good questions, Morgan.

    1. I don’t think any design process works with crap people. The goal is to arrive at a process that doesn’t prevent talented people from doing good work.

    2. But as for how this could work when 3rd parties are involved, that’s a really tricky one. With 3rd parties, you have contracts, change requests, and the entire business relationships formally relying on detailed documentation. When there’s disagreement, you have to go back to the documentation. Without it, everyone is stuck.

    For in-house teams, or contracted teams who own the entire produce, more agile processes are feasible. But when part of the work is split up, it’s really difficult to imagine how the process could function with verbal documentation.

    I think this is a big question we’ll have to think more about ourselves.

  3. Great interview Brian. Very informative. I had a very similar agile relationship with the coders on the last project I worked on in the Nokia Research Center.

    We were a small team of about 6 people, developing a client/server platform for quickly prototyping mobile games & applications. Each week we’d review & set a list of goals & features, and during the week we’d work towards those goals. When trying out new UI functionality I’d bounce my ideas off the team, and then at a more detailed level with Ari, who did most of the the front-end client coding. We would often work side-by-side going through the issues, seeing how close to our ideas we could get within the limits of Java MIDP2 and MUPE.

    This process worked really really well, like Doug mentioned a trust and respect in each others abilities quickly builds up. But equally as important, by working in such proximity the designers learn the limits of the technical possibilities, and the coders learns to view the technical issues from a user’s perspective, and in our case the collisions between these two paradigms provoked creativity rather than hindered it.

    As a team we were very quick at turning ideas into working prototypes. Indeed, in a two-day workshop we brainstormed, designed, specified, built and tested three working mobile multi-user applications (a game, a book review application, and a social gathering application). This was only possible because of the close knit & agile team dynamics.

  4. Google seems to be on a good track.
    I know that in our business every project has to be a marriage of the technical, and the artistic ends of the project. two people working right together works out better than many on one project.
    once the design has been completed, outside comments can then become more helpful in polishing the final product.