
:strip_exif()/i/2003191296.jpeg)
That said, forgiving does not mean allowing the product to be used incorrectly by breaking the «Obvious» principle. Being forgiving means reducing the negative impact users encounter during failures–not losing their data, not deleting, updating or sending something they didn’t intend to send, and so forth.įeatures like confirmation dialogs on critical actions or temporarily saving user input in case of disconnect are examples of forgiveness. There will be unavoidable product failures, whether through technical issues like loss of connectivity or through our inability to make the user aware of correct usage.
#Mattermost dark mode software
Remember: Software is an invention–there’s nothing «intuitive» about it, there is only what is familiar.

Mattermost UX should be drawn from patterns and derivations of other experiences in a mix of familiar approaches. Use design patterns familiar to our audience–general non-technical users for the core messaging experience, IT administrators for configuration experience, developers for the developer experience. Functionality that is not fundamental to the product purpose should be ruthlessly omitted. Given Hick’s Law, core functionality should be apparent, and advanced functionality should be possible via sub-menus and be well documented and tested. The “Obvious” design principle also flows through to our Documentation Guidelines.
#Mattermost dark mode how to
If a user doesn’t understand how to use a feature, all the underlying effort and code is wasted. Everything we do–features, interface layout, labeling, help text and documentation–needs to make sense in the mind of the user, even if it means occasionally oversimplifying how things technically work. When our product is correct, users are never confused. Fixes could be through user interface improvements, adjustments to help text or helping users recover when things go wrong–for example, adding undelete, undo and rolling back. We prevent problems of incorrect usage by making users aware of correct usage. There is no such thing as «user error»–it’s always our fault as product designers. Bugs should be opened on performance regressions. Loading pages, sending messages, receiving notifications and other vital actions should be automatically benchmarked for performance. Quick means things happen as soon as they can. It could be a spinner animation, or just some text saying “Loading”, but something always responds to the user. Responsive means when a user clicks, taps, types or otherwise enters input we give immediate feedback that the input is received and something is happening. Fast has two parts: being «responsive» and being «quick».
