Three Design Recommendations for IFTTT

A UX project for a product I enjoy — Part 2: Problem Solving

Kenny Yu
Design Case Study of IFTTT

--

This post is a continuation of Observing and Interviewing People Using IF.

The design process we are following:

The Problem:

People get frustrated when they cannot find/create useful recipes. (See Part 1: Problem Finding for the user research I’ve done and how I arrived this.)

Breaking Down the Problem:

  1. Steps required to add recipes = too many
  2. Layout for reading/understanding recipes = can be better
  3. (Published) recipes are made of apps people don’t use
  4. In the recipe creating process, people are being shown apps they don’t use

3 Major Needs:

  1. People need faster access to discovering recipes
  2. People need an easier way to read/understand published recipes
  3. People need to see apps they use (when browsing and creating)

Persona

Asher: College student. A new user who is not familiar with the concept of IF (This persona is based on the people I’ve observed and interviewed.)

Attributes: Has never used any automation apps. Has no programming experience. Uses Facebook, Instagram, and Tumblr. Does not use Twitter. Does not own any smart home appliances.

Frustration: Being on so many social media is sucking up time!

Motivation: Wants to get things done faster.

Milan: A returning IF user (I wrote this persona in particular to remind myself of the needs of returning users. I used information from app store reviews.)

Attributes: Smart. Understands the concept of automation.

Frustration: When recipes do not run properly. When recipes get delayed. When recipes do not run at all. When they can’t find more useful recipes.

Motivation: Wants to automate more parts of their lives.

Design Objectives:

  1. Faster access to browsing/creating relevant recipes
  2. Better recipe browsing/creating experience

Metrics to Measure:

  1. Number of recipes added within certain minutes (to be defined) after first log in (for new users)
  2. Trend line of new recipes added compared to trend line of recipes running (for returning users)

Recommendation 1

Reduce friction for discovering/creating recipes

Current Design

3 clicks to either browse or create recipes.

You need at least 3 clicks to get to either browse or create recipes (not counting collection)!

  1. Does a user want to go through “My recipes” every time he/she wants to add new recipes? Probably not.
  2. All three action icons seem to imply similar meanings…which could be confusing.

Something to be simplified!

Suggested Changes

Let people swipe to switch between the “Timeline” and “My Recipes” while using a single direct entry point to browsing recipes. This way, users will see switch control and setting only when they want to.

Let people use 2 clicks to either browse or create recipes. This will clear away 1 click of clutter.

Recommendation 2

Improve the experience of browsing recipes

Current Design

As mentioned in part 1, users complained it’s hard to look at this screen. Reasons?

  1. It requires quite a bit of energy and focus to consume so much complicated information at once (recipes are not easy!)
  2. The font size is too small here!

Suggested Changes

Increase list height and bring back the big icons and font size. This will reduce the mental energy required to read through and grasp the meaning of each recipe. This also better follows the general IFTTT branding guideline of using big icons and font size.

Tradeoff: Increasing the list height means less recipes will be shown at one glance. However, scrolling is very easy on mobile, so it shouldn’t be a big problem.

Recommendation 3

Get information on what apps people use.

The biggest reason people can’t find/create useful recipes is that they are not seeing apps they use. Therefore, we can help users get to/create relevant recipes if we know what apps/services they are already using.

Potential Solution: Embed a quick “survey” as part of the onboarding experience. This should be coupled with reducing the number of tutorial screens (there are 5 and they are not effective as mentioned in part 1).

Potential Solution

Let users input what apps they are using.

IF can use data collected from here to personalize recipe/app listings, which will enable users to discover/create relevant recipes faster.

Tradeoffs:

  1. This complicates the onboarding experience; users may get annoyed/feel intruded. For initial testing, we may put this “survey” under setting for users to complete in a voluntary manner.
  2. People download/acquire new apps constantly, how can we update this information? How can we leverage first input without compromising the accuracy of future suggestions?
  3. The system could be hard to implement.

Another fix:

Rule out android-specific recipes for iOS users and vice versa for Android users. This alone can already reduce the level of clutter in recipe browsing experience.

Yet More Problems

The above recommendations address mainly the access to and relevance of recipes. There are two more important factors:

  1. Quality of published recipes
  2. Possibility of recipes people can create.

Due to constrained knowledge on how the system is implemented and access to existing users, I am not addressing these two issues in this project.

But two quick thoughts:

  1. The voting system seems to be working okay in terms of controlling quality of recipes served to users.
  2. Possibility of what people can create should grow as the platform grows and becomes more open/easy to developers ☺

Coming soon…

Prototype

**I do not work for IFTTT, this is a side project for a product I love. I am a student at UC Berkeley. I freelance UX projects for interesting people and products.

--

--