Behind the Scenes of WebEx Meet: An Interview with Jon Nakasone

In March 2010, WebEx launched the beta of their new product offering, WebEx Meet. The designers of WebEx Meet intended to create a solution that helps users meet and collaborate with each other in a faster, more efficient way.

I recently had the opportunity to talk about the beta launch with Jon Nakasone, one of the product design leads within the User Experience Group at Cisco WebEx. Jon’s group is responsible for bringing innovation to WebEx’s online collaboration products and focusing on doing more for the users.

Back in the summer of 2009, Perfetti Media worked with Jon and the WebEx team to conduct a series of usability studies to evaluate the WebEx Meet design. In our interview, I talk with Jon about the launch of the WebEx Meet beta and the WebEx team’s approach to design and user research.

Christine Perfetti: What are your main responsibilities at Cisco WebEx?

Jon Nakasone: I work with other stakeholders and product management within WebEx to ensure we’re working toward task-oriented and user validated designs, rather than feature-driven ones.

My main responsibilities include shaping the high-level design concepts, guiding user research efforts, establishing clear design principles, and working with other members of my team to drive the design through usability testing and implementation.

At WebEx, you’ve recently launched the beta for WebEx Meet. What is your team hoping to accomplish with this new product offering?

I’m really excited by the beta launch. Online meetings have remained mostly unchanged since their inception. Traditionally, when people think of WebEx and online meetings, it’s really about being in the meeting and the live meeting experience. After the online meeting, they’re done.

We knew we could add so much more value for users. For example, when people send their meeting agenda before a meeting, they probably send it by email. After the meeting is done, they most likely follow up with everyone through email. When we started talking to people, a frustration emerged immediately: all of the good things that happen in a meeting get buried in their daily avalanche of emails.

Over the course of time, it often becomes difficult for users to keep track of everything that happens in the meeting, including the document attachments and action items. It can be a mess. Sometimes it’s even a challenge for people to remember who was in the meeting.

With WebEx Meet, we wanted to solve these problems. To help our users, we identified the key meeting tasks and provided users with a consolidated place to manage all of their WebEx meetings, including their meeting files, important contacts, and meeting recordings. With WebEx Meet, everything resides in one place for users, which is a huge value for people.

Even if the meeting hasn’t started yet, people can come to WebEx Meet and reference who will attend the meeting and download meeting files to review. Similarly, after the meeting has ended, people can come back to the same Meeting Details page to follow up on any action items or progress made after the meeting. With WebEx Meet, we bundled that experience together so users had a centralized communication hub around the meeting they just completed.

To come to a solid solution for your users, your team conducted a lot of user research. What methods did you use?

Before we began the WebEx Meet design project, we wanted to ensure we had enough data points from users to invest the time and resources to move forward with the initiative.

Back in the beginning of 2009, we started gathering feedback from users. We found that no single technique could get us all of the feedback we needed to move forward. So, we took advantage of a combination of feedback mechanisms, including focus groups, ethnographic studies, usability tests, and surveys to help us paint a more complete picture of what the key user issues were.

What types of insights did you gather from the research?

When we identified user issues from our research, we weren’t focused on getting feedback on existing WebEx products. Instead, we looked at the issues that arise when people are collaborating and identified the users’ biggest pain points.

A long time ago, I learned not to just ask users what they want. When you ask people what they want, most users will start to talk about features because those are things that are already a part of their own world. For example, some users would say to us, “I want feature X, or I want to tag.”

It’s easy to slap features, such as tagging, into a product to address specific needs, but I’ve held steady to the belief that taking a task-oriented approach to design creates systems that will map to the users’ mental models and yield the leaner, lighter interfaces.

To come up with real breakthroughs and innovations, it’s important to realize when users ask for a tactical solution, it’s often really part of a larger, overarching problem they would like solved. In our research at the beginning of the WebEx Meet project, we wanted to understand what the users were trying to tell us but not articulating effectively.

As we listened to users more, we realized they were asking for help to accomplish specific tasks better. We invested a lot of time listening to people and it made a huge difference in our design efforts. I’m thankful the organization recognized the importance of investing the time in research instead of hitting the ground running immediately. The user research got us closer to our goal in a way that a requirements document just couldn’t have.

How did the team at WebEx conduct their ethnographic research?

We have internal resources who went out and observed users in their own environments to get a better understanding of how they work, approach meetings, and complete tasks.

For a simple example, we observed how people approach setting up meetings and in what order they complete their tasks. We found that when people set up meetings, it’s important for them to put an agenda together, send out a meeting invitation, and then wait for people to respond and say whether they’re attending. After the meeting is over, it’s important for someone who is note taking to have the ability to send out the notes to attendees.

These observations may seem obvious, but there were a lot of details around what programs and applications people use and how many times they pick up the phone, versus IM or email,  to communicate with others. We also learned a lot about how people choose to communicate. For example, we observed that in some organizations, people use IM because they know they’ll get a response from busy people more reliably than with email.

All of the little discoveries eventually add up to something. By arming ourselves with this knowledge, it helped us provide tools for users to manage all of the communication and content that comes out of their day in a meaningful fashion.

You conducted a lot of informal usability testing on this project. How did you run the tests?

The gold standard of testing has always been the sessions in the usability lab. As you know, we worked with external consultants, including Perfetti Media, to run and facilitate our usability tests in the lab. Using external resources to facilitate the lab sessions was valuable because it allowed our internal resources to focus on their responsibilities and ensure the findings and recommendations were unbiased.

However, while testing in the lab is great, I also wanted to sell within the organization that we should test as early and often as possible, even before we have a big usability study in the lab. I didn’t want to be discovering things in the lab that we could have fixed much earlier in the process. By testing early, once we’re in the lab, it becomes more of a fine-tuning exercise.

In addition to our up-front research, we did a lot of testing at every possible opportunity. In order to ensure we were going in the right direction, we had to get user feedback as quickly as we could.

We relied on scribbles and quick wireframes to get speedy, bite-sized feedback to solve the many tactical design challenges we faced on a daily basis. By the time we got to the formal lab session, we could really focus on the holistic end-to-end experience with the product.

Who were your users for the quick-and-dirty tests?

It doesn’t sound right to do, but when we were getting feedback on new design concepts and terminology, we found it very effective to go to other people within the organization to test out our ideas.  These weren’t people close to the design project, but people from finance, HR, sales, and other parts of the organization, who could help us out. We typically spent 30 minutes with people to get their initial feedback on the designs.

I know there are a lot of people who feel we should always have users recruited for us, so we can address very specific user types and segments. However, on our team, we literally would have a brainstorming session, go back to our desks and mock something up quickly. We wanted to test something in 30 minutes.

When you want to test often and on the fly, it’s not always possible to be that rigorous. Our only way to test on the fly was with our internal employees. Even though it wasn’t academically the best way to do the testing, it provided a lot of value on a daily basis.

Have you and the team been surprised by any of the usability tests results?

In general, our designs and the interactions were well received beyond our expectations, so the usability testing was great validation.

One of the surprising takeaways from the usability tests was that some of our terminology choices ended up being stumbling blocks for many of our test participants. For example, terms like “VoIP” and “toll free” were not a consistent part of people’s vernacular. We also found the distinction between the terms “computer desktop” and “screen” resulted in a variety of interpretations from users.

We learned that when you work in a specific environment for long enough, it’s easy to assume that everyone uses the same jargon you do. That was a key finding for us and forced us to rethink our labels and messaging.

At WebEx, there are a lot of considerations when deciding on terminology. It’s not as simple as coming up with a term that’s universally understandable for users. We also have to consider the impact of using certain terminology as it relates to other products in our portfolio and assess before we launch whether the terminology in one product conflicts with other products.

We also must think about how the terminology affects our business positioning. For example, perhaps we don’t want to be using the terminology, “VoIP” because that’s Skype’s domain. There are all of these different considerations and it can be challenge to figure out the right nuance.

Who in your organization did you involve in the testing process?

We involve any of the stakeholders and anyone who is interested. We encourage anyone contributing to the project to attend and observe test sessions. This isn’t just the usual suspects, such as the design team and marketing. We also invite the engineering team so they can see and understand where users are struggling. We also ask the customer support, marketing, and product managers to attend the sessions.

Do you have any recommendations for working with different teams within the organization?

In addition to inviting people to observe the test sessions, we had frequent brainstorming and review sessions with the stakeholders. With this project, we introduced some new design principles and design philosophies, so it was important to us that everyone have exposure to what the product team was doing. By involving everyone in the process, it was much easier to get buy-in.

What are the next steps for WebEx Meet?

I’ve been pleased with our internal process that yielded the WebEx Meet product. I’m also pleased with the positive reception from users who have started to sign up. But we’re still very early in beta and continuing to learn a lot. We’re always looking for ways to make things better.

We see the beta launch as the beginning of the project. We’re continuing the same pace of gathering user feedback as we did when we were building the product. We’re also not overly invested in any design concept. If we find that something is very broken, we know we have to go and fix it.

As I begin work on new product offerings for WebEx, I will continue to focus on WebEx Meet. In order for WebEx to offer a meaningful product suite, all of the products have to complement each other and add meaningful value for the users. Now I’m focusing on how we can extend the design principles from WebEx Meet to other areas of the company.

Want to learn more?

This August, we will be holding the 2-day Usability Bootcamp in Boston and San Francisco. In the workshop, you’ll learn the essential techniques to improve your user research, usability testing, and design evaluation practices.