Alex Dontsov

Resume

Email

LinkedIn

Data enrichment service

A platform for enterprise teams to request and purchase enriched datasets to power their AI models

Domain

My role

Team

Machine Learning

Sr UX Designer

Engineers (FE/BE), QA, PO

Overview

The company provided data enrichment services that turned raw datasets into high-quality, AI-ready data. Customers could upload files, monitor processing progress, and download the results.

When I joined the team, there was a need to automate project setup. My role was to design a web solution that let customers submit training data requests, track their status, and access pre-processed datasets.

It also included an internal tool for analysing customer inquiries and launching data enrichment initiatives.

Challenge

Previously, customers started data training by contacting the sales team via email or phone. This often led to 1–2 day delays due to back-and-forth needed to clarify and approve project criteria.

The main challenge was designing a unified platform that brought multiple customer request scenarios into one place and removed the need for manual coordination with the sales team.

Results

Success criteria for the platform focused on three metrics:

  1. Request submission time: email/phone vs the platform
  2. Project initiation time: before and after launch
  3. Adoption rate: platform requests compared with traditional channels

One month after launch, we observed the following outcomes:

1 day

average time to submit a project request — down from 3 days

2× faster

project kick-off now takes 3 days instead of 7

80%

of requests were submitted via the platform in the first month

Design

I partnered with the product owner to map the end-to-end request flow in Miro, defining required inputs and validation rules. After alignment, I created wireframes and an interactive Figma prototype, then produced high-fidelity UI using our internal design system. Following team reviews, I iterated on feedback and delivered development-ready screens aligned with internal guidelines.

Interface overview

New request

If no requests exist, the starting page will appear empty. This happens when a customer submits a request for the first time. To get started, they can click the ‘New project’ button.

Project types

At this step, it is necessary to review the available project types and select the one that best fits the needs.

Requirements

Before, customers had to exchange multiple messages with the sales team to provide all required information. Now, everything can be submitted through a single form. The form structure prioritised the data needed to start a project.

Projects list

After submitting the form, the new entry appears in the list. The UI displays all data enrichment requests, with each row showing the status, date, language, and progress. Customers can sort the table by column headers, apply filters, or quickly search by name or ID.

Details

Customers can open project details by selecting a table row, which takes them to a dedicated page with all key information.

For example, the ‘Request details’ tab lets users review the initial requirements and edit them if anything changes.

Reports

Clients consistently asked for a reporting system for progress tracking and real-time monitoring, allowing the execution team to make immediate adjustments. To meet this need, I designed dashboard templates tailored to different data types, providing clear insights into the execution process.

Deliverables

Once everything is complete, the finalised datasets appear in the "Data deliverables" section for download.

Admin panel

The mockups above show the user-facing side of the service. We also needed an internal tool — an admin panel — for the team to track requests and initiate data enrichment tasks, which were processed differently on the back-end. This separation ensured flexibility in managing each request individually and guaranteed that every project started with a full estimation and approval.

Requests overview

My goal was to create the linking logic between requests and data enrichment initiatives. When a new submission is made, it appears in the internal table, allowing managers to assess feasibility and draft agreements.

Early steps

In parallel, after reviewing the request details, the execution team can begin project work in advance, even before the sales team completes all arrangements with clients.

Create project

To do so, it is possible to click the "Create project" button, fill out the settings form, and begin the initiative. At a certain stage, the project is linked to its request in the UI, keeping customers informed of its progress.

Takeaways

What I learned

A key lesson was learning how strongly back-end architecture can shape UX. In this system, customer “requests” and internal “projects” looked similar in the UI, but were stored and managed as separate entities on the back-end — requiring two distinct interfaces: one external and one internal.

As a result, the design challenge was to support both customer and operations/sales workflows while defining clear linking between a request and its corresponding project, so progress stayed visible end-to-end.

Design can’t always dictate structure — it must adapt to technical constraints.

Next project

© 2026 Alexander Dontsov

Alex Dontsov

Resume

Email

LinkedIn

Data enrichment service

A platform for enterprise teams to request and purchase enriched datasets to power their AI models

Domain

My role

Team

Machine Learning

Sr UX Designer

Engineers (FE/BE), QA, PO

Overview

The company provided data enrichment services that turned raw datasets into high-quality, AI-ready data. Customers could upload files, monitor processing progress, and download the results.

When I joined the team, there was a need to automate project setup. My role was to design a web solution that let customers submit training data requests, track their status, and access pre-processed datasets.

It also included an internal tool for analysing customer inquiries and launching data enrichment initiatives.

Challenge

Previously, customers started data training by contacting the sales team via email or phone. This often led to 1–2 day delays due to back-and-forth needed to clarify and approve project criteria.

The main challenge was designing a unified platform that brought multiple customer request scenarios into one place and removed the need for manual coordination with the sales team.

Results

Success criteria for the platform focused on three metrics:

  1. Request submission time: email/phone vs the platform
  2. Project initiation time: before and after launch
  3. Adoption rate: platform requests compared with traditional channels

One month after launch, we observed the following outcomes:

1 day

average time to submit a project request — down from 3 days

2× faster

project kick-off now takes 3 days instead of 7

80%

of requests were submitted via the platform in the first month

Design

I partnered with the product owner to map the end-to-end request flow in Miro, defining required inputs and validation rules. After alignment, I created wireframes and an interactive Figma prototype, then produced high-fidelity UI using our internal design system. Following team reviews, I iterated on feedback and delivered development-ready screens aligned with internal guidelines.

Interface overview

New request

If no requests exist, the starting page will appear empty. This happens when a customer submits a request for the first time. To get started, they can click the ‘New project’ button.

Project types

At this step, it is necessary to review the available project types and select the one that best fits the needs.

Requirements

Before, customers had to exchange multiple messages with the sales team to provide all required information. Now, everything can be submitted through a single form. The form structure prioritised the data needed to start a project.

Projects list

After submitting the form, the new entry appears in the list. The UI displays all data enrichment requests, with each row showing the status, date, language, and progress. Customers can sort the table by column headers, apply filters, or quickly search by name or ID.

Details

Customers can open project details by selecting a table row, which takes them to a dedicated page with all key information.

For example, the ‘Request details’ tab lets users review the initial requirements and edit them if anything changes.

Reports

Clients consistently asked for a reporting system for progress tracking and real-time monitoring, allowing the execution team to make immediate adjustments. To meet this need, I designed dashboard templates tailored to different data types, providing clear insights into the execution process.

Deliverables

Once everything is complete, the finalised datasets appear in the "Data deliverables" section for download.

Admin panel

The mockups above show the user-facing side of the service. We also needed an internal tool — an admin panel — for the team to track requests and initiate data enrichment tasks, which were processed differently on the back-end. This separation ensured flexibility in managing each request individually and guaranteed that every project started with a full estimation and approval.

Requests overview

My goal was to create the linking logic between requests and data enrichment initiatives.

 

When a new submission is made, it appears in the internal table, allowing managers to assess feasibility and draft agreements.

Early steps

In parallel, after reviewing the request details, the execution team can begin project work in advance, even before the sales team completes all arrangements with clients.

Create project

To do so, it is possible to click the "Create project" button, fill out the settings form, and begin the initiative.

At a certain stage, the project is linked to its request in the UI, keeping customers informed of its progress.

Takeaways

What I learned

A key lesson was learning how strongly back-end architecture can shape UX. In this system, customer “requests” and internal “projects” looked similar in the UI, but were stored and managed as separate entities on the back-end — requiring two distinct interfaces: one external and one internal.

As a result, the design challenge was to support both customer and operations/sales workflows while defining clear linking between a request and its corresponding project, so progress stayed visible end-to-end.

Design can’t always dictate structure — it must adapt to technical constraints.

Next project

© 2026 Alexander Dontsov