Add "Design System" as a category
Why is this change being made?
Evaluate the category of Design System at GitLab to compliment Design Management category.
The focus of this new Category will allow you to manage, version, document, and publish your design system with GitLab.
Competitors
High-level feature list for a GitLab roadmap
- Integrate with Storybook, possible as a repo or Page type which would be like Static Site
- Integrate with Static site editor to boost editability of Storybook components for better docs
- Visual inspect collab on Design Components with something like Pastel
- Stats on component use and Design System health in the app production repo. Example, used
.btn
30,000 time,.btn .btn-lg
- 232 times.
Interesting learnings and observations
- Chromatic is a paid app on top of the Storybook which is open source. Chromatic includes the functionality of testing components AND visual bug reporting jut like Pastel to create a seamless experience for a design system. We could take this a step further with our repo and testing abilities.
- We validated that Pastel has a feature set wanted by our designers at GitLab, this would be a perfect add on to Design Systems and Review Apps.
- Understanding Pajamas:
- I took time with @tauriedavis (Pajamas DRI), @deuley (PM on tracking our Pajamas use) and @ericschurter (PM of Static Site and used to work at Invision so big insights) to start a super rough diagram that illustrates how our concept of "Pajamas" is a system around 4 repos. Storybook is one aspect of that on GitLabUI: https://gitlab-org.gitlab.io/gitlab-ui/
- Current process for a new design system component at GitLab
- Stub out the element in Pajamas repo with
TBD
Demo. Example GitLab Design Component before Storybook - Build the component in Storybook by committing code to the repo. Example documented component in Storybook
- After it's "Done", embed the story as a demo back in the Pajamas repo. Example in GitLab Design with embedded Storybook Demo
- Stub out the element in Pajamas repo with
- In order for our team at GitLab to be able to use a Storybook implementation we need to upgrade it to allow for more documentation, examples and integrated testing. We could potentially merge Pajamas and Storybook into one if we do more work to define the needs.
The main decisions:
Could these features exist in Design Management?
The short answer is yes, but given the current direction of Design Management most of the Design System features were considered long term and under the "evergreen features". If we move this into its own category we can move these up in parallel with the rest of Design Management and get an earlier start on the market.
These features could also complement current Design Management features as we will be able to implement Design Views on repo assets or other areas of the Design Management workflow.
A new category would also simplify this for our customers as I always need to explain the differences.
Can we move forward with enough of an MVC to justify the category even with a team that is small and split across 2 categories already?
Right now we are approaching Viable with Design Management. We need more customers to drive the move to Complete so while we market it, we could potentially pause at Viable and move forward with some very lightweight integrations of Storybook to start. Perhaps just a Storybook Pages site template.
Business Case
Market size estimations
- Forrester claims: "50% of design teams say they are using a design system, and most say they're using one more than they were two years ago." Digital CX and Design Trends, 2020
- Design systems are used and maintained by Designers and Engineers with awesome frontend and CSS skills and the ability to deeply QA components that go live in the app, it's not just Designers.
the belief that design systems are for designers is a main hurdle that teams have to get over. Design systems are not fully adopted when this is the belief. Organizations have to understand that a design system improves the efficiency of their development teams while also improving the overall user experience in order for teams to invest. GitLab can help shape this story.
- We estimate there are 22M developers worldwide in our investor deck which could mean ~2.75M Designers in 2020
- Since 2017, IBM increased their ratio from 1:72 to 1:8 (Designers:Developers). At GitLab we have 1:7.
- Math: From 1:72 to 1:8, that is ~305k to ~2.75M Designers growth over 3 years.
Paid apps in the space
- For Invision DSM pricing is hidden (but I had a $10k per year quote at a previous job)
- Chromatic - layers on top of Storybook - plans start at $150 per month and go to $650 plus.
- Zeroheight - per user ($0 to $45 per month)
Pain
- Seeing how complex our Pajamas implementation is and having personally maintained design systems spanning a repo and Bootstrap 2, 3 and 4 I recognize how important that this is.
- Interviewing our own team about maintaining Pajamas makes it clear we can make the Storybook integration easier to use and solve problems for QAing a design system
Approvals
-
Stub in category -
Stub direction page -
Do initial competitive analysis on design system market -
Determine business case -
Approvals -
EVP of Product -
VP of Product Strategy -
The Director of Product relevant to the stage group(s) -
The Director of Engineering relevant to the stage group(s) -
CEO
-
-
The following people need to be on the merge request so they stay informed: -
EVP of Engineering @edjdev -
Senior Director of Development @clefelhocz1 -
Director of Quality Engineering @meks -
Engineering Productivity (@gl-quality/eng-prod eng-prod ) -
The Product Marketing Manager relevant to the stage group(s) @jordi_mon
-
Backstory
This MR was created during the May 14, 2020 UX Group call at 7:42 time. View the clip@sytses : Consider adding Design System Management as a category https://about.gitlab.com/handbook/product/categories/ to GitLab and having it as a feature on the group level. We can preload it with Pajamas as an example.
@cdybenko : I will start this investigation
@ebrinkman : Christen, let’s start with a MR and then fill in the gaps with the opportunity.
@cdybenko: EricB, Was going to open an issue - do you want to start with the category itself?
@ebrinkman : Start with a MR to propose creating the category. You can also open an issue as a way of tracking the overall research/info gathering you’ll need to do.