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.
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.
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.
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
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.
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.
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.
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.