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.

NAX Group

User Flow, Wireframing, Prototyping, User Testing, Design QA

10 Months (0-1 launch)

Google Sheets, Forms, Figma

Sarah: Sr. Product Manager

Christian: Project Manager

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. This new joint venture had just received funding from its investment partner, AshComm, who owns Ashley Furniture.

I joined the team just two months after it had started building its MVB (Minimum Viable Business). At this time, most of the branding was created by Jason, and the initial wireframes were crafted by Yinjia. Together, they made the first component library and design system for Reguard. I led the UX design for the new venture.

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 end, 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.

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 task, 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.

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 made sure that PCMI received the information needed to process customer claims while making the input categories easier for users to understand.

For some PCMI categories, there were selection values 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, Good, Poor, Fair, Lost, and No Power, respectively.

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

After identifying the required and desired fields, I thought of how to effectively fit this content into the File a Claim flow. The goal was to get customers through the flow as quickly and easily as possible. I started by focusing on the mobile layout first. I knew that if I could lock down the content layout on mobile first, then placing the content on tablet and desktop would be more seamless.

I planned to present the easier questions and answers first as the customer progressed forward through the File a Claim form. I believe that if the customer completes most of the answers in the earlier steps then they will be more inclined to complete the remainder of the form. The inclusion of the step counter and the progress bar only added to the encouragement for the customer to complete the form.

Having all ‘Step 1’ questions use dropdown input answers was an intentional strategy.

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.

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.

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.

The third page included a photo upload feature. This was to allow customers to attach photos to their claims.

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.

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.

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.

The Summary page allowed the customer to review the claim and a final chance to edit any information they inputted during the process.

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.