Pajamas: Define Conceptual Object Model
TL;DR
Let's clarify our design system's architecture by including an object model
as a dimension in our structure
Problem
From the perspective of a relative newbie to our beloved Pajamas, I feel like we would benefit from an update to some of the more "top down" or architectural aspects of a design system. I have a feeling this issue is going to be super abstract, but I will do my best to make it as tangible as possible.
I feel we are lacking a conceptual/object model to describe how our product fits together and how our key objects (e.g. Issues, MRs, commits) are represented, behave and feel across the product (i.e. properties and functions).
In the "Full Stack Design System", Intercom's designers highlighted that a shared object or conceptual model is often missing from many design systems:
A shared conceptual model of your product. This is the diagram you’d draw on a whiteboard to explain how your product works at a system level. What are the main objects in your product? How do they interact? Here are examples of possible objects in products you know:
- Facebook: Friend, Post, Message, Event, Page, Group.
- Airbnb: Listing, Host, Guest, Trip, Experience.
- Slack: Team, Member, Channel, Message, Reaction, Thread.
- Intercom: Customer, Teammate, Message, Conversation, Article.
At GitLab our core objects are things like Issues and MRs.
I have seen hints of trying to diagram how our product fits together by product marketing such as the GitLab Workflow and the DevOps lifecycle, but these tend to focus a bit more on the process (HOW) rather than the objects or data that you interact with (WHAT) and how those feel.
Why are these things are important?
- Greater product context - GitLab is a large & complex platform. It is sometimes difficult to understand how the thing that you are designing within your stage group fits into the broader picture. Having more clarity on the architecture could improve a designer's understanding of how our product fits together - leading to improved user flows and a reduction in stage or group level siloing.
-
Object Consistency - As our product grows, the way we interact or represent foundational objects within GitLab (such as Issues or MRs) could potentially feel very different without explicitly defining the DOs and DONTs of an object rather than just its components, regions or page design.
- For example, at the simplest level, am I visualising line changes (a property of the MR object) correctly in my Code Review Analytics table compared to how they are visualised within MRs or Lists? But to take this further... how should MRs look and behave at different levels of abstraction?
- More clarity for marketing & comms - Again, because of its size and complexity, I have found explaining GitLab to friends and family a rather difficult task. By having a more digestible architecture and principles, we could potentially make our product easier to explain to lay people like me.
Solution
Introduce a conceptual/object model to our structure
- Holarchical - An object can potentially be composed of other objects (e.g. A project is composed of a repository, issues & MRs) Objects have some of the following basic properties:
- Heritable - An object can potentially inherit properties and behaviours from other objects (e.g. An issue can inherit a due date from an epic)
- Abstractable - An object can be viewed at different levels of abstaction and show only subsets of properties and behaviours based on its context (e.g. an issue page vs issue card in a board)
Proposal: Ideate around how we can better illustrate our object/conceptual model:
- Collaborate with Product & Engineering
- Figure out how what we design is connected to GitLab Workflow and the DevOps lifecycle
- Test with newbie GitLabbers and customers to refine
Summary
Ultimately, I think if we crack these things, they could be used throughout GitLab rather than just by designers. The "Salesforce Advantage" model originated in the design team and has since been taught to every sales person as a whiteboarding tool to explain what Salesforce does and how it works.
Hopefully, this wasn't too confusing. I would love some feedback from people more experienced than me!
Example(s)
• Jeremy's whiteboarding video for analytics
GitLab workflow & lifecycle
GitLab Workflow | DevOps lifecycle |
---|---|
![]() |
![]() |
Object model examples
Salesforce Advantage whiteboard diagram | Simplified Salesforce object flow relationship | Intercom's conversation object |
---|---|---|
![]() |
![]() |
![]() |
Cheers