OVERVIEW

GitLab Inc. is the open-core company that provides DevOps software that combines the ability to develop, secure, and operate software in a single application. GitLab has been fully remote since it was founded in 2014. There are no offices as GitLab team members are spread across 60+ countries around the world! We literally wrote the (play)book on remote culture.

As Senior Product Designer in the Secure + Govern stage group, I work alongside PMs, development teams, and other designers on the application security features of GitLab. I am the lead designer for the Threat Insights group, which encompasses Vulnerability Management and Dependency Scanning. This includes showing vulnerability findings across pages (Merge Requests, Pipelines, Vulnerability Report), showing statistical data on the Security Dashboard, and enabling and configuring the security scanners. The stage spans across the entire CI/CD process and is an important consideration pre-release in addition to post-release.

I often collaborate with the Growth team to consider the learnability and discoverability of our features in the product; considering things like:

• How might we help users get started on application security with our vulnerability management features?

• How might we show users how much more they could be getting if they upgraded tiers, without spamming them or making them feel like we’re bombarding them with “ads”?

• How might we show Ultimate users the value of all that we offer if they’re not taking advantage of some features but would benefit from doing so?

GitLab’s company OKRs always include winning with security and compliance, as they are the driver for the majority of our Ultimate accounts (the highest paid tier).

In addition to my stage work, I also contribute heavily to our design system, Pajamas, in defining and maintaining our component library in Figma and at design.gitlab.com.

HIGHLIGHTS at gitlab

the following were initiatives or projects i’m particularly proud of:

• Whenever I see opportunities for process improvements in the way we work, I open up a Merge Request to propose a change to the our company handbook (which is open to the public and referenced internally several times a day). Here’s an example of an improvement I proposed to how TAMs (Technical Account Managers) interact with the Product team.

• I created a performance feedback survey so that my team could give me continuous anonymous feedback on my performance, so I don’t have to wait for our annual 360 reviews to address any areas of improvement.

• In 2021, 2023, and again in 2024, I was nominated by one of my peers as exemplifying our company values of results, efficiency, transparency, and collaboration from which I received a discretionary bonus. The peers that nominated me spanned a range of roles I collaborate closely with; the first nomination came from my Technical Writer, the second from my Product Manager, and the third from a fellow Sr Product Designer.

CASE STUDY 1 OF 3: UX ROADMAPS

UX Roadmaps are comprised of UX themes, which are bundles of work organized around the user problem, their need, and their desired outcome. UX Themes comprise a team's UX Roadmap, which should act as a single source of truth for a team's North Star UX vision, serving as the blueprint for their strategy. In essence, themes are a wrapper that looks at all the individual issues a group may have and organizes them into relational bundles, allowing solutions to be holistic and non-fragmented. A UX Roadmap is simply the prioritization of these UX Themes based on user and business needs while also considering your team's confidence in the supporting data.

In this presentation, I’ll walk you through the benefits of a UX Roadmap workshop, what we learned through piloting this initiative, and finally, I’ll share the FY25 UX Roadmap for my team at GitLab. The pilot was a collaborative effort between myself, my PM, and my design manager who facilitated the first UX Roadmap workshop back in 2021, and I’ve been creating them (alongside my PM) at the start of every year since.

▶️ Click here to view the Google presentation

case study 2 of 3: a journey in solution validation

case study 3 of 3: security scanner status dashboard widget

⚡️ problem to solve

Currently in our product, a security engineer has no way of confirming that the security scans on a project are enabled and working properly across projects in a group. The current workaround is to go into each project in a group and check the Configuration status, and then check the pipelines to make sure the jobs are succeeding. Therefore, looking at the security job statuses to make sure they’re working properly is critical. The security analyst wants to do this in one view that shows all the projects he’s monitoring, rather than going into them one by one.

Think about it this way: imagine that you own 100 McDonalds franchises and want to make sure that they’re all meeting their sales goals. Rather than viewing the status of sales for each store, and doing that 100 times, you’d rather have a page that tells you which stores are NOT meeting their sales goals, so you can dig into these ones to figure out why and how to fix it. In the same way, the security analyst only needs to see what’s not working as expected so they know what problems to be solved which helps them be more efficient with their time.

⚙️ the process

1. First, I opened an issue as the SSOT (single source of truth) for designs and discussion in the name of collaboration and transparency. In the description I made sure to include the following:

   • Problem we’re trying to solve

   • JTBDs and/or user stories

   • Link to information about the persona

   • UX goals

   • Scope (what absolutely must go into an MVC (minimum viable change) vs what can be added in future iterations, what resources do we have available, success criteria, etc)

   • Documentation

   • Design handoff and specs (including a link to the Figma file)

   • Links (e.g. to the research issue)

   • Related issues

   • Milestone - part of this process is having a conversation with my PM to decide where this feature falls in the prioritization of existing and upcoming roadmap items, and if there are any other engineering or design dependencies that would have to be built first

   • Appropriate labels

   • /cc relevant team members and stakeholders for awareness

2. Once all of that has been identified, we decide where we are on the validation spectrum:

It’s important to do problem validation if the customer problem isn’t well understood, or we want to make sure this is affecting a large number of customers (and not just one noisy one!).

2.a. In this case, we felt like we understood the problem and the significance of the potential benefit of finding a solution, so I created user flows, did some comparative evaluations in other tools, and then started on design explorations.

User flow - before

User flow - after (ideal)

💡 Comparative evaluations

🎨 Design explorations

2.b. From here, we started to narrow in further on 1 or 2 possible solutions, which then required solution validation. For this, we either use internal employees, customers, recruit participants, or UserTesting.com, depending on the time constraints, our confidence levels, and the impact of the change in the product. For this, we went with UserTesting.com. This included:

• Writing a research script (which includes our goals, hypotheses, assumptions, participant profile, and list of tasks)

• Creating a screener (to make sure we get the right type of users fitting our persona)

• Creating and testing prototype(s)

• Putting the instructions, prototype(s) links, and tasks into UserTesting.com

• Asking a UX Researcher to review

• Launching the test

Success criteria: We were looking for a minimum 80% completion rate of all tasks. I also included a question where the user ranked (on a scale of 1-7) how useful the feature would be to them in their work. For this, we were looking for a minimum average score of 5 out of 7.

3. Research synthesis and insight generation

If the feedback is mixed, I’ll sometimes create a Mural (online whiteboard) where I’ll post the designs and then add color-coordinated sticky notes calling out areas where participants struggled or, on the other hand, things that worked really well. Here’s an example of that from another project:

However, for this security scanner status dashboard widget, the feedback we got was positive and consistent, so I summarized the findings in the Solution Validation issue (https://gitlab.com/gitlab-org/ux-research/-/issues/1337#result-overview).

Note: Since this project we started using Dovetail to store research videos and transcripts, add tags and highlights to the videos, and then create research insights to share out to the team. See an example of a Dovetail research project here: https://dovetailapp.com/projects/3USNZ4MNLlhYwtp7d0bI6E/v/7oyogXtrUK5KI4xl6jN20V/present

4. After solution validation is complete, I made iterations to the design based on the research insights, and started a design review process with my team. You can see that conversation in the activity timeline in the design issue. I collected feedback from my PM, design manager, fellow development counterparts, fellow designers in Secure, as well as designers on the foundations team that manage our design system. Any feedback or ideas that were out of scope I put into a post-MVC issue here: https://gitlab.com/gitlab-org/gitlab/-/issues/325878

5. After the design was complete and finalized (which includes considering accessibility concerns, responsiveness to various devices and screen sizes, and edge cases like error states and empty states), I handed it off to my PM to work with the EMs (Engineering Managers) on taking it into the Build track, which includes planning breakdown. When the devs start working on building out the feature, I make sure we stay collaborative in case there are any technical restrictions that will require UX decisions and/or design iterations. We stay in the loop asynchronously via GitLab issues and Merge Requests, Slack, and synchronously via our weekly stage meeting.

6. Before the final release, I conduct a final UX review to make sure the built component matches my design specs.

7. Finally, post-implementation, we look at quantitative data to see how many customers are using the new feature, and collaborate with TAMs in case any customers have feedback about it. This feedback would get carried into the post-MVC issue so we can address any concerns in the next iteration. If we think a feature will generate a lot of feedback, I’ll open a feedback issue and provide a link to it in a banner on the page so customers can communicate with us directly. (Here is an example of one of those feedback issues: https://gitlab.com/gitlab-org/gitlab/-/issues/225991)

🙌 Final design

Example of component specs

Example of filter specs

⚠️ challenges

• Of course, not all projects run smoothly from start to finish. The biggest challenge I encountered with the security scanner widget was scope creep. One of GitLab’s values is iteration itself, in order to do the smallest thing possible and get it out as quickly as possible. That said, we’ve encountered problems when only designing MVCs (Minimum Viable Changes) because we’re not fully advocating for the user and their needs if we’re only working within the current design or technical constraints of the product. My design philsophy is to design the ideal experience, and work backwards from there to come up with iterations as a pathway there. However, a few times, I let design feedback stretch my brain like silly putty in all directions, which started to delay the design handoff to development. Once I caught the scope creep, I opened a new issue (Design | Post-MVC | Group-level Security Dashboard widget: Security scanner status), in order to make sure that the great ideas and considerations didn’t get lost in the original comment thread, and so that my peers leaving such valuable feedback knew that their input was valued and would be included at the right time.

senior product designer responsibilities at gitlab

Skills

• Product knowledge | Deeply understand the technology and features of the group(s) you are assigned and proactively learn others.

• Research | Independently conduct solution validation with minimal guidance from your Product Design Manager and incorporate insights into design decisions to fulfill user and business needs.

• Deliverables | Create deliverables for the group(s) you support (for example: JTBD, UX Scorecards, competitive evaluations, low fidelity wireframes, high fidelity mockups, prototypes, journey maps, storyboards, design vision, etc.) that help define the vision and execution of solving real user problems through the user experience.

• Communication | Communicate the results of UX activities with a strong point of view to the UX department, cross-functional partners with your group(s), and other interested GitLab team-members using clear language that simplifies complexity.

• Usability | Proactively identify both small and large usability issues within your product area, and help influence your Product Design Manager and Product Manager to prioritize them.

• Iteration | Lead and coach iteration of design work within the validation track for your group(s).

• Design system | Actively contribute to the Pajamas Design System, help determine whether components are single-use or multi-use, and provide recommendations to designers regarding new component requests.

• UI copy | Collaborate early and often with a Technical Writer on microcopy to ensure user experiences are efficient. Help improve docs and incorporate documentation within the UI as needed to assist users in moving through their workflows.

• Design reviews | Participate in Design Reviews, and model best practices for giving and receiving feedback.UX debtHelp reduce the creation of additional UX debt with MVCs and advocating within your group(s) the importance of releasing value to users. Identify and influence the prioritization to fix UX debt when it occurs.

• Public presence | Help promote GitLab publicly by writing blog articles, giving talks, publishing videos to GitLab Unfiltered, or responding on social media, where appropriate.

• Cross-stage collaboration | Support your Product Design Manager and Product Manager in identifying dependencies between groups and stages and advocating for cross-stage collaboration when needed.

• Mentoring | Mentor other members of the UX department, both inside and outside of your group(s) on how to approach design problems, solicit feedback, and drive for impactful outcomes.

Values

• Collaboration | Models collaborative behavior for fellow team members and others within the group.

• Results | Models a sense of urgency and commitment to deliver results.

• Efficiency | Models a culture of efficiency within the team where people make good, timely decisions using available data and assessing multiple alternatives. Models using boring solutions for increasing the speed of innovation for our organization and product.

• Diversity, Inclusion & Belonging | Actively aware of how bias or exclusion might occur on a team and helps to facilitate a team environment where team members belong and feel safe. Models empathy with their interactions with customers and cross functional team members.

• Iteration | Independently balances short term gains and long term benefit. Identifies opportunities to model the processes around iteration. If a colleague privately asks a question, asks the question in a public channel (if they don't know the answer). Models a growth-mindset by exposing the limits of your knowledge and demonstrating the machine you've built to fill those gaps.

• Transparency | Continually surfaces improvements across their functional area of expertise. They share feedback with others and understand how to disagree and commit to final solutions. They model what it means to be as open as possible.

Remote competencies

• Manager of one | Develops their daily priorities to achieve goals.

• Effective communication | Uses asynchronous communication as the starting point and stays open and transparent by communicating via text through public issues, merge requests, and Slack channels (over DMs). Places an emphasis on ensuring that conclusions of offline conversations are written down ensuring a Single Source of Truth and producing Video when necessary.

• Handbook first | Actively contributes to the handbook. Everything starts with a merge request. Provides links information from the handbook when answering questions and if the information doesn't exist in the handbook, then the team member adds it.

• Uses GitLab | Knows when and how to open, comment, close, and move on issues while utilizing an issue board. Understands and knows how to open and submit a merge request. Models how and when to use epics. Uses GitLab for managing day-to-day work.

Growth

• Adaptability | Demonstrating a willingness and ability to learn new skills and apply them to be successful under new, tough, or difficult conditions.

• Expandability | Expandability outside their areas (laterally or vertically), with the willingness and ability to take on a role of greater complexity, impact, and scope.

• Consistency | Demonstrating effective problem-solving capabilities and the consistent delivery of results over time in changing circumstances.

• Self-Awareness | The depth to which an individual recognizes skills, strengths, weaknesses, blind spots, and is able to reflect and act to improve and invest in their own development.