Protocols
Cooperation
Communication
We have set a tempo for our meetings. This tempo helps us getting updated from other designers, but doesn't not require too much of our precious time.
Before to break our communication tempo down, one golden rule:
❝
Meetings are optional and can be skipped or adjourned.
❞
This golden rule applies to all our meetings, starting with our weekly sync-up.
Weekly sync-up (50min)
During this weekly meeting all designers are sharing their progress, problems and plan (PPP) on a Figjam board.
Discussion topics can be added to the board. If no discussion topics are added by anyone, we generally skip the meeting.
Bi-weekly 1o1 (30min)
Once every 2 weeks, all designers have the occasion to bring discussion topics to their leader. It's the occasion to discuss blockers and challenges, or simply get feedback from an experienced peer.
Punctual, on-demand Peer review
Designers can ask anytime for another designer to review their work.
It helps reaching confidence and get expertise feedback
These peer reviews are precise and usually short and informal
The peer reviewer can vary depending on the type of work and based on each designer’s ownership
Quarterly Design week
This is the occasion to take a step back from our busy mission works. All designers are setting goals and projects that require high cooperation among designers. All mission leads are aware of it and designers can dedicate more of their time to function-related improvements. This is generally related to our Design system updates, but not only.
It's also the occasion for the entire team to enjoy a half day outside the office, at a museum or an event altogether.
During the design week we have all sorts of events:
Workshops (achieving something as a group)
Talks (internal & external speakers)
Individual challenges
A retrospective of this past quarter
Documentation
Every single meeting we have, just like any new component we create, everything must be documented and logically accessible by others.
Documenting is an essential component of a system. If done well, we can expect the system to run smoothly and grow as we expect it to grow. On the opposite, if the documentation isn't done or not thoroughly, problems will occur sooner or later.
What do we document?
What is important to document are decisions.
These decisions can be strategic, for instance inside a meeting note with stakeholders, or technical, related to a component and its integration for example.
-> If it's not documented, it doesn't exist!
Decisions usually lead to action items, so it is also good-to-have them documented. Action items ALWAYS include an owner (a single person) and a due-date.
How do we document?
Any kind of documentation includes the following:
Background or Context
A short description
A detailed description (or guide)
Related performance metric if applicable (or expected goal)
Where do we document?
Figma contains all of our components' documentation
Confluence/Figjam contain all of our meeting decisions
This website, design.buzzvil.com contains higher levels of documentation. It also includes decisions but from a functional perspective. Hence how we work and manage our Design system for greater performances as a function team.