goals, objectives, roles, competencies
Many experts agree that User Experience Design in IT solutions created for business users is, firstly, specific, and, secondly, unfortunately, often simply terrible. Let's try to figure out why this happens – and how this situation can be changed.
Why is UX Design needed in B2B and why is it special?
UX Design as a whole is a relatively new field of knowledge, but it is quite saturated with information. There are textbooks, educational programs, and an abundance of vacancies and resumes on the labor market, with varying degrees of detail and systematicity describing the tasks and necessary competencies. But the main emphasis is usually on the B2C sphere, creating a product for a specific (more or less wide) audience with very specific goals of increasing engagement metrics, conversion, etc. B2C UX design, accordingly, focuses on consumers, empathy, emotional triggers; the visual aesthetics of the final solution, the use of patterns similar to marketing, advertising, fixation and mood management become very important.
In turn, B2B solutions, especially those implemented in projects, are extremely rarely developed with the involvement of a UX designer. A UI designer, that is, roughly speaking, an “interface artist”, is found in projects incomparably more often, although also not in all; the name of the role as “UX/UI designer” in this case should not be misleading. It seems that additional resource costs in this case are completely excessive: after all, users will work in newly created software one way or another, if this is dictated by their job responsibilities. Functional requirements, information security, compatibility with other systems of the IT landscape are much more important for both the customer and the contractor. And since such cases are not in demand, there is no practice, accumulated experience and its generalization: there are few publications in the RU segment of the Internet on this topic, however, you can find quite interesting articles by English-speaking authors (links to some of them are given at the end of this text).
Summarizing the publications, the following theses can be formulated:
The quality of user experience of many B2B systems is extremely low, with articles using descriptions like “hopelessly convoluted”. This is due, among other things, to the accumulated features of solutions that develop the foundations laid many years ago (when modern UX methods did not really exist).
The complexity of B2B solutions further complicates the task: the system can solve many business tasks of very different groups of business users, functioning in conjunction with related IT systems of the organization. Correct operation of the system functions becomes a challenge for the team in itself, there is no resource left for “decorations”.
The customer (buyer) of the solution is not its future user. For example, the IT department does not have a very good understanding (and is not obliged to understand) of the nuances of the work of some functional department. It is difficult to find out about the specifics of non-functional requirements for the system from the top management of a large organization, no matter who is collecting the requirements. In addition, users of systems get used to their specifics and are not ready for changes, even to the detriment of efficiency.
The lack of methods is also significant: integrating UX design into processes, responsibility matrix, etc. is not only not very motivated for stakeholders (for the reasons stated above), but is also a non-trivial task that has to be solved “from scratch”, without having the appropriate competencies in the team and even more so individual specialists with the relevant experience. The methods and tools of UX design themselves are often not very well suited for B2B solutions – we will talk about this below.
All these factors make a possible revolutionary change in the form of reworking to qualitatively improve the user experience of the system during its development (redesign) extremely unlikely; the same applies to the creation of a new solution, albeit with a slightly lower probability. Still, development is underway, and some things are gradually taking root as general design and implementation patterns.
And who does this?
Let's start with the fact that often, unfortunately, no one. More precisely, the process is underway, because some user experience is ultimately born in any case (after all, the system is used in most cases), however – chaotically, without a responsible competent specialist, without using the necessary methods and tools.
In this case, the future user experience is made up of individual decisions, contextually made by a business analyst, consultant or developer based on the requirements transmitted from the customer (and we remember that the customer in many cases will not be the user). If there is a separate role (position) in the team, then this often raises some questions.
Note that in the ideal case, for designing a high-quality solution taking into account the user experience aspect, the roles are as follows (and each role corresponds to at least one person in the team, maybe more – depending on the scale of the project):
Of course, competencies can overlap. The UX sphere, for example, for not very large projects can be implemented through a set of additional competencies of a business analyst or UI designer, and there is nothing wrong with this if certain conditions are met. The UI design sphere can be divided between a business analyst, UX designer and developer, in very different proportions. All this is possible, but it requires the project management and decision makers to understand and analyze both the tasks and the knowledge and skills of the team members.
Having analyzed some publications on the topic of UX designer competencies, we can notice that this profession is often adjacent to the profession of UI designer, merging into a single whole. Perhaps you have come across these abbreviations written with a “/”, we have already mentioned this above. In principle, there is nothing wrong with this, but it turns out that the qualification features gravitate towards the visual part of the work. Here are some examples: “Most often, UX designers are people who received a design education in the profiles of “Industrial Design” or “Graphic Design” (specialty “Design” with code 54.03.01, or, for example, “Graphics” with code 54.05.03)” (https://www.profguide.io/professions/ux-designer.html); “Due to the universality of the profession, anyone can try their hand. Important qualities for the job are: a sense of style; the ability to draw; perseverance and patience; data skills (https://apokdpo.ru/stati/ux-i-ui-dizajner-opisanie-obyazannostej-i-osobennostej-professii/)” (thanks for mentioning the data, but this probably means summarizing research results, not designing dashboards or system administration processes); and even “UX is user experience. I still don't understand how you can be an “experience designer”, so I'll talk about an interface designer” (http://choose-it.ru/article/?id=1284).
What should a UX designer actually do?
Let's try to define the task areas specifically for the UX designer, assuming that the work on the final visual solution will be performed by the UI designer, having received the necessary initial data for this. We will not try to divide the activity by specific people, but rather focus on roles (above, we showed that the division of competencies between members of the project team can be very different).
Let's start with the fact that designing a user experience generally means that before the start of development and even drawing mock-ups, someone has a detailed idea of how exactly the user will interact with the system (i.e. how to manage it, what to receive, in what order, etc.). Such an idea should be born taking into account the analysis of functional and non-functional requirements for the system – as well as using the maximum possible amount of information about the automation object (we are talking about B2B solutions after all).
The most challenging UX task for any system with more than a couple of screens is designing the information architecture.
Information architecture is all the hierarchies, connections and attributes for all objects and functions that must be presented in the interface of the future system (including navigation) for the correct perception of information and its management.
In general, this is the task and area of responsibility of a UX designer. However, it is difficult to imagine that a person whose competencies correspond to those described above in some quotes would cope with such a task based on, for example, a regulation of 100 pages with appendices describing a couple of dozen iterations of a business process, a corresponding number of performance indicators, etc.
From here on, the UX designer must select and use the necessary tools for the job. And if his experience is in the field of product teams and B2C solutions, then most likely the choice will not be entirely effective for the area we are considering. Many user experience design tools are built on the emotional component (for example, the Customer Journey Map, shown in the illustration below). Moreover, the fundamental methods used by Google, among others, literally begin with the “Empathy” section. The user's steps within the scenario of his work with the system have an emotional characteristic – and this is the basis for experience design.
What changes seem logical for B2B UX? It seems that it would be much more correct to follow the business meaning of the scenario, that is, leading the user from one specific business task to the next within the framework of the general business goal that determines the meaning of the existence of this scenario. Yes, the user's emotions are an important thing in some cases, but not as important as efficiency, simplicity, consistency, priority in his business processes, if we are talking about a B2B solution. You can read more about this here: https://habr.com/ru/articles/816945/.
The rest of the tasks should be solved in the same vein, which can probably provide some not entirely obvious, but significant advantages to the project team. Thus, dividing the design process into stages can save resources on iterative changes following approval. It is much easier to make changes to a document with tasks and scenarios than to dozens of realistic mock-ups (in addition, understanding the essence of the future system is easier if you are not distracted by aesthetics and detailed details). Not to mention ready-made screen forms.
A designed (and agreed upon in some form obvious to both parties) user experience makes it extremely unlikely that the developed solution is not entirely clear or not really needed by end business users (in whole or in part). By the way, formal delivery can go smoothly regardless of this, since a good contractor will in any case meet the functional requirements 100%. Successful completion of the project, difficult revisions – or loss of business reputation and prospects for working with this customer – what to choose? And does this choice pay off with savings on some competencies of the project team?
Model of competencies in a team, planning and implementation of work
The simplest model is presented above: a full set of roles and relevant subject matter specialists. However, such a model is not always achievable and appropriate – the reasons may be organizational, or lie in the specifics of the project, etc.
Depending on the specific conditions, the following choice can be assumed for an organization implementing B2B IT projects: development of UX competencies (possibly a certain part) of business analysts or inclusion of UX designers in teams with, most likely, retraining them to work with B2B specifics and building an unusual close connection with business analysts. A single solution that is correct for all cases seems impossible due to the difference in contexts and situations.
In terms of developing business analyst competencies, the methodology of analysis and design “from the user” (human-oriented approach), practical techniques for describing business goals, tasks and scenarios are important; to a much lesser extent, attention should be paid to the skills of mastering specialized application software for layout (with a low level of detail of the visual solution) and prototyping (Figma, Sketch and the like – if, of course, there are other team members who can take on this work or its most complex aspects).
In turn, UX designers working in B2B teams should obviously become “a little bit of a business analyst”: be able to analyze business processes, regulatory and methodological documentation (again, taking into account possible help from colleagues – it is not necessary to acquire a second profession completely). In addition, they should review their tools. Some UX research methods for collecting data and design techniques will be unavailable for the reasons stated at the beginning of this publication – and design practices tied to processing research results will also “sag” in this case.
Taking into account the above, we formulate recommendations for organizations:
Managing employee competencies in such a way that any project team is provided with the necessary set, taking into account the complexity and volume of the solution (small implementations in the knowledge of project managers are especially significant, as well as individual or combined competencies of a business analyst and UX designer).
Incorporating user experience design work into project management templates and tools, as well as supporting this work (methods, artifact formats, task relationships, etc.).
English-language publications on the topic:
Luca Reale “Everything You Need To Know About B2B UX Design”
https://drewl.com/blog/b2b-ux-design-2023/
Duncan Trevithick “UX for B2B Companies: How is it Different?”
https://www.resonio.com/blog/b2b-ux-design/
Mathias Ellegiers “Designing Better B2B E-Commerce Experiences: Information Architecture and UX”
Samuel J. Horodezky “B2B UX – Common Obstacles and Attainable Solutions”
