Enhancing Group Admin Experience to Support B2B Retention

The business decision: whether to invest in operational UX for enterprise admins — a segment invisible to consumer engagement metrics but responsible for the renewal decisions on the platform's highest-revenue accounts.

Group admins at Pragmatic Works were typically L&D leads or IT procurement contacts at enterprise accounts — the people responsible for distributing training licenses across teams of 10 to 500+ employees. Their job-to-be-done was operational: assign seats, track usage, handle transfers, manage renewals. They weren't learners. They were buyers doing administrative work in a tool that had been built for neither.

When I joined, these users faced significant friction — non-responsive interfaces, opaque transfer workflows, and confusion across multiple license groups. The result was heavy reliance on customer support and growing risk of churn among our highest-revenue B2B accounts. This redesign aimed to preserve those relationships while reducing the operational cost of supporting them.

HotJar session recordings had been collected consistently; I used them alongside the customer support feed to identify a pattern: enterprise admins were unable to complete core tasks on mobile, struggled with license transfer workflows, and regularly escalated to sales or support for tasks the product should have handled independently. Leadership was aware of the friction but had deprioritized it against new feature development — the recordings gave me the evidence to reframe it as a retention risk.

I asked sales and support staff directly for friction themes from their interactions with group admins, adding a qualitative layer to validate what the behavioral data was showing. A heuristic evaluation I ran early in my tenure gave me a structured current-state baseline. Stakeholder interviews with the PM, sales team, and head of sales mapped the business constraints and service-blueprint workflows that would define the MVP scope.

Before sketching screens, I used Object-Oriented UX to map the core entities the product needed to support: License (the asset), Group (the container), User (the member), and Transfer (the action). Defining these objects first — before considering UI — revealed a structural issue: the existing product conflated License and Group in ways that made transfer workflows confusing. A license wasn't assigned to a group; it was a pool attached to an account. The UI hadn't represented that distinction, which is why transfers required support intervention.

Object mapping also gave us a shared vocabulary with engineering and made scope decisions much easier: anything that touched those four objects was in scope; anything that didn't was deferred. That clarity shortened alignment time significantly and kept the MVP tightly scoped. The wireframe below shows the object model translated directly into UI — distinct Group Assignments and Member Breakdown sections, each surfacing only what that object's manager needed to act on.

The object model drove the core UI changes. Separate views for license pool versus group membership made the distinction visible to users for the first time. An explicit transfer workflow with clear confirmation states replaced the implicit, support-dependent process. The user list was rebuilt as a mobile-responsive card layout — the most impactful single change for admins managing their teams on mobile.

I prototyped at low fidelity, tested iteratively through hallway and coffeehouse-style sessions with internal participants, then validated the high-fidelity prototype via a formal SUS assessment — run remotely via Teams with real enterprise clients on Figma mockups — before handoff.

Post-launch, support ticket volume dropped and satisfaction metrics among group administrators improved. The mobile-first interface enabled on-the-go license management that enterprise clients had been requesting. Comparative usability testing showed meaningful gains in task completion and visual hierarchy clarity.

The OOUX object model also outlasted the project itself. It became the reference artifact for the team's next two feature cycles — a shared vocabulary that kept engineering and design aligned without re-deriving context from scratch each time.

OOUX was the right tool here, but the real value wasn't the framework — it was having a shared language. Enterprise tools fail at the seams between what users call things, what engineers built, and what the business sold. The object model made those seams visible before anyone wrote a line of code.

The lesson I'd carry into any similar project: for products with complex data relationships, define objects before flows. Flows look completely different depending on where you start; objects don't. Starting there forces the hardest conversations — about what the product actually does vs. what the UI implies — at the lowest-cost moment in the process. This iteration of the member list — introducing an explicit Invited state distinct from Active — was a direct outcome of that object modeling: the license lifecycle had implicit states the original UI had never surfaced.