What might be the implications of a wrongly understood button?
Context
LinkedIn surprised me recently. I tried to create a post with a photo. Having clicked the camera icon, a dialog popped up prompting me to select a file from my local file system. I did choose one, waited till it gets uploaded and then saw the photo on the next screen with the buttons “Back” and “Done” enclosed. As I still wanted to add some text to my post, I got confused. Won’t click the “done” button place the post as in “I’m done with creating of the post”? Am I creating the right type of post – is this some kind of photo-only post without any accompanying text? I have canceled the action and went back to make sure the right icon was clicked initially. No other icon suggested otherwise, so I repeated the process including the upload of the photo. This time I did click the “Done” button and full of excitement awaited what happens. To my relief, the process advanced to the next step where I could add my text. All good.
The experience made me think about the implications of a wrongly understood button.
Will clicking the “Done” button place the post or take me to the next step of post creation?
The Meaning of “Done”
A closer look made me convinced that LinkedIn definitely had a good intention here. The process of creating a post consists of four tasks:
1. Click create image post
2. Select image to share … Buttons: Back | Done
3. Edit image (add alt text/tags) … Buttons: Back | Done
4. Create the post (add text) … Buttons: Post
The meaning of “done” button is clear here. Every dialog screen has a title that informs the user what task he is at, and LinkedIn asks the user whether the task has been DONE.
So far, the concept nicely follows the usability principle, i.e.: at every point, show the user where he came from, where he’s now, and what happens next if action is taken.
The Problem
The problem is that the select-image screen (step 2) is hardly noticed by the user because it gets covered immediately by the file selection dialog which pops up automatically right after the user clicks the “create post” icon.
It all simply happens too fast. The user won’t get the chance to learn that he is in the step-by-step mode. Instead, the next thing he sees is the photo he has selected. At that point, the screen looks like a finished post which might suggest that clicking “done” button will complete the process of creating it.
Some would protest and say that the title of the screen (Edit your photo) above the selected image suggests the task and hence makes clear what the “done” button will perform. I think that the image takes over the attention, and leaves the title unnoticed.
This screen is hardly noticed as the select-file dialog pops up immediately over it.
Assumption:
Current behavior prevents the user from learning that what he initiated is a step-by-step journey. The “Edit your photo” screen that he is presented with immediately after file selection, suggests the post is ready to be placed. The label “done” then corresponds more to “place the post” instead of “go to the next step”. This makes the user either interrupt the task.
The Implications
If the assumption is right, the scenario yields the following implications:
1. User experience
Current behavior can cause confusion on the users’ side which can result in dissatisfaction (pain-point). Part of the users will probably search for help on the internet, another part would reach out to other users either for help or to complain, and another part (though very tiny) could simply leave the platform.
2. User engagement
Current behavior may result in users decreased engagement. Engaged users are generally more profitable, provided that their activities are tied to valuable outcomes such as purchases, sign ups, subscriptions, or clicks.
3. Server-related costs
Uploading an image drains servers’ computing and storage resources. At a platform like LinkedIn with millions of users, this can end up with quite some costs.
Experiment
Experiment question:
Do users interrupt or re-initiate the create-post task?
Limited only to the create-post task initiated by clicking the photo-post icon.
Gathering Data
The question is, what do we have to measure in order to answer the experiment question? Below are some suggestions:
1. Tasks interrupted
What: Rate of completed/interrupted tasks.
How: Bind a log action to the “post”, and “discard/cancel” click-events.
Who: All LinkedIn users
How long: Either 24 hours which I think should be enough for gathering valuable data OR until certain logs amount is reached. A data-scientist might suggest a sample number that gives us considerable certainty.
Result: Rate that indicates how many tasks were successfully completed and how many of them were interrupted.
Caveats: Users might have canceled the task for a whole lot of other reasons!
2. Image re-uploads
What: Amount of re-uploads of the same file within one session.
How: Bind a log action to the upload-image event. Log session-id, date-time, file-name, file-size.
Who: All LinkedIn Users
How long: Either 24 hours which I think should be enough for gathering valuable data OR until certain logs amount is reached. A data-scientist might suggest a sample number that gives us considerable certainty.
Result: Data that indicates how many times users tried to upload the same image during one session.
Caveats: Users might decide to upload either another image or a modified image. That’s why we have to log and compare the file-name and file-size values.
3. Users’ opinions
What: User experience
How: A survey. Screen with a feedback form that pops up upon the user cancels the task.
Who: LinkedIn users. a sample that represents all users with high certainty.
Result: Responses that directly answer why the user interrupted the task.
4. Data from the customer service center
What: Inquiries addressed to the customer service center in regard to placing a photo post.
To get valuable results, I’d suggest combining all the above-mentioned methods. As a result, we get a pool of data representing users that interrupted the task related to the UI behavior.
Is the Change Worth it?
The question is, how significant the experiment results have to be so that a change is necessary? Or put differently, what will indicate that we need to perform a change?
1. The amount of (relevant) task interruptions can be used to calculate the probability of decreased engagement and user dissatisfaction.
2. The number of image re-uploads can be used to calculate the unnecessary server-related costs, i.e. how much can we save if we fix the problem.
One of the questions that might interest the managers is,
Are the costs of performing the change lower or higher than the costs resulting from leaving the problem unresolved?
The answer to the question above is closely related to company values and objectives. For examply, a company that strives to serve the users the best it can, will definitely try to resolve the issue even if the costs would be considerably high.
Solutions
The focus is on making sure that the user perceives the task as a step-by-step journey and thus understands where he came from, where he is, and what comes next.
1. Replace “done” with “next”
The word “next” clearly indicates that the task is not yet done and that the user may expect another sub-task, e.g. adding in the description text. Furthermore, “next” logically complements the “back” button. However, this solution should be checked for consistency across the LinkedIn platform. It might require other buttons to change as well.
2. Skip the “Edit your photo” Screen
“Edit your photo“ sub-task prompts the user to add alt text and tag other LinkedIn users. It is the screen where the confusion around the “done” button arises. I suggest skipping the screen and go straight to the final “Create a post” screen, still leaving the user with the option to edit the alt and tags from there. See below.
Testing the Solutions
The questions are:
1. which solution solves the problem?
2. which solution performs better?
Given that replacing a button label or skipping a screen are rather cosmetic changes, hence the costs are minimal, I’d suggest setting up an A/B test and check which solution performs better. Alternatively, before carrying out the A/B test, we could do a simple usability test with several users (min 6) just to sort of pretest both solutions.
Furthermore, I’d strongly suggest checking the solutions for consistency across the whole platform. As already mentioned, changing the button label from “done” to “next” might make this particular task behavior different from the others. Consistency is key.
Final Thoughts and Learnings
I am genuinely curious if other LinkedIn users experienced the same confusion as I have. It would be cool if LinkedIn verified.
I know from experience, that it’s very hard to predict the consequences of every behavior. That’s where the usability tests carried out during the designing phase are so important.
But sometimes even usability tests carried out before-hand don’t reveal issues. That’s why it’s good to implement a log/statistics mechanism to reveal problems along the way. In this case, I would focus on protecting the server’s resources and kept logging cases of repeatedly uploaded files of the same name or the same size within a session. Actually, this can apply to the whole platform. Increased logs would indicate the necessity to investigate the causes.
One of the goals of this article was to illustrate the decision-making process. The sequence is as follows: Describe the problem (pain-point) > understand its possible causes > form a hypothesis > validate the hypothesis with an experiment > interpret the data > ideate the solutions > check with the company values and objectives > test solutions > select the winner solution > apply the change > celebrate :-).
I have enjoyed writing this article. Thinking about such details like a button here and there, for example, might seem crazy, but I simply enjoy contemplating the implications and methods that lead to the remedy.
Little Suggestion to LinkedIn
A little fix. The title of the upload-file screen should read “Upload your photo” which, IMO, describes the sub-task better and doesn’t clash with the next sub-task.