Tagged “ux”

I loved this insight into Adam Silver’s thought process. And it came at a timely moment since at work I’m currently trying to promote evidence-based, considered choices regarding user interface patterns.

My summary of Adam’s key points is:

• he found a UI pattern (let’s call it pattern x) in his project and flagged that while it’s not always bad it risks numerous usability problems. He lists these problems.
• he advises that pattern x is beneficial only in very specific situation y
• and that otherwise, pattern x is unnecessary and a more basic solution would not only require less work but provide a better user experience
• given this context, he asks others working on the project the following:
  • can they explain why pattern x was used?
  • did research (really) indicate a need? (this implicitly also asks if evidence or research was considered at all)
  • what else was tried beforehand? (this also subtly checks for awareness of the risks of pattern x and whether other options were even considered)
  • even if the use case was appropriate, given the downsides of pattern x were you comfortable the benefits outweigh those?

Adam also mentions how on this occasion, in the end, he had to grudgingly stick with pattern x because even though there were possible alternatives, his team didn’t have time to research or implement them. A familiar dose of real life, there. It’s worth being clear, though, that their implementation of pattern x (an accordion) is at least accessible, since as far as I can tell it uses their modern accordion design system component. If that were not the case, I imagine it’d be even less viable to leave it in place.

Question: when presenting users with a means of downloading a file, should you use the anchor element or the button element?

Answer: you should use the anchor element.

Eric starts by quoting accessibility expert Scott O’Hara to explain why anchor is the appropriate element:

The debate about whether a button or link should be used to download a file is a bit silly, as the whole purpose of a link has always been to download content. HTML is a file, and like all other files, it needs to be retrieved from a server and downloaded before it can be presented to a user.

The confusion seems to come from developers getting super literal with the “links go places, buttons perform actions.” Yes, that is true, but links don’t actually go anywhere. They retrieve information and download it.

Long story short, the download attribute is unique to anchor links for a reason. download augments the inherent functionality of the link retrieving data. It side steps the attempt to render the file in the browser and instead says, “You know what? I’m just going to save this for later…”

Eric follows up by suggesting that as designers and developers we should make the experience of interacting with a download link as good as possible. To that end:

• Ensure it looks like a link, i.e. underlined. You’re using a link (because it’s semantically appropriate) so now encourage the appropriate perceived affordances via conventional visual design for a link
• Use verb plus noun for the text. For example, Download fonts
• Include the file size (for example 34 MB) to give an indication of the download time
• Consider adding an indicator that the link does something other than take you to another place on your website. A downward-facing arrow is conventional

Adam offers tips for how to proceed when we are presented with a request for a shiny new pattern which is not grounded in research but rather follows a fad.

The purpose of design is to solve actual problems. Not made up “I’m bored so I’ll come up with something new” problems.

So how can we evaluate these patterns, avoid unnecessary work and ultimately avoid patterns that degrade UX?

He recommends we should start by asking three questions:

1. Does research show this pattern solves a problem?
2. Are there any potential usability issues with this pattern?
3. How much effort is it to build?

Heather suggests that in developers’ excitement to do cool new stuff and use cool new tools and techniques “we stopped letting people do very normal web things”. Things like:

• the ability to copy text so you can then paste it
• ensuring elements which navigate also behave like normal links by offering standard right-click and keyboard shortcut options etc. Which is to say – please use the anchor element and leave it alone to do its thing
• letting people go back using the back button
• letting people scroll with native scrollbars. Relatedly, letting people get to the links at the bottom of the page rather than having infinite scrolling results which mean that the footer is always just beyond reach!
• letting the user’s browser autocomplete form fields rather than making them type it

Nathan on how complex components require comprehensive specifications rather than ill-advised assumptions, and how Figma can be used to guide engineers to reliably build such components.

I’m still amazed when designers schlep together a few pictures, publish a configurable Figma component, point their developer counterparts at the main component and say “Use Figma’s inspect tool.”

Things have changed. Components are more complicated. Designers are delivering to many different developers. Accessibility has risen to the fore. For design systems that scale, teams are finding it necessary to write down all the details again.

At work in our project to improve our component documentation across the component life-cycle, we’ve been following Nathan’s advice and using his plug-in to assist with the “specification” aspect.

Tetralogical are doing a great series of articles on running inclusive research. Their latest is about recruiting participants and covers whether you should recruit people with disabilities as part of your testing and if so who, and how many, and how to recruit them.

Previous articles addressed moderating usability testing sessions with people with disabilities, and analysing findings from inclusive user research.

I recently signed up to Vitaly from Smashing Mag’s Smart Interface Design Patterns newsletter. This latest edition regarding “date of birth” inputs was interesting, and well timed as my work colleagues and I are about to revisit our form patterns. It’s a nice explainer on why we should approach UI for dates the user knows differently from UI for dates the user will choose.

Vitaly recommends that when asking the user for a very specific date that they already know without needing to consult a calendar, drop-downs and calendar look-ups are unnecessary. And avoiding them is probably ideal, because <input type=date> and <select> based interfaces have some usability and accessibility kinks, as do many date-picker libraries.

It’s better to rely on three simple, adjacent text input fields with a label above each field. See GOV.UK’s Date input component for a great example.

Date pickers should only be required when you’re asking for a date that the user will choose (say, booking a holiday or appointment) rather than one they’ll know. Vitaly doesn’t recommend a date picker, but I reckon the date-picker web component from the clever folks behind the Duet Design System could be a good option.

Oh, and this also reminds me that I need to get the finger out and pick up a copy of Adam Silver’s Form Design Patterns.

Jeremy Keith deconstructs the cheeseburger icon and—referencing Luke Wroblewski’s Obvious Always Wins mantra—argues that while icons alone look tasty they risk users failing to understand and engage.

BLOKK is a font for quick mock-ups and wireframing for clients who do not understand latin.

A cool idea here, which gives you “block” versions of the words in your lorem ipsum text, at the same width.

However at this point I do need to remind myself that designing and wireframing with real content is always better.

It’s also important to do research with all the different kinds of people who may need your service, including those who: have disabilities or use assistive technologies; have limited digital skills or poor literacy; and may need help to use your service.

Useful advice regarding user research from GOV.uk covering how to define participant criteria, find participants for research and handle incentives.

(via @paddyduke)

In this post we have seen that with just a sprinkling of HTML attributes we can improve the login experience for our users, particularly on mobile devices.

By adding certain attributes to the HTML input element – such as inputmode, pattern and autocomplete="current-password" – we can improve the user experience when logging in.

As Andrew Coyle says, “Life is short. No one wants to fill out a form.”. Here, he presents a number of form design tips to make the user experience more bearable and increase completion rates.