Preference Driven Design
Often when approaching a design for a new app or website, it’s a pretty ‘me’ focused experience. What do I think looks good, what will sell the most, and so on. And you know what, that can be fine as a creator, drawing others into what I feel would be awesome. And people want that.
However, it’s important to remember that, regardless of creative expression, design is meant to be consumed, read, evaluated, enjoyed, and considered. But if it’s too abrasive or hard to parse, you’ll lose the very people you were trying to reach. Why not let users decide how to review your content? Let’s review the possibilities of preference driven design.
Things Users Can Control
Readability
Fonts
Users on almost all browsers have control over their font size they can set as a baseline universally, as well as the minimum size allowed. By relying on REMs and EMs for everything (not just fonts), you give power back to the user. Stop using fixed pixel sizes and let your users be free, mannn…
Additionally, on many desktop browsers, users can pick their default font-family for readability. So when you set your whole website to Curlz MT, the person who hoped to use Open Dyslexic or Lexend to help them pop into parsing paragraphs can no longer do so. That’s sad times. Set your content’s font to ‘sans-serif’ and be done with it. Let your online friends choose how to read instead of telling them how they should read. This isn’t 1984.
Reading mode
Many browsers these days come with a ‘Reading mode’ for users to turn off a website’s distractions and focus just on the content at hand. While you may have very little to say in how the content visually appears, you can have great control over the content presented by making sure to use semantic HTML tags like article, etc. and using microdata formats. For a great read on how to get your content reader-ready, check out this article by Mandy Michael on Medium.
Theming
Contrast
For users that hard a hard time seeing, or users in a situation where there is serious glare on their screen, high-contrast designs can help people see what’s going on. Windows, Mac, iOS, assistive technologies, and some Android devices allow users to toggle an OS-wide setting to help make their UI’s easier to understand.
A few important caveats here.
- Incredibly high-contrast designs can also have negative side effects on some people as well, so making designs with the highest possible contrast isn’t always the best idea.
- There are international laws that point to an accessibility standard called WCAG, and they govern that pretty much any readable or interactive content should have a 4.5:1 contrast ratio (this is a broad generalization).
- Using pure black can create ghosting on some OLED screens. Try to never use pure black. If you are worried about battery-savings, a very dark color will still give a great benefit.
- Also, there have been studies showing that white text on a black background can be uncomfortable to read, so probably don’t make that your default.
Windows has a great write-up on ways to support high-contrast designs via CSS media queries of ‘prefers-contrast’ and ‘forced-colors’ mode.
Dark Mode
Not all users enjoy having a blindingly white screen in their face all day, and they may want to toggle a dark mode at will or at a certain time of day. In any case, presenting a blindly bright UI in a dimly lit room can be incredibly off-putting and even painful. Consider supporting a dark version of your content. You can even support dark mode favicons (like my site does)!
CSS Tricks has a good article on how to do enable it.
Color
Recently, the CSS attribute ‘accent-color’ has been getting a lot of buzz. And while it is a very cool and easy way to theme and customize a UI, it does break from the OS’s accent settings that users are already primed to identify and use elsewhere. Again, let the global setting a user chooses provide the right level of interaction affordance in your UI.
MDN has a write-up of how to use accent-color here.
To go even further, you can use the system UI color from the OS itself (but not its accent color). However, since these aren’t user-set per se, it’s not really a preference driven design decision. Especially since each browser handles these system colors differently.
Devices
Medium
Another critical issue is the device a user chooses to read your content on. The screen can render on something as small as an Apple Watch to a jumbo-tron on the side of a building. Again, semantic HTML and implementing something like fluid font sizes can help your users read comfortably at any resolution they choose to consume on.
Other medium oft-forgotten are offline assets such as PDF export and printed pages. Don’t forget to render your content using the print dialog, and as needed, set up a print stylesheet. Here’s an example of what one of those looks like.
Lastly, don’t forget, you can set your site’s content to work offline or stored as a mobile application using Progressive Web App technology. And it seems you can do this PWA setup in under five minutes!
Input methods
In addition to the wide range of screen sizes, there are an even wider array of input methods. Just to name a few are:
- Keyboard
- Mouse
- Trackball
- Stylus
- Touch
- Voice
- AI assistants
- Switch devices
- Braille readers
- VR headsets
And on and on. Again, semantic and clearly labelled HTML UI saves the day for voice and AI. But in addition to that, larger, fluid inputs and interactive regions are critical for less common inputs. Touch, Wiimote-like pointers, switch devices, and VR all require larger hit areas due to pointer instability or coarser clicks. Also, be sure to make your input labels clickable as well. Lastly, make sure all of your interactive content is keyboard accessible.
If you didn’t know, it is possible to view the web on an Apple Watch.
Motion
And finally, while you may have some fancy pants animation on your app or site, don’t forget that some folks have vestibular disorders. Parallax or high-motion aspects of a UI can make them feel sick to their stomach.
All major OSes today allow users to reduce the amount of motion within their settings, and the web now supports a way for CSS and Javascript to listen for this ‘reduced-motion’ flag. As an aside, reduced motion doesn’t mean ‘Don’t animate anything”, it just means that adjusting content on an X, Y, or Z axis may be too much. Fades are fair game. In fact, removing all animation completely may take away key indicators that something has changed.
Learn more about ‘prefers-reduced-motion’ on MDN.
Conclusion
We have a lot we can share with the world, but when it comes to enjoying our content, why not let our audience choose how they do so.
I miss anything? Disagree with me? I’d love to hear from you!