The toggle between designers and users

Sometimes very simple design decisions have unforeseen complex consequences. For instance, it could make sense to design an on/of switch, in order to toggle certain settings on a website. Designing such a control visually can be done within a minute.

There can be several reasons to choose an on/off pattern instead of something simpler, like a checkbox. For instance, the designer may think it looks nicer/fancier. When the iPhone just came out many visual designers wanted to incorporate these switches into their designs. They looked good and worked well on iPhones. So they wanted them on the web as well.

Creating a prototype of such a switch that works with a mouse shouldn’t take too long. Things get a bit more complex when you try to create a prototype that also works as expected with touch, and the keyboard. And it gets even more complex when the control goes into production and it is used with a screen reader.

In his first blog post on his new blog, Heydon Pickering explains in great detail the complexities behind a few different toggle patterns for the web.

He starts with simple native controls like radio buttons and checkboxes and explains how different users experience these things. Accessibility is built into these native controls, and while they may not always be optimal from a UX standpoint, people with a bit of experience on the web do understand how they work.

He goes on with a button with a changing label. And he explains the workings of the on/off switch I mentioned before. Things get more complex here. For instance, the visual state needs to be very clear. Is it pressed or not? Is it clear to everyone whether the state is on or off? And then, when someone uses a screen reader: its state has to be explained somehow. These are layers of complexity that are easily overlooked when making a mockup in Photoshop, and they are even easily overlooked when creating the thing in HTML. It works for me is often the used definition of done. Or it works with this jQuery plugin.

Users may have different definitions of done than designers. Their needs can be pretty basic: it has to be usable. Or a small step further: it has to be easy/clear to use. When the visual state isn’t thought out or tested well enough there can be a conflict here. And when it isn’t tested with a screen reader there will probably be a conflict there.

I am very much interested in these to different, and sometimes conflicting definitions of done. The one used by designers, and the one used by users. I think that by exploring these definitions I may be able to find a few ways to understand where the pain points are, and in the long turn make these definitions less conflicting. In other words: there shouldn’t be a toggle between designer and user: their interests should both be always turned on.

I think Heydon’s blog post is a great example of these conflicts: When the complexity behind a well intended design is not fully understood the result can even be worse UX.

The brilliant thing about Heydon’s blog is that it’s not just a blog with articles, it’s also meant to be a component style guide. A place to find working examples of well thought out complex interaction patterns. It looks like it’s going to be a very nice resource for people who quickly want to copy and paste some working code, but also for people who want to truly understand the different layers of complexity in digital UX.

I’ve been thinking about these two groups. First of all: how can we make sure that amateurs make usable stuff? Good examples, especially when they get incorporated into open source projects, may result in better tools, and thus may result in better products made by tinkerers who may not be interested in gaining expert knowledge of the different levels of UX. Without them knowing, better tools may result in better products.

On the other hand, how do we make sure that professional designers understand that they don’t just design for the happy flow? Examples like this toggle functionality may help. They give great insight into possible conflicts: it may look good, but it will take a sizable bite out of the budget if we want to get it right. Is it worth it? Is it realistic?

Articles like this one are great for design educators like me. They’re great illustrations of the multitude of problems at hand, not just from a technical point of view, but also from a UX design point. And thus they can serve several different purposes in different design modules. And that’s exactly what I’m working on.