Are you new?
UserTesting is a social butterfly. It wanted to integrate with other software. And with integrations came a new user persona to write for: guest contributors.
It’s not as simple as it sounds… Here’s why getting guests to install the UserTesting app to take a mobile test was t r i c k y to say the least.
1. Greeting our guests
A guest contributor is someone invited by a client to take a test hosted on the UserTesting platform. Guests don’t have an account with UserTesting, they haven’t provided their email address. Most don’t even know what UserTesting is. /cry
The difficulties began with the mobile experience… Guest users arrived at a mobile browser page, which had a link to start their test. The problem? The test itself is in the UserTesting app.
So, these users needed to download the app, but then avoid opening it (they don’t have an account, remember) and instead return to the mobile browser page to launch the test from there.
It was so atypical that this one small problem kickstarted an entire month of iterating and testing. Almost all of which concerned words.
2. With me so far?
My first idea was to split the instructions across two steps, both on one screen. I wanted the body copy to be simple to understand, and hoped just a little bit of bold emphasis would be enough to catch the eye.
But, when I tested the content, almost nobody remembered to return to the browser page after downloading the app. Understandably.
I suspected that the common phrase “Download the app” in the CTA was a major factor. As I watched the unmoderated sessions, I saw tester after tester skim-read this page with the glassy-eyed familiarity that comes with an obvious primary button.
Why bother to read something I think I already know?
3. Time to iterate…
Spreading the steps across two screens gave me similar results.
Users continued to skim-read the descriptive headline, “Get our app”, and the all-too-common CTA, “Continue.”
After all, these kinds of instructions are ubiquitous, present all over the web. We use words like “continue” because they are so easy to read at a glance. They make the flow smoother.
That was when it occurred to me to try something strange. The principles of writing in “plain language” and reducing cognitive load are hammered into all content designers and UX writers, and for good reason.
But I needed the opposite to happen here. I needed users to slow down and think.
4. Friction writing
Against the inner voice in my head, I suggested we add friction to the experience in the form of a pop-up, to slow users down and force them to re-read the instructions before continuing.
Despite the repetition in button copy between the first screen and the pop-up (both variations of “download the app”), we finally saw some success. Users were pausing to read the instructions the second time they saw them on the intrusive modal!
Great, finally some progress. But, still I was recognising a lack of focus when users parsed the CTAs. They weren’t fully concentrating on the action.
Armed with the insight that friction was working, I set about making the wording itself more distinctive.
5. The tricky second album
We doubled down on the pop-up, and added a 5-second delay on the continuation CTA. This gave users yet more incentive to take in the instructions fully.
For the messaging, I considered balance. How could I phrase the button in a way that was plain, easy to understand, and yet didn’t cause the user to skim?
I tested three variations of the button copy, all of which were framed as a response to something: “Got it!”, “I understand”, and “Ok, download the app”.
The idea was to prompt a user to consider what they’re responding to, and then re-read the copy.
Of all the CTAs tested, “Got it!” proved the most effective. Great. Job done, right?
Not quite…
Just as success was dancing a jig before my very eyes, I had second thoughts about “Got it!” as the button copy.
What if someone downloaded the app, returned to the web browser as intended, but then re-read “Got it!” in the past tense? Was there a risk that they would select the button for a second time, mistaking it for a confirmation message that they had “got the app”?
Had I doomed the less scrutinising users to an infinite loop of app store purgatory?
Then it struck me… I had strayed a little too far from my UX writing rules. It was time to consider them again: what did this button actually do? It took users to the app store, duh! So, I rewrote the pop-up CTA to be “Go to app store” and ran a final, final test.
Finally, the majority of our test users managed to successfully download the app, then return to the web browser to launch their test.
6. That’s a bingo!
This protracted period of iterative testing showed me that what we mean by “plain” language is not as simple as merely writing things in as few characters as possible or substituting a more descriptive, longer, word for something more concise.
Sometimes we make life easier by adding words and friction to slow the reader down and help them digest.
In every day design work, we often craft the path of least resistance, relying on ubiquitous terminology (“Continue”, “Download app”, “Next”) without fully considering the user’s need for additional context.
Now, when I’m working to create bitesize content, I stop and ask myself: should I serve a bigger bite?