The GitLab design project is primarily used by the Product Design team to host design files and hand them off for implementation. It includes our open source Sketch pattern library, prototypes, and work-in-progress files. For details, please visit the project README.
The GitLab Design System, Pajamas, was developed to increase iteration speed and bring consistency to the UI through reusable and robust components. This system helps keep the application DRY and allows designers to focus their efforts on solving user needs, rather than recreating elements and reinventing solutions. It also empowers Product, Engineering, and the Community to use these defined patterns when proposing solutions. It is currently a work in progress.
Our SVG repository manages all GitLab SVG assets by creating an SVG sprite out of icons and optimizing SVG-based illustrations.
We use the Jobs To Be Done Framework to encourage thinking from the customer's point of view and keep focus on the value customers are looking for. If you are completely new to JTBD, we suggest you start with an overview:
Some hints for writing Job Statements:
Getting the granularity and scope of a Job Statement right is difficult. It will depend on several factors, including the stage group and goals of the product team. Some jobs are very big, and some are small micro-jobs. To get to the right level of granularity, think about the area where you want to innovate or improve. The Job you identify should be the scope that helps you understand the problem you are solving, the problem space, the Job Performer, and their needs, situation and outcome around the job, to a detailed enough level that it will support the product and design decisions your team has to make.
One thing to be careful of is to make sure your Job Statement truly reflects a job and not a task. Some people really like this * flow diagram for figuring out if something is really a Customer Job.
Some additional resources you might find helpful:
Synchronous design feedback is an effective tool for capturing design feedback from stakeholders and team members.
There are many ways to gather feedback in a sync-meeting, one example is to use a Round Robin turn-based structure that gives everyone on the call an opportunity to share their thoughts quickly and effeciently.
This conversation should be timeboxed to 15 minutes, so remember to be concise and have fun with it! If you ever need inspiration for feedback, consider taking a few different hats for a spin!
The setup is very simple. Before the sync session, prepare the agenda by pasting a link to these notes. As the meeting starts, look at the attending members' names and form a randomly ordered list. This will be the order for participants to go in. Make sure to put this ordering into the agenda.
The designer will kick off the process by quickly reviewing the rules and starting the 15-minute timer. After the timer has started, the activity goes as follows:
As a participant, you can do a few different things on your turn. Try to be quick, as each turn should only last around 1 minute. During your turn, you can do a few things (in order of priority):
Remember, the goal is to capture a quantity of specific feedback. While it may be tempting to start discussions around the design choices and feedback, this activity doesn't make for a good forum. The designer will follow up with discussions asynchronously afterward in the issue(s) to start discussions and conversations around the feedback.
Mural We use Mural for collecting design feedback, mapping workflows, brainstorming, affinity mapping, and anything else where we need a visual, whiteboard-like workspace.
Everyone in the UX department and all Product Managers can get a Mural account with the ability to create new Murals. If you want to share your Mural to get feedback from members of your team who do not have a Mural account, you can send an anonymous link via the Share dialog.
The UX Research project contains all research undertaken by GitLab's UX researchers and is only used for the organization and tracking of UX research issues.
Once each quarter, we run a System Usability Scale (SUS) survey to measure user perception of the GitLab product. We send the survey to members of the wider GitLab community, with the goal of asking for a response from any individual no more than twice per year.
At GitLab, we want everyone to be able to contribute. To that end we created First Look where we accept applicants to participate in various studies and testing.
User personas represent the people who actually use GitLab. The UX and Marketing teams use personas to inform decisions around the user experience and design.
The UX design archive is a collection of key design issues broken down by specific areas of GitLab. It is not a comprehensive list. It is intended to shed insight into key UX design decisions.
Not only do our team members create great work for the wider GitLab community, but they also create some amazing industry-related resources to push our craft forward.