Is anyone here working in a design role with an engineering team to help them improve the UX of the command-line tool?
If so, do you have any resources, or guides or any wisdom you could share that would help a designer with a background in IxD for GUI products pivot and become capable of applying those same principles of good UX design, but to non-GUI products (like a command-line tool, or API etc)?
Nice to meet you! At the moment, I’m working on the usability of pip (the Python package manager) which is a CLI tool.
Hmm, that’s a good question you’ve asked. I’ve been putting together a (short) list of resources for myself about CLI design. It’s not a very long list.
I can post some of the things I’ve found here. Most of the same principles apply to CLI, just that its a lot more restricted in terms of possibilities, and that the UI is more…procedural. (I can’t find the right word for what I mean).
In terms of API design, thing main thing is - APIs are for machine to machine interaction. That interaction needs to be built by developers. Developers understand how the API works by reading the documentation (and possibly reading the code). Therefore it is really important that the documentation is usable by the develoeprs.
So do usability testing of the documentation with the developers. If necessary, get a content designer (person who writes good readable documentation) and get them involved in testing the documentation. There are different ways you can do this, here’s an easy old method
(I don’t have an experience of testing APIs and their documentation with this method)
If you have any particular questions, or things you want to discuss, fire away and post them here.
Also, I’d be very interested in hearing about what your working on.
I’m working on Flyway (a command-line tool for database migrations) and I’ve also found that there’s not a lot out there to help with designing non-GUI dev tools. I’m a product manager, but my background is in design.
We’ve hired a designer onto the team recently. Right now we’re focussing on user research, and the GUI design of a complementary service - but I can’t shake the feeling that it’s possible to contribute to the design of the dev tool itself - it’s just not that obvious how.
So far my research has turned up similar results - I think you’re right about the procedural nature of the CLI, the context of API design (ie. a human interacts with it via their code) and the importance of good docs (right down to their IA).
I’ve tried to reverse-engineer what makes a good CLI design, which turned up some interesting insights like inconsistencies between terminal apps - I wrote about it here if you’re interested:
I think what I’d really like to end up with is some kind of tool (or training?) that would help a designer get confident with applying design principles to CLI tools.
There’s some fairly impressive usability work going on that could vastly improve dev experience (like Example 4 in this post) and I think UX people could really help advocate for the value of putting that kind of dev effort into dev tools.
This is interesting - the API absolutely counts as something that needs design love. As Bernard said, the API is for machine-to-machine activity, but even that’s still put together by a human .
A couple of things I’ve picked up this week…
First, Rich Pictures (which is a systems thinking thing) is a great way to understand a system that involves an API, CLI or any other non-GUI interface.
Second, since I work on an OSS project I’ve never found it hard to get involved from a design / usability point of view, so I was kind of surprised to read that other designers did find it difficult, particularly in showing they can be useful in the short term, which I can see for sure.
Nice finds Diogo, thanks! I think the CLI design space - or at least people’s awareness of the CLI as something that can be designed well - is really growing.
Since I posted the original message clig.dev – an open source guide to CLI design – also went live (getting 600 GitHub stars in its first week). It gets technical quickly, but its philosophy looks well grounded in designing for humans.
All the same, I’d love to see ways for more designers to learn how to get involved with CLI design, and Developer Experience design in general.
I’m starting to wonder whether documentation could be a good place for a new designer to start, so I’m half-way through writing about that here.