Teams should interact. That is the basic lesson we learn from agile ways of working.
We keep asking ourselves how to build a culture of internal communication when we do not work close together, sometimes not even in the same place. In articles, we always read how companies with large groups of designers work, how they get a remote team to operate in the same scope, but we fall into the same story: “we do not have just one product.”
Internally we have a tribe structure, where we allocate more than one designer, with squads working on several products. We work directly with the teams, and we try to have at least one designer per project. Right now we are more than 20 designers. Watching developers share knowledge about technologies and processes, we wanted to use that same idea of constant knowledge exchange and feedback across projects, however different they might be. That helps generate new hypotheses, make products better — increasing interaction within the team — and it is also personal growth.
In my reading, I found a Trello board idea (aaaaah, Trello! S2) for creating feedback groups aligned with a kanban system. So we started with a test group before expanding the idea to the rest of the team. After all, we are agile, we test before we implement. “Ok, but how does it work?”

The initial methodology
It is quite simple: we split into smaller groups of 5–6 people and meet once a week for an hour. We have a mediator, responsible for kicking off the meeting and keeping the energy in check, and someone presenting their project or question. A few days earlier, we write a Trello item with a summary of what we will talk about so everyone stays on the same page, since the meeting is very dynamic. During the presentation, participants write on post-its that are later read one by one by the mediator and discussed with the group. Five minutes before the meeting ends we make another item with “What went well?”, “What can we improve?”, and we also schedule the next meeting. Pretty simple, right?
How we actually do it
What is written down often does not work in real life. We started with one group (6 people, almost half the team at the time) and kept adapting as needed.
No post-its.
I know it may sound absurd to anyone who loves those little pieces of paper, but in our setup the post-it strategy does not work. Our meetings were often a mix of in-person and virtual, since someone was always on a computer and could not join that dynamic. We write down our points and talk with the presenter without an intermediary.
The mediator is just the organizer
We know that many designers together can turn into a mess, but we rarely go off topic. The mediator is the person who does not let the other participants forget the meeting, who is responsible for the video call and who makes sure the board item gets done. They write the final notes and schedule the next meeting.
The board structure
If you open the link from the initial methodology you can see how it is structured at first. We realized the feedback cards were unnecessary and the number of lists did not fit what we were proposing. We reduced it to three lists: “Pontos da reunião”, “Próximos huddles”, and “Huddles passados”.

What to share
The meeting became a collective support point. Besides projects or problems, we started bringing other items where we needed help. We opened space to understand how our client works and ways to relate better with other people on the projects. We brought research techniques and data analysis to the team. Even how to foster an understanding of what design is. The point is to share.
How we actually do it
What is written down often does not work in real life. We started with one group (6 people, almost half the team at the time) and kept adapting as needed.
Rotation
This is an essential question. We have to rotate huddle members so we can see different views of the same product. Each project has particularities that can inspire others. So after 5–6 weeks the group is dissolved and we assemble another group with different people.
Schedule
Our biggest difficulty is getting one hour a week from each designer on the same day. At first it will be hard to justify this meeting with the project manager or the client, but as soon as we start seeing the impact it creates, it becomes a priority. That is why it matters that each meeting schedules the best possible date for the next one (usually after lunch is the best time). We accept that not everyone will always join and that is fine; we like to keep 60% attendance so the meeting can happen without having to reschedule.
This way we created a decentralized ritual, very important for a team that grows every day. We adapt to the difficulties, shaping a process that a month from now might be different. We fully understand that this kind of communication is essential for the company as a whole. This is how we do it at dti digital — how do you do it at yours?