There are a zillion different screen sharing programs out there these days, and really, the functionality isn’t that different across the board. Host a meeting, send a link to your participants or clients, record if necessary. Rinse and repeat.
What I’m trying to say is that I’m sure this feature I’m about to talk up isn’t specific to our choice in application. In fact, I know it isn’t. InVision, Google Hangouts, even Slack will allow you to give someone else control over your screen. But I’m getting ahead of myself.
We’ve written recently about our struggle with WebEx and their unwelcome welcome page. When our subscription expired late last year, we made the switch to Zoom. Zoom has some challenges in itself (although if you know of any tool that makes scheduling meetings across time zones flawless, let me know. I’m all ears). In general, though, we’ve been much happier.
Our Problem
As user experience design consultants, we spend a lot of our time running remote usability and validation tests. We need to see our user’s screen. In the past, we tended to gravitate towards one of two ways to accomplish what we needed.
Option 1:
- Keep control of your screen and walk users through the necessary pages.
- Good for validating short content page.
- Not so good for validating interactions.
Option 2:
- Send link to meeting.
- Send link to the thing you have to open during the meeting.
- Cross your fingers and hope that the user has both managed to download the screenshare software correctly and made it into the meeting okay.
- Make sure they have the right link (and can open it).
- Walk the user through how to share their screen.
- Start the test.
Neither of these processes were particularly ideal. With Option 1, you’re not really getting a good idea of how your user would realistically interact with your design. But with Option 2, you’re assuming a lot of technical know-how on the part of the user, and putting a lot of the cognitive load onto them. As UX people, we should know better.
A Solution
So we’ve started giving users control over our screens during calls. This means that we’re in charge of setting up the screen share, pulling up the right page, and giving control over to our user. And it means that we can take back control at any time. After running this several times in two different scenarios, with two very different clients, we’ve found that in the right context, this hits the sweet spot between Option 1 and Option 2.
In our experience, this works particularly well for InVision prototypes that might have a gap in the middle, like if you’re moving from the end of purchasing a product to a confirmation email. You can bridge this gap in the prototype by swooping in and hitting the right arrow key to move your user forward without having to switch controls back and forth.
It also works best for users that aren’t familiar with screen sharing, and need just that little bit of hand-holding to get them started. Like I said, it’s the sweet spot.
Learn How: Request or Give Remote Control in Zoom
Of course, this method isn’t without its pitfalls. After all, you’re still requiring users to download a new, potentially unfamiliar program. First, you can’t touch your mouse during the test without messing up your user, so having a separate notetaker is usually required. As is having said notetaker signed in to the meeting (or Slack) in order to field any spur-of-the-moment requests from stakeholders or other remote testers who may be on the line. And second, a difference in browser or operating system might confuse some users. Think, if you’re used to Windows / Internet Explorer, the default hidden scrollbar in macOS might mean that you’re not aware that you can scroll further down the page.
You have questions. I (might) have answers.
But Kelly, what about lag?
Great point, dear reader. Personally, I’ve never run into a situation where lag disrupted a test to the point of it being unusable. But lag is inevitably something you’re going to have to deal with no matter the meeting software. It’s something you can’t control. Our best advice is to always assume that there’s some latency. Keep that in mind during the test and move a little bit slower, regardless of whether you’re having a user control your screen or not.
Is this the right method for every user test?
Maybe not. I’ll admit that this type of testing is better in some scenarios than others. In doing enterprise work, we often test with business people with a good degree of familiarity with screen sharing programs. They might even have their own preferred program. In that case, it might be beneficial to use their software, send them whatever link you’re working off of, and run the test from there. But in the case of someone unfamiliar with user testing or who doesn’t spend her entire day on the computer… granting remote control is an option. And a good one, we’d argue.