Designing an API-Driven Assessment & Reporting System
Designing an API-Driven Assessment & Reporting System
Turning a complex legacy architecture into a shared system model—and using it to integrate a new API into an enterprise assessment experience.
Heidrick & Struggles — Assessor-Led Integrated Reports
I led UX and information architecture for a complex API integration within Heidrick & Struggles' assessor-led reporting ecosystem.
Before designing the experience, I needed to understand how a network of legacy systems, assessment logic, data transformations, scoring rules, and report-generation processes worked together.
Over six months, I partnered across engineering, psychology, product, stakeholders, and an external UX agency to map the existing ecosystem, document its technical constraints, establish shared terminology, and identify where a new API could integrate into the workflow.
The resulting architecture became the foundation for an assessor-facing experience and integrated reports that successfully launched into production.
Project visuals have been reconstructed and simplified to protect proprietary information and represent work no longer accessible after my departure.
01 / THE CHALLENGE
The Challenge
A new API needed to be integrated into an existing assessor-led reporting ecosystem built on interconnected legacy systems, assessment logic, data transformations, scoring rules, and report-generation processes.
The challenge was understanding how a change in one part of the system could affect everything downstream, from which assessment questions were presented and how responses were processed to what information ultimately appeared in the integrated report.
Before I could determine where the new API could fit, or design the experience around it, I first needed to understand how the entire system worked.
THE SYSTEMS QUESTION
Where can we introduce new data and functionality without disrupting the logic, dependencies, and outputs the existing assessment experience relies on?
02 / UNDERSTANDING & MAPPING THE SYSTEM
Understanding & Mapping the System
The existing assessment ecosystem was too complex to understand from documentation alone. I worked closely with engineering and cross-functional teams to trace how information moved through legacy systems, assessment logic, scoring, and report generation.
I joined technical discussions across the project, asking detailed questions, documenting dependencies, and progressively mapping the system through workflows and data-flow diagrams.
Over time, I developed an end-to-end understanding of how the ecosystem worked, giving the project a shared model for evaluating technical constraints and making informed design decisions.
MY ROLE
Turn fragmented technical knowledge into a system the broader team could understand and design around.
03 / CREATING A SHARED SOURCE OF TRUTH
Creating a Shared Source of Truth
As I mapped the system, another challenge became clear: critical knowledge was distributed across teams, documents, and terminology that wasn't always consistent.
I standardized key terminology, restructured technical documentation, and created a tagging system that connected related source materials. I also documented the current-state workflow, technical constraints, and changes introduced throughout the integration.
This created a shared source of truth that made complex system knowledge easier to find, reference, and communicate across teams.
THE SHIFT
From fragmented knowledge across teams → to connected, traceable system documentation.
04 / FINDING THE INTEGRATION STRATEGY
Finding the Integration Strategy
With the system mapped and its dependencies documented, I could begin evaluating where the new API could realistically integrate into the existing assessment workflow.
Rather than designing around an ideal-state experience, I worked within the technical constraints of the existing ecosystem, identifying what was fixed, where flexibility existed, and how introducing new information could affect assessment logic, scoring, UI behavior, and report output.
These findings were translated into technical requirements and UX direction, giving engineering and design a feasible path for integrating the new functionality.
DESIGN PRINCIPLE
Design around how the system actually works, not how we assume it works.
What this project taught me
The most important design work doesn't always happen in the interface. On this project, understanding the architecture, creating shared language, and making complex technical relationships visible were prerequisites to designing an experience that could actually be built.
ROLE
Lead UX Designer & Information Architect
DURATION
6 Months
COLLABORATION
8+ Cross Functional Teams
FOCUS
Systems UX, Information Architecture, API Integration, Enterprise Workflows, Intraportals
DELIVERABLES
System Documentation, Data Flows, Workflows, User Flows, Technical Requirements, Report Design
05 / FROM ARCHITECTURE TO LAUNCH
From Architecture to Launch
Once the integration strategy was defined, I translated the system architecture, technical constraints, and assessment requirements into actionable UX and technical requirements.
I worked with our external UX agency to translate those requirements into the assessor-facing interface and report experience, while continuing to partner closely with engineering throughout implementation.
The new API was successfully integrated and launched as part of the assessor-led reporting experience, establishing the updated workflow for integrated reports moving forward.
THE OUTCOME
A complex technical ecosystem became a documented, shared system that teams could understand, design around, and successfully evolve.