Build with Google Cloud
The ask
Create the “Flying Car” of newsletters and thought leadership content. Build with Google was intended to be a content rich website that would distribute thought leadership content, and highlight the use of google products through that content. It would arm executives with ways of snipping content and including in their own presentations.
The history of machine learning
The build product was a platform that needed to be designed and developed from scratch. We were in a blue sky arena, our clients focused on content that was rich in thought leadership, the content would include many google products as solutions and discussion of how they support the various business leaders (their audience).
Content rich interaction design
The Machine Learning timeline was an example of thought leadership content that is engaging and educational. This content was not a simple long for article, the timeline required a lot more interactivity than a regular article. We decided to utilize a persistent timeline across the top that would allow users to view the cursory view of events and what year. Users can access the content in two ways, scrolling down and/or click on the year in the timeline. Each timeline entry had more content that would be revealed by the user initiating the expansion.
Defining the MVP
At the start of the product definition, we held a client and agency meeting to run an MVP feature prioritization session, following the Moscow Method. This session was critical in agreeing and voting on Must Have features, and then align other features to be in future releases. One of the best examples of rolling out a product in phases. We even launched without a nav!
Exploring grids & layout
I started out creative exploration by designing various layouts, each layout would allow for different goals. The variations and options presented to the Google team isolated navigational options (top horizontal, left vertical), and content layout and way finding. We had options for our content grid, and even pushed breaking the grid with overlapping titles and allowed for more white space.
Responsive design approach
When designing, we created each screen in 3 sizes for our responsive web solution, rather than tackling mobile first we designed one screen and obtained approval and then designed the other device views to ensure smooth hand off to development. This way no one has to make assumptions about how the screen should resize on each device. Our visual language utilized the Google brand colors, each color represented a category or topic.
Obtaining the lead user flows
For our future releases our strategy revolved around lead capture for all Google cloud products. Each product would have a user journey and cadence that would lead them to eventually buy and/or subscribe to the Google Cloud Products.
Anatomy of a newsletter
As part of the push for thought leadership content, one of our best sources of acquisition and an audience of subscribers would be tapping the millions of current newsletter subscribers. With this effort, we conducted an audit of the best in class of newsletters and ways of subscribing. Off the back of the audit, we then created an anatomy of a newsletter review with the client to ensure we’re following best practices and industry standards. This was well received and provided much guidance for the team.
Newsletter wireframes
Each email newsletter was designed to be thoughtfully laid out across all devices. From our review of the research and data provided by Google, we knew that Tuesday afternoons are the best time for distributing newsletters. This time was directly attributed to have the largest open rate. Each wireframe was created intentionally based off the research. Inputs and insights such as “Length of read, short pithy titles, left aligning for scanability and snippets of interactivity were main drivers in the wireframing process.
Tablet wireframe & mockup
As illustrated above, you see the wireframe and then the visual mockup where once we figured out the best layout, then, and only then, we were able to apply the UI and visual design language.
Defining a platform
A content platform
As the build product advanced we began to explore how this platform could become a more robust product and could account for multiple content creation scenarios. It would also allow for content to be pulled in. These skeletal layouts were used to facilitate our recommendation to create a platform and not just a product.
Platform architecture
While exploring the content platform, we were thoughtful in the way we explored how users would engage and navigate through the content. The platform would behave as a “spotify-esque” experience.
Platform features and functionality
Feature sets were explored based on the necessities of the users and the business goals. Saving content for later, pulling in other Google content from other sources would be a value add for customers and users.
Platform personalization & engagemenet
The platform needed to be engaging and that engagement would provide users with more tailored content and would be personal to users needs and time.
With the platform conceptualized, we started to then thought about collecting quantitative and qualitative data from users who engaged with and utilized our content, what could we learn from this, how could we iterate on the product, how will this feedback advance the platform and the user experience.
Tapping our users for Feedback
The flow chart above demonstrates how users will navigate through the process of providing critical input and feedback on the experiences of thought leadership events, spun off of a Machine Learning platform that informs which content and events Google Cloud Service customers are seeking.
Award winning design
As a result, we couldn’t be more pleased with the awards and accolades given. This product had the best of interactivity, engagement, illustration, and most importantly content that real people want to see and read.