Making Complexity Manageable

At a glance

• Situation: D2L wanted to shrink Brightspace's admin learning curve and speed time-to-value in a powerful but highly configurable product.

• My role: Senior UX Researcher — led a multi-phase program end to end: framing the problem space, choosing methods, running studies, synthesizing across threads, and shaping product direction.

• Method: Product analytics + a 300-person survey + 12 foundational interviews, followed into four deep threads — platform structure, integrations, data management, and permissions.

• Biggest insight: Administrators weren't asking for less complexity. They were building manual workarounds because the system didn't give them enough clarity or confidence.

• Outcome: Reframed the goal from "How do we simplify this?" to "How do we make necessary complexity clearer, safer, and more manageable?" — and moved org-unit, integrations, data-management, and permissions work onto the roadmap (redesigns began releasing in 2025).
  
  

Overview

Brightspace administrators set up and maintain a large digital learning platform — who can access which tools, how the platform is structured, how third-party tools are added, and how old data is handled safely over time. That flexibility is powerful, but it also makes some admin workflows hard to learn, manage, and scale.

I led a connected program that started by identifying the most-used and most-difficult admin workflows, then followed those signals into deeper studies on platform structure, integrations, data management, and permissions. Over time, the work shifted the question from "How do we simplify this?" to "How do we make necessary complexity feel clearer, safer, and more manageable?"

Mapping the whole admin experience first

Before going deep on any one workflow, I needed evidence about where administrators actually spend time and where friction concentrates — so I could prioritize on data, not internal assumptions.

I paired two inputs: product analytics in PowerBI to see which admin tools were most heavily used (platform-structure tools like the org-unit editor stood out immediately), and a 300-respondent administrator survey with 12 qualitative follow-up sessions to understand the why behind the patterns. Together they produced a prioritization map of the admin experience and surfaced three major threads — platform structure, integrations, and permissions. A fourth, data management, emerged later from the structure work itself.

Thread 1 — Platform structure

In Brightspace, "org units" are the structural backbone — they shape how content, access, permissions, and relationships are organized. Problems here ripple through the whole product.

To make that legible for stakeholders, I used a filing-cabinet metaphor: org units are the folders and files, and administrators are constantly creating, copying, categorizing, and archiving them. It made the problem easy to see — the cabinet kept filling up, folders were hard to find, and archiving didn't work the way people expected. Across 8 administrator sessions, I found people spending real effort on manual naming and categorization workarounds to manage the structural backbone, because the built-in experience was hard to navigate, trust, and maintain. The strongest recurring signal — confusion around archive, delete, and cleanup — pointed to a broader data-management problem (Thread 3).

What shipped → Redesign of the org-unit editor and course-management tools moved onto the roadmap. I led the research from exploratory work through concept and usability testing, shaping improvements like bulk management and tagging/categorization. Redesigned tools began releasing in 2025.

Thread 2 — Integrations

In the foundational research, integration work surfaced as both frequent and difficult — administrators set up and manage third-party tools regularly, often alone, and described it as complex, anxiety-inducing, and costly.

I ran a dedicated study — 15 sessions on integration setup and management — and found two systemic problems. First, setup depended on incomplete or inconsistent vendor documentation, forcing administrators to chase information and manage vendor relationships just to get the basics in place. Second, the experience was fragmented across disparate tools with no single place to set up, edit, remove, and see what was actually in use — which meant real downstream cost, including continued spend on integrations no longer needed. This reframed integrations from a set of isolated frustrations into a systems problem to be solved at the platform level, not patched locally.

What shipped → The work aligned the team around a unified integrations experience and contributed to a redesign consolidating previously disparate tools into a cleaner, more consistent one.

Thread 3 — When structure problems pointed to data management

The structure work kept surfacing the same thing: administrators weren't using archive, delete, and related actions as intended. Old objects accumulated, and uncertainty about what each action did made the system harder to trust and maintain.

I followed it with a focused study — interviews on administrators' mental models for archive, recycle, delete, and purge, plus a heuristic evaluation of the data-purge tool (which was barely used at all). The pattern was clear: administrators hesitated because the language and system behavior didn't match their expectations, so they built naming conventions and workaround structures instead of relying on built-in actions. The issue wasn't terminology — it was confidence.

What shipped → A full redesign wasn't immediately feasible, so I worked with the PM, designer, and dev manager to translate the research into near-term changes: renaming actions, clarifying the archive/delete/purge hierarchy, improving recovery language, making restore options more visible, and refining warning and confirmation patterns — reducing risk and confusion early rather than waiting for a perfect future state.

Thread 4 — Permissions and administration at scale

Roles and permissions surfaced as both important and difficult — especially for large organizations managing multiple departments, campuses, or sub-orgs — and larger clients were directly asking for better support for distributed instances.

I triangulated those client signals with the broader admin research, then went deeper through interviews and workflow research into how administrators manage access, privacy, and delegated control at scale. Administrators valued the granularity of the permissions system but relied on brittle workarounds — duplicating nearly identical roles across the organization to preserve privacy and separation. The flexibility was valuable; the maintenance burden wasn't. And because multiple large clients said these workarounds made it harder to scale, this moved from a local usability problem to a long-term retention risk.

What shipped → A permissions redesign moved onto the roadmap, focused on simplifying the tool and making access easier to manage for large, distributed clients — and it strengthened trust with key clients by treating their needs as signals about the product's future, not edge cases.

Reflection

What the program taught me. These stopped feeling like separate workflow problems. The same pattern appeared everywhere: administrators weren't asking for less control or flexibility — they were asking for clearer, safer ways to work within a genuinely complex system, and building their own safeguards (manual organization, avoided actions, private tracking, duplicated roles) wherever the product didn't give them enough clarity or confidence. The opportunity wasn't to flatten the system; it was to make necessary complexity manageable.

What changed because of the work. It shifted the team's framing from isolated usability complaints to a connected challenge — helping administrators work safely and confidently in a configurable system — and gave teams a shared, evidence-based map of where to invest. It informed the structure and integrations redesigns, produced near-term data-management fixes when a full redesign wasn't feasible, strengthened the case for permissions work supporting large distributed clients, and built cross-functional empathy by making administrator workarounds and constraints visible.

What I'd improve. I'd connect the story more directly to downstream outcomes over time — using behavioral analytics and follow-up research to test whether the experience actually improved (e.g., data-purge adoption, rerun ease-of-use ratings, uptake of the redesigned features). I'd also turn what we learned into reusable team assets — administrator personas and shared frameworks — so future teams build on the work instead of rediscovering the same patterns.