Cloud Foundry Command Line Interface (cf CLI): Enabling faster feedback cycles and greater coherency
The practice of CLI design is surprisingly inflexible 🙅🧘🏻🙅...
(Once you have a schema you need to stick to it as long as possible. You also need to strive for consistency in all things so your naming structure and CLI responses become familiar, predictable, and are scriptable.)
& nebulous ☁️🌫️.
(You have a new feature. Should it be... a flag on an existing command? a new command, with flags? a new set of commands? something you interact with via the manifest rather than in the CLI itself?).
With an inherited style guide in hand, I focused on interaction design and accelerating the process of developing a feature, from concept to delivery, for each CLI project I worked on.
Case Study - Domains
Fix the convoluted and inconsistent workflows for:
creating a private/shared/global domain
deleting a private/shared/global domain
sharing a private domain.
What I did
introduce lean UX process to team
rapid CLI prototyping + testing
🎉 Winning design confirmed!
Reduced user confusion
Reduced user error
Consistent creation and deletion workflows
💪 Stronger team muscle for setting success heuristics, and rapid feature prototyping, testing, and delivery
Understand the history & reasoning behind the set of domains commands
Scope the problem and timeline in a design brief
Define success heuristics
Diverge: Conduct a design studio to go wide and wild with ideas. Solicit feedback from team and stakeholders.
Converge: Synthesize and consolidate designs into a smaller set of qualified candidates
Create a testing plan + recruit usability testing participants
🔗 Link to Usability Testing Brief
👀👉 Screenshots of the Recruiting Plan + Testing Goals, Testing Plan
Conduct usability tests on three distinct prototypes + mini-synthesis sessions after each test
👀☝️Gif of one prototype click-through above
Synthesize usability testing results, compare results with success heuristics
Choose and refine the successful design
Share findings and design choices with team and stakeholders; move designs into backlog stories for engineering; announce the change via appropriate channels and invite feedback
What I've learned
1 - 'Designing an API' is a loaded concept.
API design may not directly translate to UX design, but the entry points for end-users to learn about the API, the UI and CLI that end-users interact with to access the API, and the process of creating home-made tools that access the API directly, are all experiences for different personas that can and should be improved for the sake of user productivity & satisfaction, business value, and product reputation.
2 - Effective discovery research will always need to be persona or problem-specific.
At PCF, this also means discovery research always needs to span across more than one component team.
3 - No data? Use proxy metrics.
My number one struggle at PCF has always been the lack of user data (due to privacy and security concerns, and the nature of a CF foundation). The go-to metrics for knowing a new feature, redesigned workflow, or new piece of documentation have moved the UX needle aren't available anymore - so one has to be creative.
I've learned to measure my work and impact in terms of team culture shifts towards design-thinking; the frequency and value of user research; direct feedback we receive from interviews, Slack messages, and help tickets; and the kinds of questions teams begin to ask about, after a research or design cycle has been completed.
4 - Facilitation of the process may be even more valuable that actual completion of a process.
Some of the most meaningful impact I've had while at PCF was as a result of facilitating a conversation, a design studio, a research track, a new connection.
Well-designed UI and CLI experiences are good and important, but advocating for the right problem to be solved at the right time will go much farther towards ensuring a team or organization builds the right thing, for the right users.