The Basics

Use Colour, Shape and Grouping

Reducing information overload is not necessarily about reducing the amount of things on a screen, it’s about organising things in the optimum way so that they can be easily processed by the brain. Visual aspects like colour, position, shape, texture and movement register pre-attentively.

info

Coherent visual cues can make relationships easier to recognise. More cues are not automatically better: competing colours, shapes and movement can obscure the distinctions that matter. If all this is new to you, it's time to brush up on your Gestalt Principles — they still do real work in modern interface and diagram design¹².

In a complex application, several purposeful colours can distinguish categories or states. Pair colour with another cue so that the distinction remains available without colour perception. Using shape/ colour/ size/ grouping is the most pure example of synergy in software design, the resulting whole being so much greater than the sum of its parts.

StudyESEM 2007

Gestalt principles: organising complex diagrams

Lemon and colleagues asked 27 software-engineering students to answer questions about three diagrams, each with an original version and a version reorganised using proximity, similarity and continuity. After excluding one participant’s results, they found that the reorganised complex diagram supported faster responses. Comparable benefits were not established for the simpler diagrams, and accuracy was high across conditions.³

The information and connections were retained; their presentation changed. For node graphs and dependency views, this suggests testing whether grouping and clearer connection paths make complexity easier to read before removing useful information. The experiment changed several visual properties together, so it does not establish the independent benefit of each principle or performance in a working DCC.

PDF

Contrast and Legibility

This can be quite a challenge in complex apps with many different areas, app states, UI states and depth levels. Accessibility is a requirement for good software design, so plan for it from the outset. For web interfaces, WCAG 2.2 generally requires a text contrast ratio of 4.5:1, or 3:1 for large text, with specified exceptions.⁴ The 3:1 threshold is not a general baseline for ordinary inspector labels. Native applications also need the relevant platform accessibility guidance.

At a design conference two legally blind people came to do a workshop in our DCC. It wasn't great, and we will do better. Contrast is only part of that work: keyboard access, focus, structural alternatives and interface scaling matter too. See Accessibility in Creative Tools for practical checks.

The illustration shows how background changes affect contrast in a dark interface. Check each actual text and background pair against the applicable threshold, including hover, selected and disabled states. 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, and this one's personal: I find blue backgrounds fatiguing in long sessions — treat this as preference, not evidence.

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 honourable Kai Krause designed them, it can still be flat, don't worry, I just mean that it needs to be distinct from an icon. Controls need cues that communicate their purpose and availability.⁵ An icon-only button can work in a familiar toolbar, but its appearance, context and accessible name must make the action clear. Test recognition rather than assuming that a familiar icon will be familiar to everyone. 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.

Finally, state buttons (on off buttons) need to look distinct from regular buttons in order to avoid needless confusion over what something does.

StudyINTERACT 2015

Flat design: recognising icons and clickable controls

Burmistrov and colleagues compared visual-search tasks with 20 university students. Finding a target in a matrix of flat icons took an average of 15.4 seconds, compared with 8.0 seconds for realistic icons. On website screenshots, participants missed more clickable areas in the flat examples (35.8% versus 26.0%) and more often judged non-clickable areas to be clickable (28.0% versus 16.6%).⁶

The practical lesson is to preserve cues that help users recognise objects and actions. These were particular icon sets and existing websites, with differences beyond depth cues alone. The results do not establish that every flat interface performs worse, or that adding a shadow will by itself fix a control.

PDF

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 above 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...

Separate Appeal from Task Performance

ExperimentInteracting with Computers 2000

What is beautiful is usable: perceived usability

Tractinsky, Katz and Ikar studied an ATM-like application, collecting ratings before and after use. Perceived aesthetics and perceived usability were strongly related.⁷

This is a reason to measure visual appeal and perceived ease separately from task success, accuracy and effort. It does not establish that an attractive DCC interface performs better, or that positive ratings can replace observation of the work.

PDF

Practical check: compare the same task in the proposed presentation and its predecessor. Record recognition, mistakes and completion alongside preference. Check whether a favourable appearance hides a difficult operation.

Text

For Westerners, left align all multi-line text as 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.

---

Footnotes

1. Bennett, C., Ryall, J., Spalteholz, L., & Gooch, A. (2007). The aesthetics of graph visualization. In Computational Aesthetics in Graphics, Visualization, and Imaging. The Eurographics Association. ↩

2. Park, C.-I. (2019). The visual weight of interface design. Journal of Digital Convergence, 17(12), 461-466. ↩

3. Lemon, K., Allen, E. B., Carver, J. C., & Bradshaw, G. L. (2007). An empirical study of the effects of Gestalt principles on diagram understandability. Proceedings of ESEM 2007, 156–165. Sections 3–5. Published paper. ↩

4. World Wide Web Consortium. WCAG 2.2, Understanding Success Criterion 1.4.3: Contrast (Minimum). Guidance and exceptions. ↩

5. Norman, D. A. (2013). The Design of Everyday Things, revised edition. Basic Books. ↩

6. Burmistrov, I., Zlokazova, T., Izmalkova, A., & Leonova, A. (2015). Flat design vs traditional design: Comparative experimental study. Proceedings of INTERACT 2015, Part II, 106–114. Sections 3–5, Tables 3–4. Published paper. ↩

7. Tractinsky, N., Katz, A. S., & Ikar, D. (2000). What is beautiful is usable. Interacting with Computers, 13(2), 127–145. Published paper. ↩