Design Teardown: LiveShare—designing for many

One of the most valuable outcomes of a challenging design project—besides the final product, of course—is what you learn about user experience design in general. By abstracting the specific solutions you come up with, you can arrive at general principles that help you get more done faster in the future.

And since we learned a ton from building LiveShare, we thought we’d share a few of its most valuable lessons. Before we dig in, it’ll be handy to know what LiveShare is, so here’s a quick video.

Got it? Good. Now let’s get down to the nitty-gritty.

The design challenge: building a web-based presentation and collaboration tool

InVision’s base sharing functionality—sending out a URL or inviting a collaborator to get input on a project—covers one of the most common collaboration scenarios: that of the individual clicking through a prototype, adding comments based on their personal expertise and perspective.

But what about another incredibly common collaboration scenario, the design meeting?

Design meetings get teams together, either in person or via videoconferencing software, to share their thoughts in real time. They’re great because they:

• Get designers from various disciplines—from UI to visual design, mobile to desktop—together to share their unique perspectives
• Make it easy to gather input from related disciplines, like copywriting, research, SEO, etc.
• Save time by getting feedback from many people at once
• Spark insightful discussions that might not happen via email or comments

But how do you design a web-based experience that reproduces the dynamic collaboration of a design meeting?

In other words, how do you design for many, as opposed to one?

Designing for one

Building experiences for single users or multiple asynchronous users

We user experience designers typically design interfaces for a single person to interact with—even if it’s a collaborative product like InVision. We try to anticipate how an individual will interact with an interface and how the interface should respond. That means it’s usually a 1-to-1 relationship between a user and the interface.

Let’s say we want to create a mobile camera app. To do that, we have to think about how the user will:

• Frame the subject in the viewfinder
• Interact with customization tools like zoom, exposure, flash, etc.
• Take the photo
• Interact with the photo once it’s been taken

Plus how the camera will provide feedback about what’s happening, which might include visual, auditory, and even haptic elements.

But we don’t have to think about how anyone else, even the people in the photo, will interact with the interface—because they probably won’t. And even if a subject gets behind the camera after the shot’s been taken, their needs don’t differ significantly from the shooter’s.

Designing for many

Building experiences for multiple simultaneous users

But when you’re working on a feature where multiple users can determine how the interface responds, these questions become a little more complex. Joe’s experience may get completely hijacked by Fatma. Do we want Fatma to have that kind of power?

With LiveShare, the biggest challenge was finding that balance. We wanted the presenter to feel in control and set the pace of the presentation—but we also wanted the rest of the team to be engaged enough to feel like they’re in a design meeting and not just watching a 1-sided presentation.

To get us started, we thought about the types of control people would have in a physical meeting room during a design presentation.

What people expect from design meetings

When you’re designing a digital experience to match a real-life one, it pays to think through the real-life experience so you know what your users will expect.

Here’s what people expect from design meetings, along with how LiveShare meets those expectations.

One person runs the show

In a physical design meeting, one person, usually the designer, runs the show. They control both the pacing of the presentation and navigation through the deck.

We decided to replicate this because it:

1. Ensures that no one can jump ahead or access something they weren’t meant to see (yet … or at all)
2. Builds a level of trust between the presenter and the product

The latter point is key because, whether you’re conscious of it or not, you use products because you trust them. Just think of all those people who leave social networks because they “don’t want to put my life out there on the web for all to see.” That’s a trust issue.

Everybody else can speak up

During an in-person meeting, you don’t have to wait for the presenter to let you speak or sketch—you just do it. So we didn’t want that limitation in LiveShare either. Problem was, in a real meeting you can physically see who wants to speak up.

We solved this by assigning a color to each person in the meeting, so everyone can see who’s sketching based on their personal color.

We also added a whiteboard mode that lets people dive into ideas that might diverge a bit from the design being discussed. Of course, this raised a question of power: should anyone be able to interrupt the meeting so they can start sketching?

We went back and forth on this a few times, but in the end decided it didn’t feel right to hold anyone back from being heard. Of course, in person, you can always tell who’s interrupting, so LiveShare lets everyone know who’s entered whiteboard mode. If someone switches over to whiteboard mode to dive into something deeper, everyone sees a notification letting them know who.

Everyone has a choice: watch or participate

In a design meeting, you can choose to kick back and watch, or dive right in and make sure you’re heard. We reproduce this on a digital level by letting participants choose whether or not to make their mouse pointer visible.

Of course, that raised its own issue. If we set the pointers to default to invisible, people might not know they could make theirs visible, or simply assume theirs was visible to others. And if we set them to visible, presentations got very visually busy, distracting from the design we were discussing.

In the end, we decided to make the pointers invisible on load, but educate users about the option via some initial onboarding messages.

Some things to consider when you’re designing for many

Every design challenge represents a learning opportunity that can inform future product or feature builds. Here’s what we learned:

• If your product or feature has a real-world analog, think through the expectations that analog creates for your digital version
• Consider the balance of power between users—and remember that you sometimes want one user to have more control than others
• The abilities you give users within a multi-user experience should reflect that balance of power
• A multi-user experience is usually collaborative in nature, so think about ways that users who aren’t in control can participate—and opt out of participation
• Think about how you can build users’ trust in a product or feature. In a situation where there’s a complex balance of power, trust can be tenuous.