Touch point, or How to build communication between teams within a company

Working in large companies is not only about voluntary health insurance, pizza on Thursdays and corporate merch. This is a large flow of information, both related and not very related to design. Daily meetings, retros, grooming sessions, synchronicities between teams, general meetings of designers, one-on-ones, design reviews, regular reporting events and, of course, correspondence in endless chats.

Despite popular belief, large companies constantly undergo many internal changes. Some are local in nature, while others affect the work of the company as a whole.

The designer must be focused on design, and, as usual, this is a task with a large number of unknowns. To get started, you need to gather a fair amount of information. Something can be unearthed in various kinds of documentation, something can be suggested by teammates, other designers, managers, business representatives, and some hypotheses can be explored with end users.

In large companies, work on a project can last several months or even years. Therefore, documentation becomes outdated, and knowledge holders simply leave the teams.

In addition to information, it is important to have all the tools at hand to solve the problem, for example, Figma, Framer or Miro. A design system is just one such tool. In the case of Alpha Business, the design system team supports more than 100 teams with two designers, four front-line developers, the product owner and me, the design lead of the channel.

In this article I will tell you how we built communication between the design system and the design community. The article will be of interest to product owners and engineers who work directly with the design system.

What is a corporation in simple terms?

Imagine a small village, a dozen houses and one street. People are quite aware of what is happening in their neighbors, and therefore in the village as a whole. Close interaction creates shared values ​​and standards.

Time passed, the village expanded, neighborhoods and districts were formed. There was more information, and the groups gradually isolated themselves, focusing on something local and specific. The districts begin to operate and develop more independently, while continuing to be part of the same village. In my analogy, the districts are product streams, the groups consist of product designers, and the village is obviously a company. To be completely precise, we also have administrative districts, for example, b2b and b2c directions.

A new beginning

At the end of 2022, we relaunched the design system, taking a fresh look at its structure and operating principles. For a long time, we supported a version with a full set of basic components, such as input fields, buttons, simple tables, a tariff grid, and so on. In addition to them, there were several more specific components created exclusively for Alfa Business, then still NIB (an abbreviation of the internal name of the web version of the Internet bank for business, stands for New Internet Bank).

A little context

The bank also had another design system – Core, which was used for individuals, on the website and in internal products. Over time, we began to differ greatly in the UI, which was often reproached to us, saying, why do retail products look better?

We decided to stop supporting our own core components and move teams to Core in order to focus on producing unique solutions that are needed only by B2B clients, for example, complex filters, super-functional tables or specialized widgets. In order for everything to work as it should, it was necessary to update design standards, the use of components, and also regularly create new ones.

Much of the documentation was a literal transfer onto paper of information collected from the “old-timers,” those who still remembered and could explain why it was being done this way and whether everything was ok.

At some point, the number of designers began to grow sharply, and it was time for the experienced guys to move on. An information gap has arisen – not all the necessary information has been recorded yet, but the design system team is already lined up for answers. Obviously, a huge number of questions flew into the chat – it was impossible to open Telegram and not see a row of red eyes, as if constantly watching you.

Always be in touch

No matter how cool and useful our components and patterns are, they are worthless if no one knows about their existence. We needed a communication channel between the design system and the design community, which performs the following 3 tasks:

• Allows you to inform designers about news in a timely manner

• Has as much coverage as possible

• Allows you to collect feedback

The channel should be familiar, efficient in terms of time spent on its support and, of course, easy to use. I won't tell you how we place components in our storybook or how we organize the library space in Figma. It's about communication.

1. Telegram channel

You can't do without chats. We have three of them:

• News

  There are posts about new patterns and components, as well as reposts from other channels that we think would be good for our design community to know about.

• Basic

  There are many threads in it: in one there are questions and discussions about tables, in another they ask about patterns. The threads have clear names that make it difficult to get lost. You immediately understand where to go. The most popular thread is “UX/UI First Aid”, where you can simply ask a question. The beauty of the chat is that the information remains, so if you wish, you can find the answer through a search, unless this is some kind of unique situation, which is even better, because for us it is a reason to think – is it working correctly now?

• About patterns

  Designers make contributions to the design system, joining in the work on components, or undertake to describe a certain pattern. It has threads on specific solutions where you can discuss both during development and after.

Of course, questions are also asked in personal correspondence, but we have nothing against it, because usually at this moment some specific cases are discussed, and for us this is an opportunity to look inside the product.

2. Regular meetings on patterns

The design system team is the same as a product team and it works in sprints, so the cycle is within 2 weeks. Every first Monday we have a pattern meeting. On it we tell current news and share plans.

When we need to collect an invoice, we directly turn to designers for help – who else knows about real cases and practices. For example, at the last meeting we announced that we were working on reworking the mobile version of the component and we needed help compiling an invoice. The layouts flew onto the board, and some of the designers volunteered to help twirl the component.

We devote the remaining time to analyzing current cases. Any of the designers can write down their question in advance in a special form, so often the meeting turns into a kind of grooming, where the expertise of designers of different products intersect. Not many people come, but there are already regular participants, which is gratifying!

3. Consultations

We started with team consultations. Design leads united designers based on a common characteristic, for example, similarity of products. The meeting was led by one of the designers from the design system team. The news of the design system and the correctness of applying certain solutions in real scenarios were discussed there.

The groups were not equal, sometimes 3 people, sometimes 8. Not everyone came, so sometimes team consultations turned into personal ones. In total, such meetings could take about 16 hours per sprint, which, in addition to chatting, is a huge amount of time.

Now we have abandoned this format and switched to consultations by appointment and have reduced the time by almost three times – now a sprint includes 6 hour-long meetings at a fixed time, and the designer independently signs up for a consultation, and most importantly, indicates the question in advance on the meeting card so that the guys from the DS had an understanding of what would be discussed and could prepare a competent response.

We believe that such a format will not only allow us to devote more time to developing new elements, but will also encourage the independence of designers.

4. Meetings with software and developers

Clients and designers are not our only users. Product owners and developers have direct contact with the design system. Information about plans, capabilities, and dependencies helps make work more efficient and predictable results. So far, we have only managed to hold one such meeting, after which the product owner wrote: “I learned more about the design system from this meeting than the entire time before,” nice.

A busy start to the year did not allow us to expand to full capacity, but we do not lose hope and believe that such a format will help us better understand our users, and they, in turn, will have a direct channel for feedback.

conclusions

You and your colleagues from other teams and departments work to make the end user feel good and convenient, so much so that he is willing to pay for it. Only by talking and exchanging opinions with each other do we ourselves and the bank as a whole develop. Based on my experience, I would define 4 criteria to consider when building communication:

• Clear language

  This concerns the presentation of information and its type. For some there are signs with traffic lights, for others there are bright pictures and layouts. A person does not have to immediately begin to understand your sparrow language, full of specific terms and Anglicisms. It is in your best interest to be heard.

• Flexibility

  Everyone has their own rhythm, schedule, time zone, after all. There are cases of the “now or never” level, and someone can afford to park the problem and return for information later. Use different tools, and your users will choose the most convenient one.

• Current documentation

  What is written with a pen, as they say. Thanks to public access, anyone can find out what they need using the search. In addition, the information is easy to reference. It’s not cool to waste time answering the same questions 100 times if the answer could be “Read, here’s the link.”

• Need to listen

  If everyone around you says something is wrong, it probably is. You don't have to believe it, but it's worth checking out. Receiving feedback is critical for development and understanding “Are we even moving in that direction?” The monologue format no longer works; people want communication.

It is worth striving to ensure that the designer has all the necessary information and tools at hand and, instead of adding new steps to already complex processes, become part of them, making as few changes as possible with maximum benefit.

How does your company organize communication between different teams and departments? What difficulties have you faced and what hurts you the most?