Design Pods

What is a Design Pod

A Design Pod is a design team comprised of two or more Product Designers and other relevant counterparts from various Stage Groups. It has defined roles and responsibilities and is tasked with achieving a high-impact business goal that will specifically affect the user experience of the product across Stage Group workflows. Members will come together to tackle a singular design problem following GitLab’s output design principles and Product Designer Workflow processes. Once this goal is achieved the Design Pod will disband allowing the Stage Group DRI to drive the project to completion.

Roles and Responsibilities (all roles are required)

DRI

The pod’s DRI should be the Product Designer that is most closely related to the problem being addressed’s Stage Group or Section. The DRI will be Accountable for guiding the pod’s design direction. While they’ll work collaboratively with the rest of the Design Pod, as the DRI, they’ll be in charge of decision-making and driving the best strategy for completing the pod’s work. It’s highly recommended that the DRI at least be a Senior Product Designer as the role will require a high level of leadership and organizational skills.

Product Manager (Sponsor)

The Product Manager that is most closely related to the addressed problem. The Product Manager’s Stage Group or Section will need to approve the pod and should also prepare to participate in the oversight. The Product Manager should also expect to be consulted as they often have unique knowledge or insights into the problem space.

Product Design Manager or Staff Product Designer of the DRI

The Product Design Manager or Staff Product Designer of the DRI is Responsible for working closely with the Design Pod to ensure they are progressing and have what they need to succeed. In addition, they may be responsible for helping free up their time to participate in the pod and assisting in recruiting other pod members or securing any tools that may not be available.

Members

Other Design Pod members will consist of Product Designers or Product Managers from other Stage Groups that have some relationship to the addressed problem. Depending on their level of participation, they’ll be responsible for attending meetings synchronously or asynchronously regularly, sharing information learned from the Design Pod with their peers, gathering feedback from their peers, bringing that feedback, and completing necessary tasks to help the Design Pod progress and succeed. Members must work closely with their manager and Stage Group’s Product Manager to ensure they will have at least 30% of their typical time per Milestone freed up to participate in the pod. Use the RACI model to help assign pod member roles based on interest/capacity.

Guidelines

• The DRI and Product Manager, Design Pod sponsors, are responsible for preventing the proliferation of Design Pods and ensuring there is a real need for the Design Pod to assemble.
• A member and DRI should not be a part of more than one concurrent Design Pod in any role.
• It is highly recommended that anyone in the Design Pod work with their Manager to ensure that they will have at least 30% of their time per Milestone freed up to participate in the pod and that the pod work will not adversely affect their Stage Group’s needs.
• Providing accurate updates on the design status is crucial; Design Pod updates might involve a larger group of stakeholders. Be sure the following points are clearly addressed:
  • Communicate which stage of the design process the pod is in, for example: exploration, refinement, validation etc.
  • What type of feedback is needed, for example: product directions, feature suggestions, user interaction, visual design, etc?
• During the exploration design process, consider using sketches or wireframes to indicate that work is still in progress as a concept or incomplete.
• While regular sync meetings are likely necessary, consider adopting async ways to keep each pod member informed; for example: use weekly Geekbot updates in the pod Slack channel.

Process

• Preparation
  • The DRI is responsible for creating a Design Pod Issue or Epic as the SSOT
  • Name it after the problem that is being addressed but keep it brief. Apply ~UX, the primary DRI’s ~group::, and ~DesignPod labels It should be public unless there is a specific reason to keep it private. The DRI is responsible for creating a Slack channel (with #dpod_ prefix) that is public to the company.
  • Assemble the pod team and share the formation of the pod in any appropriate Slack channel(s) to encourage participation.
  • All members together determine how the pod will work collaboratively, whether through consistent synchronous calls or asynchronous periodic check-ins. And add it to the Issue/Epic description.
  • If synchronous calls were determined to be the way, schedule the call and invite all pod members. Set any consulted or informed members to be optional participants, and be sure to share the meeting video with everyone through your Slack channel and any other relevant channel (e.g. #ux, #product).
• Define the addressed problem (both user problems, product, and engineering challenges)
• Define the goal of the Design Pod
• Define the Design Pod team and how they will participate using the RACI model.
• Gather any existing research or data necessary for driving the pod forward to successful completion.
• Gather existing design proposals
• Define What success looks like (if necessary, gather metrics that will tell you success or not, for example, a positive result from qualitative research or a quantitative research goal)
• Organize activities that should provide incremental progress.
  • Workshops (asynchronous or synchronous)
  • Competitive Analysis/Walkthroughs, etc.
  • Figma design collaboration
  • Research (e.g. problem or solution validation)
• Communicate the results
  • Communicate status regularly in the Design Pod’s slack channel
  • Consider regular updates to the progress to #whats-happening-at-gitlab, #ux, and related Stage Group(s) slack channels (take the multi-modal communication approach as a guideline)
• Disband the Design Pod
  • Celebrate. Being able to close a Design Pod is definitely a thing to celebrate!
  • Update the Issue/Epic with the final result.
  • Close the Issue/Epic
  • Archive the slack channel.
  • Delete the recurring calendar meeting.

Participating in an existing Design Pod

Suppose you are interested in participating in an active Design Pod. In that case, it is recommended that you first communicate with your manager and then discuss your involvement with the Design Pod’s DRI. Remember that they may not be in a place to accept new members. However, if the DRI has approved your involvement, you’ve worked with your manager and Stage Group’s Product Manager to ensure you can participate at least 30% of your time per Milestone. You can add yourself to the Design Pod members list by creating an MR against the specific Design Pod handbook page.

Past Design Pods

• (RCA: Role Based Access Control (RBAC) Design Pod, Authentication & Authorization)[https://gitlab.com/gitlab-com/gitlab-ux/ux-rca/-/issues/3]