It’s never a good time to do research (which is why you should be doing research all the time)

While the methods and the amount of collaboration required may differ, what goes for individuals goes for organizations. Every single time you are faced with a decision, you need to ask “Do we have the right information to make this decision?” If you are continuously making decisions, you need to continuously ensure that those decisions are well-informed.

Erica Hall – It’s never a good time to do research

Our Lives are Becoming Comfortable Illusions

But there’s a cost. We’ve unleashed dangerous oversimplifications of our humanity, and they’re spreading like viruses. They disrupt so many layers of our being, from our mental health, to our identities, to our relationships and our politics. We need a tribe of designers who are ready to step up and help lead the immune response. We need designers who care.

Modus – Our Lives are Becoming Comfortable Illusions

Where do UX research methods come from?

The field of UX research is relatively new, but its methods are not.

And while UX methods may have new names, many of these methods are specialized adaptations of methods with roots in other fields, well back into history.

When you understand the fields where the methods originally came from and how they’ve been adapted, you can effectively use them in UX research.

Here are twelve UX research methods and some of their interesting roots.

Jeff Sauro, PhD – Where do UX research methods come from?

Field studies and Intranet Redesign

The corporate intranet, and Enterprise Social Networks, has to support a broad range of users and many different functional use cases. Understanding the context of the people who use the platform, including the things they do that are not directly on the platform, is critical in providing a “right” design. 

“Identifying the real problem is one of the main reasons to conduct field research. After all, if you solve the wrong problem, it doesn’t matter how well you solve it. A great design of the wrong thing? It’ll still be the wrong thing. “ 

http://www.nngroup.com/articles/field-studies-intranet-redesign/

A brief case for inclusionary accessibility in design

I was at a local big-box store the other day picking up some hardware for a home improvement project and had the need to visit the men’s room. It is a large store and so has a relatively spacious men’s room, with the sinks just inside the entry followed by a row of four urinals. As I walked in I was struck by the fact that the four urinals appeared to be exactly the same, except for one detail. If you can see the featured image of this post, I’m sure you know what I’m talking about.

I couldn’t help wondering, “Why didn’t they just install them all that low to the ground?”

Of course, that was a somewhat rhetorical question to myself because I can easily visualize how the design process went.

Based on the size of the store, the building codes require us to have four urinals. Let’s go ahead and put them along this wall here and install them at the standard height. Oh, except for one that needs to be lower because, well, you know, the “rules”. Left or right side? Doesn’t matter, as long as we have a short one.

And as a result only one of the urinals was installed lower to the ground, because that was all that was required.

It would be easy enough to say that “accessibility” was not considered in the design process for this men’s room, or that it wasn’t sufficiently considered. I would argue, however, that this design is very much based on a consideration of accessibility. It’s just that the accessibility considered was exclusionary and not inclusionary.

Here’s what I mean.

Back when modern urinals were first designed to be more than an open depression or slit in the ground that men stood around to, well, you know, the only people who would ever use them would most likely be adult men. There was little or no effort made to make it possible for those with physical handicaps to even get into the building, much less any thought given to how they might use the restroom. So the urinals were designed to be exclusively accessible to adult men who could stand up in front of the urinal. (To be clear, this is just an assumption, my impression based on my understanding of history in general.)

Fast forward to today when we know better and make more effort, at least on paper, to make access to spaces and facilities more inclusively accessible. The exclusionary approach is so ingrained in the culture and in design that making something accessible for the “other” is seen as something separate, something that needs to be done because someone somewhere said it had to be done.

An inclusively accessible design for this men’s room would have, in my mind anyway, had four urinals closer to the ground than the old standard (it should become an old standard, anyway). To take it even further, the design and construction standard (and building codes, to be sure) should be changed to reflect this inclusive design approach.

If one of the urinals is going to be lower to the ground than the “usual”, why not just make them all lower to the ground? In this way you are meeting the needs of all (or at least more) with one simple change.

To be sure, inclusionary accessibility is more difficult in some situations than in others. The urinal example above is relatively straightforward compared, for example, to the challenges software and website developers have. Unlike the physical example of the urinal, which can easily accommodate all users with a single configuration, software developers have to understand and contend with often competing and contrary needs.

A basic example is the user interface of a web site in a web browser. Just take a moment and consider how you use the web browser on your laptop. Now, close your eyes and think about how you would use the web browser on your laptop if you couldn’t see it.

For the person who can see the screen, visual cues are typically sufficient and they would likely not want to hear a description of the screen or the layout read to them as they navigate the page. But for the person who can’t see the screen, the actual visual design of the site is unimportant and, for all intents and purposes, of no value. They need another way with which to navigate and to consume the content.

Which gets us back, once again, to the prevalence of exclusionary accessibility in design.

Blind people aren’t going to use a web browser, how would they see it? So we’ll just design it based on people being able to see what they are doing.

I am encouraged by some recent examples of incorporating accessibility in digital design. WordPress, for example, requires that “all new and updated WordPress code must conform with the WCAG 2.0 guidelines at level AA”. The upcoming St. Louis Service Design and UX Conference has accessibility as a focus; I hope that the speakers will at least touch on this idea of inclusionary design. And I am especially encouraged by the growing (slowly growing, but growing) awareness and use of human-centered design principles.

But none of this matters if “accessibility” continues to be seen as something separate from the main design, an add-on for the “others” that can’t use the “real” version.

We need to become inclusionary not just in our design work, but in how we see the world as a whole.

 

 

Design decisions – Shuffle Play as default on Spotify

I am really enjoying Spotify since signing up a month or so ago, but one thing really* irritates me – the default play mode is “Shuffle Play”. There’s a big button at the top of every list of songs, be it a playlist, radio station, or an album. And when you click on a song to play, it seems to automatically assume that you want to shuffle the songs.

This may be OK for most albums, but it’s a bit jarring when you go from “Speak to Me” to “Any Colour You Like” when what you were expecting was the seamless transition to “Breathe” on Pink Floyd’s Dark Side of the Moon. Which really needs to be listened to as an album, not a random mix of songs.

I don’t know how the conversation went when they set this as the default, and put that big-ass button at the top of each list of songs, but I’m going to guess it is just a reflection of how music is produced, distributed, and consumed by a large part of the music consumer base.

Maybe I’m just old school, but coming from an age when you listened to albums, and not just songs, I still prefer to listen to albums straight through, the way they were put together and intended by the artists. Sure, some albums are just collections of songs, but even with those it is comforting to hear them in their proper order. Nostalgia alert 🙂

I also tend to gravitate towards and listen to albums that are meant to be listened to in a specific order, concept albums such as the aforementioned Dark Side of the Moon and concert albums in which an entire performance is captured.

Which isn’t to say I don’t appreciate shuffle play. Over the holidays, for instance, shuffle play got plenty of use with the various Christmas and holiday playlists we had playing as we decorated, cooked, and celebrated. I just wish it wasn’t the default. Or that I could change that default.

tl;dr Is it possible to change the default play setting in Spotify to be not shuffle play?

*A lot of other little things just kind of irritate me

Design choices – web browsers

In addition to the many different features implemented in the various Web browsers, there are many  different decisions and choices made in the design of the features common across browsers. Some make sense to me and some don’t. For example…

Right-clicking

Right clicking a link provides several options for interacting with the link, the options being different based on browser features. The most common of these options, listed at the top of the right-click list, are options for opening the link,  typically “Open in new tab” or “Open in new window”. In IE11, however, the top option on right-click is simply “Open”.

rightclickdesign

What decision process went it including the “Open” option on right-click in IE11?  Did the designers think that a lot of people would want the first option on right-click to be exactly the same option as simply left clicking? Indeed, how many people right-click and select “Open” when they could simply left-click and open the link?

Smart card authentication

I use a smart card to authenticate to our organizational websites. Different browsers have a different visual design of the dialog for selecting certificates and entering PINs, which makes sense to match the overall visual design of the browser. But the on-screen location of these dialogs differs in interesting, and significant, ways.

In Chrome, for example, the certificate selection dialog is displayed at the center-top of the browser window while the PIN entry dialog is displayed at the center of the screen. If you have the browser in full screen this is the center of the browser, otherwise not. This can be especially irritating if you have a multi-screen setup and you are using Chrome on the non-default screen: the PIN entry dialog will show up on a completely different screen from the browser in which you are working.

In IE, on the other hand, both the certificate selection and PIN entry dialogs are displayed in the center of the browser window. Not only is this more intuitive (to me, anyway), it provides consistency of location for all actions related to logging in via smart card.

Update: It turns out that IE doesn’t do this universally. When sending a digitally signed email using the smart card in Outlook Web Access, the PIN entry window is displayed in the center of the screen (the default screen if you have more than one). 

Were these conscious design decisions for placement of the smart card related dialogs? Did each of the design teams look at both options (center screen and center window) and simply make a difference decision? If so, what drove that decision? Or perhaps this is just default behavior for these types of actions based on the overall design and code of the browser. Perhaps something to do with the underlying OS (in this case Windows) since smart card authentication requires interaction with the OS?

Intentional or incidental

These are just the two design differences that I notice most frequently, I’m sure there are many many more. I can’t help wondering are these choices intentional or incidental? Is it possible to make an intentional decision about every design element? Is it desirable?

How intentional are you about the design of your products, and how much of the design simply “is”?