Principles of UI, A Thread:
1. natural mapping
2. visibility of system state
3. discoverability
4. constraints and affordances
5. habits and spatial memory
6. locus of attention
7. no modes
8. fast feedback
9. do not cause harm to a user's data or through inaction allow user data to come to harm
10. prefer undo to confirmation boxes. For actions that can't be undone, force a "cooling off" period of at least 30 seconds.
11. measure using Fitt's, Hick's, GOMS, etc. but always test with real users.

12. don't assume that your skills or knowledge of computers as a designer or programmer in any way resemble the skills or knowledge of your users.

13. Consider the natural order of tasks in a flow of thought. Verb-Noun vs. Noun verb. Dependency->Dependants vs. Dependants->Dependencies.

14. Instead of having noob mode and advanced mode, use visual and logical hierarchies to organise functions by importance.

15. Everything is an interface, the world, learning new things, even perception itself

16. Consider the psychology of panic. Panic kills scuba divers, panic kills pilots. panic kills soldiers. panic loses tennis matches. Panic leads to stupid mistakes on a computer.
more at:!.h

17. Consider the 3 important limits of your user's patience:
0.1 second, 1 second, 10 seconds

18. An interface whose human factors are well considered, but looks like butt, still trumps an interface that looks slick but is terrible to use. An interface that is well considered AND looks good trumps both, and is perceived by users to work better than the same exact interface with an ugly design.

19. Don't force the user to remember things if you can help it. Humans are really bad at remembering things. This includes passwords, sms codes, sums, function names, and so on. My own personal philosophy is to consider humans a part of your system, and design around our shortcomings instead of thinking of users as adversaries. Software should serve humans, humans shouldn't serve software.

20. Some Sources:
Donald Norman
Jef Raskin
Jacob Nielsen
Bruce "Tog" Tognazzini

I recommend all the talks by Alan Kay and Bret Victor, here's two:

Doing with Images Makes Symbols
The Future Of Programming

The first 8 items of this thread are extremely terse, to the point of being meaningless on their own. Please use them as search terms, or ask me to expand on them when my dog isn't barking at me to go to bed.

21. Gall’s Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

22. show, don’t tell. lengthy tutorials and “protips” forced on the user at app start usually do nothing other than get in the way of the user’s task. if you want to teach the user about a feature, include easy to find examples.

23. don’t interrupt flow of thought. if a user is opening an application, they usually have some specific task to complete. nagging them at this point in time about software updates or handy tips is very user hostile.

24.many jokes are made about the “save” icon looking like a floppy disk. it’s very appropriate, since the command as a concept is built around the technological limits of floppy disks, limits that are comically irrelevant in the 21st century.drag your app out of the 1980s and implement autosave and version control already.

25. consistency consistently consistent. there’s few things more fun than designing your own custom ui widget toolkit, css framework, or interaction paradigm. however, please strongly consider *not* doing this. custom UI is like ugly baby photos. instead, stick as much to the HIG guidelines and conventions of the platform you are on, so users can use what they’ve already learned about where things usually are, and what the fuck the weird molecule icon does.

26. try to imagine ways to use your shiny new software to abuse, harass, stalk, or spy on people, especially vulnerable people. ask a diverse range of people to do the same.
then fix it so you can’t. if you cannot figure out how to do your special software thing without opening vulnerable people to abuse, consider not making it available to anyone.

27. UX is ergonomics of the mind (and also body). Where traditional ergonomics considers the physical abilities and limits of a human body, UX considers the limits of the human mind: attention, memory, response time, coordination, emotions, patience, stamina, knowledge, subconscious, and so on. If you ever find a UX practitioner sacrificing accessibility on the altar of so called “good experiences”, you are dealing with incompetence.

expanding on 1. Natural Mapping:
user interfaces typically “map” to the system they control, each button and dial corresponding to some element of the system. Natural mapping is when the interface forms an obvious spatial relationship to the system, such as 4 stovetop dials that are in the same arrangement as the stovetops. the anti-pattern is arranging controls in an arbitrary order with no spatial correspondence to the system.

2. Visibility of System State:
Software typically has state (to state the obvious), such as “where” you are in the software’s menu system, what “mode” you are currently in. whether your work is safely stored on disk or has “unsaved changes”, what stage of a process you are up to and how many steps are left. Failure to effectively communicate system state to the user is inviting them to get lost and make mistakes. counterexamples: setting the time on a digital wrist watch, programming a VCR

3. Discoverability
this is about making the possible actions in a system visible- or if not immediately visible, the mechanism of their discovery should be visible and consistent. For instance, the menu items in a GUI system are discoverable. the available commands in a unix system are not. the opposite of this principle is “hidden interface”, examples of hidden interface are rife in iOS: tapping the top of the screen for “scroll to top”, shake to undo, swipe from edge for browser back- etc.

@zensaiyuki I feel like there could be a lot of benefit in more seamlessly integrating the terminal and GUI interfaces to the OS. What's lacking is a one-to-one correspondence with terminal and GUI behavior. Another thing is that the terminal itself could be designed with menus to perform actions, which it then automatically populates as a text command. Eg. You go to terminal and choose copy, it pops up a box asking for source and destination, autopopulates the terminal with eg (cont)

@zensaiyuki 'cp someFile someNewFile', then shows the user the copied file in the destination. Or something like that. It could be integrated into the file manager or something.

@unspeakablehorror there’s a very nice model (yet to be fully implemented by anyone) for integrating gui and cli interfaces described in Jef Raskin’s “the Humane Interface”, one of my sources for this thread. tiny parts of the idea have been integrated into OSX spotlight,

@unspeakablehorror his son Aza Raskin implemented other parts in Enso and Ubiquity, two now abandoned projects.


@unspeakablehorror a slightly different part of the idea can be seen in interactive “workbook” systems like mathematica snd jupyter

· · Web · 0 · 0 · 1
Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!