Project Kickoff

Working with the PM and a fellow UX Designer, we set out to learn everything that we could about this space. We did a lot of discovery work. We were able to do a lot of white boarding and exploration to drill down to the core issue of this request. We broke down the current into these key categories: 

Tier 4 Customers:

• Need a quick way to view the number of GoGuardian licenses they have across our suite of products.

Try Before You Buy:

• Enable Tier 4 customers to trial, purchase, and renew product licenses without any intervention from GoGuardian representatives.

Internal Business Goal:

• Free up the Tech Touch Team to focus on core business goals.

Customer Interviews

We conducted discovery user research sessions, gathering insights from both customers (IT Admins) and our internal Tech Touch team. We categorized the main pain points these parties faced daily:

• Difficulties in quickly viewing and managing license counts.

• • Challenges in trialing, purchasing, and renewing licenses independently.

• • Strain on the Tech Touch Team due to high demand for support from Tier 4 customers.

Diagnostic Test

Early Wireframes

During our discovery user testing sessions, a common theme emerged: customers were often unclear about which GoGuardian products they needed to purchase or renew. This confusion led to a heavy reliance on the Tech Touch Team. The primary issue was that the person responsible for paying the invoice was usually not the one using the product, and the most knowledgeable staff member was often unaware of the full suite of GoGuardian products.

Given that users typically only navigate to this page 1-4 times a year, we couldn’t expect them to know all the intricate differences between our products. During a working session with the PM and the UX Designer, we realized that a workflow where users could complete a questionnaire to receive product recommendations would be beneficial. Thus, we concluded that building a diagnostic test would help users identify the GoGuardian products that best met their needs for the coming school year. This self-directed approach could reduce the dependency on our Tech Touch Team for guidance.

Here is the workflow for the diagnostic test:

• Users complete a questionnaire to identify their needs.

• The diagnostic test provides product recommendations based on their responses.

  
  

The diagnostic test was highly successful during usability testing. However, due to build constraints and several business contingencies, its implementation was deferred to a future release.

Beta Release

A beta release was launched with seven customers to assess and iterate on improvements.

Version 2: Landing Page Refresh

After releasing the beta version and conducting six onboarding customer feedback sessions, we found that the feature wasn’t meeting the needs of the customers or the Tech Touch Team. Following the discovery phase, I transitioned to a different project, and our UX Designer left the company. I was asked to step back in and help iterate on the design.

We quickly pivoted to make the build more intuitive, recognizing that we had over-engineered the landing page, causing critical information to be lost. In true agile form, the PM, PMO Delivery Manager, back-end engineer, front-end engineer, QA engineer, and I collaborated to determine the essential elements required for users to view, purchase, and renew licenses.

Within a week, we developed a brand new design. We tested the new design with seven customers, and it was a success. We shipped the updated build, which has since been automatically processing all SMB requests.