Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab Design
GitLab Design
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 268
    • Issues 268
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 2
    • Merge requests 2
  • Requirements
    • Requirements
    • List
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLab DesignGitLab Design
  • Issues
  • #797

Closed
Open
Created Dec 17, 2019 by Nick Post@npostDeveloper

Pajamas: Actionable Principles Update

TL;DR

I broke this down from #789
Let's update our design principles to be more specific in describing GitLab's unique end experience

Problem

From the perspective of a relative newbie to our beloved Pajamas - I feel we are lacking design principles that are specific enough to be used by anyone as a decision-making framework to judge whether or not a new design is representative of GitLab's experience. Right now, IMO having a principle like Human is more of a hygiene factor in good UX design rather than something that represents how GitLab uniquely feels.

When I have designed principles in the past, my most influential bit of reading was from Luke W's "Developing Design Principles":

In order to be most effective, however, design principles need to provide teams with a way to gauge design decisions. That is, they should be specific enough to help groups of people choose between different design options. Unfortunately, many team's first tendency when creating design principles is to go too broad. Principles like "make it easy to use", "keep it fast", or "put the user first" are usually some of the most common ideas that spring to mind.

As stated in the above article, I feel like our design principles are too broad, and thus, I find it difficult to use them as a decision-making framework in my design process. For example, when I tried laddering the principles whilst designing new areas of Analytics, the results didn't yield anything unique to GitLab.

Solution

Updating our design principles to be more specific Revisit our principles by performing a cross-product UX research & design project across...

  1. Current design team practices - How each stage group applies principles currently
  2. Brand - How we position our product to customers
  3. Customer insights - How customers feel when using our product
  4. Cross-functional collaboration - How we use principles as a tool with Engineering and Product

Example(s)

  • https://atlassian.design/guidelines/designPrinciples/design-principles
  • https://www.lukew.com/ff/entry.asp?854
  • https://principles.design/
  • https://inclusivedesignprinciples.org/
  • https://principles.adactio.com/#formats

Cheers

/cc @gitlab-com/gitlab-ux

Edited Dec 20, 2019 by Jeremy Elder
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None