Design collaborator's playbook
What’s it for? This page acts as a quick reference of mental models for sync and async collaboration. Its purpose is to create a common language for collaboration between designers, GitLab team members and the broader GitLab community. It should be used to understand and label patterns in collaboration, pain points, where we get stuck and how to get unstuck. It is not our design workflow.
Why is this important? Collaboration is one of GitLab’s key values. At GitLab, we believe that everyone is a designer and everyone can contribute. This means the UX department is a humble facilitator of design. The design team can support collaboration across GitLab (and our broader community) by leveraging and sharing the mindsets, methods and tools of design thinking.
Mental models
2 steps forward, 1 step back design
At GitLab we ship using the Minimal Viable Change (MVC). Designing in this context can often be confusing for newcomers because it’s important to consider the big picture as well as the steps for how we get there. To deal with this dichotomy, we design by initially thinking about the mid to long-term vision and then reducing the scope of the experience (in a lovable way) to make implementation quicker. In other words, we design by taking 2 steps forward and 1 step back.
Actions
- Use this model with your team to break a vision down into a series of small (MVC) issues
Divergent & convergent thinking
From a young age we are often trained to jump to solutions as quickly as possible. This prevents us from taking the time to explore fully all our options. We can overcome this challenge by understanding and leveraging divergent and convergent thinking. These are two of the foundational modes of creative problem-solving:
- Divergent thinking (go broad): Generating lots of different ideas and exploring options without too many constraints in place.
- Convergent thinking (focus in): Reflecting on your options and ideas, combining them together in unique ways, analysing them, and converging on a solution (with constaints in mind).
Actions
- Watch short video
- Discuss with your team whether it is time for diverging or converging
- Leverage a synchronous collaborative cycle
- Summarise text in a divergent thread and ask to converge on a solution (example)
Ladder of abstraction
We can’t design in isolation. All the decisions we make are in the context of a broader system. We must zoom in and out between the system and its component parts to do our best work. Unfortunately, humans can only hold 5 (plus/minus 2) pieces of information in working memory at any one time (see cognitive load, Miller’s Law). Therefore, we need to think at different levels of abstraction to manage this limitation. The ladder of abstraction is a useful mental model to recognise what level of abstraction you are currently working in. You can move up the ladder (more abstract) by asking “why?” or “what does that mean?”. You can move down the ladder by asking “how does that work?” or “can you give me an example?”.
Example:
- Very abstract: “This is how I commute to work”
- Moderately abstract: “This is my personal transportation device”
- Concrete: “This is a bicycle”
Actions
- Read “Up and Down the Ladder of Abstraction”
- Use the “5 Whys exercise” to move up the ladder of abstraction
- Use sketches and prototypes to move down the ladder of abstraction
Resources
- Salesforce Workdifferently
- Salesforce Workdifferently: An Introduction To The 6 Principles To Work Differently (video)
- IBM enterprise design thinking
bed95a10)
