### How do we determine if the topic is cross-stage design
Platform-wide experiences often require Product Designers to collaborate across multiple stage groups. This page provides guidance on effective cross-stage collaboration.
There are several points during the design process where we might identify cross-stage collaboration needs. It is recommended to involve potential partners as early as possible. It is best to determine if there is a collaboration need quickly rather than have to backtrack later when it is too late.
## When to collaborate across stages
**During the discovery and research phase**, it is essential to pay attention to the user journey or other types of research reports; from the research insights, we can assess if the user is using multiple features that cross-stages or if the pain points involve features owned by different teams.
Consider cross-stage collaboration when:
**During the design phase**, there could be signs that we need to contact other teams for potential collaboration. First, the target user is the primary persona of another stage; second, the use case you are targeting is part of a JTBD belonging to another stage; third, the feature you are designing exists in a page/area belonging to another stage; and last, some part of the user's journey is using some features that belong to another stage.
- User workflows span multiple product areas
- Design decisions impact experiences outside your stage group
- Platform-wide patterns or navigation are involved
- Multiple teams are solving similar problems
**For Pajamas contributions**, it is a collaboration-first approach. When designing a component, we want to ensure that the component is suitable for all areas. When we design reusable features and components, such as search or filtering, it is better to collaborate with more than one designer to consider the frequency and complexity of these features in the product.
## How to collaborate effectively
### How can we find the right DRI for a particular feature
**Start with connection:**
GitLab has a wide range of product features. Several resources can help us identify the [Directly Responsible Individual (DRI)](/handbook/people-group/directly-responsible-individuals/) for each feature:
- Reach out to designers in affected stage groups early
- Share context in Slack, issues, or UX Forum
- Invite relevant designers to design reviews
- Which feature belongs to which group: use the [category page](/handbook/product/categories/) and the [feature page](/handbook/product/categories/features/)
- Who is responsible for the feature: use the [team page](/handbook/product/categories/#dev-section)
Ask in the [#ux-coworking](https://gitlab.slack.com/archives/CLW71KM96) channel if you can't find the answer using the above resources
**Work together strategically:**
### When should we contact the other team(s)
- Align on shared user workflows and goals
- Identify dependencies and overlapping work
- Challenge each other's assumptions
- Build on each other's ideas
During the planning phase, if you can anticipate a certain amount of effort will be needed from other team members, it's better to contact them as soon as possible. Suggestions:
**Stay coordinated:**
- Contact the other team(s) **before** problem validation if we can anticipate that they may want or be able to contribute to the research.
- Contact the other team(s) **after** problem validation in relation to the research insights if a collaboration opportunity was uncovered during the research.
If, for some reason, another relevant team was not involved before problem validation, make sure to involve them as early as possible in the design discovery and exploration process and provide opportunities for the other team(s) to provide feedback on the ideal future-state design, to avoid duplicative work.
- Keep communication asynchronous and transparent
- Document decisions in issues and epics
- Share progress in UX Forum
- Loop in Product Design Managers for strategic alignment
### What kind of information would be helpful for teams for better cross-stage collaboration
## Resources
**At the problem validation stage**, the goal of the collaboration is to make sure the problems are the right ones to solve by all parties, so it's recommended to have the following information:
-[UX Forum](/handbook/product/ux/ux-forum/) - Share work and collaborate with the broader team
- A research plan (or at least some research questions or a hypothesis to be answered)
**At the design stage**, the goal is to design a solution together that matches all user needs and workflows. Therefore, it is essential to have clear documentation of the following:
- How the feature works: both from the user's point of view and a technical point of view.
- The precise problem statement, JTBD, and persona(s)
- Relevant user feedback/ UXR insights and data
- Design scope and urgency: this helps all teams figure out a prioritization and collaboration plan
### What needs to be agreed upon for better cross-stage design collaboration
To execute effective collaboration, come to an agreement on the following with your team and relevant design partners:
- Prioritization: It is ideal if all teams agree on when this problem needs to be addressed, and both the leading team and supporting team should plan together. However, if one team needs the feature sooner to solve confirmed user pain points, the team can be the DRI and move forward with an MVC. At the same time, keep the discussions ongoing for further design, research, and development plans for the next step.
- Effort and timing: Based on the prioritization, all teams should agree on clear effort needs from each team and the time frame for the project.
- Who leads the collaboration: There is no definite answer to who is leading the design and implementation. In general, consider the urgency of the need and the capacity of both the leading designer and the designer who provides support. For example, if two different teams will lead the implementation and design, the implementation should be at most six months after the design effort is done.
### Cross-stage design collaboration frameworks
The collaboration methods can be flexible. You can collaborate like [design pairs](how-we-work/#https://handbook.gitlab.com/handbook/product/ux/pair-designing). Or use formal frameworks to help designers work together, consider using those, especially when there are more than two designers. [Design Pod](/handbook/product/ux/how-we-work/cross-stage-design-collaboration/design-pod) is a framework that has clearly defined roles and responsibilities and is tasked with achieving a high-impact business goal. If the design collaboration is more aimed at exploitation without a clear business goal, consider using a Design Jam instead.
### Tips for cross-stage collaboration
- Keep a single source of truth in one issue/epic.
- Have a list of todos and be sure to check them off when complete so that it is clear and straightforward to everyone what the current status is and what still needs to be done.
- Have a "parking lot" issue to put future (post-MVC) ideas/ discussions in.
- Have a sync session or record a video walking through the prototype to show the context of the product.
Always assume positive intent (and other communication tips per our handbook). And keep in mind that all GitLab users are essential, not just those that our stages tend to prioritize.
Strategic partners collaborate organically, not through rigid processes. Trust your judgment on when and how to collaborate.
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](https://design.gitlab.com/get-started/principles/) and [Product Designer Workflow processes](/handbook/engineering/ux/product-designer/#product-design-process). 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](https://monday.com/blog/project-management/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::<namehere>, 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](/handbook/communication/#multimodal-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]
