CLI design system

research | design

Most of the products that Canonical creates have a command line interface (CLI) that is actively used by a large percentage of the users. The design team here has spend a number of years working on the Vanilla Framework, our internal design system where we all contribute and expand the various elements as they evolve within both the marketing websites and the application UIs. Inspired by this design system and a large piece of work completed a while ago, aiming to align the commands of the CLIs of a few of the products, I proposed and am now leading the design of the CLI Vanilla Framework. It will contain guidelines and examples of what format and interactions should the input and outputs of all Canonical products have when used at the command line. For this piece of work, I am collaborating with another senior UX designer.

The biggest challenge for this work is the need to understand, in depth, a large number of highly technical pieces of software - both the Canonical ones that the design system will apply to, but also the ones that are generally regarded as having a good experience for developers, used for benchmarking the work.

An example of the first piece of work on aligning the commands and introducing new language in some of the tools, in order to provide a coherent and expected experience across the suite.

An example of the first piece of work on aligning the commands and introducing new language in some of the tools, in order to provide a coherent and expected experience across the suite.

As the CLI experiences are designed by nearly all of the engineering teams, the stakeholders are numerous and, mostly, spread all around the world as all of Canonical engineering is based remotely, gathering everyone and ensuring the work is signed off has been proving to be a challenge. For the previous piece of work - aligning the commands of four software products, two for building and publishing (Snapcraft and Charm), and two for consuming other software (snap and juju) - we were lucky to have a week where many of the stakeholders were in London and available for a design sprint. During that design sprint we went through the list of all available commands and aligned the language, grammar and structure, so they follow the same pattern and are more easily guessable by the developers using the tools.

Unfortunately, for this part of the work due to the current situation in the world, it’s impossible to have everyone together, so this time around I have been holding bi-weekly meetings with different cross-sections of the teams and the CTO of Canonical.

A concrete example of this round of design system work - providing exact structure to some of the main commands across the tools, `help` in this case.

A concrete example of this round of design system work - providing exact structure to some of the main commands across the tools, `help` in this case.

As this design system will be used exclusively by non-designers to both update and improve existing products and to build new ones, the outputs are twofold - general guidelines on the use of grammar, positioning, and structure of the commands and input, as well as concrete examples of how these should look (in the form of reworked instances from the current experience).

This is a work in progress, I am tackling the guidelines around the outputs, such as use of colours, ordering and structure of the information, language (passive and active tenses), active feedback, and many others. I am, also, assisting my fellow designer in her work of extracting the patterns we had established from the previous work, formalising them, and applying those new guidelines to the CLI of MAAS, as a proof of concept.