Simplified Primo RPA AI Server setup: customers configure the AI service without an implementation team

Only experts could handle the configuration. This slowed down sales

The AI Server is deployed on the client’s internal servers. The product was actively tested, and the feedback revealed an unpleasant truth: only experts and the Primo RPA implementation team could configure it. Every new client consumed hours of technical support. The product was losing its appeal and didn’t scale well.

I started by getting to know the team and the configuration experts. I divided the scenarios into primary and secondary ones, created a visual representation of user behavior, and worked with the development team to identify areas where the interface could be simplified. I had already worked with AI and similar web platforms, so I quickly got up to speed on the subject matter and was able to speak the same language as the development team.

Constraints

• Customers were already using the product. It wasn’t possible to halt development and completely rebuild the interface.
• Changes had to be incorporated into the release plan; no one allocated time for a separate “redesign sprint.”
• Strict tech stack: Ant Design on top of React, styled after Hope UI. We only created new components as a last resort; first, we made the most of the existing library.

Navigation was confusing: project sections were mixed in with the main menu

The service used a layout common to admin panels: a sidebar on the left, content on the right. Space was wasted, and when opening a project, navigation through its sections was intermixed with the main navigation. Users got lost.

I moved the main navigation to the top and condensed it. The content now has noticeably more space, while the layout remains familiar. Projects now have their own navigation that doesn’t overlap with the main navigation.

Dataset Editor: the screen where users spend most of their time

This is where users spend most of their time. Annotating fields on hundreds of images is monotonous work, but the quality of the data used to train the model depends on it. The previous editor didn’t fit the overall style, looked cluttered, and made working with fields confusing.

I broke the editor down into microscenarios, organized them by priority and interdependencies. Together with the team, we designed a smoother and more intuitive user experience, reserved space for future features, and aligned the design with the service’s overall style.

The page became symmetrical. Almost all the space is devoted to the image being annotated, and actions are grouped by panels: the desired function can be found quickly.

For advanced users, I’ve added a “Full Screen” mode. The side panels collapse, and you work using keyboard shortcuts and the bottom panel. This is a lifesaver on small monitors.

Dozens of fields on a single scan, without sacrificing document space

Related task: Configure unique field settings for the dataset. A large area is needed for the document scan, with dozens of fields, each having its own types and dependent settings.

The interface turned out to be compact. The mechanics aren’t immediately obvious at first glance, but after a short learning curve, working with it becomes quick and comfortable.

Training cards: a pattern that has spread throughout the product

After annotating the dataset, the model undergoes fine-tuning. We analyzed all user actions and explored several page layouts. We settled on a card feed.

At the beginning of the feed is a configuration card: the annotation results for the active dataset, parameters, and the option to start fine-tuning.

A separate card appears for each running process. You can start multiple processes with different parameters and compare which configuration performed better.

Cards can be collapsed; the title and status remain visible in the header.

Patterns from these cards were later applied to other sections of the product. It became easier to maintain a consistent style.

Long processes—in a separate tab

Some tasks run in parallel with other work. For such scenarios, a modal window opens on a separate page.

Meanwhile, a placeholder with a button to navigate to the process remains on the project page.

What I Decided Not to Do, and Why

• I chose not to disable buttons on individual pages during active processes. A modal on a separate page is technically simpler, and progress is visible in the adjacent tab.
• I didn’t create new components except in extreme cases. The ready-made Ant Design library sped up development and kept the interface consistent.
• I didn’t remove the editor’s side panels entirely; instead, I made them collapsible. Beginners need on-screen hints, while advanced users need as much space as possible for their document.
• I didn’t set up a separate design system. The product already had a framework, so I passed links to the existing user flows in Figma to the development team.

Handoff to Development

Once a week, we discussed the design with the team: the task list, priorities, and deadlines aligned with release plans. I went over the details of the mockups one-on-one with the front-end developer and provided feedback after the layout was completed to ensure the result matched the intended behavior.

Result

• Requests to the implementation team during the setup phase decreased by 40%. Clients complete the basic setup on their own.
• 7 out of 10 new clients set up their first project without technical support. Before the redesign, it was 1 out of 10.
• Setting up the first project: from ~3 days to ~4 hours.
• Over 30 screens were redesigned: navigation, dataset editor, model training, and data import.
• We established design patterns that allow functionality to be expanded without major rework.
• The company hired a second designer. I brought her up to speed and oversaw the results; after she became familiar with the project, it was entirely transferred to her responsibility.

Conclusions

• The rigid framework turned out to be an accelerator rather than a limitation: the ready-made component library allowed us to focus on scenarios rather than pixels.
• The most valuable insights came from configuration experts. Next time, I would involve the implementation team even earlier.
• Handing the project over to a new designer confirmed that the established patterns work and can be explained and maintained without the original author.