Oftentimes we witness the results of elitist practices upon users, usually worded in the form of the acronym RTFM or “Read The Freaking Manual”. User manuals have their place, but up to which point can we expect users to learn by reading instead of doing?

A similar stigma often appears in Free Software / Open Source projects as well. The alternative “Read the Documentation” certainly would ensure that people would give a little more effort before repeating questions. With limited resources it’s also understandable that this might be the most sane way for a project maintainer to channel user interactions. However is that by design or due to lack of resources? One could argue that it would make more sense to integrate those ‘user lessons’ right inside the application instead of a manual or documentation alone.

Manuals are no replacement for good Usability

Make a great manual and a mediocre application and you might be able to keep a user from running into blockers, however you won’t be able to improve their workflow. The user is basically learning an app by heart, not by intuition.

This is where Usability and User Experience come into play: An alternative to the traditional manual, created by a researcher or designer instead of an engineer, so to speak.

Unlike a manual though, a delightful User Experience doesn’t ask to be read, it is seamlessly integrated into the application in a human-centric nature. Not the other way around.

There is a strong connection between Usability and a user’s emotional feedback: When an application lacks usability, the amount of time it takes the user to accomplish that task is not only higher, it also brings along negative forms of feedback such as frustration and impatience. If this happens in the case of privacy-enhancing software, those emotions can quickly turn into fear and breach of trust, putting the stakes higher. At that point, usability is not only a commodity anymore.

Consistency is Key

User Experience is shaped by the usage of patterns and aesthetics familiar to the user within the same software. Unsurprisingly, users don’t like change. If change and inconsistencies confuse users, we can conclude that consistent design decisions create trust; it feels familiar and the user has witnessed it in the past.

Facilitating consistency can be done via a range of tools, including Brand Guidelines and a Tone of Voice. As early as 3 years ago, our friends at Simply Secure highlighted the importance of Brand Guidelines in relation to creating user trust.

Brand guidelines ensure consistency when many different people are working on a product. This is an important component for building trust with end-users. It’s crucial for secure communication projects in particular because lay users can’t assess the underlying cryptography. Instead, they assess how trustworthy something is by the user experience, and consistent brand expression is a key part of that. As a counterexample, consider how a sloppily-implemented logo in an email can alert people to a phishing scam by signaling untrustworthiness.

Style guides serve as a single source of truth for design decisions and guidelines. They also ensure that a project can be inclusive to diverse contributors, while helping them to communicate with users in one consistent voice throughout the whole range of mediums the project is present on. Depending on the context, style guides can include various ingredients, including (but not limited to) Brand Guidelines, UI Components and Tone of Voice. A style guide has no specific definition and can vary from use case to use case, so depending on a project’s needs, specific parts can be prioritized.

Playing by the Rules

Sketch revolutionized Prototyping and UX Design years ago. Nowadays Figma is gaining popularity, being praised by its focus on unified design systems accessible by all members of a project without reinventing components. Figma emphasized the need for consistency and streamlined the design process by integrating it within a powerful design system. It’s one of the primary reasons designers are so excited about it.

Icon Grid Display

At the end of the day, style guides serve as a playbook for software creators. They go beyond the debate whether design decisions are justified or not, as long as it’s covered within it. They are a single source of truth to help create consistently well designed experiences familiar to the user. It might not be a silver-bullet solution in the short run, but it immensely helps everyone involved be on the same page.

Examples

In the past we have implemented style guides for various projects, including The Tor Project, Thunderbird and Reproducible Builds. If you want to know more, we also suggest to read Simply Secure’s blog entry on Why Open-Source projects need Style Guides.

Last but not least, the points touched upon in this article is the very reason we started building Identihub. Have a look and try it out yourself!

If you like to explore the possibility of a style guide for your project, feel free to reach us by email or Twitter