Touchpoint, or How to build communication between teams within the company

Touchpoint, or How to build communication between teams within the company

Working for big companies isn’t all about DMS, pizza on Thursdays and corporate merch. This is a large stream of information that is not so much related to design. Days, retros, groomings, meetings between teams, joint meetings of designers, alone, design reviews, regular reporting events and, of course, correspondence in endless chats.

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

A designer must be focused on designing, and as usual, this is a task with a lot of unknowns. To get started, you need to gather a fair amount of information. Something can be dug up in various documentation, something will be suggested by teammates, other designers, managers, business representatives, and some hypotheses can be investigated on end users.

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

In addition to information, it is important to have all the tools to solve the task at hand, such as Figma, Framer or Miro. The design system is one such tool. In the case of Alpha Business, the design system team supports more than 100 teams with two designers, four front-end developers, a product owner and myself, the channel design lead.

In the article, I will tell 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 plain language

Imagine a small settlement, a dozen houses and one street. People are quite aware of what is happening in their neighbors, and therefore in the village in general. Close interaction forms common values ​​and standards.

Time passed, the village expanded, quarters and districts were formed. There was more information, and groups were gradually isolated, focusing on something local and specific. Districts begin to act and develop more independently, continuing to remain part of one village. In my analogy, neighborhoods are product streams, circles are made up of product designers, and a village is obviously a company. To be precise, we still have administrative districts, for example, b2b and b2c directions.

A new beginning

At the end of 2022, we restarted the design system, looking again at its structure and principles of operation. 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 specific components created exclusively for Alpha-Business, then NIB (abbreviation of the internal name of the web version of the Internet bank for business, in the transcript New Internet Bank).

Not much 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 diverge greatly on the UI, which we were often criticized for, saying, why do retail products look better?

We decided to abandon the support of our own basic components and move the teams to Core to focus on the production of unique solutions needed only by customers of the b2b segment, for example, complex filters, super-functional tables or specialized widgets. In order for everything to work as it should, it was necessary to update the standards of design, application of components, as well as regularly create new ones.

Much of the documentation was a literal transfer to paper of information collected from “old-timers”, those who still remembered and could explain, and why it is done this way at all and is everything about it approx.

At some point, the number of designers began to increase dramatically, and it was time for experienced guys to move on. There was an information gap – not all the necessary information was recorded yet, and the team of the design system already had a queue for answers. It is obvious that a huge number of questions flew into chatik – you could not open Telegram and not see a row of red eyes that seem to be 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 they exist. We needed a communication channel between the design system and the design community, which performs the following 3 tasks:

  • Allows designers to be informed about news in a timely manner

  • Has the greatest possible coverage

  • Allows you to collect feedback

The channel should be familiar, efficient in terms of time costs for its maintenance and, of course, easy to use. I won’t cover how we place the components in our storybook or how we organize the library space in Figma. It will be about communication.

1. Channel in Telegram

You can’t do without chatiks. We have as many as three of them:

  • news

    Here 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 question and discussion on tables, in another they ask about patterns. Threads have clear names that are difficult to get lost in. You immediately understand where to go. The most popular thread is “Quick Help with UX/UI”, where you can simply ask a question. The most beautiful chat is that the information remains, so if you wish, you can find an answer through the search, if it is not some unique situation, which is even better, because for us it is a reason to think – is it working correctly now?

  • About patterns

    Designers contribute to the design system by joining the work on components or by taking on the task of describing a particular pattern. It has threads for specific solutions where you can have discussions 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 into the middle of the product.

2. Regular meetings on patterns

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

When we need to collect an invoice, we directly turn to designers for help – who knows about real cases and practices. For example, at the last meeting we announced that we were working on a mobile version of the component and we needed help picking up the invoice. The models flew to the board, and some of the designers volunteered to help rotate the component.

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

3. Consultations

We started with team consultations. Design leaders united designers by a common feature, for example, the similarity of products. The meeting was conducted by one of the designers of 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, and 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 abandoned this format and switched to consultations by recording and almost tripled the time – now the sprint consists of 6 one-hour meetings at a fixed time, and the designer himself makes an appointment for the consultation, and most importantly, indicates the questions in the meeting card in advance so that the guys from the DS had an understanding of what would be discussed and could prepare a competent response.

The names of the characters are invented or coincidental

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

4. Meetings with software and developers

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

The dense beginning of the year did not allow us to turn around at 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, 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 comfortable, and so that he is willing to pay for it. Only by talking and exchanging ideas with each other do we develop ourselves and the bank as a whole. Based on my experience, I would define 4 criteria to consider when building communication:

  • Understandable language

    This applies to the presentation of information and its type. Some have signs with traffic lights, some have bright pictures and layouts. A person should immediately begin to understand your rowan 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 task and come back for information later. Use different tools, and your users will choose the most convenient one for themselves.

  • Current documentation

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

  • You need to listen

    If everyone around says something is wrong, it probably is. You don’t need to believe it, but it’s worth checking. Receiving feedback is critically important for development and understanding “Are we moving in that direction at all?”. The monologue format no longer works, people want communication.

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


And how is communication between different teams and divisions structured in your company? What difficulties have you faced, and what hurts the most?

Related posts