Jessica Versaw

Background

In recent years, Hudl has moved from a strictly SaaS model to including "Hardware as a Service" offerings, such as Hudl Sideline. Teams pay an annual fee for Hudl Sideline, which includes leasing the equipment that can then be replaced/upgraded/downgraded as needed. Though Hudl had been offering hardware for two years, management of hardware orders was largely a manual process that took place across multiple tools -- Google docs, Typeforms, Slack, etc. 

My squad was tasked with building internal tools that would allow our internal teams to more efficiently manage our hardware offerings. As part of this project, my team created a School Hardware page, which included the three common hardware management flows -- Replacements, Returns, Upgrades, and Downgrades. My role in the project was to design these three flows. 

Goal

Create a processes through our admin that allows internal users to efficiently gather the information they need from the users, submit hardware requests, and supply the user with information and return labels without any manual intervention from other teams, such as operations and fulfillment. Additionally, the tools should be future-proofed -- at the time of the project Hudl Sideline was Hudl's only hardware offering, however Hudl has since began offering Hudl Focus camera units, and may add additional hardware as a service offerings in the future. 

Challenges

Much of the development work had been completed prior to design input, due to the squad designer being out on extended leave. Therefore, designs had to fit within database constraints that may not have been present had design been involved with the project from the outset.  This project also had to integrate with both our supplier and UPS, which provided further constraints. Finally, there were many unknowns around the efforts to future-proof the project. 

Research

Objectives

• Determine where confusion in the existing hardware workflow occurs

• Gain a better understanding of what other tasks are occurring in concurrence with filling out the hardware flows

• Understand how support users come to the conclusion an item needs to be replaced

Method

• Internal interviews with support representatives

  • Some interviews that were used to inform the design were conducted at the beginning of the hardware bet.

Key Findings

• Most of the hardware tasks are the result of multiple interactions with an external user, and are often escalated to “Sideline Experts” rather than a standard support rep.

• Support representatives have little understanding or faith in the current hardware flow. All reps indicated that they felt unsure the tasks would actually be completed, as there were no feedback or updates.

• Lack of information made it difficult for support reps to give clear timelines or information to users regarding their hardware, which was frustrating as many users were already frustrated if they need to initiate a replacement.

• Hardware flows are cumbersome, and usually not able to be completed while on the phone with a user. Frequently reps would need to initiate follow-up interactions with the user to gather more information.

• Support representatives usually don't know why an item is broken if it's being replaced -- they may have suspicions, but the external fulfillment company runs any diagnostics regarding hardware issues when they receive the item.

Takeaways

• Feedback regarding how long items would take to be shipped to a user, what is being shipped, what needs to be returned, and the success of a form submission needs to be clear. Support reps need to be able to tell a user their next steps and how long replacements may take.

• Support reps need feedback that a form has been submitted correctly and that progress is being made toward the task. They need to be clearly pointed to where they can track progress in case they need to follow up with a user.

• Additional tasks that need to be performed related to the hardware flows need to be clear (i.e. billing tasks, users sending items back).

• Completed hardware tasks should be simple enough that they can be completed in a single support interaction.

Replace Individual Item

This form allows support reps to fill out information to initiate a hardware replacement, which creates the order with our third party supplier,  generates the return labels, and emails the return labels to the user. 

• Individual item replacements are most common, so the form is defaulted to individual items.

• Individual items are broken into two categories: serialized and non-serialized items. Serialized items are items that the user will need to return, whereas non-serialized items don't have to be returned to Hudl as part of the replacement process. If a serialized item is selected, the helper text under email outlines that the email will be used to send the return labels, and the option to choose how many return labels are needed is shown at the bottom of the form.

• Contact and Shipping Information will be autofilled from the original order. If the address needs to be changed, Google Address lookup will autocomplete the form. Country/State as a text input rather than a dropdown list is due to scope rather than a specific design decision.

Replace Full Kit

• If "Replace Full Package" is selected, individualized items are not displayed, and the hardware return copy and inputs are displayed, as users will always need to return their existing kits.

• Upon submission of the form, a toast is shown to indicate the form was submitted successfully. The toast copy changes depending on whether serialized items that require a return were selected.

• "View Order" deep links to the new return order on the Orders page.

Upgrade/Downgrade Hardware

This form creates the hardware order needed to upgrade or downgrade a hardware package. In an upgrade or downgrade scenario, the user returns all their equipment, and is sent new equipment. 

• The backend does not have a concept of whether an order is an upgrade or a downgrade, so specialized flows could not be built out for each scenario.

• Though billing tasks are out of the scope of this flow, upgraded hardware is not sent until the invoice has been paid. Therefore, the invoice number is needed to check that the hardware order should be created as pending payment or paid and for immediate processing. This also serves to remind support representatives that billing tasks must be completed independent of this flow.

• Contact and Shipping Information is autofilled from the original order.

• Toast deep links to the new upgrade or downgrade order.