People Analyzer — Katie DeVoe

Overview

Performance review tools that don’t speak EOS

Ninety is built for organizations running on the Entrepreneurial Operating System (EOS). But the platform’s existing “Fit Check” tool lacked clarity and was disconnected from the language and workflows of EOS — particularly the Right Person, Right Seat framework that leadership teams rely on for people decisions.

I owned the People Analyzer from discovery through delivery — conducting user research with Admins, Managers, and EOS Implementers; mapping the role-based experience; and designing a dual-rating evaluation system that gave leadership teams a consistent, visual framework for assessing both Core Values alignment and GWC (Get it, Want it, Capacity to do it).

The Problem

Subjective evaluations with no shared framework

Most performance review systems fail to account for EOS-specific frameworks like RPRS, which leaves leadership teams with incomplete data when making people decisions. Without a structured way to evaluate both values alignment and role fit, organizations face three compounding problems:

Subjective, inconsistent evaluations — Without a shared framework, two managers evaluating the same employee reach different conclusions using different criteria. People decisions become political rather than principled.

No visibility into development opportunities — Leaders couldn’t identify whether an employee was in the wrong seat, misaligned with values, or simply needed support — because there was no structured way to separate those diagnoses.

No organizational health baseline — Without structured data, it was impossible to assess team health at scale, track improvement over time, or surface patterns across roles and departments.

“The existing ‘Fit Check’ tool lacked clarity and was disconnected from the language EOS practitioners actually use. We needed something built from the EOS framework up, not retrofitted onto a generic performance review template.”

My Approach

Discovery, role mapping, and EOS alignment

1. Discovery & Research

I partnered with the PM and EOS Implementers to gather early qualitative feedback, running user interviews with Admins and SLT members to understand how they currently evaluate employees, what “RPRS” means in their day-to-day language, and what friction they experienced with existing tools. This shaped both the structure of the evaluation framework and the specific terminology we used throughout the UI.

2. Mapping the experience by role

Each user role had distinct workflows and permissions. Rather than a one-size-fits-all interface, I designed tailored experiences for three distinct archetypes:

Admins — Configuration screens to define thresholds for Core Values and GWC ratings, control who can evaluate whom, and set the rating scale for their organization.

Managers — Evaluation dashboards with the ability to assign, complete, and track feedback. The dashboard surfaces RPRS status at a glance without requiring the manager to calculate it manually.

Employees — Simple views of their own feedback and alignment status, with plain-language context for each rating so the evaluation feels like a growth conversation, not a verdict.

Evaluation Framework

A dual-rating system with automatic RPRS calculation

The core of the People Analyzer is a dual-rating system that evaluates employees on two independent dimensions:

Core Values alignment — Rated on a + / +/- / - scale for each of the organization’s defined Core Values, using visual bars for clarity. The threshold for “Right Person” is configurable per organization, so the tool adapts to different EOS implementations rather than imposing a single standard.

GWC (Get it, Want it, Capacity to do it) — A Yes / +/- / No rating for each dimension of role fit. These are shown as distinct indicators rather than a combined score, so managers can distinguish between an employee who “gets it but doesn’t want it” and one who “wants it but doesn’t have the capacity.”

The two dimensions combine to produce an automatic RPRS status: Right Person (Core Values > threshold), Right Seat (GWC all Yes or +/-), Both, or Neither. Automation was essential — having managers manually calculate this from ratings introduced error and inconsistency; the system does the math and surfaces the conclusion.

The most important design decision: keeping Core Values and GWC as separate, independent ratings rather than combining them into a composite score. An employee can be the right person (values-aligned) in the wrong seat (GWC not met) — and those two diagnoses lead to fundamentally different interventions. Combining them into a single score would have hidden that distinction.

The tool was designed as modular from the start — built on the Terra Design System with a clear data model that supports future integration with Ninety’s Org Chart, To-Dos, and AI-powered insights via Maz.

Before & After

From disconnected modal to structured full-page evaluation

The existing “Fit Check” modal was disconnected from EOS language, visually unclear, and didn’t give managers the contextual framing they needed to make consistent decisions.

Fit Check (before)

Disconnected from the language and workflows of EOS

People Analyzer (after)

Built from the EOS framework up, not retrofitted

Reflection

What this work reinforced

Domain language is a design problem

EOS practitioners have a precise vocabulary — RPRS, GWC, Core Values. Designing in that language rather than translating it to generic HR terms was the difference between a tool that felt native to EOS and one that felt like a corporate performance review with EOS labels applied afterward. The research interviews made that distinction clear before we wrote a single spec.

Separation of concerns in evaluation design

Keeping Core Values and GWC as independent rating dimensions — and resisting the urge to combine them into a composite score — was the most important structural decision. It preserved the diagnostic value of the framework. That same principle shows up in how I approach complex SaaS tools generally: when the domain has meaningful distinctions, the UI needs to preserve them, not collapse them for simplicity.

Role-based UX is worth the extra surface area

Designing three distinct role experiences instead of a single unified view added complexity to the spec. But the alternative — one interface trying to serve Admin configuration, Manager evaluation, and Employee feedback simultaneously — would have served none of them well. The investment in role-mapping early made every subsequent design decision simpler.

← Back to portfolio Discuss this work →