Revision Tool {Reliable implementations and change tracking}

Revision Tool is a core module of Lekta — a conversational AI platform used by enterprises to build and manage voice and text bots.

This tool streamlines how teams save changes, retrain models, and deploy new bot versions to specific applications — replacing a previously manual developer-only process.

Users & Audience

Product teams & conversation designers – needed a simple way to record and implement changes in bots without developer support.
Client project managers – wanted to see which version of the bot was currently deployed in their environment (e.g., test or production).
Internal R&D team – used the tool to control versions and track changes between enterprise projects.
Developers – used the Revision Tool indirectly, as it limited their involvement in routine implementations and reduced the risk of errors.

Roles & Responsibilities

As the lead designer of the Revision Tool — a core platform module for managing bot versions and deployments — I was responsible for the end-to-end design process, from discovery to handoff.

Collaborated closely with ML engineers, frontend and full-stack developers to understand the technical structure of revisions, versioning logic, and environment dependencies.
Defined the MVP scope together with the CTO and development team, identifying must-haves vs. nice-to-haves.
Mapped key revision attributes and designed how users interact with the freeze–train–assign process — aligning with business requirements to keep it as seamless and abstracted as possible.
Created high-fidelity prototypes and designed the full UI, ensuring consistency with Lekta’s internal design system and other platform tools.
Defined the information architecture and data flow between the Revision Tool and the broader platform ecosystem.
Co-created naming conventions and taxonomy in collaboration with the UX researcher to ensure coherence across tools.
Supported internal QA and participated in rollout validation post-implementation.

Scope & Constraints

️The project was completed in approximately 2–3 months — from the initial concepts to the implementation of the MVP.
The main limitation was the time needed to train the model and the logic of the existing revision system, which determined what actually needed to be retrained.
The tool was not used for inter-team communication — the team used external trackers (e.g., for freezes or progress), so the Revision Tool had to remain a purely technical place for publishing changes.
As a project built from scratch, it required reconciling development limitations with future business needs — the first version was very MVP-oriented.
Detailed analysis of differences between revisions (changes in NLU/NLG/Dialog Designer) was removed from the MVP to focus on a stable publication process.
After implementation, iterative improvements were introduced, including the positioning of trained revisions in the list and training success statuses.
The tool was integrated with the rest of the platform (Conversations, NLG Editor, Dialog Designer) to be able to collect all changes and train them after saving.

Process & What I Did

The project was created from scratch as a new platform module, so the entire process covered both discovery and delivery:

I mapped the revision structure

I talked to developers and ML engineers to understand what a revision consists of, how it is trained, and how it should be connected to applications (app = environment + connector + revision).

I identified limitations and dependencies

Together with the R&D team, we determined that the tool could not serve as a communicator between teams (freeze still determined externally), which affected the scope of MVP functionality.

I developed the flow for creating and activating revisions

I drew up use cases (e.g., new revision, linking an existing one, checking the training status) and the conditions that must be met before activation.

I designed the UI structure and interactions

Based on existing platform components, I designed a new home screen that takes into account the full context of revisions: creation time, activation, list of revisions, and applications that use them.

I prepared a working prototype and final UI

I handed over the final design to the developers and supported testing and implementation. The components were created with reusability in future modules in mind.

Outcomes & Lessons Learned

We simplified the process of testing and activating new bot versions. Non-technical users could train models and assign them to applications without dev support.
I designed clear training status feedback despite backend constraints like the lack of real-time progress.
I learned how to turn complex ML logic (NLU, NLG, dialogue graphs) into clear and intuitive interfaces.
The project taught me when to reduce or limit features to avoid tool overlap and keep the experience focused.
If possible in the future, I would add a floating “freeze module” to trigger actions from anywhere in the platform.