Slash GraphQL - Design Principles

Update: On April 16th 2021, Slash GraphQL was officially renamed Dgraph Cloud. All other information below still applies.

Our passion for user experience

Creating an incredible user experience is a fundamental core value at Dgraph. This holds true for our latest product offering - Slash GraphQL. Slash GraphQL is a fully-managed GraphQL backend database service that lets you focus on building apps, not managing infrastructure. Building Slash required a design process that focused on creating the right user experience to realize this vision.

Often, we need to make design decisions across multiple teams. Design and collaboration on this scale require a well-defined design philosophy - a common design “manifesto” that reflects our shared purpose through a set of design principles. Our engineering and design teams use this set of design principles to guide our design decisions and to lay the foundations for our design system. With Slash GraphQL, our goal is to enable developers to build apps that leverage production-ready GraphQL and a high-performance graph backend.

In a nutshell, we have just one purpose - ridiculously simplify backend development!

Translating this goal into reality is all that matters to everyone who is building Slash GraphQL. To achieve this purpose, we use our design principles to inspire our team to continuously improve our product. The design principles described below help us to achieve something spectacular - thinking like one single mind.

Our design principles -

1. Direction over choice. We want developers to focus on app development and guide them on a success path, rather than asking them to spend time navigating a labyrinth of choices to configure and manage Slash. Fewer clicks for the app developer means more work for us during Slash design, but less work for you, the app developer.

2. Enable super users. Our users are developers - who love keyboard shortcuts and keyboard-based navigation, and who love to become power-users with any tool they use in their workflow. Accessibility for all developers is important, as is helping you to supercharge your workflow.

3. Build purposeful interfaces. We want interfaces to resemble similar patterns and speak to the actions developers want to perform. Every piece of the screen needs to match user intent and help the user to take action.

4. Build “toy-like” (indestructible) interactions. Developers are smart, fast-moving, and results-oriented. We need to ensure that each interaction is reliable, make sure that error handling is robust, and make sure that error messages are clear and actionable. We imagine that we are building a toy for a baby - it should have no sharp edges or small parts that can easily break off and be swallowed.

Are these principles written in stone? The answer is: No! As Slash GraphQL evolves, so our principles will evolve in response to the needs of our users. Our design principles are based on time-tested design principles, but over time we will refine the principles that guide the development of Slash.