EPAM Systems
15 months
UX/UI design · User research · Discovery · Design ops · Cross-product strategy
Sole UX/UI designer (me)
Product dev, QA, BA teams
Product owners
Process managers
Portfolio leaders
As the sole designer of the Performance Evaluation Suite, I was responsible for end-to-end design across all three products, ranging from hands-on delivery to cross-product strategy.
Three internal tools supporting employee performance management, built at different times for different needs. Expectations for setting goals, Feedback for collecting peer input, and Talk for documenting it during 1-1s.
Each tool moved at its own pace and answered to its own pressures. Talk was aging and needed a technical overhaul, Expectations had no defined process to begin with, and Feedback ran as an unstable standalone tool. Left alone, they risked becoming three disconnected pieces of what was, for the employee, one continuous process.
I addressed each product's challenges: supported Talk replatforming, aligned stakeholders around a vision for Expectations, and stabilized Feedback's process. But more importantly, I carried context between them. That continuity became the seed for a shared vision concept: the unified Employee Performance Tool.
The concept won stakeholder buy-in, and its first step, a unified evaluation scale, shipped before I moved on. The vision it pointed toward became the company standard process, and then showed up in my own inbox.
Evaluation Suite is part of EPAM's People Programs Portfolio — three tools that together take an employee through the performance management cycle: Expectations for setting goals, Feedback for collecting input on an employee's work, and Talk for turning both into an actual conversation with a manager.
On paper, that's one process. In practice, each tool had been built at a different time, for a different need, and was now facing a different kind of pressure. My involvement with the suite didn't start with a plan to design all three, it grew into that, one shift at a time.
I joined focused on Talk. The tool was already used daily by thousands of Resource Managers and supported important business processes, such as compensation. It was old and needed technical replatforming.
My job was to replatform it quietly enough that no one noticed a disruption. That meant protecting the flows and patterns people already relied on, while working through a real constraint: very limited developer bandwidth, so only the most important things could get built. So, I prioritized features against that constraint together with stakeholders, and used user feedback to separate what was essential from what could wait.
The replatform landed cleanly. No wave of complaints, no disruption to a tool people relied on daily, just a smoother version of something that already worked.
Once Talk had moved through its replatforming and settled into a steadier maintenance rhythm, my attention shifted to Expectations. It was a tool meant to support a goal-setting process that hadn't actually been defined yet. There had already been one attempt to launch it, and it failed for exactly that reason. So, the scale of the problem here turned out to be bigger than a new interface. I decided to start over with discovery.
First, I ran research to understand what people actually needed.
Then I mapped that onto an experience map, to ground it in how people actually experience goal-setting.
And most importantly, I ran alignment workshops with stakeholders to shape what the process should even be.
It took several rounds of concepts before stakeholders converged on both a vision and a process, and that concept got approved. We never got to bring it into production, because company priorities kept shifting and a bigger change was already underway. Nevertheless, what we achieved was a clear, aligned vision for Expectations, and that concept would matter again later. I'll come back to that in a couple of sections.
As the company priorities evolved, Feedback became part of what I owned too. Feedback collection had been an established process at EPAM for years, but it had grown as a standalone experience, disconnected from the rest of performance management. The product needed to evolve, but the team that had built it was gone, and delivery had collapsed as a result. So, the first step was rebuilding the basics so the product could actually move.
I set up a design delivery process and rebuilt stakeholder communication that had broken down along with it. Design files stayed current again, testing got easier, fewer errors made it downstream, and the AI-assisted features we'd been building shipped to production in solid shape. That stability is also what made it possible to start folding Feedback into the bigger performance evaluation process without disrupting the people already relying on it.
By the time I was responsible for all three products, one pattern was hard to miss: Expectations, Feedback and Talk weren't really three products. They were three views into one employee's performance story that no one experienced as connected.
That observation led me to a conversation with the product owners about whether the suite should behave like one. Out of that came a concept I developed for a unified Employee Performance Tool, a single view pulling everything together, so users didn't have to piece the picture together from three separate tools. The earlier approved Expectations vision fed directly into it, and Feedback's newly stable process meant it could plug in without dragging its old instability along.
The concept was met with strong stakeholder buy-in, because it clicked with something they'd each been circling for a while. That turned it into a strategic direction: move all three products toward this vision gradually. We started with one concrete step, unifying and synchronizing the performance evaluation scale across the company.
I moved on from the project shortly after the unified evaluation scale shipped as the first step toward the shared vision. Over the time I spent across all three tools, I managed to deliver what each product needed and to shape a strategic vision for the suite as a whole.
I stayed at EPAM, though, and being a Resource Manager myself, I got to watch the products keep evolving firsthand, gradually moving toward the vision we'd shaped together. The performance management process we'd aligned on became the company's unified standard, and I ended up using it myself to run performance management for my own team.
Back