Reguard
Increasing customer lifetime value through customer satisfaction.
Reguard is a warranty administrator and insurance company focused on the furniture industry. We provided a new way for customers to maintain their warranty with chatbots, quick registration, tailored contract lengths, and more.
The Highlights
Simplified UX for purchase protection
→ Clearer onboarding, improved transparency, and trust-building with customers.
Optimized user flows
→ Reduced friction in the application process, leading to faster sign-ups and policy selections.
Increased buyer confidence in warranties
→ Designed an intuitive experience that helps buyers understand and manage protection plans effortlessly.
The Challenge
Filling the User Experience gap from 0 -1
Team Challenge
I entered NAX Group as the Head of Design had just resigned, making me the most senior product designer. The first venture project I worked on was Reguard Protection.
The newly funded joint venture was backed by AshComm (owner of Ashley Furniture).
I joined two months into its development, as the team was building its Minimum Viable Business (MVB).
The branding and initial wireframes were created by a brand design consultant and another designer, who also established the first component library and design system.
I took the lead on UX design, driving user experience strategy and execution for the platform.
Design content in flux due to business unknowns
Business Challenge
The development for the File a Claim epic was hitting a blocker.
This was due to unknowns between the backend (warranty management software) fields not being in sync with the frontend (user interface) fields on the Reguard site.
On the business and legal side, the content details for the essential ‘File a Claim’ epic were in a state of flux.
I recognized how this would impact the design, product, and ultimately the overall launch of the business. To move the venture forward, I made it a priority to solve the content and flow of this epic.
The Process
Creating a system to organize the content requirements
I synced with the business venture team to clarify the field requirements for the warranty management software, PCMI. I wanted to confirm that we covered the foundational field requirements on our UI screen.
To accomplish this goal, I crafted a shared spreadsheet to help organize the PCMI fields. I made it the goal to make more user-friendly terms to serve as the equivalent of the backend management fields. This included all category titles and all the possible answer values for each category.
Converting backend terms to frontend UI titles
The main PCMI categories that had to be converted are listed on the left.
The equivalent user-facing titles are highlighted in Blue:
PCMI generated Contract Number = Claim ID
External Reference Number = Contract #
Product Number on contract = Product SKU
Failure Date = Date of Damage
Report Date = Submission Date
Functionality Status = Product Condition
Failure Type 1 = Type of Damage
Failure Type 2 = Cause of Damage
Failure Note = Description of Damage
Having user-friendly versions of the above categories was essential to the File a Claim flow. I confirmed that PCMI received the information needed to process customer claims while making the input categories easier for users to understand.
For some PCMI categories, selection values were attached.
For example, the category, Functionality Status, had five selection options:
Functional, Non-functional, Intermittently Functional, Lost, and No Power.
After converting the category title to Product Condition, I renamed the selection options to values that would be discernable by the customer, respectively:
Good, Poor, Fair, Lost, and No Power.
Expanding the content to improve the user experience and consider the business liabilities
Once I covered the PCMI required fields, I started to think about possible categories and values that could add to the overall File a Claim experience. I considered any field that the business team might want to add to help meet the Terms and Conditions. I also thought about areas that would be nice to have from a user perspective.
I worked with a business strategist to help refine the list of added fields and why they needed to be added. As I did for the PCMI-required content, I put my UX writer hat back on to create titles and values that would resonate with the user.
The additional fields and their values that made it on the interface are shown below. The category titles are in bold while the associated values are in italics.
Damage Area: All Over, Arm - Left facing, Arm - Right facing, Both Arms
Location of Damage: During delivery, During assembly, At home (normal use), While moving, While in storage
The Solution
Structuring the layout of the content on screen
After identifying the required and desired fields, I thought of how to effectively fit this content into the File a Claim flow.
The Goal: To get customers through the flow as quickly and easily as possible.
Started by focusing on the mobile layout.
I realized that locking down the content layout on mobile first, would make placing the content on tablet and desktop more seamless.
I planned to present the easier questions to start the File a Claim form. Once the customer submitted several answers during the earlier steps, they would be more inclined to complete the remainder of the form.
The step counter and the progress bar were added to encourage the customer to complete the form.
Step 1 - Damage Details
Having all ‘Step 1’ questions use dropdown input answers was an intentional strategy.
Dropdown Fields
Except for selecting the date, all questions on the first page utilize a dropdown with preselected answer options.
The first page needed to be quick to fill out to keep the user engaged and motivated to complete the rest of the form.
Step 2 -
Description of Details
Placing all the dropdown fields on ‘step 1’ allowed ‘step 2’ on the flow to have one write-in answer and one multiple-choice answer.
Write-in answers
If this content was on ‘Step 1’, it could have deterred customers from completing the form.
The write-in description does not ease the user into filling out a form like a dropdown answer can.
The write-in description worked best on ‘Step 2’ of the flow.
Step 3 -
Upload Photos
The third page included a photo upload feature. This was to allow customers to attach photos to their claims.
Incorporating the photo upload feature
I interacted with business and legal to confirm the minimum required and the maximum allowed amount. We agreed on a 5-12 photo range.
Figuring out how to best present a zoomed-in photo view and how to delete uploaded photos took a few brainstorming sessions and visual design iterations.
Step 4 -
Verify Contact Info.
The fourth and final step consisted of contact information verification. Since one of Reguard’s selling points was ‘quick registration’, we opted for a ‘smarter’ verification process.
Smart Verification
We utilized the addresses that the customer had previously submitted for their initial product delivery and presented it as ‘smart’ options for them to select for service.
We also did the same for the best number to contact.
For both fields, we still gave the user the option to either add or edit their contact information.
Summary
The Summary page allowed the customer to review the claim and a final chance to edit any information they inputted during the process.
Verifying the Epic with User Testing
I led the user testing interviews for the File a Claim epic. I crafted the questions to ask the user as they navigated the clickable prototype. We surveyed participants from usertesting.com. I asked the questions while a colleague recorded the user responses in Google Forms for future feedback analysis.
Examples of the questions asked:
Were any parts of the claim process unclear or difficult to complete? If so, which ones and why?
How did you feel about the balance between dropdown selections and text input throughout the flow?
What was your experience uploading photos, and did anything about this step feel confusing or frustrating?
Did the prefilled contact information options meet your needs, or did you need to make changes?
Was there anything about the process that felt unexpected or different from what you anticipated?
Prototype used for testing:
User Feedback Consensus:
Screen-to-screen flow made logical sense
Content information was clear and easy to understand
Duration to complete the form was reasonable
Questions asked on the form were essential to the completion
The Impact
I recognize the impact that my proactive method of aligning the backend software fields with the user interface fields had on the completion of this epic. I was able to smooth out the discrepancies between business, legal, design, and product by utilizing a shared spreadsheet. After creating and sharing the spreadsheet, I set parameters for the number of field values for optimal UX.
I was aware that File a Claim was the core function of the Reguard service, it was responsible for approving and rejecting claim requests from buyers. If the deadline to complete this flow was missed then it would have impacted the overall launch of the venture. (Pre-launch, Reguard was valued at over $300M. The projected first year of revenue was $8M) The regional California launch was in February 2023. Reguard launched nationwide on June 2023.
I was able to give design more time to create better solutions by clearing up the unknowns earlier in the process. This ultimately served us well as the third-party engineering and development team created a mountain of issues that we had to QA.
Company
NAX Group
My Deliverables
User Flow, Wireframing, Prototyping, User Testing, Design QA
Timeline
10 Months (0-1 launch)
Tools
Google Sheets, Forms, Figma
Team
Uba: Sr. Product Designer
Sarah: Sr. Product Manager
Christian: Project Manager
And the rest of the Reguard team