Assessment Builder

Strategic context & problem

Cornerstone’s assessment capability existed four separate times. E-learning, talent acquisition, recruiting, and performance management each had their own admin builder, their own question types, their own scoring and conditional-logic rules, and their own end-user player. None of that duplication was cosmetic. Admins moving between products hit a different configuration UI and different terminology for what was conceptually the same task. End-users completing assessments across products ran into fragmented flows that dropped completion rates. Every product team rebuilt the same feature from scratch whenever a new assessment capability got requested, and leadership had no way to see usage or performance across the platform as a whole.

The goal was to consolidate all four into a single platform-level system: one admin builder, one end-user player, one shared component and pattern library, with a documented path for each product team to actually adopt it.

Process

I led the design effort as the primary designer on a three-person design system team, managing two designers day to day and partnering with a design system engineer on scoping and integration architecture. Two more designers from the feature teams contributed edge-case validation, and two PMs and two engineers brought business and system context.

The hardest part wasn’t the components, it was the four incompatible admin conventions sitting underneath them. Each product’s builder had its own information architecture, its own settings vocabulary, its own default behaviors, and reconciling them without regressing any single one was as much a political problem as a design one. I ran structured interviews with each product team, reviewed their existing usability studies and analytics, and mapped every team’s edge cases into a shared component model. The working sessions mattered as much as the research, they were where trade-offs got surfaced openly instead of a single “winning” pattern getting dictated from the top.

Solution

Admin and end-user work turned out to be fundamentally different problems wearing the same feature name. An admin needs configuration density, preview and validation, and control over publishing. An end-user needs clarity, momentum, and completion. I designed them as two parallel systems that share primitives, question types, scoring, conditional logic, but diverge completely at the interaction layer, rather than one system trying to serve two mental models at once.

What I personally owned was the admin builder end-to-end: the question-type architecture, the admin-side conditional logic UI, settings, scoring rule patterns, and the preview and validation flows. I delegated the end-user player experience and its conditional logic to another designer, on purpose, so the branching behavior on that side had a single owner from end to end instead of splitting across two people.

None of that mattered if migration killed it. Each product had years of shipped assessment content and live customer workflows riding on it, so a big-bang replacement was never viable. I worked with the design system engineer to define an integration path that let each feature team adopt the new system incrementally, product by product, without disrupting anything already live.

Validation

There was no clean lab study here. The real validation was whether four product teams with four different roadmaps would actually adopt the thing. I spent nearly as much time on stakeholder alignment, adoption sequencing, and the integration path as I did on the components themselves, because a component library nobody adopts is a failed platform investment, not a design win. Getting that adoption model credible enough for engineering leads to commit sequencing to it was the real test.

Outcomes & impact

Takeaway

The most durable platform work turned out not to be a single unified UI. It was a shared component and pattern system that let each product team keep the parts of their admin experience that actually mattered to their users, while giving up the parts that were just duplicated effort. Getting that split right took as much political alignment as design craft.

Treating admin and player as two co-designed systems from day one, instead of one system with two modes, made both experiences sharper and made the shared primitives cleaner. And the deliverable that actually mattered on a platform team wasn’t the components, it was the adoption model that got them used.