console-ux-design

Topics in the source

• Console UX Design
• Stay inside the console boundary
• Establish the operating context
• Read only the references the task needs
• Produce a reviewable design
• Preserve safety and composability

Design a predictable console interface for people at a terminal and callers in automation. Create or improve ordinary commands, subcommands, and line-oriented console applications. Treat Laravel Artisan, Symfony Console, and similar frameworks as examples, not as universal APIs. Analyze an existing command when that analysis leads to a redesign or implementation-ready change. Do not turn a report-only audit into a redesign. Do not cover web, mobile, native GUI, terminal-emulator themes, or full-screen terminal user interfaces. Do not treat shell implementation alone as UX work. Activate only when the command's contract or user experience changes. Before designing, determine: the user's task, domain vocabulary, command frequency, and cost of mistakes; novice, expert, and automation journeys; current command names, signatures, help, output, exit codes, compatibility promises, and tests; supported platforms, shells, console framework, terminal widths, locales, and character encodings; TTY and redirected behavior for standard input, output, and error; interactive, non-interactive, quiet, verbose, color-disabled, and machine-readable modes; destructive effects, secrets, cancellation, pa

This is an excerpt. Refer to the complete source and its current requirements.