Design Collaboration at Alan in 2019
A quick look inside Alan’s design community!
Alan has written a lot about its “no meeting” policy and about its written culture. Some like it; some hate it. Anyway, it does not leave people indifferent, and it generates lots of questions like “how do Designers collaborate in such an environment ?”
Let’s start with a quick description of the Alan way of working:
Alan’s product organisation
The crews
At Alan, designers work imbedded in small multidisciplinary teams; we call them crews. At other companies, you might use the term “pods” or “squads”. Basically, it’s a project team.
On top of a Designer, each of these crews has at least an Engineer (usually several) and a Product Manager. The team can also include Insurance, Sales or Care crew members depending on the type of topic the crew is tackling.
Crews have a short life expectancy (about 3 months).
They are created to work on a specific problem and are free to write in autonomy their mission statement, their objectives and their roadmap.
Crews generate a quantity of initiatives (or projects), that they hope will impact their objectives.
The initiatives
As at crew level, initiatives have a Designer, an Engineer and a PM involved. There are two important moments in the life of an initiative:
- The “Framing” when we make sure that we understand the root cause of a problem. We scope the work to be done and roughly define a solution.
- The “Making” when we deliver on the solution that was roughly defined earlier.
Most of this communication happens in writing, in discussion threads that we call “Issues” simply because we host them on Github Issues.
This way of collaborating through writing with crew mates also makes it super easy to invite another Designer to the discussion for new insights.
We can simply ping them with a direct question, and they will have all the context available to make a detailed answer.
The communities
A community is an ensemble of Alaners sharing the same skillset or broad job description. For instance, we have a Product Design Community.
Among other things, communities have the following goals:
- Maintain good horizontal communication between members of the community
- Organise community-related projects (like shared processes and tools).
Now that we have covered a little bit about the organisation at Alan, let’s get into how designers work collaboratively in that environment!
The basics 🔨
Breaking news: Designers have a dedicated Slack Channel. Among other things, it’s used for small talk among designers as we do not sit next to each other. Design world news, work related questions, angry comments on the last update of Sketch. You name it.
Also on Slack, everyone at Alan writes each Tuesday evening an HPFO.
An HPFO is not an alien spaceship, it stands for Highlight, Progress, Fire, Objectives. It’s a short description of every alaner’s past week and of next week’s goals.
Thanks to HPFOs, each Designer has a quick overview of what others are up to.
Design Lunches 🍱
On Monday, Designers eat together.
Julien, Marion, Nassime (our new User Researcher) and I enjoy “frichti” while Marie (always the picky one 🧐) prefers having her own homemade cooking (it does look yummy though).
The first part of the lunch involves small talk and catching up with each other on how things are going in our personal lives (Julien will make fun of Marion’s tiny accent; we’ll talk about movies or a recent art exhibition, about some topic from Twitter or recent news on Elon Musk, why Z-Note Post-its are glued in such an unusable way or how AR/VR will change the future of portable productivity computing). In other words, anything’s game.
The second part, after lunch, is about sharing work that may have impact on other designer’s work. It can be screenshots of new pieces of interfaces, new flows; the point is to inform the community.
Before every lunch, we each share in the “Design Lunch Google Doc” which elements we want to talk about during our Design Community Lunch. This way we can add links to ongoing work so other Designers can look at things in more detail and we can make best use of the time in-person together.
Design Reviews 🔎
Alan’s methods are very much about leveraging collective intelligence.
Designers working on an important new piece of interface can call for a “Design Review”. Design Reviews can happen at several stages of a project:
- Early stage: Review covers the very basis of the project (Is it something we should do? Is it the right approach? How can we make the project better?)
- Draft: Review covers the usability and visual aspects
- Last check: Close to finish, Review is in regard to UI and Interaction details
The Review is done in about 30 minutes with 2 reviewers (Product Designers). The reviewee has 5 minutes to introduce the context (goals, background) and share a link to the presentation.
Reviewers take 15 minutes to test the demo in silence, while taking notes.
Reviewers then share their feedback
The reviewee is then free to iterate on their project as they see fit. We’re big believers in distributed ownership (meaning, the autonomy of decision-making for all Alaners.
Mentoring and 1 on 1s 🙌
It’s important for us at Alan that everyone is given the chance to grow in the direction they want. One of the mechanics we use is direct mentoring through “1 on 1s”.
“1 on 1s” are in-person (or video) 45-min discussions that happen on a weekly or bi-weekly cadence. We usually walk during “1 on 1s” which is a good way to liberate the speech and do some exercise.
Alaners are free to be coached by any other Alaner (not necessarily in the same community). So if you are interested in developing Project Management skills, you can ask to be coached by a Product Manager, e.g.
“1 on 1” discussions usually have a “meta” nature (a word that we like a lot).
We do not talk about the work directly, we talk about how we can do the work better or more efficiently, at a personal or company level. It is also the opportunity to discuss personal growth paths and how that fits with Alan’s evolutions.
Other topics that might be discussed:
- Better ways to communicate with others
- Best Practices for approaching product thinking or ideation
- Personal projects or areas of mutual interest
- What we like/dislike in our current activities
There is plenty of good writing elsewhere on how to conduct “1 on 1s” such as this essay. Here is a high level view on one way to set them up at Alan:
- Both participants keep notes privately during the week about frustrations, questions, topics of inquiry
- Ahead of the meeting, share with the other participant the list of topics you’d like to discuss based on your notes from the week
- After the meeting, keep quick notes of the exchanges to feed future discussions or your own thinking during the week ahead
Final note: At Alan, “1 on 1s” can come with a coach/coachee relationship (One person is here to help the other, it’s mostly uni-directional) or with a peer relationship (The two people are on the same level and are exchanging advice).
As the team is relatively small, all designers additionally have “1 on 1s” with every other Product Design Community member every week or every other weeks.
What’s next ?
The team is growing fast and we constantly evolving our methods.
For now, the Product Design community is composed exclusively of senior Designers (10+ years of experience) with a large scope (Product thinking, UX, UI). Hopefully the above has given you a clear and transparent picture of how Designers collaborate currently at Alan.
We are currently expanding the design team with new hires. New team members will inevitably introduce new ways of working collaboratively with one another inside of our crews and community!
Thanks for reading!
