A personal UX Design Case Study
Amazon Edit/Remove Address Confusion
Introduction
My wife recently encountered a lot of frustration after attempting to update her Amazon addresses after we moved. She LOVES shopping on Amazon and is familiar with how to buy things, many of which she does not really need;). However, she is not very comfortable with digging into her settings. Furthermore, she is disabled and gets quickly frustrated with apps. She has a slight speech impediment, and her hands shake. Siri only sometimes understands what she says, forms often time out on her, and error messages make her very anxious. On this occasion, she got stuck trying to edit her address. Simply selecting Edit resulted in an error message telling her the edit had failed. Selecting Delete displayed a similar error message. Although Amazon uses many inline links, she never saw one in an error message. I spend a lot of time looking at designs, especially for accessibility. I quickly understood her confusion and noticed the error messages and call to action could be more clearly implemented. Also, since I enjoy the challenge of understanding software issues, I figured out what was causing the error messages.
Typical Flow
The actions to modify an existing address are very straightforward. Selecting Edit directs the user to the Edit Address form. It is essential to note the form includes a field for a phone number.
Removing an existing address gives the user a confirmation to verify the action.
Error Flow and Root Cause
Selecting Edit or Remove resulted in a critical error warning message. The Edit failed error appeared before my wife added any updated address information. Furthermore, the red text confused her and distracted her from the inline link.
I showed her the link and discovered she had created a unique corner case. Amazon autofills new addresses with the user's phone number preceded with a + sign. Somehow, she made two identical addresses that had slightly different phone numbers. One was preceded with a + sign, while the other was not. Once I resolved the problem, I wanted to find out if there was a better way to direct the Call to Action.
I also thought it was redundant that there was a Set as default option for the default Fresh address.
Time for some UX Research
What would Amazon do? My first step required access to an Amazon Style Guide for direct guidance. However, without one, I first resorted to locating examples of how Amazon implemented links. My next step was to investigate UX Writing of similar error messages.
Inline Links
Most of these used a verb to help guide the user.
Stand-alone Links
These stood out better than inline text and were a softer Call to Action than a button.
UX Writing of Error Message Text
The examples used an inline link within the error message. A small outline in the upper right corner reminds users of this Call to Action.
UX Research Next Steps - Severity and User Feedback
Initially, I would recommend viewing some app traffic analytics to look for the frequency of customers arriving at the error message and selecting the existing inline link vs. the Cancel button. Selecting Cancel and repeating a similar flow could imply that the error message is confusing. To validate this, I would suggest a customer survey to determine if the inline call to action is clear. Some questions I would want to ask:
-
What does the message mean to you?
-
Do you understand what you need to do next?
-
Could this be written more clearly?
Finally, the Remove failed error message might need to be clarified for some users. Grammarly agreed with me!
Presenting the UX Research Results
If the data supported Call to Action improvements, I would make a case for the following recommendations.
-
Improve the UX Writing of the error messages, thus clarifying the error text and what to do next.
-
Place the improved second sentence as a stand-alone link, highlighting the call to action away from the red error text.
Validating New UX Designs
I would recommend testing versions of improvements with either a simple prototype or an A/B test of the error messages. Following with a quick user survey would provide direct before and after comparisons of related data points. Since the wording of both error messages is very similar, I would start with the Edit operation because this would be the more common operation for an Amazon customer who has moved. I would also present the team with several versions to help iterate the best versions for testing. I used Figma to create four iterations to get the discussion started.
Final Thoughts
This case study represents how I see products around me through the lens of UX Research and Design. My phone is filled with images of UX Designs that span from clever and effective to what were they thinking. I hope you enjoyed reading my case study and look forward to future opportunities in UX, especially from an accessibility perspective.