Identifying the Problem

Customer Problem: Enterprise customers struggle to fully utilize their budgets. Unspent budgets expire, creating pressure for full utilization and frustration when not fully utilized.

Business Problem: Based on input from customers, low budget utilization hindered customer renewals.

Goal: Our primary goal was to increase product adoption and budget utilization. A secondary aim was to give learners who had reached their individual spend limits access to additional learning opportunities with administrative approval.

Validating the Problem

I interviewed four customers identified as likely candidates for Browse & Request. Each had created their own workaround for the feature, but all faced difficulties managing these processes within our current admin and learner portals. Three of the four customers also highlighted concerns about managing high volumes of learner requests, stressing the importance of limiting the number of pending requests per learner.

Overall, the interviews confirmed that customers struggle to fully utilize their budgets under the current setup and need a more streamlined solution to make this feasible.

Defining Key Design Requirements

While translating interview insights into project scope, three critical factors emerged as must-haves based on customer feedback:

1. Limits on Requests: Customers worried about being overwhelmed by large volumes of course requests. We started with a conservative limit of one pending request per learner at a time.

2. Toggle for Browse & Request: Customers wanted the flexibility to enable or disable the Browse & Request feature within each budget. This would allow them to experiment and scale as they saw fit.

3. Budget Impact Visibility: Customers needed visibility into how approving a request would affect their remaining budget.

Understanding How Browse & Request Fits In

I mapped out user flows to understand where Browse & Request would integrate into existing processes. These flows helped visualize its place within the broader budget ecosystem and served as a clear reference when presenting to the Engineering team.

Exploring Solutions with Low-Fidelity Wireframes

I presented two initial concepts:

Concept A placed the Browse & Request toggle at the global portal level, an idea engineers initially found appealing as it was a simpler and faster option to implement.

Concept B proposed enabling the toggle within each individual budget, reflecting what customers preferred. By showing both approaches side-by-side, I highlighted the user benefits of the budget-specific solution.

Concept B:

Despite initial concerns about scope, Engineering agreed to move forward with Concept B, the budget-level toggle approach. This early collaboration ensured we chose a solution that balanced user needs and technical feasibility.

The Final Solution: A Streamlined Browse & Request Experience

With Engineering aligned on the project scope, I refined the solution to focus on three key elements of Browse & Request:

Pending Requests Category:
A dedicated “Pending” section in each budget gives admins a clear overview of incoming course requests. This interface provides quick access to approvals and denials, while also displaying the financial implications of each pending request.

One Pending Request per Learner:
To prevent administrative overload, each learner is allowed one active request at a time. This limit provides manageable oversight and ensures a more balanced workflow. If customers find this limit too restrictive, we can adjust it as needed in future iterations.

Budget-Level Toggle:
Administrators can now enable or disable Browse & Request on a per-budget basis. This flexibility ensures that only budgets intended for learner-driven exploration include the feature, reducing unnecessary complexity and maintaining clear boundaries between different budget types.

By implementing these elements, the final design achieves a strong balance between user needs and technical feasibility, offering customers a more intuitive and effective way to fully utilize their L&D budgets.

Outcomes and Impact

Launched in early Q4, Browse & Request is still in its early days. We’re actively monitoring how it influences customer behavior, focusing on two key metrics:

1. Reduced Need for Extensions:
   Our aim is to lower the number of customers who request plan extensions by improving budget utilization upfront.

2. Decreased Budget Waste:
   By helping customers fully allocate their funds before expiration, we expect less unspent budget, which should ultimately translate into stronger renewal rates and greater overall value for our customers.

As we gather data and track these metrics over time, we’ll continue refining the feature to better meet our customers’ needs.