Why is moving to new software such a pain for employees? What to accept and what can be improved
This article is for those who have at least once organized a move to new software at work. And it doesn’t matter what it was – Notion in a startup, Jira for development, or a pack of separate SaaS systems.
In the process of life and growth, any company has to shuffle, merge, change systems on which team processes have already been established, and this is always unpleasant.
As a specialist with ten years of experience in implementing B2B systems of various formats, as well as a product (UI/UX) designer, I will try to formulate the pains of the general relocation process and common mistakes. I'll tell you what can't be avoided and what can be done better.
Hello, my name is Timonov Maxim, I am a design director. As a product designer and lead, I developed both projects from scratch and customization of finished products or entire wrappers for them. Now I act as the design director of the BPM system “First Form”. We make a low-code designer for setting up business processes of any complexity.
In one line – a VERY brief summary of the article: The best way to complicate the transition to new software is to incorrectly structure the implementation team and the requirements gathering process. It is worth working not according to a waterfall, but according to Agile with periodic CustDev with end users. |
Now let's take a closer look at what this means.
How to complicate the transition to new software at the start of the project
I will consider a situation in which you have already chosen a solution and came to the vendor or integrator for it. The search for the ideal software itself is a long and complex process, which requires a separate article.
So, this is what happens every other time during the first meeting with a client. The IT director or manager responsible for purchasing software comes to the vendor. None of them are the end user of the system. The last time we discussed processes for producers, the implementation manager and two c-level managers from other departments came to me.
We discuss the requirements – usually at this point the working group already has some expectations, formed on the basis of their own or others’ experience. But the opinions of end users are still ignored.
Then we set up the system, go through the PMI, launch users and – what a surprise – they don’t like everything. And what happened?
5 common workgroup problems
Here is a short list of pitfalls where moving to new software falls into. Later in the article I will reveal them in detail.
In these examples, the customer is any manager who dictates the conditions that are critically important for him to observe when setting up a specific process.
The customer was stuck on formal requirements.
If the client insists on “that’s right THAT’S IT” and does not want to delve into the logic of the system, the contractor will sooner or later give up and cover the requirements with crutches. But the end user experience will be the same.The dialogue is on
aviandifferent languages.
Each system has its own concepts, and it is important to check the terms on shore so as not to confuse the customer and the contractor. In the “First Form,” for example, signatures are specifically a signature for a task or a digital signature for a file. And in another product from which they switched to us, this was the name of the entire process of agreeing on contracts, that is, the entire business process of the task.The customer piled on “unnecessary” requirements.
You need to start small, it seems obvious. But some people immediately describe complex conditions in the requirements, many statuses and automation for all occasions. Moreover, each new condition multiplies the time and cost of implementation, and this delays the receipt of value here and now.Care in cognitive distortions customer teams.
Everyone has heard at least once “Everything is bullshit, we don’t like it, we’re used to it differently.” You can get out of this message through metrics, user stories and reference examples. Direct discussion in the “We like it” format only creates conflicts.Evaluation of experience for employees. The phrase “I don’t understand, which means the employees won’t be able to figure it out” is a subjective opinion with a cognitive distortion-generalization. At such times, we usually suggest asking 10 employees to rate the usability of an area of the system on a scale of 10 (based on CES/CSI metrics). The average score is 7-9 points, and the work group leader agrees.
But why is it so hard to get used to something new? Problem with the product?
Besides the fact that in B2B end users usually forget to ask what they need, it’s also a matter of brain function. The power of habit in a routine process makes completing a task much easier. But to build new neural connections in adults, you have to work hard.
It follows from this: moving to new software will still be difficult. What can be done is to take into account previous work experience as much as possible.
If at the implementation stage all communication between the vendor team and the receiving party comes down to unconstructive complaints, escalations and attacks like “You can’t hear us,” you can cool down the discussions using the following UX metrics:
CES (Customer Efforts Score) is an index of the efforts that need to be made to solve a problem in the system.
CSI (Customer Satisfaction Index) is an index of satisfaction on a specific section of the interface.
CSAT (Customer Satisfaction Score) is an index of satisfaction with the entire system.
How to count them has already been written exhaustively Here.
A simple example: over the years of work, the team has learned that the boss writes priority tasks in an email with the subject “To do,” and confirms them with the phrase “Looks good.” If we move to a new system and abandon mail, the process breaks down. Yes, the new solution may have priorities, statuses and the ability to accept work by signature. But this is still a completely new experience for everyone involved, and in this case the grass will be greener in the mail. And the “hurttest” person will be the leader. He has neither the time nor the energy to get used to new names, buttons and stages. And if its needs are not taken into account, a conflict may arise with the ideologists of digitalization. |
Therefore, the closer the new experience is to the previous one, the lower the cognitive load and the easier it is to move to new software.
How a vendor or integrator can improve the transition to new software
So, what can and should the implementation team take on?
Gather work group requirements
We must both create a list of all basic user stories and clarify the technical criteria. Without the first, we will not be able to understand exactly how the function will work and how it should look in the interface, and without the second, we will not be able to make critical fields and settings. Below I will give an example of such a situation.
Set up interfaces and processes, trying to take into account past experience, if any.
I justified the importance of this above. Example – employees worked with tasks in Outlook, where in one part of the screen there was a list of letters, and in the other the contents of the task.
It’s not just habit that plays a role here, but also the successful layout of interface details for a specific activity—for stream processing, it’s really more convenient to open tasks in Outlook format. Modal windows would overlap table fields and take time to hide/open.
The second example is that the team worked according to Agile and carried out work in Trello. It is more convenient for them to open tasks from Kanban in a modal window in order to see only the task itself, without other interfering elements. That is, on the contrary, visual isolation of information is valued more.
Requirements for the load and density of information in the interface strongly depend on the role and competencies of the employee. Here is an approximate formula:
The simpler the employee’s role, the faster he should get used to the system and begin to work fully in it. To do this, the interface should be as familiar, understandable and linear as possible, and mastering it should not require long, expensive training courses. And vice versa – the more complex an employee’s position, the more data and manipulations with it he produces. And here you can already give time for immersion, but provide role-based access with delimitation of information. And, of course, establish an onboarding process to work with the process. |
MobileFirst
Even at the stage of choosing a product, you should consider whether you plan to use the system not from a desktop. It is worth considering what devices these will be, for what roles and for what part of the process. Then we can implement functions for those who often work outside the office. For example:
Leaders. A secure enterprise application allows them to receive automated notifications about problems and issues outside the office. For example, while the commercial director is sitting at negotiations without access to a laptop, new sales people can lose the sale. On-site and field employees: couriers, inspectors, warehouse workers. For one client, we set up reading barcodes on documents through the application. Archive workers receive boxes with documents for storage, scan the barcode and can control deadlines through the system. On the desktop there is no reading function, because it is not needed there. Office employees. Through a mobile corporate application, they can issue sick leave, enter the results of field work into the system, and attend a planning meeting from a traffic jam. |
System branding.
This is another layer that affects satisfaction from working in the company and the HR brand. The vendor can specify colors, fonts, logo, icons and illustrations on certain screens. A separate option is a brand app in stores, which will have its own update cycle and design.
How a customer can simplify the transition to new software
Not everything depends on the vendor. Now let's see what you can do.
Ask employees for their opinions
Mostly, companies do not have Agile coaches and other specialists who can regularly analyze and optimize business processes. Therefore, each department and between them develops a unique experience of working interaction.
The goal of employees is to do their job and meet KPIs. Collect their usual practices and transfer them to the vendor in a raw interview format or in the form of already processed conclusions. Form a test group of employees that you can contact regularly. This will significantly increase design accuracy.
One client sent us an Excel spreadsheet with a list of recipients of various documentation as a sample. In one column there was a format code “DG 241206-00-2432”, but there was no explanation. We set up a test process based on primary requirements with a code field and launched employees. They were not happy. It turned out that the numbers “00” in the middle of this code denoted a group of top managers. In Excel, filters were configured for a set of groups and conditional color formatting, which was not described in the requirements. No one except the performers knew about this convention, but a whole business was based on it. |
Optimize first, automate later
As I mentioned above, with redundant criteria for a new process, it’s easy to get bogged down in multi-layered setup. 10 statuses and 20 approvals are reasonable for a complex and risky construction project with a cycle of a year or two. But not for tasks that must be completed in two business days.
One of our clients collected requests for processes from the customer – the HR team – but did not analyze the criticality and did not allow us to interview users. So, on the list there was an item that in the middle of onboarding the CEO and the entire HRBP group joined as observers. They started receiving all types of notifications about the movement of tasks and their changes. Notifications have gone from a useful tool to an incomprehensible mess of logs. Really important messages could not be found in it; the system became “bad and inconvenient.” Only the escalation of the problem and the removal of demands from the first manager helped to correct the situation. |
The vendor can automate any little details and conditions, but do you need it? Too much control, information, or asking for action will cause confusion. Therefore, you should first put the requirements in order and abandon conditions that have little effect on the final result.
Look for employees in the company who are interested in a new solution
Typically, a working group is involved in replicating the system in a company. This is their task – to show an example of working with the system
But for the best result, you should look for those in the company who are really ready to use the new solution, and collect their feedback on the system. It is advisable if these are beginners who did not have time to catch the generalization “It was better before.” They will not take the move to new software with hostility.
This graph shows the spread of an innovation over time. In the beginning, the team will have a minimum of employees who will want to use the solution without any problems, and it is they who need to be supported. Ideally, there will be an opinion leader among them whose experience can overcome bias.
The early majority will follow the innovators, and training will help push the “lagging behind” and immerse them in the tools. And start building new neural connections and habits.
Instead of a total
Moving to new software in B2B is like changing an apartment where the entire team is children. Their opinion is not key in the first stages, but they need to get used to the new environment. And if this causes problems, the situation can escalate to blocking the department’s work and conflict with the vendor due to a “poor solution.”
The same goes for corporate systems. Employees learn to use new tools, build new agreements, and at the same time try to remain effective under stress. And if you don’t pay attention to their needs and don’t help them figure everything out, hysterics will happen.
I will be waiting for your comments, questions and implementation stories!
