Redesigning the Actions on Google homepage
2019 — Google — Responsive Web
About this project —- Actions on Google is a development platform for the Google Assistant. It allows the third-party development of "actions"—applets for the Google Assistant that provide extended functionality. The website had been hastily put together and not a ton of thought was put into IA; and the site hadn’t been updated to reflect the rapidly evolving ways to build for the Google Assistant.
Project Goal —- Redesign and develop the Actions on Google site in order to clarify the multiple building paths and solutions for developers, enabling clear and simple access to the right resources.
Platforms — Responsive Web
Team — Design Lead (me), Product Manager, Product Marketing Manager, Visual Designer, Technical Program Manager
Project duration — 3 months
Links — Actions on Google Homepage
Sprint 1: Discover
Gaining a comprehensive view of the problem space
I began by conducting a series of workshops with the main stakeholders. I was working with a marketing team that had deep understanding of the product, but also had difficulty building consensus and alignment. I first wanted to understand their POV on why the current website wasn’t driving the results they expected.
Website audit
Stakeholder interviews
Key personas
Remote UXR
Workshops
• “If we provide clear pathways to building for specific purposes, users will find it easier to get started.”
• “Adoption is going to come through showcasing compelling use cases and positive developer sentiment.”
Hypotheses
Sprint 1: Discover
Creating key personas through UXR
Working with the Google Assistant Developers community team, I sent out an online survey to 50 developers, in addition to bringing 10 developers in for in-person structured interviews, asking each one to walk us through their most recent voice project from conception to completion.
Process
From our research, we created 3 main personas with clear goals and jobs to be done; and highlighted website sections that corresponded to those goals. This was an important exercise to make sure that we designed with a comprehensive understanding of the different types of developers that used site.
Results
Sprint 1: Discover
Key personas
Persona A
The Professional
These user is typically the “tech person” at an established company trying to grow the business. “I want to build something that has the most reach with the least amount of effort.”
Goals & needs
— Amplify company product with conversation
— Drive traffic and increase awareness
— Out of the box solutions
Persona B
The Innovator
This person is the “startup” founder persona — highly tech-literate, and wanting to dive in, build fast, break things. “When I have a new idea, I want to build an MVP as quickly as possible to test”.
— Make a business out of developing conversational experience (s)
— High level of customization
— DialogFlow, Assistant-enabled devices, Interactive Canvas
Goals & needs
Persona C
This user creates or is in charge of a body of content, and their aim is so increase discovery and engagement through voice search.
The Content Creator
Goals & needs
— Increase reach of content
— Quickly transfer their content to voice markup in efficient manner
— Out of the box solutions
Sprint 1: Discover
Understanding the user journey through UXR interviews
We asked the developers to walk us through the process of creating a new Google Actions project for their specific use case. It helped us understand how users navigated the current iteration of the site.
Sprint 2: Define opportunities Combining insights
into clear design opportunities
I conducted a series of workshops with the main stakeholders, where I presented my work from Sprint 1 and solicited feedback. This process helped me create a series of design principles. Each principle had to be:
(1) Supported by research
(2) Agreed upon by all key stakeholders
(3)Actionable by design
Design principles
Examples
(1) Prioritized pathways
(2) Show, not tell
Adoption will come through compelling use cases and positive developer sentiment
Users will be more inclined to build if they’re given clear directions on how to begin
Main user insights from research
Sprint 2: Define
Developers don’t know how to build for the Google Assistant
(1) Lack of understanding about how to build on a new platform leads to lowered confidence
(2) Lack of emphasis on developer’s preferred methods for learning and developing on landing pages
Developers don’t know why to build for the Google Assistant
No emphasis on addressing key developer motivations such as:
• Monetization
• Career advancement
• Potential audience
• Community incentives
Developers don’t know what to build for the Google Assistant
(1) Addressing lack of inspiration
• Lack knowledge on what already exists
• Lack of knowledge on what’s possible to build on the platform
(2) Fighting “blank canvas” syndrome
Content prioritization through card sorting
Sprint 2: Define
I conducted card sorting on a group of 24 developers, asking them to sort types of content into three categories: the content that was most important and relevant to them when developing an Action, content that was somewhat important, and content that was not important.
Process
Rationale
This was an objective way to create some sort of alignment amongst my stakeholders, who ranged from marketing and PR backgrounds who wanted the site to look visually pleasing and tell a compelling story to program managers who were deeply entrenched in the documentation.
Now that I had a deeper understanding of the overarching goals of the developer portal and who would be using it, I began to honing in on specific UX/UI choices such as navigation, support content - using our acquired context, stakeholder feedback, and light-weight user testing to make decisions.
Sprint 3: Develop designs
Navigation & systems
Key activities
User Journeys & Support Content
Navigation
Illustration System
Content & UX Writing
A focused navigation bar with shortcuts to content
Sprint 3: Develop
The previous nav bar consisted of broad categories that led users to separate category pages that developers had to scroll through in order to find the specific sub-pages they were looking for. In our developer interviews, developers consistently mentioned this approach as inefficient and expressed a desire for a short-cut to sub-pages that centered around the nav.
Before
After
We redesigned the nav to incorporate drop-down menus that provided shortcuts to key support content (as identified through our card sorting exercise).
An illustration system that appeals to developers
Sprint 3: Develop
I worked with an illustrator to establish a new visual system for the developer page. After several brainstorming sessions, we landed on two divergent treatments that we presented to stakeholders.
Before
After
Treatment 1 was more abstract and whimsical; Treatment 2 focused on more realistic depictions of Assistant-enabled devices and concrete examples. We ultimately decided on Treatment 2 on the basis that the concrete and realistic style was more appropriate for a developer-facing page.
Leveraging our insights, I made the decision of emphasizing 3 key pathways originating from the home page that would lead to dedicated sub-pages. Each subpage would cater to the context and goals of each of the 3 main personas we previously identified.
Path 1: The Professional
Hero title: “Extend your mobile app”
Path tl;dr: “Provide faster ways for users to
access your Android app via the Assistant”
Path 2: The Innovator
Hero title: “Build rich & natural conversations”
Path tl;dr: “Create custom voice and visual
experiences for smart devices”
Path 3: The Content Creator
Hero title: “Enhance your web presence”
Path tl;dr: “Present your content in rich ways for Google Search and Assistant.”
Sprint 3: Develop
Creating subpages for each key persona
Usability testing with prototypes
Sprint 3: Develop
I created a series of prototypes and recruited another 12 developers to walk through them. I gave each developer a series of situations (You’re a developer who is looking to extend a recipe app to voice…”) to see if they understood the different “pathways to build.”
Comprehension testing
I had developers rank a series of content modules from most to least important for their use case. This would help us have an initial idea of how to rank content and what to prioritize above the fold (iterations could be done based on CTR after we published).
Card sorting
— Overall, our task success was 62.1%, which was a great sign. However, there were still some improvements to be made.
”There’s a lot of text on the screen…it’s hard to differentiate paths quickly just by reading.” (Developer, US)
Sprint 3: Develop
Main takeaways from testing
Task success
— Proceed with drop-down “mega-menu” instead of tabbed IA
— Leverage visual design to provide differentiation in paths
— *Adapt to new deisgn system (!!!) We found out mid-sprint that developers.google.com was in the middle of converting assets to Google’s new Material 2 standards, so we had to adjust our component library accordingly.
Design changes
Sprint 4: Delivery
Nailing down a final design
Activities
Usability testing
I created a series of prototypes and recruited another 12 developers to walk through them. I gave each developer a series of situations (You’re a developer who is looking to extend a recipe app to voice…”) to see if they understood the different “pathways to build.”
Iterations based on research
Polish final visual assets
Create design system for handoff
Project Results
Original site (System Usability Score)
SUS Score*: 33%
Initial audit with 12 developers. Developers didn’t know how, why or what to build.
SUS Score*: 33%
First iteration
We addressed key points of friction, including density of copy, unclear choices (“not sure where I’m supposed to go”), a lack of concrete examples and a lack of patterns for easy path recognition,
Final iteration
SUS Score*: 88.6%
Pathways were clear and developers were able to find their solutions, interviewees were able to understand how to build and examples and
visuals helped confirm that users were where they wanted to be.
Feedback
Feedback gathered from the Actions on Google Developers Twitter account