As the Design Director for WooCommerce at Automattic, I manage a large team of designers. Automattic is distributed company and everyone works from home (or wherever they happen to be). Our team is spread out across Europe, the US, and Australia.
The WooCommerce design team has grown and changed over time. As new people join, we try new things and the things that work, stick. One of those things that has organically evolved over time has been our twice-weekly team meetings.
Why meetings? Why two a week?
We are a team of designers. A designer’s job primarily is to identify and solve problems. But the end result is making a thing. Whether it’s a design, landing page, flow, or insights from research, we are all making something. And great design needs a short feedback loop. Since we are all remote, we have to be more intentional about meeting than we would if we were all together in an office.
The purpose of our meetings:
- To form a tight feedback loop so our product is consistent and the best it can be.
- To get to know each other, bond as a team, build trust. In a remote setting, virtual face-to-face time is key.
- To discuss thoughts, ideas, and changes to make as a team.
How we run them: logistics and tools
Our team chats are very casual, but over time a general flow and process has evolved. I’ll walk you through how a typical meeting goes, including the tools we use.
Reminding and alerting
An hour before the call, a recurring slackbot reminder that I set up goes out. (“Team X” is the name of our team.)
The link leads you to the running meeting agenda in Google Docs. For efficiency, we keep the same doc for every meeting. It contains the following information:
- The header, which stays on top of the agenda, has the title of the doc with everyone’s name.
- Below that is the note taker and call leader, the blog post title with date, and a list of who was present/not the previous meeting.
Before the meeting
Whoever is the first person to click on the link that day is the one who updates the agenda. To update the agenda, you simply copy and pasting the portion below the line. Then change the date to today’s date, update the leader and note taker (we go in order of colored names up top) so its all ready to go for the meeting.
If you have work in progress to share, you add it to that section. If you have something else to discuss, you make a new section and add it below.
When the meeting starts, I drop the Zoom link in our public Slack channel (it’s also in the channel description) and everyone starts filtering in. We chit-chat and say hi until everyone joins.
When everyone is on, I usually announce who is the call leader and who is taking notes. The call leader takes over and runs the meeting. Running the meeting involves two things: reading through the agenda topics, facilitating discussion, and making sure we are good on time. This will vary from person to person, depending on their style and personality. Taking notes involves writing down what is discussed and posting the meeting notes to our team’s p2, a private WordPress blog only accessible to people within the company. (The Google doc is formatted in a way where it’s pretty much just a simple copy & paste.)
What we do
The short answer is: Anything anyone wants as it relates back to the purposes of our meetings. The only real rule we’ve made is no status updates. This came about from a quarterly retrospective; someone expressed that our team had a bad case of Status Update Overload. We all agreed they weren’t a productive use of time and wanted to fix it. We all agreed to focus our meetings on three things: Question of the day, show and tell, and topical discussion.
Question of the day
This idea came up after a recent company-wide survey, where we scored low on “Feeling Part of a Team”. Someone on the team suggested we try a Question of the day at the beginning of every Tuesday meeting. It was around the time when three new people joined the team and it was a great way to get to know everyone.
Questions are asked in the beginning of the meeting as an ice breaker and usually take around 20 minutes. Past examples include:
- What time of day are you naturally most productive? When are you least productive?
- What else is on your desk besides a computer? (Bonus: Stop, take a picture and share on Slack)
- If all the computers, electronic gadgets and software on earth disappeared tomorrow, what would you do with your time?
A note: We don’t do these every week anymore as we all feel part of a team now. Instead we do them ad-hoc as questions come up. For example, today we spent our whole meeting on this one question: “What is something you are actively working to improve upon?” This was asked for a variety of reasons, but essentially it was to make a space for people to be vulnerable, share their work struggles openly, and for everyone to see that they aren’t alone. It was sort of like group therapy so we decided to not take notes and keep it in a safe space.
Show and tell
For those who went to design school, you may know this as a Design Critique. Every meeting (give or take), someone from each squad will add an in-progress design they are working on to the agenda. The process varies from here depending on what the design is. If its a:
We try and stick to only sharing designs, even if they are super rough sketches. This way, we’re all seeing the same thing. When you are sharing ideas about a design instead of an actual design, everyone will have a different picture in their head and it can be difficult to get on the same page. That said, it does happen and we’ll listen to the idea(s) and offer feedback on if and how to move forward, usually by asking to see a design 🙂
Sketch/Figma file or other static design
If there’s a piece of UI, a logo, or a landing page that a designer is iterating on, they will share their screen, describe the problem, and show the various solutions they have come up with. They’ll ask for feedback and anyone on the team can comment. The notetaker is responsible for capturing the feedback.
Prototype or flow
If the designer wants to share a prototype or flow, they’ll first set the stage by explaining the scenario, much like they would if they were testing the flow with a real user. They’ll then ask for a volunteer to run through the flow. The volunteer will then share their screen and run through the prototype, talking out loud as they go. The notetaker takes notes and the rest of the team gives their feedback as well.
Giving and receiving feedback
We’ve never set any rules for this, but follow this basic guideline: Focus on the work, not the person. It’s up to receiver to decide which feedback to implement and return with an updated design next meeting, post it to p2 for a wider audience, or start prepping for a usability test.
Whatever topics people want to discuss with the team, they can add them to the agenda. This can be big initiatives in WooCommerce product, the Design org, Automattic, or in the outside world. In the past, examples of this have been:
- Research: Demos, tips, tricks, updates to process
- Brand strategy: Explanation, thoughts, next steps
- Figma: It seems to solve a problem we have with Sketch not being collaborative. Should we investigate further?
The whole design team. On Tuesdays, we invite guests from other teams within the company to learn and share.
When they take place
We meet twice a week at two different times to be inclusive of timezones and not to be too US centric. Tuesdays are at 3pm UTC and Thursdays are at 5pm UTC.