TL;DR

Hangouts Meet is the culmination of my 5½ years of work at Google on video calling. It’s a complete rethinking of business video calling from Google, elevating video calling to full fledged app in the G Suite. I am immensely proud of the work that we did to bring it to market. Here’s a summary of the project:

• I co-founded the project, created a vision for a new G Suite product, pitched it to leadership and ultimately the project was funded with an engineering team.
• This team was a small startup inside the company that moved very quickly, getting an initial version of this new app into customers hands in 1 quarter.
• Managed a small team of designers and coordinated with UX researchers to constantly test and evaluate what we were building.
• Moved to Sweden for 5 months with my family to follow the project when it was moved to Stockholm. Onboarded a new team, continued the vision, and the team designed the new experience for Android, iOS, TV (conference room), Hardware, and Web.
• The product launched as Hangouts Meet at the Google Cloud Next Conference in March 2017.

Due to confidentiality there’s a lot that I can’t share in this case study. For example: early explorations or features that never saw the light of day, images of customers and research participants, personas, prototypes, specs and red lines, and most importantly usage data and metrics.

Context

Google launched its first video calling product in 2008, Gmail Voice and Video Calling, but it didn’t get into multi-way video calling until Hangouts launched with Google+ in 2011. I worked on Hangouts video calling when I joined Google in 2011, launched it externally, and continued to work on other parts of video calling including Hangouts On Air and Chromebox for Meetings (VC hardware by Google).

Hangouts had originally been built as an internal tool to solve Google’s video conferencing problems, but when it was released as a part of Google+ in June 2011 it had been remade into a social video calling product. Even then, it was both powerful (free 10 person video calling in a web browser) and simple to use. Over the next few quarters, Hangouts added more productivity features that would appeal to businesses including screensharing and basic document collaboration. But it was still a product that suffered from a split personality, one part social communication tool and another part business video conferencing system.

…it suffered from a split personality, one part social communication tool and another part business video conferencing system.

I had a front row seat while Google adopted GVC, its Hangouts powered internal video conferencing system in 2011-2012. GVC is deployed in every conference room internally, and it is second only to Gmail in importance as a corporate communication tool at Google. Internal communication improved greatly when GVC was deployed at it changed Google’s corporate culture for the better.

The problem

But as good as it was, Hangouts suffered from a few critical flaws that we needed to solve if we were going to compete in the marketplace and improve customer experience.

1. Because it was built for Google, it wasn’t great for companies that weren’t like Google.
2. It contained too many fun social features and not enough productivity and business focussed features.
3. Hangouts was better than average when compared with other video conferencing tools, but it was still too hard to join a call. In order to be widely adopted, users needed to trust that the video call would work, and it had to be easier to use than calling someone on the phone.
4. Hangouts had been designed at a time when mobile phones weren’t pervasive and mobile networks couldn’t handle video conferencing. But this was increasingly changing; customers needed to be able to join the call from anywhere on any device.
5. Video calling on mobile was a part of the all encompassing communication app that was Hangouts. But the needs of enterprise chat and the needs of enterprise video calling were very different. Splitting them into 2 seperate apps would allow each team to move faster and better meet the needs of their users.

In order to succeed, we needed to create an product that was:

1. Incredibly easy to join. It had to be easier than calling someone on the phone.
2. An entirely separate app with a mobile experience that was just as good or better than what you got inside the browser on your laptop.
3. Worked for businesses of all types, even those that weren’t like Google.

What if we started from scratch?

In April 2014, I took a trip to Stockholm to meet with my Product Manager and talk about the next few quarters. He was trying to grow Hangouts usage in the Enterprise, and I was going to be the UX designer responsible. We were both frustrated by the limits of Hangouts for businesses because it was primarily a consumer product. So, as a thought experiment I started imagining what a purely business focused video calling app would look like.

I codenamed it “Google Meetings” and imagined it as a top level app inside the Google Apps Suite (at the same level as Calendar, Docs, Drive, and Gmail). It would combine our newly launched conference room hardware with mobile meeting apps that would make it easy to meet on the go. And, it would integrate with the video streaming and live broadcasting infrastructure that we had in Hangouts On Air and YouTube Live to enable companies to stream a meeting to thousands or even millions of people around the world. In short, it would take all of the pieces that I had worked on previously and bring them together into a cohesive product designed for business customers.

Selling the vision

I became very excited by this idea. The potential was clear. We needed to bring the incredible video conferencing system that we had internally to customers under a unified brand and focus on their needs.

The problem was that there were no engineers to build it. At the time, the entire Hangouts team was focused on growing the newly launched Hangouts (unified communications product for consumers that had been launched the year). Enterprise communication wasn’t an area of focus and there weren’t any resources to dedicate to this project and vision.

…there were no engineers to build it. Enterprise communication wasn’t an area of focus and there weren’t any resources to dedicate to this project and vision.

Luckily for me, another org inside Google (the Google Apps team) was tired and frustrated that there wasn’t enough focus on Hangouts enterprise features even though customers had been asking for them. So, they had decided to commit a few engineers and a PM to work on this problem, but that team didn’t know where to start. My “Google Meetings” vision was just the thing that was needed to catalyze the team into action.

A product design story in 2 acts

Act 1 - Project Ironman: A startup within Google

We were a small but mighty startup inside Google. Our job was to prove the vision to leadership in order to fund the project and convert it from idea to actual fully funded project.

Rather than work towards a fully fleshed out complete product, we focused on getting as much data as we could about things that we wanted to change or add to Hangouts. We focused on the more radical and controversial ideas in the hopes that some of them would actually succeed. Since we weren’t building something that was going to last, we could afford to take risks and get data.

Start with the design sprint

It was a room full of people who’d never really worked together. A Product Manager, a few engineers, a sales strategist, 3 UX Designers, and 2 UX Researchers. I believe in the power of a Design Sprint (see The Sprint Book, written by my friend Jake Knapp). In a week, sketch, ideate, vote, build, and—the most important part—bring real people in to use it on Friday. Yup, 5 days from idea to user prototype and testing.

We structured the sprint around the three phases of a meeting’s life cycle: before, during, and after. Google Hangouts had always primarily focused on the in-meeting experience. But, it never really helped you prepare for your meeting or follow up on decisions and questions that were discussed in the meeting.

How might we make meetings better before, during, and afterwards?

We split into 3 groups and focussed each group on one part. By the end of the week we had several ideas and 3 prototypes that we tested in the lab with real users.

Due to confidentiality, I can’t show images from these early sprints or research sessions.

Move fast: build, test, repeat

With the data from the Sprint we set the audacious goal to actually build a working product that we could launch to ‘trusted tester’ customers in one quarter of development. There was no way we were going to be able to build a Google caliber app in that amount of time, so instead of trying to build something that could operate at Google scale, we built for speed using off-the-shelf components, open source systems, and tools. We were operating like a startup inside of Google.

Design constraints for trusted tester:

1. It would only work on Chrome.
2. You could only have up to 4 people in the meeting.
3. Initially, it would only work on the web and on Android.
4. Many features that you might expect wouldn’t be there.
5. No interoperability with other systems like Hangouts.

Concepts we wanted to validate:

1. Great mobile meetings experience.
2. Short URL based meeting in a global (not domain based) namespace. This was a major departure from the way that Hangouts worked.
3. No remote control in the conference room. Instead you would “cast” your meeting to the TV from your phone.
4. Features to make meetings more productive by helping people stay on track.
5. Make it simple to join a meeting; get users in as quickly as possible.
6. Enable awesome and useful meeting notes.

With an extremely small team of people (3 UX, 2 PM, 6 Eng) we delivered a functional app that we could give to 10 trusted tester customers (outside Google) on 2 platforms in 1 quarter. The first version supported file sharing (from Google Drive or Dropbox), screensharing, and meetings were created with a single click. Anyone with the link could join.

The prototype was extremely limited in features. You could only have 4 people in the call, HD wasn’t supported, and the UI was very utilitarian. And yet, because it was so easy to use, several of these trusted testers actually switched their entire company onto the platform (which we didn’t recommend because we didn’t think it was reliable enough for tha). We knew we were on to something and kept working.

And yet, because it was so easy to use, several of these trusted testers actually switched their entire company onto the platform.

By the end of the next quarter, we were able to add iOS as well a conference room system. We built a “smart agenda” feature, and the conference room system was completely controlled from your mobile phone using Bluetooth LE, no remote control required. You walked into the conference room, swiped on the push notification, and the meeting magically appeared on the TV. This pairing experience was so fast that we had to actually slow the UI down and add additional visual cues because everything happened too quickly.

Act 2 - Project Thor: From California to Sweden

Building a product in 2 quarters that customers actually used and relied upon across 4 platforms is not the norm inside of Google. Google builds products that are meant to scale to hundreds of millions of users on day 1. Folks inside the company began to take notice of what we were doing. And to make a long and somewhat political story short, the decision was made to move the project from one org to another and from Mountain View to Stockholm. This new project was named Thor.

I still believed in the vision, and I wanted to finish what we had started. I was asked to move with the project to Sweden to continue work and help onboard the new team in Stockholm. My wife and 2 little kids decided to take a leap of faith and move to Stockholm for 5 months. So on January 8, 2016, the 4 of us took off from Oakland en route to Stockholm, on our way to an apartment that no one but me had seen with 8 bags and 2 strollers.

My wife and 2 little kids decided to take a leap of faith and move to Stockholm for 5 months.

Our new mandate was to take the Ironman vision from idea to reality and launch the next generation of video meetings from Google in less than 12 months. We were no longer building a prototype, but a production ready app, one that would replace Hangouts for all Google Apps customers. This would be the first only-for-business app that Google had built and released.

Link-based meetings - 2 birds, one stone

Hangouts for business was token based. If I wanted to meet with you, we both came up with a meeting token,e.g. chat, and anyone who typed in the same token was in the same call. This worked well for Google for 2 reasons: 1) Google has a very open culture and so any inadvertent meeting name collisions because two teams used the same token at the same time were easy to resolve, and 2) most Googlers don’t usually talk to people outside the company.

But for organizational cultures that weren’t as open or expected only the right people to be able to join a call these meeting collisions were at best problematic and at worst a deal breaker.

And for sales-driven organizations or those that need to communicate with people at other companies the fact that the meeting names weren’t global was a real problem. In order to join a call at another company, you would need to know the full meeting name which would actually be “chat@example.com”. This fact, combined with a restrictive and cumbersome access control system meant that using Hangouts for video calls with those outside your domain was very painful.

The solution was to change the meeting token to a short URL and to make the namespace global instead of local. So as long as you had the URL, you’d be able to join the meeting no matter what. Click the link and you’re in. And, since the codes aren’t guessable and are unique, name collisions wouldn’t occur. Only the people who have the link can join.

People understand how to share links, whether they are sharing them on a phone, via SMS, email, or through corporate chat. And, on mobile, we could add URL handlers so that clicking the link would open up the right app or take the user to the app store to install it.

This seemingly simple change was incredibly controversial inside Google because we had been doing things one way for so long.

This seemingly simple change was incredibly controversial inside Google because we had been doing things one way for so long. But we knew that our customers had needs that the typical Google engineer didn’t so we backed up the decision with lots of research and held firm to our convictions.

A small but mighty team

I was there at the beginning of this project, but all of the good ideas came from collaboration with the team. The team that built the Ironman prototype was very small, and the team that did most of the work to bring Hangouts Meet to the market wasn’t much bigger.

If there is anything that I learned from this project it’s that a small team of people who all believe in a common vision can achieve a lot, certainly more than people expect.

…a small team of people who all believe in a common vision can achieve a lot, certainly more than people expect.

Getting out of the US was helpful because I was able to meet with international customers and see how they got work done. We ran regular research sessions in Stockholm, London, and Zurich in addition to sessions in the United States. At peak times, were putting things in front of users every 2 weeks.

I continues to lead the design team of 3 (2 UX & 1 researcher) from January 2015 - June 2016 when I left the project to join YouTube. Shortly thereafter, another trusted tester session with many more companies began, feedback was incorporated, and the product ultimately launched at the Google Cloud Next conference in March 2017.

Process

Due to confidentiality, I can’t share a lot of the work that the team and I created that never saw the light of day like early sketches and whiteboard drawings, research prototypes, personas, specs and red lines, and the feature ideas that didn’t launch.

Below, you’ll find high level overviews of the process that we employed when working on this project and some of the things I learned during that time.

Critical user journeys

Very early we established our Critical User Journeys for users of the App. Critical User Journeys (read more about CUJs) is a process that teams at Google use to identify and audit important parts of the user’s journey using the app or feature. This is similar to creating traditional User Journey Maps but differs in how you determine what to map. Too often, journey maps (because they are time consuming to create) focus on the most important features to the organization or the bottom line, and they ignore a category of experiences that are less commonly used but still vital to the overall customer experience.

CUJs attempts to improve this by splitting journeys into categories: pivotal journeys and toothbrush journeys. These journeys are then audited and tracked before and after launch. This last bit is key; the audit data helps Engineers and Product Managers have a tangible metric for product quality which often feels intangible which is bad because they are too easy to ignore.

…the audit data helps Engineers and Product Managers have a tangible metric for product quality…

Pivotal Journeys

These are important journeys that may not occur often, but if you get them wrong they sour the entire experience. For Ironman and Thor, we picked some journeys that we wanted to focus on. Here are 2 examples:

Joining a meeting on a mobile phone having never used meetings before.

This journey allowed us to focus on the mobile first run experience for a new user, which we wanted to make sure set someone up for success. If their first experience was bad, or they couldn’t figure out how to join a call, we knew that they probably wouldn’t want to come back.

Creating a meeting with someone outside my company who I’ve never met with.

Since we wanted to make sure that cross-company communication was really good, this journey allowed us to focus on the nuances of inviting someone from the outside and getting them into the call.

Toothbrush Journeys

These journeys are the common experiences that a user/customer does every day (get it? like brushing your teeth).

Creating a quick ad-hoc meeting with a colleague inside my organization.

Hangouts had always done scheduled meetings really well due to its integration with Google Calendar, but we knew from research that external users were less confident in creating ad-hoc (spontaneous) meetings.

Adding people to my meeting (inviting), both from inside the organization and outside it.

This is a very obvious journey that needed to be exceptionally good. Making this work well is table stakes to any video communication app.

Embrace controversial ideas when failure is cheap

Too often in product design, especially for established and launched products with real users, pushing things forward or trying something new can be seen as risky. You don’t want to invest time and resources building something unless you know it is going to work. And yet, I’ve found that many of these risky ideas really pay off and move the user experience forward.

With Hangouts, we had a product that had established ways of doing things. They worked really well for Google and had a lot of internal user momentum behind them. You might even call them the sacred cows. But some of these sacred cows didn’t work well for users (like the way we handled sharing meetings and meeting links). There were other ideas that we had as a team with the goal of making meetings more productive. We had no idea which of these ideas would work, and which ones wouldn’t.

…these sacred cows didn’t work well for users…

But because Ironman wasn’t touching Hangouts, we didn’t need to fear for our established users. So whenever we had an idea, we always pushed that idea to the most extreme we thought made sense. Don’t play it safe; don’t go for the conservative option. If it didn’t work or if we went to far we hadn’t invest that much time into development nor had we affected more than a handful of users. But, if our trusted testers like these controversial features and changes we were able to move the product forward very quickly. And instead of opinions about what might or might work, we had actual customer data and feedback.

Rapid iteration and usage with real users (trusted testers)

I’ve never been a part of a team that moved at the speed we moved, both on Ironman and Thor. This speed was an incredible asset to us. But speed without the knowledge that what you are doing is going to work is often a recipe for disaster. So for these projects, we built quickly, and launched what we built to trusted testers in order to validate what we did. The process looked roughly like this:

1. Design it a new feature or idea
2. Test it in the lab (UX Research)
3. Make changes to address feedback, if needed
4. Launch to trusted testers
5. Interview trusted testers and analyze quant usage data/analytics/logs