Design System - III. Principles (Dgraph Cloud)

It is one system. The principles are there to connect the dots.
— Jürgen Spangl, head of design, Atlassian”

Design principles define what good design team means for the team and a tip on how you can achieve it.

Good design principles have the following qualities -

  1. Action-able - It should offer practical guidance on how to solve a design problem.
  2. Memorable - It should be easy to recall, should be referred in everyday conversations.
  3. Opinionated - Principles need to communicate priorities. It should help making trade-offs.

After curating design principles of some products & understanding our use case, I have drafted our principles -

Our Design Principles -

  1. Direction over choice - We want our user to focus on app development and not spend time making a lot of choices on Dgraph Cloud, less clicks more work.

    Example 1 - Set defaults in forms, don’t make the user select.

    Examples 2 - Ask the user what is the type of app, based on that suggests initial settings. Like if the user is building a realtime app - suggest subscriptions.

  2. Enable super users - Our users are developers - who love shortcuts, who love do to more and navigate with the keyboard.

    Example 1 - Focus on HTML elements is important, user should be able to navigate on the app just with the keyboard.

    Example 2 - Frequent actions can be done using keyboard shortcuts, nudge the shortcuts to the user.

  3. Match user purpose - Once a backend is created, the user doesn’t visit often. Get the job done as quickly possible for the user, drive to complete the user intent.

    Example - Pages must have a unique hero action, quick actions must be available, don’t let the user search all over the screen.

  4. Build toy-like interactions - unbreakable - Our users are smart, fast-moving, and very ruthless. One small mistake, one glitch, the product gets a label and its hard to win back our user. We need to ensure each interaction is reliable and it is very important to have robust error handling. We need to build a toy for a baby - which unbreakable, with no sharp edges.

    Example - Think of boundary conditions - what if the user navigates away without saving some settings? What to do if service fails? All need to addressed.

Principles are not permanent, they can evolve based on product direction and purpose. Use these principles to make your design choices.

Feel free to comment!

Case Studies -
Dashboard Redesign

Resources referred -


I agree with all these principles, and they carry over to the extended ecosystem (slash-graphql client) as well

1 Like

I like the shortcuts idea. Wouldn’t have thought of that if I didn’t get the chance to collaborate with an engineer on this.


Just putting out @Shekar 's suggestion given in the demo - Maybe reflect a principle on how we address our users, how we breathe & think about users, agile processes, and product-led growth.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.