Soft Thoughts on User Experience, Usability, and Design in Software

In my opinion, the keys to good user experience are all about information and convenience, we want the user to easily understand: • where they are – what is the current application state • what has happened – indicate the result of every action ◦ loading/progress bars, toast messages, error banners, etc. • how to get where they want to go ◦ For every action available in a UI, it should be obvious that it does something and what it does. To meet this we should either use established icons and keywords, or use/build a clear mental model in the user about how the application works. It is also important to never surprise the user. ◦ This also introduces the balance between distance and simplicity. ie. We want any workflow to include as few steps as possible, but we don’t want to introduce confusion by including too many elements in any particular screen. That is, we want flat interfaces that don’t require navigating many screens (ie. We want to minimize clicks), but we also want those flat interfaces to be simple. When using an interface with too many options, it won’t be immediately obvious which choice is the correct one. ◦ Remember that where the user wants to go might be “backwards” always indicate how to backtrack (and remember the user might want to come back, so if the user navigates “back” from a form, and then enters the form again, in most cases their previously entered data should not be lost). • Comprehensive guides are useful for advanced users, but a good rule of thumb is that if your interface requires explanation, then it has bad UX.

I think there are a few methods that succeed in leading teams to produce good UX: • Applications should have unified theming; so styling should be done in a single module, and only minimally within specific components • A comprehensive style guide should be produced, which developers must read and be familiar with, and review should be done with this guide in mind. • When possible, we should use UX Contextual Inquiry, as promoted by The DevOps Handbook. Actually observing users as they use the app will reveal some of the pain points. Users will often blame themselves for having difficulty and won’t take the initiative to report issues. Sometimes they may not even be able to articulate what is wrong with an interface, as UX design is not their area of expertise. • When designing workflows, I find it useful to actually list all of the discrete actions necessary, and to improve convenience ask, “how many of these steps are necessary?” ◦ This leads to such improvements as automatic (in)validation of a 2FA key for example, rather than including a submit button. If the user has entered all 6 characters, then there is no reason to wait for submission. • A similar approach can be used when implementing user stories. ◦ For example, if the user wants to enter a Landscape management screen to examine the various workstations, and each node can be selected to see more details (such as in a right panel, or sidebar, etc.). One major task would be to look for alerts due to a newly discovered vulnerability. It should not be necessary to enter the details panel to see the vulnerability, rather the summary card should have a “!” icon. But also, if after entering the management screen the first task would typically be to immediately select the first node with a vulnerability, it is better then to have that first node pre-selected, and its details immediately visible. The tension here is between whether it is better to display the maximum possible detail cards, or limit the number of cards to provide more detailed information, but I digress.