AI HR Assessment Platform
AI HR Assessment Platform
AI HR Assessment Platform
Product Designer
Product Designer
Freelance
Freelance
Turning a 13-year manual assessment process into a scalable AI-assisted platform. The core challenge wasn't simply digitising the process. It was designing an AI system that could accelerate expert work without taking control away from the people doing it.
MVP in 16 weeks Timeline Nov 2024 – Sept 2025
Scope UI Design· IA · UX · AI workflow · RBAC
Scope UI Design· IA · UX · AI workflow · RBAC
Scope UI Design· IA · UX · AI workflow · RBAC
85%
85%
Reduction in report time
Reduction in report time
100%
100%
Audit trail coverage
Audit trail coverage
3X
3X
Faster assessment creation
Faster assessment creation
The problem
The product didn't start with a blank canvas. It started with 13 years of process.
Breakfree's assessment methodology had evolved over years, but the tooling hadn't.
Assessors moved between documents, spreadsheets and email to manage competency frameworks, scores and reports. That created three problems:
Repetition Every engagement required significant manual setup.
Inconsistency Different clients used different competency scales and descriptors.
No source of truth Information lived across multiple tools, making reporting slow and error-prone.
A report that should have taken hours could consume an entire workweek or more.
Breakfree's assessment methodology had evolved over years, but the tooling hadn't.
Assessors moved between documents, spreadsheets and email to manage competency frameworks, scores and reports. That created three problems:
Repetition Every engagement required significant manual setup.
Inconsistency Different clients used different competency scales and descriptors.
No source of truth Information lived across multiple tools, making reporting slow and error-prone.
A report that should have taken hours could consume an entire workweek or more.
The problem
The product didn't start with a blank canvas. It started with 13 years of process.
The design challenge - Manual assessment process into one reusable system without flattening the domain knowledge.
The opportunity
Multiple sources of truth
Repeated setup
Manual compilation
Different frameworks
From a process people had learned to work around → a system designed around how the work actually happens.
Understanding the Workflow and System
I didn't start by designing screens. The product had a formal SRS, but the documentation couldn't explain the operational nuance behind 13 years of assessment work.
So I started with the people who knew the process best.
I worked closely with Andrea, who had been running the process for 20 years, using early sessions as an apprenticeship into the domain studying internal documents, previous engagement reports and the reasoning behind different client frameworks.
This helped me separate:
What the system needed to support
from
What the existing process had simply learned to tolerate.
Designing the system
The biggest challenge wasn't the UI. It was the underlying model.
The existing process had several layers that were easy to miss if we looked at it as a collection of screens. Every client could define competencies differently. If we created one flat list for every assessment, we'd solve the immediate MVP problem but create a system that couldn't scale. An assessment could involve:
Competencies What are we evaluating?
Activities How are we evaluating it?
Assessment configuration Who participates and how is the assessment run?
AI profile How should AI interpret and generate assessment content?
Report structure How should the final output be assembled?
Participants & assessors Who is being assessed and who is evaluating them?
These relationships became the foundation for the product architecture.
01
Competency Library
Reusable competency definitions.
02
Competency Maps
Competencies organised for a specific designation or framework.
03
Assessment Scoring
The actual candidate-level assessment.
How do you make a highly configurable system feel simple?
The product needed to support different combinations of:
Competency frameworks
Assessment activities
Scoring models
AI configurations
Report structures
Participants
Assessors
Trying to expose all of these decisions at once would create a powerful system that was difficult to operate.
So I focused on three principles:
01 Separate configuration from execution, Users should configure an assessment before they start running it.
02 Reuse wherever possible, Competencies, activities, AI profiles and report structures shouldn't need to be rebuilt for every assessment.
03 Reveal complexity progressively, Users should only have to make the decision relevant to the step they're currently in.
Decision 01
I treated competency frameworks as reusable infrastructure, not assessment content.
One of the biggest risks was flattening Breakfree's competency methodology into a simple list. That would make the MVP easier to build, but every new assessment would become another isolated setup. Instead, I structured the system around reusable competency frameworks that could be selected and applied across assessments. The model
Competency Library → Competency Map → Assessment → Activities → Candidate evaluation.
This meant the product could support different assessment programmes without rebuilding the competency structure each time.
Decision 02
Assessment creation needed to feel like configuration, not form-filling. Actual complexity of the setup: Select content → select competencies → subject/exercise matrix → framework → documents → report configuration → participants & assessors.
Putting all of this into one form would technically work. But it would make the user think about the entire assessment before they could complete the first decision. So I separated the workflow into meaningful stages.
01 — Content What activities are included?
02 — Competencies What are we measuring?
03 — Exercise matrix How do activities map to competencies?
04 — Framework Which competency framework applies?
05 — Report configuration How should the output be structured?
06 — Participants & assessors Who is involved?
Decision 02
Assessment creation needed to feel like configuration, not form-filling. Actual complexity of the setup: Select content → select competencies → subject/exercise matrix → framework → documents → report configuration → participants & assessors.
Putting all of this into one form would technically work. But it would make the user think about the entire assessment before they could complete the first decision. So I separated the workflow into meaningful stages.
01 — Content What activities are included?
02 — Competencies What are we measuring?
03 — Exercise matrix How do activities map to competencies?
04 — Framework Which competency framework applies?
05 — Report configuration How should the output be structured?
06 — Participants & assessors Who is involved?
Decision 03
AI should configure the process — not silently take over the decision. The platform introduced AI through configurable AI Profiles. From the actual product, users can define:
AI model
temperature
system instructions
profile configuration
This created an important product question: How much control should users have over AI behaviourI chose to make the AI configuration explicit rather than hiding it behind a single "AI" switch.
The user can understand: Which model is being used → how it behaves → what instructions guide itThat made AI behaviour part of the product's configuration rather than an invisible layer.
Decision 03
AI should configure the process — not silently take over the decision. The platform introduced AI through configurable AI Profiles. From the actual product, users can define:
AI model
temperature
system instructions
profile configuration
This created an important product question: How much control should users have over AI behaviourI chose to make the AI configuration explicit rather than hiding it behind a single "AI" switch.
The user can understand: Which model is being used → how it behaves → what instructions guide itThat made AI behaviour part of the product's configuration rather than an invisible layer.
From configuration to execution
The system then had to support the people actually running the assessment. Once an assessment was configured, the workflow moved into participants and assessors. The platform needed to support:
Participant assignment → assessor management → assessment progress → results → report generation
This is where the configuration work became operational.
From configuration to execution
The system then had to support the people actually running the assessment. Once an assessment was configured, the workflow moved into participants and assessors. The platform needed to support:
Participant assignment → assessor management → assessment progress → results → report generation
This is where the configuration work became operational.
The reporting problem
The final output had to be as structured as the assessment itself. Previously, reporting was one of the most manual parts of the process. The product now brought the reporting workflow into the same system:
Assessment data → Competency results → AI-assisted interpretation → Configured report structure → Downloadable assessment report
This reduced the need to manually compile information from multiple sources.
The reporting problem
The final output had to be as structured as the assessment itself. Previously, reporting was one of the most manual parts of the process. The product now brought the reporting workflow into the same system:
Assessment data → Competency results → AI-assisted interpretation → Configured report structure → Downloadable assessment report
This reduced the need to manually compile information from multiple sources.
Domain discovery Understanding how the existing assessment methodology worked.
Information architecture Turning the methodology into a navigable product structure.
Data modelling Defining relationships between competencies, assessments, activities and reports.
Assessment workflows Designing the configuration and execution flows.
AI experience Designing AI Profile configuration and its relationship to assessment reporting.
Reporting Designing report configuration and output workflows.
Enterprise UX Permissions, participant management and auditability.
I worked as the solo design lead with the engineering team, translating a formal SRS and domain knowledge into a working product.
What I owned
My role went beyond the interface. I owned the design across the core product system:
Domain discovery Understanding how the existing assessment methodology worked.
Information architecture Turning the methodology into a navigable product structure.
Data modelling Defining relationships between competencies, assessments, activities and reports.
Assessment workflows Designing the configuration and execution flows.
AI experience Designing AI Profile configuration and its relationship to assessment reporting.
Reporting Designing report configuration and output workflows.
Enterprise UX Permissions, participant management and auditability.
I worked as the solo design lead with the engineering team, translating a formal SRS and domain knowledge into a working product.
What I'd do differently? I would validate the AI workflow earlier.
What I'd do differently? I would validate the AI workflow earlier.
The hardest part of the project wasn't building the configuration model.
It was introducing AI into a workflow where experienced professionals already had established ways of working.
With more time, I would have run a dedicated usability round around the AI configuration and review experience before broader rollout.
The lesson I took from the project:
When AI enters an expert workflow, trust has to be designed into the product — not added after the model works.
What I'd do differently
I would validate the AI workflow earlier. The hardest part of the project wasn't building the configuration model.
It was introducing AI into a workflow where experienced professionals already had established ways of working.
With more time, I would have run a dedicated usability round around the AI configuration and review experience before broader rollout.
The lesson I took from the project:
When AI enters an expert workflow, trust has to be designed into the product — not added after the model works.
Breakfree's assessment methodology had evolved over years, but the tooling hadn't.
Assessors moved between documents, spreadsheets and email to manage competency frameworks, scores and reports. That created three problems:
Repetition Every engagement required significant manual setup.
Inconsistency Different clients used different competency scales and descriptors.
No source of truth Information lived across multiple tools, making reporting slow and error-prone.
A report that should have taken hours could consume an entire workweek or more.
The problem
The product didn't start with a blank canvas. It started with 13 years of process.
The design challenge - Manual assessment process into one reusable system without flattening the domain knowledge.
The opportunity
Multiple sources of truth
Repeated setup
Manual compilation
Different frameworks
From a process people had learned to work around → a system designed around how the work actually happens.
The design challenge - Manual assessment process into one reusable system without flattening the domain knowledge.
The opportunity
Multiple sources of truth
Repeated setup
Manual compilation
Different frameworks
From a process people had learned to work around → a system designed around how the work actually happens.
Understanding the Workflow and System
I didn't start by designing screens. The product had a formal SRS, but the documentation couldn't explain the operational nuance behind 13 years of assessment work.
So I started with the people who knew the process best.
I worked closely with Andrea, who had been running the process for 20 years, using early sessions as an apprenticeship into the domain studying internal documents, previous engagement reports and the reasoning behind different client frameworks.
This helped me separate:
What the system needed to support
from
What the existing process had simply learned to tolerate.
Designing the system
The biggest challenge wasn't the UI. It was the underlying model.
The existing process had several layers that were easy to miss if we looked at it as a collection of screens. Every client could define competencies differently. If we created one flat list for every assessment, we'd solve the immediate MVP problem but create a system that couldn't scale. An assessment could involve:
Competencies What are we evaluating?
Activities How are we evaluating it?
Assessment configuration Who participates and how is the assessment run?
AI profile How should AI interpret and generate assessment content?
Report structure How should the final output be assembled?
Participants & assessors Who is being assessed and who is evaluating them?
These relationships became the foundation for the product architecture.
01
Competency Library
Reusable competency definitions.
02
Competency Maps
Competencies organised for a specific designation or framework.
03
Assessment Scoring
The actual candidate-level assessment.
How do you make a highly configurable system feel simple?
How do you make a highly configurable system feel simple?
The product needed to support different combinations of:
Competency frameworks
Assessment activities
Scoring models
AI configurations
Report structures
Participants
Assessors
Trying to expose all of these decisions at once would create a powerful system that was difficult to operate.
The product needed to support different combinations of:
Competency frameworks
Assessment activities
Scoring models
AI configurations
Report structures
Participants
Assessors
Trying to expose all of these decisions at once would create a powerful system that was difficult to operate.
So I focused on three principles:
01 Separate configuration from execution, Users should configure an assessment before they start running it.
02 Reuse wherever possible, Competencies, activities, AI profiles and report structures shouldn't need to be rebuilt for every assessment.
03 Reveal complexity progressively, Users should only have to make the decision relevant to the step they're currently in.
Decision 01
I treated competency frameworks as reusable infrastructure, not assessment content.
One of the biggest risks was flattening Breakfree's competency methodology into a simple list. That would make the MVP easier to build, but every new assessment would become another isolated setup. Instead, I structured the system around reusable competency frameworks that could be selected and applied across assessments. The model
Competency Library → Competency Map → Assessment → Activities → Candidate evaluation.
This meant the product could support different assessment programmes without rebuilding the competency structure each time.
Decision 02
Assessment creation needed to feel like configuration, not form-filling. Actual complexity of the setup: Select content → select competencies → subject/exercise matrix → framework → documents → report configuration → participants & assessors.
Putting all of this into one form would technically work. But it would make the user think about the entire assessment before they could complete the first decision. So I separated the workflow into meaningful stages.
01 — Content What activities are included?
02 — Competencies What are we measuring?
03 — Exercise matrix How do activities map to competencies?
04 — Framework Which competency framework applies?
05 — Report configuration How should the output be structured?
06 — Participants & assessors Who is involved?
Decision 03
AI should configure the process — not silently take over the decision. The platform introduced AI through configurable AI Profiles. From the actual product, users can define:
AI model
temperature
system instructions
profile configuration
This created an important product question: How much control should users have over AI behaviourI chose to make the AI configuration explicit rather than hiding it behind a single "AI" switch.
The user can understand: Which model is being used → how it behaves → what instructions guide itThat made AI behaviour part of the product's configuration rather than an invisible layer.
AI wasn't the end of the workflow.
The AI profile only becomes useful when it connects to reporting. The next challenge was connecting AI configuration to the final assessment output. The report-structure flow allowed users to:
Select an AI profile → Select assessment types → Choose report sections → Define the structure of the final report
The important design decision here was keeping these relationships visible. A report wasn't just a generated document. It was the output of the assessment configuration that came before it. Report configuration connected the assessment inputs to the final output, instead of treating reporting as a separate step.
From configuration to execution
The system then had to support the people actually running the assessment. Once an assessment was configured, the workflow moved into participants and assessors. The platform needed to support:
Participant assignment → assessor management → assessment progress → results → report generation
This is where the configuration work became operational.
The reporting problem
The final output had to be as structured as the assessment itself. Previously, reporting was one of the most manual parts of the process. The product now brought the reporting workflow into the same system:
Assessment data → Competency results → AI-assisted interpretation → Configured report structure → Downloadable assessment report
This reduced the need to manually compile information from multiple sources.
The reporting problem
The final output had to be as structured as the assessment itself. Previously, reporting was one of the most manual parts of the process. The product now brought the reporting workflow into the same system:
Assessment data → Competency results → AI-assisted interpretation → Configured report structure → Downloadable assessment report
This reduced the need to manually compile information from multiple sources.
From configuration to execution
The system then had to support the people actually running the assessment. Once an assessment was configured, the workflow moved into participants and assessors. The platform needed to support:
Participant assignment → assessor management → assessment progress → results → report generation
This is where the configuration work became operational.
The reporting problem
The final output had to be as structured as the assessment itself. Previously, reporting was one of the most manual parts of the process. The product now brought the reporting workflow into the same system:
Assessment data → Competency results → AI-assisted interpretation → Configured report structure → Downloadable assessment report
This reduced the need to manually compile information from multiple sources.
AI wasn't the end of the workflow.
The AI profile only becomes useful when it connects to reporting. The next challenge was connecting AI configuration to the final assessment output. The report-structure flow allowed users to:
Select an AI profile → Select assessment types → Choose report sections → Define the structure of the final report
The important design decision here was keeping these relationships visible. A report wasn't just a generated document. It was the output of the assessment configuration that came before it. Report configuration connected the assessment inputs to the final output, instead of treating reporting as a separate step.
What I owned
My role went beyond the interface. I owned the design across the core product system:
Domain discovery Understanding how the existing assessment methodology worked.
Information architecture Turning the methodology into a navigable product structure.
Data modelling Defining relationships between competencies, assessments, activities and reports.
Assessment workflows Designing the configuration and execution flows.
AI experience Designing AI Profile configuration and its relationship to assessment reporting.
Reporting Designing report configuration and output workflows.
Enterprise UX Permissions, participant management and auditability.
I worked as the solo design lead with the engineering team, translating a formal SRS and domain knowledge into a working product.
What I'd do differently? I would validate the AI workflow earlier.
The hardest part of the project wasn't building the configuration model.
It was introducing AI into a workflow where experienced professionals already had established ways of working.
With more time, I would have run a dedicated usability round around the AI configuration and review experience before broader rollout.
The lesson I took from the project:
When AI enters an expert workflow, trust has to be designed into the product — not added after the model works.
What I'd do differently
I would validate the AI workflow earlier. The hardest part of the project wasn't building the configuration model.
It was introducing AI into a workflow where experienced professionals already had established ways of working.
With more time, I would have run a dedicated usability round around the AI configuration and review experience before broader rollout.
The lesson I took from the project:
When AI enters an expert workflow, trust has to be designed into the product — not added after the model works.
What I owned
My role went beyond the interface. I owned the design across the core product system:
Domain discovery Understanding how the existing assessment methodology worked.
Information architecture Turning the methodology into a navigable product structure.
Data modelling Defining relationships between competencies, assessments, activities and reports.
Assessment workflows Designing the configuration and execution flows.
AI experience Designing AI Profile configuration and its relationship to assessment reporting.
Reporting Designing report configuration and output workflows.
Enterprise UX Permissions, participant management and auditability.
I worked as the solo design lead with the engineering team, translating a formal SRS and domain knowledge into a working product.
What I'd do differently? I would validate the AI workflow earlier.
The hardest part of the project wasn't building the configuration model.
It was introducing AI into a workflow where experienced professionals already had established ways of working.
With more time, I would have run a dedicated usability round around the AI configuration and review experience before broader rollout.
The lesson I took from the project:
When AI enters an expert workflow, trust has to be designed into the product — not added after the model works.
What I'd do differently
I would validate the AI workflow earlier. The hardest part of the project wasn't building the configuration model.
It was introducing AI into a workflow where experienced professionals already had established ways of working.
With more time, I would have run a dedicated usability round around the AI configuration and review experience before broader rollout.
The lesson I took from the project:
When AI enters an expert workflow, trust has to be designed into the product — not added after the model works.
More projects
More projects
Ready to Make Your Brand Success and Unforgettable?
Let's make it happen!
I'm open to full-time product design roles where AI, compliance, and complex systems are the actual brief not an afterthought. If your product has to work in the real world, under real pressure, for real users that's exactly where I do my best work.
Open to roles
Sakshi Gupta
Fulltime
Skills and Tools
Web Design
Mobile Applications
Saas
Design Systems
AI workflow UX
UX Research
Visual Design
What I bring
Compliance-first thinking
AI product experience
Complex systems
Cross-functional collab
Ready to Make Your Brand Success and Unforgettable?
Let's make it happen!
I'm open to full-time product design roles where AI, compliance, and complex systems are the actual brief — not an afterthought. If your product has to work in the real world, under real pressure, for real users that's exactly where I do my best work.
Open to roles
Sakshi Gupta
Fulltime
Skills and Tools
Web Design
Mobile Applications
Saas
Design Systems
AI workflow UX
UX Research
Visual Design
What I bring
Compliance-first thinking
AI product experience
Complex systems
Cross-functional collab
Ready to Make Your Brand Success and Unforgettable?
Let's make it happen!
I'm open to full-time product design roles where AI, compliance, and complex systems are the actual brief not an afterthought. If your product has to work in the real world, under real pressure, for real users that's exactly where I do my best work.
Open to roles
Sakshi Gupta
Fulltime
Skills and Tools
Web Design
Mobile Applications
Saas
Design Systems
AI workflow UX
UX Research
Visual Design
What I bring
Compliance-first thinking
AI product experience
Complex systems
Cross-functional collab