You’re a strong, beautiful user and you deserve more
and other comforting things I told strangers in Yerba Buena park.
You’re sitting cross-legged on a blanket reading John Grisham’s The Whistler when I approach you. I’m holding three cell phones and you just made eye contact, unfortunately. You’re stuck with me for 10–15 minutes.
It’s guerrilla user-testing time, baby.
I start right into conditional logic and automation, and your eyes glaze over.
We’re talkin’ IFTTT, one of my favorite products in the world. You check your watch but it’s only been 3 minutes.
Here’s why you should care about IFTTT:
The products you love are natural introverts. Apple doesn’t want your Android photos. Dropbox won’t sync to Google Drive. You aren’t in control, MailChimp is.
IFTTT (if this, then that) is an unbiased mediator that allows one product to extend the power and range of another. If a specified event happens in one product, then it triggers a defined reaction in a second product. Conditional logic.
With IFTTT, Alexa knows where you left your iPhone. Evernote archives a copy of every tweet you like. HUE lights in your townhouse (townhome) will turn purple every time it rains.
IFTTT helps you design the systems of your life.
There’s a dedicated base of early adopters, but you aren’t one of them, and that won’t do. We’ll tear this thing down. You’re early majority, right?
The way a user moves through the app tells a story that reflects her understanding of IFTTT’s value. The UX has a responsibility to signify a successful path — to communicate clearly and deliberately.
I want to analyze the IFTTT user experience by collecting these stories. Then we’ll improve them.
IFTTT is courting new users from an early majority in order to grow.
Impressing this group requires an irresistible magic moment.
That moment has to come fast—attention spans are low. Technical products (like IFTTT) prioritize TTV for wider appeal.
IFTTTs newly relaunched app is their attempt at such a mass-market product. It’s a vehicle for a magic moment.
The prompt—IFTTT 101
Every morning before leaving for work, you check the weather to see if you need a raincoat for your walk to work.
Yesterday, you forgot to check and got soaked.
Today you didn’t have time to check, so you wore the raincoat just in case. Of course, you didn’t need it. Life is chaos.
A coworker recommended an app called IFTTT — he thinks it can be set up to automatically send you a warning text, triggered by a rain forecast. You download the app and open it, excited to solve your problem. What do you do first?
I’m asking the user to create an Applet from scratch.
If she is successful, she will understand the mental model of IFTTT (and conditional automation). I have a hunch that IFTTT bounces users because they never connect with this core functionality.
I only tested users new to IFTTT’s mobile app. See assumption #1.
The mass of people I spoke with fit in two broad user stories, and I’m comfortable designing for two personas that represent them, without assuming any other shared characteristics.
The first has used the web version of IFTTT within 5 years, but doesn’t have active Applets. She is a likely chasm jumper if we can deliver a compelling experience in the app.
The second has no idea what she is testing. She could be the backside of the early majority.
COLLECTED USER STORIES.
Chapter 1: Don’t tour me, bro
Our users skimmed or skipped the tour— it’s a dead pattern. Three dots at the bottom of a screen signifies a thumb race to the login screen.
Unfortunately, the tour doubles as the app’s main documentation. You can’t revisit once you’re in the app.
Jakob Nielsen advocates against a documentation dump in his 10 Usability Heuristics for User Interface Design:
“Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another.”
Chapter 2: Garbage accounts
IFTTT requires an account to enter the app. Everyone I tested entered a fake email address.
The user doesn’t know what IFTTT is yet. They don’t want an account.
IFTTT hasn’t earned the user’s trust yet. Too soon, guys.
Chapter 3: Is an Applet a… small app?
Once logged in, the meat of the product lives on three tabbed screens.
TAB 1: Discover. This view has scrolling banner ads for collections of Applets, and Recommended (pre-made) Applets populated below.
TAB 2: It's TAB 1, but with a search bar. Cool. Cool cool cool.
TAB 3: My Applets. This screen is blank, because you’re a new user. You don’t have Applets. There's a link back to Discover, in case two tabs of Recommended Applets didn't get the point across.
Still don’t know what an Applet is? IFTTT told you in the tour. You read the tour, didn’t you?
Naturally our users interacted with Recommended Applets first. 2/3 of the interface is dedicated to them. Some users successfully set one up. Neat, is the test over?
No magic moment here, folks.
I’m going to categorize Recommended Applets as accelerators.
Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users.
Experienced users might love exploring Recommended Applets, but are they the best way to introduce new users to conditional automation?
Our test suggests no.
I asked each user to explain IFTTT to me at the moment they got stuck. The results weren’t good.
It does lots of stuff with other stuff.
It has to do with calendars and emails, like getting alerts. Where is the Calendar? I don’t see it.
Hidden behind a + icon in the top right, is this:
This simple screen guides the user through the mental model of IFTTT. When you’re done, you’ve created your first Applet from scratch.
When our users got frustrated with my task and gave up, I guided them here.
Almost instantly, it all clicked for them.
Suddenly, users could describe what IFTTT does. They got it.
Two of them even downloaded IFTTT on their own phones after the test. Now we’re talkin’ IFTTT all over the place.
WE CAN FIX THIS.
#1 — Explain the Conceptual Model.
It’s best for a product to be so intuitive that documentation isn’t needed. IFTTT can’t be that product. So lets make our documentation count- appropriately timed & brief.
The best way to learn something new is by doing. Ask the user to build an Applet immediately.
The framework already exists in the screens above. Let’s put the Applet Maker front and center. Give it one of the tab spaces.
Hypothesis: Asking our new user to complete a guided Applet Maker task will help them internalize the mental model of the app.
We will know this is true if she can describe what IFTTT is and why it’s useful—more eloquently than the control group.
(the control group = the first 5 users tested. Try to keep up, please)
#2 — No Tour, No Login.
IFTTT is never going to be a simple app. Our only alternative is to make simple people feel smarter. The first time a user creates an Applet from scratch is magic. She’s basically a genius.
Let’s get her there fast.
No thumb-race tour. No login. We’ll only ask for 30 seconds of attention. If we can’t hook her in 30 seconds, her account info isn’t worth storing.
I know, Snapchat makes users log in first—but Snapchat has adults lining up for a robot selling knockoff Persols.
After the magic moment, IFTTT can prompt the user to create an account— to save that thing they just created. It’s not a trick, it’s genuine engagement. Why does IFTTT want a bunch of junk accounts anyways? Most of the users I tested never completed anything worth tracking.
Hypothesis: Reorganizing the app (as below) will guide users to a magic moment, and fast.
- Abolish the tour.
- Login/account creation is prompted after a user creates something.
- Landing screen is the main conceptual model page. IF + THEN +.
I will know this is true if users continue after testing to create an account to save their work.
Stay tuned for Part 2 of my IFTTT case study.
I’ll build a prototype with my proposed changes, test it with more users, and tear my own work apart.