how interaction works in a systems approach
Hello! My name is Nastya, I am a UX designer in the technology projects department of Leroy Merlin. We are developing an internal technology portal – this is a united front where product teams can receive services from other teams in Self-Service mode. We provide a tool for managing the product infrastructure, formulate recommendations for cost optimization and aggregate all information about the product in one place.
Today I want to talk about how a UX designer can work with user expectations and system limitations in order to get the most effective service or product.
I’ll start with the context and tell you why this topic is important, including for “near-technical” specialists.
User experience and the process of its formation
To create a user experience, we must understand the following:
What is happening around the product, how it is integrated into the surrounding world: what systems and supersystems it comes into contact with, how it interacts with them, etc. In fact, in order to become a user, you first need to learn about the product and get a link to it. At the same time, a potential user often chooses between several options at once, and you need to fight for his attention.
A need that the user wants to fill with the product. If a user chooses a product but cannot quickly and easily solve their problem with it, they leave.
In fact, the formation of user experience begins even before the interaction with the product begins – from the moment the need arises to solve a specific problem. At this stage, we can influence the user’s decision to use our product/service. Marketing strategy, advertising, easy onboarding, ease of use, positive reviews, etc. are aimed at this.
With internal systems, loaded with interfaces, and back-office services, the situation is most often different. It is as if the user is being told: “Go there, and only there can you solve your problem.” He has no alternative, which means there is no stage before direct interaction, the moment of choice, comparison and acquaintance.
At the same time, the experience is formed not only by the interface screens, but also by a whole complex of interrelated factors that surround the product. Brand, competitors, usability, inclusivity, existing experience, taste – all this affects the impression. And here it is important to understand that the experience gained from interaction is the success (or failure) of the entire team that works on the product or service. But a user experience specialist is a UX designer, UX architect or UX researcher. During my work, I came to the conclusion that the area of responsibility of a UX specialist is not limited to conducting research and assembling a layout, but covers a wide range of conditions and is intertwined with a variety of processes. After all, the user interacts with the finished product/service, and not with the layout.
What is important for a UX designer to consider when creating a user experience?
Let's consider the picture of the world from the user's side. His task is to satisfy his need. And once the choice fell on a specific product, there is initially trust in this product. If we draw an analogy, then when we come to see a doctor, we believe that this doctor will competently advise us, and then make the correct diagnosis or refer us to another specialist. The brain works in much the same way with digital products: when visiting a service to order resources, the user expects to receive either the resources themselves or instructions on where to look for them.
When interacting with a product, the user immediately begins to form his own experience: he focuses on subjectively important aspects in order to understand whether he can satisfy his need and whether he trusts the service. This is influenced by the veracity and relevance of the information displayed, the effectiveness of the tool, the availability of the necessary functions, etc.
The user does not care at all why incorrect data is displayed in front of him. Sometimes he doesn't even realize that the data is wrong. But if reality and data visualization diverge, the formation of a negative experience is inevitable. No one will figure out why the data is incorrect; the user will simply stop trusting the product.
Therefore, it is necessary to consciously design solutions and create layouts. Team members, in particular the designer, must understand how the data comes in and how the reality of the processes correlates with their visualization. For what reason something might go wrong, who is to blame for it, who might be affected, what risks exist and their consequences, how to identify and fix it as quickly as possible.
What do you need to know and what to pay attention to when creating a product (or part of it)?
For myself, I have identified several top-level reference points that you should pay attention to, and added examples that will help you understand the vector of thinking.
Whether the product is independent or integrated into another product. Are there connections that need to be taken into account? For example, a bundle with a boxed solution, other products, etc.
Monolith or microfrontends. Understanding the differences between them will help you determine how they affect your product's scalability, support, and deployment.
How does information arrive at the front: are we the data holder or the data comes via API. For example, what needs to be shown to the user if the API is not available, can we modify the API with another team by adding the fields we need into contracts, etc.
How information is received: asynchronously or simultaneously. How requests are grouped, what comes in them.
How is data updated? For example, do we display data online or “go” for it once a day? Or do we change it manually in administrator mode?
Element loading speed. Depending on the answer, you can think about the following solutions: data that takes longer can be placed at the bottom; make a form with step-by-step loading; cache part; display onboarding, beautiful loading or stubs until the elements are completely loaded, etc.
Is there plurality? How much data should be loaded into the interface at once. Here you need to think about how many elements there will be: 10? 100? 1000? Will there be a default limit? In addition, it is important to understand how the page should behave when the specified conditions occur: vertical and horizontal scrolling, several types of elements and their groupings, opening in a new tab, gradual loading, etc.
How the user should interact with the interface, what restrictions and assumptions there are, what functionality is available to him. Here we are talking about a role model and possible limitations. For example, the application may not be available in a certain country. Or some users should not be able to edit the content of a particular interface.
What are the technical limitations that need to be taken into account at the solution design stage. For example, field validation, corner cases, maximums and minimums set for processes. It is important to consider what we can influence and whether we need to map something additional, connect it, etc.
Why does a UX designer need to know this?
The answer is simple: it is better to take these points into account at the design stage, so as not to waste time on editing and reworking ready-made solutions.
Ignorance of this truth does not exempt you from the consequences.
Layouts designed in an ideal static representation may fall apart when connected to loaded product data. This will increase the number of errors received, as well as the time it takes to identify and correct them.
If systems capabilities and technical limitations are not taken into account, developers can cut the design into pieces and throw away most of it.
In this way, it will be possible to optimize time and costs so as not to go through new rounds of testing the feasibility of a product solution. You will still have to go through several circles, but there will be no longer ten, but four (the values are relative).
In addition, this way we can get rid of some of the problems:
irrelevant data in the finished product/service;
delays in detecting and correcting errors;
and, as a result, low quality of the product and the formation of a negative user experience.
Solutions expressed in mock-ups and prototypes, changes in internal and external processes cannot live in isolation from systems. The ability to build connections is a useful and necessary skill. It is important to find a balance between streamlining the overall information flow and providing enough flexibility for users to tailor their experience and integrate it into processes.
Understanding technical limitations and capabilities helps to communicate with the team in the same language, offer and build “live solutions,” and optimize time and resources. It is important to make a reservation here: we do not need to know everything deeply and thoroughly. We must be in the overall context, know the limitations and understand what the output will be. Then our solutions will be of higher quality and more efficient, product delivery will be faster, and the creation of user experience will proceed according to plan.
Thanks to those who read to the end, I hope the article was interesting and useful. See you again!
