This site is a work in progress. Last updated January 2023.

Interface Design

Introducing boring-but-usable-morphic design!

Process

Mockups

Be wary of doing visual designs ahead of conceptual designs, even for stakeholders who've asked for 'finished' mockups. Instead, indicative designs are best (and will give you more breathing room to change things later if needed). Indicative designs will help you create a style guide which can then inform more detailed designs later. A frequent issue with providing high-fidelity mockups early in the design process is that these result in high-fidelity feedback, such as button placement, or text alignment - when early on in the process it's more useful to get feedback about how things work and what they do.That said, with modern tools and mature projects it's often just as fast to do a high fidelity prototype than it is to do wireframes and charts, I do this often as it helps me to get a feel for a feature or workflow. To try to mitigate the high fidelity feedback that this would engender I always prep my audience and request feedback on very specific aspects of the prototype. This sadly doesn't completely sanitise the feedback, but it does improve it considerably.

Design Systems

Design Systems prevent conflict; a common source of problems on product teams stems from visual designers spending a long time refining and making designs pixel perfect - something that can make the designers become attached to their designs, only to find out that the product designers have changed how things should work or be laid out. Design systems minimise the risk of conflict here by making the design process more of a kit of parts - thus swapping things in and out or changing them around is more straightforward.

Consistency

The goal of any UI is to make things clear and easy for the user, consistency is one of the main ways to achieve this because by making things consistent, you make patterns known, and you stop the user from guessing, this tends to make things better for the user by removing stop and think moments. Until it doesn't.A lot of people get confused by consistency and end up tripping over themselves. The problem is, many designers strive for consistency without realising it's a sliding scale; you can go from everything being insanely inconsistent - let's say every button in your app has a wildly different design - to insane consistency - every button being identical, including the icons and text. I've obviously taken two extreme positions here, but it illustrates a point, extereame inconsistency would at least still be somewhat usable, if hilarious, and extreme consistency on the other hand, would not even be remotely useable.The axiom goes "consistency in user interface design is paramount". This is a somewhat problematic statement because the minute you ask "consistent with what?", everything becomes a lot less scientific and a lot more subjective. A very simple and common example of this is visual designers making all their icons a single consistent colour - something which actively harms usability - a happy medium would be colouring icons by category or usage for example (or even letting users tint them as a form of tagging).Next let's consider a more complex example of being consistent with 'competing software'. This is a very common choice product designers make - to copy someone else in the field, especially if the feature in question is required but not a differentiating factor. The theory goes that if you copy the other software then your users who switch will not need to relearn how it works, because it will be the same. So far so good, what could go wrong? Well, we don't know how the competition ended up with said feature the way they did, here's a list on this from the Introduction of this guide:

It's impossible for us to know the internal politics that lead to a product design, e.g the loudest voice in the room or the most senior voice, rather than the most skilled may have won out.
It may be a mistake.
It may be unfinished.
Budget/time may not have allowed for a polished product.
It could just be good old fashioned incompetence.

So if you copy a feature blindly, you may be copying faults and providing a suboptimal product, you might not think this is too bad due to the inherent advantages, but this can have far reaching consequences. Let me introduce you to the insanity which was (and still is) everyone copying how Photoshop gradients work, which can be summarised with the quote: "CSS does it wrong because SVG does it wrong because Photoshop does it wrong...".Finally, a third kind of example: if an app appears on Android TV, WebOS and tvOS, and it requires an onscreen keyboard, is this keyboard exactly the same on all platforms, thus being consistent across all products? Of course it isn't, it would be idiotic to do that, instead you would be consistent with the platform (to take advantage of additional platform features like being able to type on your phone, and accessibility settings). Now I can almost feel your eyes rolling back with that example, thinking no one could be that stupid... Well, may I introduce you to NowTV who use the same unusably awful keyboard on all platforms - a decision which is utterly bizarre from a company so enormous and rich. In this situation, consistency was a terrible idea.Suffice to say, consistency is not the goal, clarity is the goal. Consistency is a sliding scale that you can use to achieve clarity, but if you're not sure what to be consistent with, or if consistency would harm usability in any way, do whatever makes things clearer for the user. Don't be a consistency zealot.

Implementation

The following section will be split in two:High level: Strategic UI, the general approach to the design of a complex user interface, in short, how not to annoy your users within the all important first few minutes of them using your app.Low level: Macro UI, this includes affordances, animation and all that pixel perfect goodness, in short, how not to subject your users to death by a thousand cuts.

High Level

Large Content Area

The content editing area should be as large as possible, so consider making utility windows and other editing areas compact and efficient, it can be tempting in this day and age to double or triple pad every control, this is a bad idea with complex software, as you're robbing space from places that need it more and the consequences of doing so will be serious, but won't show up immediately.

Graphically Rich

Convey the purpose and meaning of controls and items with graphical previews / explanations. This could also be termed graphical feed-forward, this is particularly useful for abstract controls where it's difficult for users to grasp what exactly their choices will mean. The best of both worlds is when you can combine rich graphics to create an interface for abstract controls. Here's a particularly good example of this from Cavalry designed by André Maura.

Direct Manipulation

Put editing controls in the content area - for example there are endless helpers and contextual tools in Google Sheets which speed workflows, in a graphics program this could be editing a gradient in the content area (as shown above). Anything which puts a user closer to the content they're creating and puts distance between them and control panels is a good thing for reducing friction and increasing the likelihood of flow state.

Customisability

Allow users to customise the interface to suit the way they want to work, or the kind of work that they do. Customising window layouts or toolbar contents are two of the most common ways of supporting this.

Low Level

Buttons

Once more for the people in the back row, buttons need to look like buttons. By this I do not mean they need to look like the great and honorable Kai Krause designed them, it can still be flat, don't worry, I just mean that it needs to be distinct from an icon. There is such a staggeringly enormous amount of research behind the efficacy of affordances that at this point you basically need to be a conspiracy theorist to think that flat icons as buttons are a good idea (outside of some very particular contained - literally boxed in - use cases like toolbars).Another area for consideration is button labelling, NNG has an article on that here. In short, label your buttons, label your icons. If you don't, know that you're knowingly reducing usability (which is okay, compromises are allowed, just be aware of what it means). One clever way to have your cake and eat it, is to have button/icon labels, but give power users the ability to turn them off.

Icons

The ultimate aim of icon design is to relieve the user of the necessity for recall when trying to locate commands, actions and any other data-carrying element within the graphical user interface. So you should try to make them distinct and easy to recognise, the section on managing complexity talks about Gestalt Principles which is how you should achieve this.It's worth noting that even with all the Gestalt tricks employed, semiotics (images/ icons) are usually not as effective as text at communicating meaning. I realise I just mentioned this under buttons, but this is why all the UX courses and top tier designers recommend labelling your icons. I appreciate some visual designers would rather pull their own ears off than do such a thing, but it's only your users you're hurting, unless of course you do actually pull your ears off...

Text

For Westerners, left align all multi-line text this minimises the amount of scanning the eyes have to do and the amount of processing required to take in the information. You can however centre align isolated text, like headings, or hints without penalty.

Contrast

This can be quite a challenge in complex apps with many different areas, app states, UI states and depth levels. Most online contrast tests out there compare against the WCAG 2.0 standards — I need to be careful here or I'll get letters — but generally speaking this is not actually necessary, the WCAG standards are aimed at making things legible for the average 80 year old which is very admirable, but I'll take a guess that there aren't likely to be too many 80 years olds using your complex software, that said, accessibility is a requirement for good software design, so you definitely need to plan for hitting some minimum baselines and the ISO-9241-3 standard's 3:1 minimum contrast ratio sets an accessible and easily achievable bar fit for everyone except those with moderately low (20/40) or worse vision. Always strive to do more, so if you can keep your contrast ratios higher without flattening the life out of your UI and causing a whole different pile of usability issues, you should do so.

As you can see, to pass the 3:1 test with a 'dark mode' app, the background needs to be relatively dark - this doesn't give you a whole lot of space to play with for rollovers, selected states and backgrounds. It may in fact be easier to represent certain states in one or more different ways, for example underlining text, using outlines, changing colours, textures and such.

As mentioned, one easy way to increase legibility is to use colour tints. We use them in Cavalry in our hover and selected states (which are lighter than the deselected state, and would thus otherwise reduce the contrast between the name text and background).Another general tip is to avoid too much blue in the backgrounds of your app, this is known to cause eye strain, much more so than warmer colours.

Colour

More Coming soon...

Google Sites

Report abuse