Document and write guidelines for responsive breakpoints

Problem

Sunjung and I touched on the topic of pre-defined widths for Sketch in our most recent UX Buddy call. I said that we don't really have them but that I know that the FE team uses the Boostrap breakpoints and doesn't really like to steer away from them.

To discuss:

• should we document those breakpoints? UPDATE: there's already a placeholder for them on https://design.gitlab.com/layout/grid, so the answer to this one is "yes".
• should they be added to Sketch as custom artboard presets?
• can we write guidelines for how a designer should approach designing responsive layouts and for using these breakpoints?

Solution

If we do decide we should have predefined custom artboard presets I'd love to have them stored under GitLab breakpoints, instead of Custom.

The following two articles explain how to add presets to non-custom options but I don't think that would work with our gitlab-pattern-library.sketch file:

• https://martianwabbit.com/2014/04/05/Sketch-Presets-For-Desktop.html
• https://www.newmediacampaigns.com/blog/edit-the-default-artboard-presets-in-sketch-3

So we'd probably need to stick with the Custom option in that menu.

If we decide to work on this, whatever comes out of it, should be documented here: https://design.gitlab.com/layout/grid

If nothing else, we should document the breakpoints as there already is a placeholder for them on that page:

I didn't find an existing issue for that so we could use this one.

Example(s)

Usage

Dos and dont's

✅ Do	🛑 Don’t

Related patterns

Links / references

Checklist

Make sure these are completed before closing the issue, with a link to the relevant commit or issue, if applicable. Get familiar with the Sketch UI Kit documentation which has information on updating files, structure, fonts, and symbols.

1. Author: Create a Sketch file in your progress folder with the changes required for this issue. Try to use existing symbols, layer styles, and text styles.
2. Author: Ask another Product Designer to review your personal Sketch file, linking them to your latest commit so they know where to find it. If they have the capacity, they should assign themselves to this issue. If not, try pinging another person.
3. Reviewer: Review and approve author's changes in their personal Sketch file, according to the workflow.
4. Author: Add your changes to the GitLab Sketch UI Kit (pattern library and/or instance sheet), following this step-by-step process.
5. Author: Ask the reviewer to review your changes to the Sketch UI Kit files.
6. Reviewer: Review and approve author's changes to the Sketch UI Kit files, according to the workflow.
7. Author: Create an issue in the Design System to update the design specs and documentation. Mark it as related to this issue.
8. Author: Add a read only (FYI) agenda item to the next UX weekly call to inform everyone of these changes, linking to this issue.

/cc @gitlab-com/gitlab-ux