How UX Research Improves Product Quality and Reduces Development Time

Benefits of UX research (based on an existing project)

In practice, customers do not welcome UX research: it takes a lot of time, and development is not carried out during this period. However, there are situations where one cannot do without UX. This is exactly what happened with a project that the Andersen team was working on.

A customer asked us to redesign a call center system and optimize this solution for the needs of users. The company wanted to get a prototype right away, but we insisted on conducting a full-fledged study, showing the advantages of this approach. We will tell you what came of it and how we improved the project thanks to the well-coordinated cooperation of a Business Analyst, a Project Manager, and a UX/UI designer.

How it all started: a complex system with a huge manual, just like in the 90s

So, the customer approached us with the idea of ​​a complete update of their call center system. The program was very powerful but didn’t sell well because it looked outdated and took a long time to master. The client wanted to make it more attractive on the market and optimize its functionality.

The Andersen team reviewed the then-current version of the system and saw several major problems:

1. An extremely complex system.

The development of the system started more than ten years ago. All these years, it has continued, and numerous updates have appeared as the system considered the needs of completely different customers and provided excessively wide customization options.

2. Unclear functionality.

The second problem had roots in the first one. The abundance of functionality led to the fact that navigation and the overall appearance of the system were outdated and completely illogical and incomprehensible, which made it difficult to work with the program.

3. A huge useless manual.

In theory, it was possible to deal with the system using the manual, but it took about three hundred pages. In addition, it was written as a description of the functionality, not user scenarios, so it was not easy to understand what to do in a particular situation. As we found out later, no one used the manual.

4. A system without customer orientation.

Despite all the above issues, the system must be user-centered. After all, working in a call center implies an instant response, quick interaction with clients, and performing various operations.

To summarize, we got a complex incomprehensible system with excessive documentation, and it lacked customer orientation. UX research was a must in that case.

Source: andersenlab.com

How UX research we prepared and conducted

To show the customer what problems the system had, the Business Analyst and the UX/UI designer studied the manual and the then-current version of the system and analyzed similar systems and competitors. The first acquaintance with the program revealed problems with navigation and instructions for its use. The team realized that it would be necessary to communicate with different stakeholders (business owners, sales department) and made a detailed plan for further work with specific deadlines and results. Every two weeks we called up the customer’s managers and the PM provided reports and metrics and discussed potential risks and improvements. As a result, the customer knew exactly what they would receive and why they needed it.

It took about two months to study the domain, instructions for the system, articles about call centers, and software for them. It was necessary to correlate what was told in the manual with what was actually in the system. As a result of careful work, the Business Analyst was able to create a mind map, which presented the structure of the system and the main functionality that each of the main entities performed.

During the UX research, we encountered certain obstacles. Let’s talk about them in detail.

User testing is not allowed. How was this issue resolved?

The team needed answers to the following questions: “Who are our users?” and “How do they use the system?” User roles were poorly described in the manual, and therefore we needed to clarify whether we understood them correctly.

Unfortunately, Andersen specialists were unable to conduct user testing because the call center worked with banks, insurance companies, and other organizations. According to security rules, third-party data cannot be transferred to anyone. In addition, due to closed borders, we could not visit the clients in person.

But these obstacles did not stop us as our team had a plan. It was necessary to understand what call center users expected, what offers were on the market, and how companies attracted new customers. During the first call with stakeholders, the Business Analyst, PM, and designer were asked to organize online communication with the end-users of the product. The customer agreed to it, and Andersen employees were able to conduct a general survey and arrange interviews.

User interviews: English is not the first language of the respondents

That was the most interesting part of the job. The Business Analyst and the UX/UI designer created a Google doc questionnaire to explore some of the points. As part of the survey, two approaches were combined. Thanks to a quantitative approach, it was possible to collect statistical data on the use of the system according to user roles. A qualitative method helped us to delve into the details and bring out key insights.

First, it was necessary to check the user roles. The designer, with the consent of the customer, sent a questionnaire to 21 call center client companies: banks, insurance organizations, enterprises, etc. We found out how 139 employees from different structures worked with the program and what their responsibilities were. The UX specialist learned which modules of the system clients used most often. One of the items in the survey clarified if respondents wanted to talk to Andersen experts. If so, they left their email in the form and we scheduled an interview with them.

Interviews were limited to 30 minutes per respondent. A list of questions was prepared for each user role. Participants’ answers were recorded, which was useful for transcription. The interview was conducted in English, which was a bit difficult because this language was not native to our respondents. Nevertheless, the Andersen team managed to collect good insights, which were then presented to the customer in the form of a report.

Source: andersenlab.com

UX research tools and data processing

Many articles tell how to do UX research. But they lack information about what to do with the large amount of data that has accumulated since the interview stage. So, the team used an affinity diagram to interpret the results.

For this project, the affinity diagram was used as a methodology to help structure information. To do this, we identified the main topics covered in the interview. For example, we singled out the “shortcomings of the system” category, where we recorded respondents’ thoughts about shortcomings. Moreover, we considered comments regardless of roles, experience, etc.

Opinions of ordinary users (“there is too much functionality in the system which makes it uncomfortable”) and the administrator’s remark that they cannot customize the system to the needs of their banking company — all these issues were entered into the category of system flaws in the affinity diagram. Thus, conversations with respondents helped us to discover the main problems. Based on these results, we created personas and understood what user problems we needed to solve in the first place.

The second important stage of studying the system, which the Business Analyst worked on, was the creation of BPMN diagrams of the main processes, class diagrams that illustrated the relationships between entities, and status diagrams showing the development of individual elements of the system. Thus, we described all the business processes in a simple standardized language. By looking at the diagram, managers, developers, consultants, and other specialists involved in the process could understand the essence of the system without reading voluminous instructions.

How research helped to shape further work

During the research, the Business Analyst and the UX/UI designer received enough information, based on which they made the following conclusions:

• Main clients are banks and insurance companies

The study helped us to establish that the system was mainly used by employees of banks (13.7%) and insurance companies (12.9%), and other institutions used it to a lesser extent. Therefore, when creating the design, the Andersen team decided to focus primarily on the needs of these customers.

• In-house employees are the main users

Since agents (51.1%) play the main role in the system, the team realized that they should take them into account when developing the product. Other participants (admins — 10.8%, back-office users — 10.8%, users — 15.1%, and so on) also needed attention. However, you need to focus on advanced users familiar with the best UX practices (e.g., Google, Apple, etc.).

• The system is mainly used by young people

Based on the survey, it became clear that the user audience of the program is employees aged 18–30 (67.4%). Therefore, the team did not need to adapt the design for older people (larger fonts, improved contrast, and so on) and could opt for modern web behavior (search, button placement, and the like). After all, following the latest design trends draws more attention to the product in the market and also makes it more intuitive for young users.

• Most users have worked with the system for more than a year

According to the results of the survey, it turned out that clients could be roughly divided into “junior” (one to three months), “middle” (three to twelve months), and “senior” users (more than a year). This data helped to understand that most users (32.4%) were old-timers with more than two years of experience. A slightly smaller percentage of employees (25.2%) had worked with the system for one or two years and 30.2% had been familiar with it for 3–10 months. Thus, it was better to leave the main logic of the system so that it would be easier for consumers to accept any updates to the program.

• The most commonly used communication channels are email, calls, and messages

The analysis of the questionnaires showed the following: to work effectively, users primarily needed e-mail, phone calls and messages, an address book, search, reports, and a control panel. Those were the most used modules, which should have been automatically displayed in the menu and developed in the first place for comfortable work.

What problems did users report?

The study showed what users did not like in the system:

1. It turned out that they were not entirely satisfied with the design: they found it inconvenient. Employees did not like to frequently switch between modules.
2. Agents needed to see all the information about the client with whom they communicated. At the same time, there were certain difficulties with recording information during calls with clients.
3. Most call center workers found it difficult to understand what each function in the system meant and what needed to be done to proceed.
4. The abundance of information confused users.
5. Some respondents wanted to implement additional features such as communication channels (Viber, WhatsApp, and other social networks).
6. The user setup process needed to be simplified.

It became clear that it was necessary to create a new design system. There, functions would be grouped, and buttons, icons, and other complex elements would be displayed with hints when hovering over.

Why did we need personas?

The team’s next step was to create personas based on real user data. As a result, we got two personas which helped us to discuss the flow with the customers.

Then a customer journey map was created. It helped us to define requirements, make positive and negative scenarios, and outline the concept. Later, when design disputes arose, the team returned to this map to coordinate changes with user requests and needs.

The most important thing was that all documents were interconnected and that they were discussed and agreed upon with the customer. Thus, the client understood what the team was doing and why.

What happened in the end?

In the course of work, the PM set up the processes on the project in such a way that the customer had maximum transparency in all systems, access to all materials, regular accumulated progress reports, and SWOT analysis.

The Business Analyst and the UX/UI designer did an excellent job, prepared the results of the study, and reported on the work done. The Business Analyst used personas, CJM, and User Story Map to write user stories and define acceptance criteria. Focusing on the questionnaire, they described the requirements for the design of the system. Also, based on this documentation, they checked the completeness and reliability of the requirements and established the status and priority of individual parts of the project.

After that, the team created UX/UI design. Everything went quite quickly because all the documentation of the study was structured and available. For the UI, analytic data was used. For example, since most users work on a monitor with a resolution of 1200 pixels, the design was drawn for these screen dimensions. Also, as the clients’ monitors were mostly quite old, the team paid more attention to color contrast.

As a result, we got a big and functional system. One of the stakeholders commented on our work in the following way: “We are satisfied with the cooperation with Andersen. The design they presented to us is clear, fresh, and modern, and the UX design is perfect. The specialists turned out to be high-level professionals.”

At the moment, we cannot give statistics on how UX research helped us to improve the system, because the program is under development. It will be possible to test it on users after the completion of the Programming Phase.

But the Business Analyst and the UX/UI designer can conclude that detailed requirements and a clear design emerged after four months of extensive research. On the other hand, the team left many paths open for the system to evolve logically and consistently beyond the MVP.

The results of the UX research allowed us to work out the main patterns of user behavior in the system and create key screens and ways to work with the application. Based on them, the team was able to quickly create new modules to let the product develop logically without conflicting with existing navigation. As a result, developers can access detailed descriptions of any scenario, and users have a system that addresses their needs and preferences.

From the user’s point of view, development, testing, and design are quite promising. No one is interested in beautiful yet useless pictures. It is important that every feature in the application works and helps to make a profit. And to be even more successful, you should consider the opinion of users, based on the results of preliminary UX testing. After all, investing in UX design at the stage of creating a project concept reduces the life cycle of software development by 33–50%. These are just a few of the benefits of successful UX research.