Severstal’s CRM supported B2B sales: working with customers, leads, deals, contracts, and approvals. At the same time, managers had to gather information from different systems, enter data more than once, and work through overloaded forms.
I worked on the product in two roles: as a UX Designer and UX Researcher from December 2017 to November 2023, and then as a Junior Product Owner from December 2023 to December 2025. In a team of around 25 people, I developed solutions from problem research through implementation.
I started with the problem, not the screen
The CRM had many features, fields, and statuses, but that alone did not show whether the system helped managers. I wanted to understand what people were trying to do, what information they needed, and where unnecessary work occurred.
For example, data quality and freshness were problems, and customer information was spread across corporate services. People had to find and transfer the same data manually. Free-text fields led to inconsistent company names and made search harder.
I used interviews, work observations, qualitative and quantitative research, hallway testing, and usability tests. I organized feedback, formulated questions and hypotheses, and analyzed scenarios through task analysis, CJM, and JTBD. User input came both directly and through business analysts and product owners.
Some problems were visible in a single field. Others affected the whole journey: data came from several systems, decisions crossed departments, and even after completing a form, a person might still not know what to do next.
I turned requirements into testable scenarios
Textual requirements did not always add up to a workable process. When I translated them into a mockup or prototype, it became clear which states were missing, where rules contradicted one another, and how one action would affect the next steps.
To validate the solution, I built prototypes in Figma and HTML, showed them to users, and refined them based on their reactions. Then I discussed the design with stakeholders, analysts, and technical specialists. When requirements conflicted, I went back to clarify them before development was complete.
The prototype helped clarify not only the appearance, but the problem definition itself: what data was needed, who entered it, where it came from, and what happened after a user action.
I worked within user roles and SAP constraints
The CRM was built on SAP Fiori / UI5 and connected to other corporate systems. The interface therefore could not be designed separately from the data, integrations, and existing technical constraints.
For example, when working with related companies, users needed to understand the relationship between a parent organization and its subsidiary legal entities. This required accounting for business relationships and technical limits in the system. I developed options and aligned their feasibility with SAP consultants and developers.
Different roles needed different work priorities: managers needed their current customer actions, team leads needed a view of their department, and analysts needed data for analysis. I designed the home page around users’ tasks rather than giving everyone the same set of metrics.
Two workflows that changed day-to-day work
Creating a customer record
Creating a customer record used to take around 20 minutes. I designed a flow to create the record from a tax ID and automatically load the company details. As a result, customer onboarding took about a minute.
Preparing a contract
The original process required more than 100 fields to be filled in across different systems and took 30 days. I researched the causes of delays and designed new scenarios and interfaces. The team reduced the number of fields by about five times and cut the overall contract preparation time to seven days.
This was a team result. My personal contribution was researching the process, designing the scenarios, and validating the interface.
I supported changes after alignment
After handing the solution over to development, I answered the team’s questions, clarified scenarios, and checked that the implementation matched them. I worked with QA, checked the interfaces and functionality, logged defects in Jira, and retested fixes.
After release, I collected feedback. If we found that a scenario did not cover real work—for example, because a required field was missing—the team assessed the change for a future release.
For data work, I initiated discussions about reference data and free-text input, and proposed suggestions and prefill. For integration scenarios, I worked through retrieving information from corporate systems and populating documents automatically. Technical specialists implemented the integrations together with the team.
I tracked usage separately from satisfaction and sales
According to the data provided, the share of managers using the CRM increased from 3% to 60%. This was a team result of the product transformation.
Usage did not mean that every user was satisfied: some people continued to see the system as mandatory reporting. We also could not reliably connect CRM changes to sales growth. This became an important limitation for me: usage shows that people work in the system, but by itself it does not prove that the product helps them sell more.
From interface changes to a product vision
Over time, I defined a broader direction for the CRM. The system should not only record information and control the process, but also help managers work with customers.
The concept I proposed combined customer context with market intelligence, gave users a way to record observations and sales hypotheses, and showed the interaction history: what happened → who did it → what outcome it led to. Another direction was helping managers identify the next step for a customer.
These were proposals and hypotheses for future development, not a description of features that had already been implemented. They required separate validation of their value and an assessment of feasibility.
What I took away from the work
The CRM taught me to look at an enterprise product from several angles at once: the user’s task, the business process, the data, and the platform’s constraints. A good solution did not start with adding another feature, but with understanding which work it should remove or simplify.
I worked on scenarios from initial research through implementation review: defining the problem, making it testable with a prototype, clarifying requirements with the team, and supporting delivery. I also distinguish team outcomes from my own contribution and delivered changes from ideas for the product’s future.