Remote workshops to improve your product design team organization
I started my job at Doctolib in July 2020, when the Covid crisis already determined our lives for a while. Together with my colleague Sasha, I was the first designer to join the German team in Berlin. And because of the travel restrictions and health regulations, I didn’t have the chance to meet any of my colleagues in Paris. How do you manage to create and keep a healthy work relationship with people you only know from “the internet”?
A bit of context
Doctolib acts both B2B and B2C. The B2C side creates a free-of-charge doctor’s appointment booking platform for patients. The B2B side focuses on creating various products for healthcare professionals, to help them spend more time with their patients, instead of having to deal with administrative tasks. Both sides are separated into different domains and every domain has multiple feature teams. When I joined there were 20 designers (including product and brand designers, user researchers, and UX writers) and now, not even a year later we have grown into a team of 35. Taking in all these different, highly interlinked, and complex topics can be challenging as a newcomer, and keeping the overview in a fast-growing team is just as demanding.
Workshop or meeting?
When I joined Doctolib, we had two 2 hour product design workshops every week. These workshops were not “workshops” in the classical sense: there was not a clear outline, there were no exercises, we didn’t have any facilitator or other defined roles. But they were great for getting to know all the different projects and for understanding which designer worked on each one of them. We mostly met up with the whole product design team, which consisted of 8 people at the time, and talked about challenges in our day-to-day projects, components that we would like to add to the design system and we reviewed design iterations and discussed feedback.
After a few weeks and when I had a better understanding of the products we worked on, a few things about our “workshops” began to bother me. The missing structure made it hard to add your topic to the schedule, usually, we had too many topics (on other days we didn’t have enough to fill the 2 hours). The short time slots per project made it very hard to dive into the complex issues of a different domain if you hadn’t worked on them yourself. We spent a lot of time debating instead of making decisions and these workshops felt less and less as workshops and more like… meetings.
“We had to organize a workshop on how to organize better workshops.”
So what could we do? The answer to tackling our problem was too easy. We had to organize a workshop on how to organize better workshops. Our session had a classical retro format and we collected all the things we liked and should keep and everything we disliked and should change along with general questions and then brainstormed ideas.
It became clear that we appreciated the possibility which these workshops gave us: to meet up with other designers regularly. Especially since we have been working from home 100% of our time since the fall of 2020. We also liked the possibility to share common knowledge about our different digital products and that we were able to create a better overall consistency when all product designers were in the same room. On the other hand, we missed a better structure and the possibility to use our sessions more efficiently. Having discussions for two hours is not an easy thing to do in general and it is even harder in a large group of people in a remote work situation. We clearly needed a better structure.
The new Doctolib design workshop approach
Together with my colleague Hugo, I sorted the outcome of our retro and we created a foundation of 5 pillars, which stated what we as a team expected from our workshops (and ourselves):
1) Spread the knowledge
- Improve the global product knowledge
- Stay up to date
- Find ways to tackle tricky subjects
2) Boost speed
- Boost ideation by the power of many
- Get different viewpoints, especially when you’re stuck
3) Increase product consistency
- Discuss the usage of our design system components
- Align on shared issues or use cases
4) Relevant participation
- Find ways to make it easier for the whole team to focus
- Make sure that all voices are heard
5) Clear Preparation
- Be better organized
- Know what to show and when
We collected different types of topics that we usually tackled in our product design workshops. Then, we sorted them on a scale from the more abstract discovery and definition phase to the very concrete creation of new design system components. We realized that we could connect our demands to three different types of workshops.
1) The Docto Design Workshop
A workshop-type, that was based on classic innovation approaches and which helps us face complex and more abstract problems. This type of workshop should mark the beginning of all bigger projects, can be set up as a design sprint, and requires a cross-functional team of designers, researchers, developers, and product managers. I created a workshop kit within Mural to help kickstart workshops, using explorative exercises. Based on our medical context, our discovery phase is called Anamnesis, the creation phase Diagnosis, and our validation phase Therapy.
2) The Live Product Design Workshop
When you have a more concrete design problem to solve. We use this type of workshop in the design team only, to generate a vision, to innovate, find quick solutions, and to work on UI & UX fixes. Once a week we review design ideas together or create design explorations as a team using Figma. Usually, this type of exercise requires a good amount of knowledge of your product domain, which is why we decided to create domain workshops. For example, in these sessions, only the designers who work on the Doctolib calendar software for practitioners meet up. We still have a one-hour session with the whole product design team every week, but we mainly use it for project presentations or demos, to create a better overall product knowledge within the team.
3) The Design System Hour
In this workshop, whoever created a new design system component or has an idea for an improvement, can bring their topic to the table, and the team votes about a keep or sweep. Our design ops lead Jérôme hosts the session and informs us about new components which have been finalized and implemented into our system. (You can also check out the Doctolib design system “Oxygen” here).
Uniting by separating
Now we were at a point where everything seemed to be in place. We had some good workshops with a clear purpose in place. We knew which one to choose, when dealing with abstract or concrete problems, we had regular meetings with our domain teams in place and were still able to learn about projects outside of our direct work horizon. On top of that, we had a clear process to improve our design system, but something was still missing. Our design system sessions also included our UX Writing team but we had no real connection to our brand designers, except for the monthly all-hands design meeting, in which each one of us presents a project they worked on in the past month. As our team was constantly growing, this was not a very scalable approach and the direct interaction between two people was missing. I also realized that in our workshops some of my colleagues were still quieter than others, as we could not always create an exercise with a task for everyone. I can relate to that because as an introvert I can say that discussions with a group of more than 3 people usually drain my energy pretty quickly. So what could we do?
Jérôme talked about pair programming, which our developers did regularly. Maybe we should try something similar? I always believed that designers should work in a pair and complete each other’s characters and skills. Just like a good investigator team like Holmes & Watson or Mulder & Scully, I think that working in a team of two has a lot of benefits, especially in the early discovery phase of a project. For some designers, it’s easy to dive into a project right away. They can generate a lot of ideas on the spot when they didn’t even completely hear the full briefing. Others prefer to read a briefing a few times, start with some research to fully immerse with the topic, and follow a more method-based design process. I think both approaches can be good at times and both types of designers can feel stuck sometimes. Design pairing forces the team to iterate constantly, to question their ideas, and can often boost the ideation process due to a creative game of mind ping pong. Pair design was also the perfect answer to the question: How might we make creatives of different disciplines in our design team work on a topic together? On top of that, it would give more introvert designers a more comfortable playground to work on their topics.
So without any extensive planning, I created random groups of two and invited them to individual 1h google meet calls to work on 2 different topics for 30 minutes each. This way, each person could pick a topic they wanted to run by another designer. We tested these random teams for a few weeks and I received mixed feedback. Some people loved it and told me it was the most useful design workshop they had. Others told me that half an hour per topic was not enough time to really dive into a complex issue or that working with a designer from a different discipline was not helpful, as the other person couldn’t support them with the specialist knowledge they needed in their project phase. The time constraint was clearly a problem. To gather more information, I set up another workshop.
We first collected some good and bad things about the pair design sessions and grouped them into overarching categories. It was quickly clear that everyone liked the connection they had with the other designers in the team, especially as we couldn’t meet in the real world due to the covid restrictions. For many, it was a fun distraction from their regular schedule and a way to talk to designers outside of their domain.
An interesting thing to see was that some designers enjoyed the randomness of the session and the possibility to dive into a completely new topic every week. Others however preferred to use the time to work more concentrated together with somebody, who already had a good understanding of their project.
We brainstormed silently, by writing digital sticky notes (a great way to give everyone in the team and not only the ones with the loudest voices the chance to pitch their ideas) and then voted for the most practicable implementations.
Random and not so random pairs
Our new pair design process looks like this: we add pair requests to Slack a day before the session to give people, who already have a pair project idea and maybe even a teammate the chance to work more effectively. Everybody else is assigned to a random pair and uses the time for cross-functional collaboration or for its learning and distraction aspect. We have specific times each week for design system hours and domain workshops and create additional docto design workshop sessions or design sprints when we need them.
Are we perfectly organized by using this new process? Probably it can still be refined and like every lean project, we’re testing and iterating a lot. We’re collecting pain points and insights and developing new ideas, which we quickly test and trash if they don’t work. As I recently realized that we had a few last-minute cancellations or that I was not aware of some of the preferred teams and topics, when I set up random pairs on Friday morning, I started to post this chart on Slack on Thursdays in the afternoon. It helped as a reminder for everyone and gave people the chance to add their preferred pairings and requests if they already had a topic.
If you would like to try pair design or any type of workshop with your (remote) team, I can definitely recommend doing so!
Why you should do regular workshops with your remote team
Here are a few aspects which the different kind of workshops positively influenced:
Collaboration: Our team liked getting feedback from outside of the team, to be able to see something with a “new set of eyes”.
Fun: We loved the aspect of it that let us talk to other people outside of our regular team and break out of the routine.
Consistency: We appreciated that teaming up with other people let us see what other teams are “cooking” and we felt that we could achieve better sync in between the different feature teams, which helped us solve cross-domain issues.
Productivity-boost: We felt empowered by getting new input from somebody else and by quickly iterating on ideas together.
Learning: We learned new things, either by seeing how other techniques can be used to tackle a problem or by exploring completely new fields when we teamed up in between product design, brand design, user research, and UX writing.
Did you make a similar or very different experience with remote workshops? Please leave a comment, I would be interested in hearing your thoughts.
