The Azure Developer (azd) CLI is a terminal-based interaction for developers to easily deploy their products to Azure. In my background as a PM, I had worked with the Azure (az) CLI, a more complex CLI that aims to encompass every possible command to manage Azure resources.

Azure Developer Design Principals:

Consistent commands for any resource
Clean, clear, and coherent
Enable customers to quickly and easily get their projects into Azure

My work as a UX designer for the CLI:

Work closely with engineers, product managers, and other key cross-functional partners to drive design, decision-making, and reduce toil
Lead workshops to improve team collaboration and consensus
Expand and improve design standards for Azure Developer CLI
Socialize and advocate for general design standards across Microsoft CLIs
Review and submitted PRs for UX improvements
Collect and synthesize feedback from a variety of sources

Command Structure and Composability

A key part of CLI design is command structure. Terminal commands become muscle memory for developers, or are encoded in scripts, which means that changing a command is very difficult in the future. With the azd CLI, there were some unofficial patterns. I did an analysis of the commands and documented our pattern:

Keep subgroups to a minimum: While the az CLI might have subgroups within subgroups (ex: az containerapp ingress access-restriction set), azd tries to only have one subset at a time (ex azd config set) and the main comands have no subgroups at all (ex: azd up)
Noun - Verb organization: Subgroups (auth, config, env) are always nouns, and the commands (up, deploy, login) are verbs
Simple, clear words: We keep compound verbs (ex: list-alpha) to a minimum, and try to keep our verbs clear, consistent, and in line with common understandings.

My first big feature I worked on was composability. The goal was to be able to easily add resources to your project without needing to dive into Bicep (a complicated language for deploying resources to azure). We tried out a variety of command structures, tested them out with users, and considered how we might need to future-proof the commands. In the end we decided on azd add as the main command and management within azd infra.