Designing the functionality of a back-office product based on practical experience

Hi! My name is Nastya, I am a UX designer for internal services at Lemana PRO (Leroy Merlin). My team and I are creating a very complex internal product, and it is critically important for us that the services and sections in it are understandable to colleagues and easy to use.

Therefore, we do not need research for the sake of research. We need to understand what data will help improve something and, perhaps, even make a breakthrough or a leap, and what will lead to nothing, and the company's resources will be wasted.

Today I'll talk about our processes, as well as the research and tools that help design a product.

About the product

TechGate is the portal of the Technology department, where product teams can track and manage deployed resources, order technical binding for their product, from databases to hybrid cloud. I have been working on this product for more than two years, and the number of internal users coming to it is constantly growing.

TechGate is conditionally divided into 3 parts:

• Catalog of serviceswhere most of the functionality is configurators of varying complexity, through which users can independently deploy the infrastructure necessary for their product. For example, configurators for DevOps, DBaaS, YandexCloud, OpenStack services, configurators for support activities, work with microfrontends, etc. This section also includes summary tables, general pages where you can view information on your requests, calculators and entry points to other services.

• Analytics sectionand also FinOps — a wealth of tables and summary information needed by teams to budget and track their expenses and costs.

• Section with information for teams for more than 800 products. It allows you to find out what is included in the product, what services are connected, what resources and connections are available, and also see what optimizations the portal offers. Plus, the card displays which carbon footprint at the product.

Our product is internal and complex. The user must have a certain set of characteristics and skills. This is not a case where even a grandmother should understand the interface. This is a story about flying a plane, when you can’t fly without certain skills. There are difficulties and conditions that cannot be ignored.

How we create and design solutions

We work consciously, relying on data obtained through the use of various tools.

Below I will try to describe the process, how we organize the work and what happens next,
I will share my practical experience. What tricks do I take into account for the effective formation of a minimum set of methods and tools that help to go through the iteration cycle when designing solutions in working on tasks. And I will also tell you how I work with the data obtained.

What we will talk about:

1. Product complexity and specifications, “corridor of limitations”.

2. Target audience and the tools we use to be flexible.

3. Competitive analysis, how to collect it for internal products.

4. Working with the received data: tools and examples of process organization.

Some design challenges and tools to solve them

When designing complex, loaded solutions, there are problems:

• often these are closed systems with limited access;

• it is necessary to develop a solution according to our business requirements; it is impossible to fully use existing solutions available on the market;

• limited number of methods and tools for collecting information.

These difficulties can be solved using several tools.

Sometimes it is enough to simply digitize something that already exists, freeing specialists from routine work. In our product, these are parts related to configurators and displaying information on the front end, which previously required several days to find.

Sometimes it is necessary to refine something taking into account what already exists. For example, refinement of “box solutions”, integration with systems that we cannot influence.

Sometimes you need to design something new, but there is no clear idea of ​​what it should be. In this case, we rely on the results of studying the target audience (TA), needs, “pains”.

How we studied the target audience, what tools we used

Our product has an interesting and complexly segmented target audience.

We could immediately see a polar division of users into two groups: “I can tell you how to do it and why, how to optimize it and what feature to add, what might follow” and those who are not very immersed in the subject context, have never encountered our tools, do not know the specific terminology and do not understand what opportunities we offer.

Another part of the target audience is made up of users who need to be taught to work with the available capabilities. They are not experts yet, but they are not newbies either. They come to the portal to cover their needs: order resources for the product team, add administrators, get product support and support for the product team via the support line.

Looking ahead: Subsequently, we divided these groups according to needs – introduced sections, differentiated functionality, added hints.

Our goal is to study the needs and ensure that all segments of our target audience successfully cope with their task.

In order to fully analyze the target audience, we used various research methods. For certain reasons, it is difficult to recruit a sufficient number of respondents for quantitative research, so we mainly conducted qualitative research. And with them, everything is not so clear-cut, because users have different experiences of interacting with the product.

As a result, we used surveys, observations, and interview series. Surveys segmented our target audience and identified those who knew about us — had experience of interaction, as well as those who were our potential users, but had not yet come to us. Observations identified the product's problem areas and how different roles interact with the product's capabilities. A series of interviews were also conducted, I will tell you more about them.

We conduct a lot of interviews, work with feedback and support requests, try to hear and understand the user. And then we try to impose a solution to his “pain” and his wishes on the reality of the business process and technical limitations, thus obtaining the best product.

Expert interviews help to collect and process information for designing solutions based on expert opinion. After that, we test prototypes and intermediate solutions on our target audience. At the same time, the focus is not always on the experts with whom we conducted interviews. In fact, it turns out that the experts check whether we have correctly understood the process and technical features. And from the rest of the user segment, we receive, identify “pains” and problem areas that concern user interaction with interfaces.

The process goes cyclically through several iterations until we get the optimal solution.

In terms of technique, an expert interview is no different from a regular one:

1. We set the goal of the research – why do we need an interview?

2. We define the target audience and set research objectives.

3. We form an interview structure with several branches of possible answers. Branches of possible answers are something like a plan “B” in case the user answers a question differently than we expected. We must not get confused, but still clarify the details with him and continue the interview.

4. We collect the necessary attributes for conducting the research. We determine the format (online or offline), prepare a list of respondents, and draw up an agenda for the meeting. If the presence of another specialist is required for the interview, we agree on this. We check the equipment, links, access, etc.

5. We conduct interviews. In my experience, it turned out that this is a combination of directed and undirected types of interviews.

It can be said that studying the target audience never stops. We regularly monitor how the audience grows and changes, how satisfied it is with the interaction with our functionality. We do this through support, incoming requests for enrichment and development of the portal, SCAT surveys, and collect various metrics. We compare the data and conclusions we receive once every six months — this helps determine how much we can change and how to help the user. Subsequently, we adjust and improve the solutions we develop.

How we got to know our competitors and conducted a comparative analysis

It is necessary to clearly understand who and to what extent is a competitor, and who is not. This is necessary to find the key indicators of competitors and compare them with your own, keep up with the times, work out growth points, be more convenient and attractive for internal work and support of product teams.

The first difficulty is of a general nature: to determine the criteria by which the analysis will be conducted. It is necessary to understand the “attributes of competitiveness”, their sufficiency and influence, aggressiveness and potentiality.

The second difficulty is that information about similar products is closed. Finding direct competitors or a close reference is very difficult. Not only is it necessary to find something similar, but it is also necessary to compare how much this similar product is our “competitor”. It happened that when comparing attributes, a similar product was not a competitor.

In fact, we need to compare the “first-complexity solution” with the “second-complexity solution” and determine, based on the selected parameters and attributes, whether a similar product is our competitor or not.

There are several ways to get an answer to the question “what about the competitors?”:

• from articles or videos published by competitors themselves;

• from demo recordings, at face-to-face closed meetings, where companies that sell their product can talk about it;

• from trial versions, if any;

• from personal communication: networking to the rescue.

To analyze competitors, we collected information in all these ways. Plus, we looked for technology portals that could be called analogs, and looked not at the entire product as a competitor, but at its parts, functional blocks.

That is why we often conduct competitive analysis not “product by product”, but “function by function”. We constantly monitor the market and its development, on the basis of which we identify our needs, initiate new research and enrich our backlog.
I have told you about the difficulties. But we also have an undeniable advantage: since the consumer of the internal system will not go to a competitor, we are, in fact, a monopoly. This allows us to make a customer-oriented product at our own pace, without chasing the market.

How I work with the received data: tools and examples of process organization

When forming proposals for solving problems of users and businesses, when working on tasks, I use research methods, business TRIZ tools, and combine some of them depending on the incoming conditions.

It is important to be able not only to obtain data, but also to process it correctly.

I collect all the information — references, system screenshots, interview results, feedback from teams — on the Miro board, then process and form the results. By the way, members of different teams can extract and bring information — the more input data, the better.

Then I analyze, synthesize and create the artifacts needed for a specific purpose. To do this, I use various data tools: Affinity map (Affinity Diagram), User Story, CJM, JTBD, composed several times Value Proposition, for further work and prioritization — RICE framework and MoSCoW methodand also binary prioritization.

For example, I conduct text coding of interviews and form Affinity mapthat is, I present the received information in the form of semantic blocks. In such a representation, one can clearly see group sections by topics, and in them – the number of problems and proposals. Moreover, after text coding and processing of information, it is detached from the respondent's personality and only the information received is analyzed.

How it looks. I transfer information about groups to stickers, simultaneously dividing it into three semantic blocks: pink – “problems”, yellow – “neutrality”, green – “suggestions”. The names of the groups are on blue stickers.

The blocks are formed by thematic/semantic groups, which I set myself depending on the purpose and objectives of the interview or the semantic context of the product. It turns out to be a kind of segmentation, where you can quickly view the number of triggers in any of the segments, see problems and suggestions.

Interesting observation: If respondents see after the interview that their “pain” has been worked through, they prepare better for the next interviews, formulating their description and clear proposals in advance.

Several times I combined co-design and expert interviews, when respondents move interface elements themselves during the conversation and comment on their actions. This helps to understand how an expert or user imagines the nesting of objects and the hierarchy of relationships.

It can also be useful to combine preference assessment and field research. If I manage to identify a pattern during observations, I allocate part of the interview time in subsequent iterations to assessing solutions that can improve the product based on this pattern. That is, the following respondents not only go through the interface, but also evaluate the proposed options for completing it.

The most important thing

It is important to understand that you should not conduct all kinds of research and apply all existing data analysis methods at the same time. No business needs research for the sake of research, this is targeted work that requires a lot of time and resources.

The most valuable are the qualitative conclusions – they allow us to understand what needs to be done now, to form a picture of the product/project/task, and to identify existing limitations.

Regardless of the volume and complexity of the incoming task, it can always be decomposed, or broken down into parts. The iterative path allows you to avoid overwhelming research, isolate a part of it and stay within the framework of the product or project.

And that's all, see you in the next posts!