Over the summer of 2022, I worked as a UX Design Intern for Amazon's F3 VIDA team, which works on design and research for Amazon Grocery (Amazon Fresh and Whole Foods). Over one-third of all online grocery users in the United States rely on Amazon Grocery for their grocery delivery needs, as well as a substantial proportion of users in countries outside of the US.
I worked with a Senior UX Designer (my mentor), two Product Managers, and a team of Software Development Engineers to improve the shipping options experience, which is where users select which delivery or pickup option they would like to use for their online grocery orders with Fresh and Whole Foods.
This project is currently under NDA, so specific details and images have been omitted. If you would like to know more about this project, please send me an email!
Amazon's F3 VIDA team wants to introduce a new feature in the shipping options stage of the Amazon Grocery experience. Additionally, the team wants to increase customer retention rate at the shipping options stage, as research has shown that customers have various reasons for dropoff.
To better understand the problem, I began to research and audit existing resources. I analyzed the current live experience and identified usability issues, audited analogous experiences with direct and indirect competitors and noted differences between those and Amazon's experience, and I did a deep dive into the existing internal research that had been done in the problem space.
I began by exploring the current live experience and identifying major usability issues, inconsistencies, and logical design fallacies based on what I already knew about the problem space. This allowed me to make note of how current infrastructure was implemented, ask questions about logic and design system components, and frame how potential solutions may fit into the current solution with enough time to implement it for testing.
I conducted an analogous experience audit of Amazon Grocery's direct competitors, Walmart, Target, and Instacart, to discover what features and functionalities Amazon Grocery's shipping options lacked and to better understand how these differences might contribute to the customer dropoff that Amazon Grocery experienced.
I soon realized that platforms that weren't necessarily competitors with Amazon Grocery, such as platforms that utilized scheduling systems like Zocdoc (for scheduling doctor's appointments) and Resy (for booking restaurant reservations) would also be useful to my research. I conducted an audit of these platforms as well in order to understand common mental models that are used in the scheduling space.
I also searched through a massive research insights database for research insights pertaining to shipping options, reading through lots of documents and research studies to help me make better informed decisions as I better understand the problem space and user needs. This allowed me to validate all of the desk research I had done and make connections between what I found in my desk research and what users felt.
After conducting my initial research, I was able to synthesize the data I uncovered into an affinity map, which I then organized into key insights and findings.
The research and key insights I found allowed me to identify target users. I identified three main groups of target users: User A, User B, and User C, who each wanted to optimize for different things when choosing a delivery or pickup option on the shipping options page.
Wants to optimize for A
Wants to optimize for B
Wants to optimize for C
To better understand the pain points of each of the users and opportunity areas for design solutions, I mapped out the user flow of the current live experience.
I compared this to the mental models that each type of user refers to while in the shipping options experience, which I also mapped out with user flows.
After comparing each user's mental model, I found that the greatest opportunity lied in optimizing for User C's needs, as User A and User B's needs were already addressed in the existing experience.
Each week, I met with the Product Managers working on the project to clarify existing research and gain more insights on the problem space, coordinate with other teams that may be working on things that are connected to the shipping options space, get feedback on designs, and validate and defend my design decisions. I was able to learn a lot about how to convey my thoughts and decisions to others, especially in more high-stakes situations.
For each meeting, I was tasked with
writing and sending out an agenda before the meeting and writing a recap of our meeting afterwards,
leading the meeting based on my own prioritization of discussion topics, and
explaining my designs and why I chose to make certain design decisions.
To organize what I learned from my research, user flows, and feedback sessions with other team members, I created a list of design requirements to prepare for design solution ideation.
The design should refrain from containing unnecessary repetition.
The design should allow customers to see slot availability before changing shipping dates.
The design should keep design system components consistent across the website.
The design should...
Based on the design requirements I created, I ideated several design solutions and worked with my mentor and Product Managers to prioritize and better understand how these solutions would fit in with business needs and engineering constraints. This helped me determine which design solutions were worth exploring further, and which ones I should leave as just opportunities to explore at a later time.
After having a strong enough understanding of the problem space, design requirements, and priorities for the organization and the company, I began with low-fidelity sketches of potential design solutions, getting feedback from PMs and other designers and continuing to iterate through multiple high-fidelity design solutions.
As I iterated on my designs, I found myself constantly going back and forth to do more research, make more sketches, and refer to lots of past documentation, making the design process a lot less linear than I thought it would be. Once I had enough information to proceed, I was able to reframe the problem statement to better fit the user needs that I had prioritized earlier in the process, allowing me to paint a much clearer picture as I continued to iterate on my designs.
A challenge I experienced was having to iterate without any explicit user feedback on my designs, as F3 VIDA does not employ user testing until designs are ready for A/B testing, which was different from what I had done in the past. I had to rely on my own expertise as a designer as well as my team's experience and the research that had been previously conducted by the team's User Researchers.
As I iterated on my designs, I ran into a challenge that I couldn't overcome, and I found it difficult to come up with any ideas that could possibly solve my problem. To help me figure this challenge out, I reached out to my teammates for more feedback and ideas.
My first course of action was to do what was most accessible to me: walking around the office and asking my teammates in the F3 organization for feedback on my designs and asking about the kinds of resources they like to use when scheduling things. This helped broaden my frame of reference, as I didn't ask only designers for feedback, but also engineers product managers.
My team hosted weekly design critiques that anyone could sign up for to receive proper feedback from other designers. I was able to talk to designers who were working in problem spaces similar to and connected to mine who gave me feedback to help me get off the ground.
Next, I reached out to Principal Designers on my team to learn more about how the space had been addressed in the past, as they had a lot of historical knowledge. They also reviewed my designs to ensure that the design system components I was using were consistent across the entire platform.
I organized an engineering review with the engineers who would be working on deploying my designs for A/B testing to better understand what was possible within the given timeline and any constraints that may exist for new features I had introduced, helping me limit some of the interactions I had thought about using in my designs.
Finally, I scheduled time to meet with the PMs working on this feature outside of our weekly check-ins to present all of the information, feedback, and ideas I had gathered from my teammates to prioritize and determine my next steps for the design, helping me get out of my slump and progress toward meaningful design solutions.
By the end of my internship, I was able to hand off three designs for A/B testing: Design A and Design B, which had a variation in X and Y features, and Design C, which was an exploratory design using new design system components that I had created, as F3's design system is still growing.
At the end of my internship, I told the story of my work in the format of a case study and presented it to my manager, my mentor, and the PMs I was working with on the project. I showcased my entire process from my initial research to my final designs and showed how I rationalized each of my research and design decisions. This final presentation also helped to frame how my design solution would be used in the future with other features that other designers on the team are working on.
While I received a lot of feedback throughout the whole process, the most memorable piece of feedback was from one of the Product Managers I was working with during my final shareout:
This project was scheduled to undergo A/B testing and be shipped by December 2022, but recent layoffs and shifting business needs at Amazon have delayed this project to be shipped at a later date. After results from A/B testing is available, my mentor will use the handoff documents that I wrote to hand off this project to other designers to continue to iterate and test.
While this internship wasn't my first corporate design internship, it was my first time working in an extremely large organization on an extremely large-scale product. I learned a lot from this experience and was able to connect it to all of the things I've learned in my past work and school experiences.
In my previous projects, both for internships and school projects, I had conducted the majority of user research myself. However, Amazon has dedicated User Researchers to conduct the research and publish their insights for designers to see and use, which was a bit diffcult for me, as I had to completely change the way I thought about user research.
While conducting audits of the current experience, I found several small features that I thought could be improved upon. However, after bringing them up to my mentor and product managers, I found that those small features were actually not so small—they would require months of work for engineers and would even need input from lawyers and finance experts.
As I worked on my project, I had the opportunity to see the projects that my other teammates were working on through shareouts and design critiques. I found that a lot of my teammates were working on projects similar to mine, and participating in these shareouts and design critiques for other projects actually helped me find ways to approach problems within my own project.
Although I learned a lot from my teammates because most of them are Senior Designers, I felt that despite knowing that I was an intern with much less experience than them, everyone was open to hearing my feedback as well. I felt that this encouraged me a lot to produce my best work possible.
