lego.com replacement parts self-serve request project main image

LEGO.com Replacement Parts Request Flow

Project Overview

Project TypeWeb app

RoleDesign Lead

Time2023 - 2024

ToolsFigma, ProtoPie

DescriptionThe replacement parts request flow is a self-serve experience for user who have a missing or broken bricks from a LEGO set. After analysing the existing flow, me and the team ran a design sprint. From the sprint, ideas and prototypes were created and tested by the users. The product went live and further usability testing and accessibility testing were conducted with the live product.

Design Process

lego replacement parts self-serve request project design process
Figure 1. LEGO Replacement Parts project design process

Project Objective

The main objective of this project is to make the experience/flow simple and enable users to self-serve more rather than contacting customer advisors. It is for both users and business sides. Users can make a quick request whenever they want without waiting to contact customer advisors and the the customer service team can focus on other tasks. The main success metric is the completion rate of the flow.

Context and Analysis

Context

The LEGO.com replacement parts request flow is a self-serve experience that users can use when they want to request a missing or broken bricks in a LEGO set. Because of some complexity in the existing flow, the completion rate of the request was low which means users needed to contact advisors to get their missing or broken bricks.

The Existing Flow Analysis

The existing/current flow was analysed with heuristic evaluation, data analytics and user interviews to find opportunities to improve the flow.

the existing fow analysis - heuristic evaluation, analytics and user interviews
Figure 1. The existing flow analysis - Heuristic evaluation, data analytics and user interviews.

Design Sprint

To improve the flow and experience, a design sprint process was planned to build a shared understanding with the team and stakeholders, and to find ideas we want to test for the future improvement.

design sprint plan structure
Figure 2. Design sprint plan structure.

Day 1: Understand it

On Day 1 of the sprint, the existing flow, quantitative data from analytics, qualitative data from user interviews were presented to build a shared understanding with the team members and stakeholders.

design sprint day 1 banner - understand it
Figure 3. Design sprint day 1 banner - Understand it.

Day 2: Ideate it

On day 2, the team and the stakeholders had some ideation sessions - Worst Possible Ideas and Best Possible Ideas - and generated some solutions to improve the flow. Similar ideas were grouped. The team discussed the effect and effort of the groups of ideas.

design sprint day 2 banner - ideate it
Figure 4-1. Design sprint day 2 banner - Ideate it.
design sprint day 2 outcome - worst possible ideas and grouped ideas.
Figure 4-2. Design sprint day 2 outcomes - Worst Possible Ideas Method and Grouped Ideas.

Day 3: Create it

On day 3, everyone sketched and visualised their ideas. After explaining each one's sketches, we voted to our favourite sketches.

design sprint day 3 banner - create it
Figure 5-1. Design sprint day 3 banner - Create it.
design sprint day 3 banner - create it
Figure 5-2. Design sprint day 3 outcomes - Sketches.

Day 4: Build it

From day 4, I worked on building prototypes of the improved replacement parts flow. Hi-Fidelity prototypes were aimed to be created for a realistic experience when doing the user testing. And 2 prototypes were created based on some ideas from the day before - A step-by-step flow and an all-in-one flow. It took several days to finish the prototype.

design sprint day 4 outcome - two prototypes. A step-by-step flow and an all-in-one flow
Figure 6. Design sprint day 4 outcome - A step-by-step flow prototype and an all-in-one flow prototype.

Last Day: Test it

Two different flow prototypes were tested by recruited participants. The findings and insights from the testing helped us choose the right one, and prioritise the features that we need to implement.

design sprint last day - prototype user test
Figure 7. Design sprint last day - prototype user testing.

Implementation and Iteration

Implementation

The dev team worked on implementing the design. During this phase, lots of discussion happened to maximise the value versus the cost to implement it. Based on some feasibility, some features and designs were iterated and eventually, the team launched the final products and it's live on all markets. And the iterations keep happening based on further findings and backlogs.

Post-Launch Usability Testing

Live Product Usability TestingUsability testings were carried out with the live products. Findings and insights from the testing were documented and shared with the stakeholders, and in a product showcase meeting.

live product usability testing and the results
Figure 8. Live product usablility testing and the results.

Accessibility TestingAccessibility of the flow was considered during the design and implement phase. And accessibility-focused testing was conducted after the product went live. Total 4 participants who use assistive technology were recruited for this testing - 1 mobile screen reader user, 1 desktop screen reader user, 1 mobile screen magnification user and one desktop vocie recognition users. The findings and insights were documented and shared with the team and stakeholders, and the team continuously iterate, improve accessibliity of the flow.

live product accessibility user testing
Figure 9. Live product accessibility user testing.

Results and Reflection

Both user experience and business goals are important.After the improvement, the completion rate has increased from 28% to more than 60%. Which means that not only now it delivers a better experience to users but also a great value to the business since there are less people contacting customer advisors. As a UX designer, representing users' needs and satisfaction is crucial but considering the business side is also important to make better products.

Prioritisation is important in a product develeopment.It'd be good if a product team can implement/develop the products as what we want. However, due to the limited time and resources, prioritising features and flows when developing a product is needed. With a thorough discussion and planning, the most valualbe features can be developed first and improve more from the minimum viable product.