Synchronization at the project level
An experienced designer can take on a synchronizing role within the project by communicating with key stakeholders and shaping what the product should be — in both function and form.
To do this, the designer needs to read all the chats, stay updated on how the project is evolving, analyze the "internal chaos", and distill useful information.
This doesn’t mean the designer has to actively participate in every discussion. What matters is staying aware of what’s going on, analyzing and understanding the context, and responding quickly when needed.
For example, after discussing development steps with the founders, the designer naturally has ideas and a rough vision of how things might look and be implemented — this is key information that needs to be shared with the rest of the team.
We can communicate information to the team on several levels:
- What and why we’re building: what the product brings into the world.
- Which functions are most important: a system-wide priority hierarchy.
- Which layouts and features matter now: the current sprint’s focus.
This creates a shared foundation and allows the team to move in sync, aligned around a common direction.
As a result, the designer becomes a “knowledge keeper” — a core member of the team who gathers, organizes, and distributes information through the knowledge base.
Of course, it’s also important that the rest of the team doesn’t remain passive. The more actively everyone participates in gathering, filtering, and structuring information, the better the outcomes. Designers also need feedback and precise data to make the right next steps.
Tools
- Describe the current context in messages.
- Document key information in the knowledge base.
- Prioritize tasks in the task tracker.
Synchronization at the process level
It’s important to synchronize not only on the product level but also in day-to-day work.
Example: It’s highly unlikely that you can get illustration requirements once, disappear for a few days, and return with a final result that’s immediately accepted. At best, there will be minor edits. At worst, the work will need to be redone. What’s needed is a series of small steps and check-ins.
Not only the designer
The product turns out better — and collaboration is easier — when the team doesn’t just “complete tasks”, but truly engages with the core of their work, thinks critically about their contributions, and sees how everything connects.
Example: A developer notices a narrow use case or a simpler way to solve a problem — they bring it up with the designer, and together they come up with a better solution.