Workato Redesign

A new experience for Workato users to create a recipe


Design challenge


Mar 8 - 12 2018


This is an individual design exercise I completed in 3 days. I was asked to do a heuristic evaluation of the current experience of creating a "recipe" on Workato and redesign it. I found the current user flow had some major problems, which are the steep learning curve and requiring great mental efforts to complete tasks, since the concept of "recipe" is new to most users. The new user flow I came up with helped users have a clear picture in their mind about how the recipe works before asking them to dive into details of settings. I also fixed some usability issues.

My design solution received very positive feedback from the Workato team:


Paper&pen, Sketch, Photoshop, Marvel


Workato Recipe

Workato is a cloud integration platform that ties web applications together into complete business processes. It provides users with the ability to create recipes (programs) that links apps through their published API’s. Once connected, data can be moved between applications. Each recipe can be created using a business logic that expresses how data should be utilized and modified as it moves from one app to another.

User group

The target users of Workato are app admins. Their characteristics are:

- need to maintain multiple enterprise applications every day

- know well about these enterprise applications (how to use, the data structure inside, etc)

- good at solving problems but not tech-savvy

Provisional persona

Based on some secondary research, I created a provisional persona to help myself keep users in mind when doing design.

Create a recipe

The current way of creating a recipe can be divided into 4 major steps. Select and connect trigger app, setup trigger, select and connect action app and setup action. Normally, there will be a huge dropoff when asking people to connect to the applications.

A walkthrough video of the current experience:


To find problems of current design more easily, I decided to focus on the experience of creating one specific recipe in this design exercise, which is using Dropbox as the trigger and Slack as the action: when there is a new file uploaded to Dropbox, there should be a message in the Slack to notify the app admin.

Current flow

The current flow of creating that recipe is like this:

This linear process works for expert users who know the concept of recipe well and are very clear about what they want to achieve. However, it is not friendly to users who are unfamiliar with the recipe creation process or are just trying out this feature. I think the main problems with the current flow are:

Steep learning curve

Current flow requires users to be very familiar with all the concepts of trigger, action and how recipe works. Or it is easy for them to get lost at one step and don't know what they are doing.

Requiring great mental efforts

To create a recipe, users need to have a clear diagram in their mind about how it should work. There is no visulization of that diagram to help users consolidate it. Therefore, on each step, users need to think very hard about their goal in order to do the right actions.

Difficult to be dynamic

With this linear flow, it is hard to know what users are trying to do until the late stage after users select the action, which makes there less room for the application to be dynamic.

Usability issues

I also identified some usability problems on each step.

Select trigger app

Inefficient to select an app

With such a long list of apps, users literally need to type to find the app they want to add, which is not a simple interaction. There is no shortcut for them to quickly select an app, like an easy access to a connected app. Users will only use a limited number of apps and it is not frequent for them to use new apps, which means most apps inside this list will stay unused and only reduce efficiency.

Need to scroll to get a full view of the dropdown list

When user clicks a dropdown on the lower part of the screen, the list will get clipped and users need to move the cursor out of the dropdown to scroll the page to get a full view then move back to make a selection, which is a bad experience. The page should be automatically scrolled to the end position of the drop-down list when user clicks on it.

Connect to app after selecting trigger

If users fail to connect to their application, the selected trigger information will become useless. So it makes more sense to ask users to connect to the app before letting them select trigger.

Redundant "connect"

People are still required to click on the "connect" button, even though they have connected to the selected app before. It should not be common for users to have multiple accounts connected to one application. So this will be a redundant step for most users.

Setup trigger

Occasional "Required"

On the prior step, there is no "required" beside the label because every field is required. This inconsistency will lead to some confusion. Also, personally I would prefer to use an asterisk (*) instead of the word "required" to simplify the interface, considering the asterisk has become common enough and the target users who have been using many apps should realize what it means.

Unintuitive way to set direct URL

Current way to set direct URL is confusing. It makes more sense to ask users whether to obtain a URL first. If they choose yes, then let them choose whether to generate a URL or use custom value.

Select action app

The problems are same with the "Select trigger app" step.

Setup action

Hard to map the fields to results

People who know well about how to use an app are not necessarily familiar with the data field names fetched from its API. Most of them will only use the interfaces of the app. So it's hard for them to picture how the fields are related to the result in the action app interface.

Unhelpful "App data"

For some fields, what users need to input is irrelevant to the data in "App data". Showing this panel will lead to some confusion.

"Required" fields inside an "optional" field

It is confusing to show the required fields inside an optional field. Those fields should only be shown after users select the optional field.

Unhelpful subtext

The subtext below the prompt data doesn't help users to understand its meaning.

Unintuitive way to add/remove fields

The current way of adding or removing fields is not intuitive.

Global issues

Unhelpful progress bar

It's hard for users to estimate remaining work with the current progress bar.

Too much padding in the header

Right now there are too much white space in the fixed header which takes too much vertical real estates.


User flow

The new user flow I proposed asks users to select and connect apps for trigger and action first. These two connections are the most essential steps to create a recipe and all the rest actions are based on them.

After users connect to selected apps, they need to select trigger and action. I intended to help them build a clear picture in their mind about how the recipe will work before diving into details. This will help the setup process be more dynamic as well since it allows the fields in the trigger to be different depending on the actions.

When setting up trigger and action, users would be able to preview a real-time result of the recipe, like what the message sent to the Slack channel will look like after user's actions. This helps users consolidate the recipe picture in their mind and be more confident when setting up the field they are not sure what that's about.

Hi-fi interfaces

#1 Select apps for trigger and action

Users first need to select the apps for trigger and action. I used an arrow between the two panels to help users understand the relation. Putting the similar actions on one step can also help reduce users's cognitive workload. I provided a shortcut for them to connect to an app that has been connected before with a simple click.

Users can also easily change account or add a new connection if they want to.

A walkthrough:

#2 Select events for trigger and action

Then users need to select event respectively for trigger an action. This help users establish a full picture of the recipe they are building.

A walkthrough:

#3 Setup trigger

On the left part, there will be a diagram reflecting user's real-time actions, helping them know it clearly that how they are progress towards their goal. I also redesigned the experience of setting direct URL. Users first need to check the checkbox, then select whether to generate a URL or use a custom value.

A walkthrough:

#4 Setup action

One big problem of current experience of setting up the action is that it is hard for users to picture how the fields are related to the final result in Slack. In my redesign, users would be able to preview how the message would look like after their settings.

I used a pop-up modal for users to customize optional fields instead of the drop-down list. I think using a modal here is a more intuitive way to make customization.

A walkthrough:

Interactive prototype

Here is the interactive prototype I made with Marvel:


I'm pretty sure there should be some technical constraints that make some parts of my design not feasible, like the feature of previewing Slack message real time can be difficult to implement. But since I will never get enough inputs in that aspect working outside of the team, I decided not to guess about the constraints, but only focused on polishing the experience based on my empathy with users.

Another potential problem is about the scalability of my design. I only focused on creating one specific recipe in this design exercise. Whether my solution can be applied to all the other recipes will need more investigation.

For future steps, I think conducting several sessions of user testing would be super valuable. Then incorporate the findings as well as the feedback from the engineer side to iterate the design.

Thanks for reading!