Last Thursday, I attended a free session organized by SIGCHI, Puget Sound region at Google Seattle HQ. Jake Knapp, a very well-spoken user interface designer, entertained a packed house with a speech on 17 tactics that he uses for creating strong UX work in "the flood" of projects that pour through his UX department from month to month.
Since Google is well-known for its sprint approach to application development -- working quickly in small agile teams, touching base often to assess progress, aiming for short-term goals instead of having a long-term target, changing course to aim for quick wins -- I was very interested to see what methods they used to keep their many trains on the rails.
Jake did not disappoint, and unpacked his toolkit to show how he managed his workflow. I can't fit his whole talk into a single post, so instead I'll share what seemed like the top four main topics and their highlights.
Have Strong Project Foundations
The UX team at Google is fairly small, so they need to choose what to focus on wisely. When they start new design projects, they ask the following questions:
How much does this project matter? Is there a value for the UX department to take it on if they're extremely busy with big projects?
What is the business impact? If it's an app like Gmail or Google's search home, improving the user experience could have a huge impact on Google's bottom line. Better focus some attention on it.
How much UX impact will it have? How complex is the system to represent? As an example, Jake showed a view of a sidebar menu from Google Talk versus a chart that needed to explain the whole process of going through a signup process with Blogger. A well-rendered chart could have a big impact on user experience for Blogger, so this is where they'd likely focus the most attention at first.
Is the whole team (a.k.a. internal clients) willing and ready to engage with the UX team in the right way? This question dovetailed right into Jake's next key point: when you're working with new clients, you need to know what their expectations for UX are, then aim for quick wins to establish trust with them and build up a strong relationship. This is consistent with what I hear from many designers that work in-house within a large corporation: behave like you've been hired as an outside designer, and approach each project with the same level of professionalism and client service.
Let the Code Be the Mockup
Since Google is in the process of getting great ideas produced quickly, Jake noted that they often whiteboard the implementation of an idea with the engineer, then let the engineer build it. Wherever possible, they reuse code and existing patterns from other applications, then iterate the user experience with actual working code to get to a result faster.
Often, this investment in application prototyping will pay off. Many of the Google engineers are strong designers as well and they bang out super-functional prototypes. This allows the UX design team to try it with users, find all the edge cases, then shipping it -- often saving a buck or two on engineering in the long run.
While I can't imagine taking this approach to a heavy Flash piece, it sure makes sense for the kinds of apps Google is looking to unleash on the world on a regular basis.
Be Smart About (Re)using Research
Within Google, researchers talk to each other all the time, ensuring that they don't duplicate each other's user studies. This research is then shared wholesale through the corporation.
When new research is required, Jake noted that they try to hit multiple projects simultaneously. Through field research, diary studies, and ethnography, they'll map out their personas and other necessary use cases. Then, as their project narrows into tangible prototypes, they'll enter into usability studies to confirm their research and ensure it's functioning well.
Research-based workshops were another interesting twist to their overall research methodology. In order to solve certain UX problems or brainstorm improvements, large teams will take part in an immersive research approach. The rough structure that Jake outlined was thus:
Research Immersion: 2-8 hours long, with 10-35 people
1. Show the group rough personas of the users they're looking to target.
2. Identify unmet user needs. As an open-ended exercise, everyone would write on Post-It notes their imagined needs. As a group, these needs were categorized into themes.
3. Brainstorm solutions. The overall group would brainstorm possible solutions to those top themes that seemed most relevant.
The work from the immersion session would then enter UX design. The most promising concepts would be mocked up and presented to an overall committee, which would critique the ideas. From these concepts, project managers would step in to help the UX team build a rough schedule and plan out next steps.
Designers Need to Create Memorable Presentations
Since much of what Jake presents is evidence-based, and much of his work is reviewed by a committee before it can be implemented, he's become expert in giving top-flight, simple creative presentations. His rules for getting a great presentation together were:
1. Have a singular goal for your presentation.
2. Start on paper, and see the big-picture story. His metaphor was, "Don't use a periscope to map the ocean."
3. Make horizontal and vertical storyboards. Jake showed a photograph of his presentation written out on Post-It Notes, from left to right. The "vertical" storyboard was a way to ensure that each Post-It, when pulled out of context, still made sense as its own contained message.
4. 3 words or less per slide. 'Nuff said.
5. Follow the 10/20/30 rule, per Guy Kawasaki. 10 slides. 20 minutes, even if you have an hour to present. 30 pt font for your text, though Jake advocated 32 pts or larger.
6. Be careful how you present mockups. Often, Jake would grayscale his tight designs, then slap on crappy graphics for the approval of the rough markups in PowerPoint to ensure that they were discussing the ideas behind the UX, not the design itself.
7. Drawings invite people to participate. Keeping the design work rough cues everyone to know it's a work in progress -- and treat it as such in discussions.
Recent Comments