Tuesday, July 23, 2019

Just because it isn’t done doesn’t mean it can’t be done. Just because it can be done doesn’t mean it should be done. (Barry Glasford)

I was listening to something on NPR today about the new version of The Lion King, which just came out. In case you’re not au courant with all things Disney, the new one is all CGI, with absolutely no animation, unlike the first one. One of the panelists hated the new version, and used almost this same quote to justify his stance. Even though I haven’t seen either version, he made some excellent points, and I heartily agreed with him. 

Personally, I’m familiar with the quote from my own field, but I can definitely see where it could apply almost anywhere. In fact, a quick Google search led me to links related to the Bible, feminism, travel, self-help, and – OMG! – Disney’s new Lion King.

Interestingly, though, most of those results focused on the first part of the saying. Now, to me, there’s no real insight in that. That’s basically a, “Well, duh, so what?” 

The real wisdom is in the second part. In other words, this is really a matter of balance. So, in addition to being innovative and creative and ground-breaking and all, we also have to be aware of the possibility of conflicting goals (and unintended consequences as well).

I think that’s especially important in the field of UX. So, while designers, developers, and marketeers may have fallen in love with some new “kewl” way of doing things, the team really does need to ask itself whether that’s genuinely helpful, or right for this audience, or for this context – or whether it simply gets in the way (or is even impossible to understand or use). Otherwise, all you’re really doing is showing off.

A perfect example of this just happened recently at work - one of my designers came up with a scrolling marquee. Now, in our field, brokerage, this does make some sense. You’re probably familiar with old ticker-tape-style marquees outside and inside actual brokerage offices. So, this is really just putting something like that online. And there is at least one competitor who does that as well.

At the same time, though, there are also some good arguments against it – it’s distracting, there are accessibility issues, it can remind users of those cheesy marquees on amateur sites that date back to the 90’s …

Well, I wasn’t able to convince anyone to ditch it. But it did prompt this post. And we’ll definitely see who comes out on top after a little usability testing.




Tuesday, June 11, 2019

Writing reports doesn’t change anything. Acting on the findings does. (William Horton)

If there’s one thing that gets under a usability engineer’s skin it’s ignoring their findings. 

Now, I realize that UEs are also realists as well. Yes, we are smart enough to know that legitimate business decisions can trump all. And we are also aware that schedules and deadlines might mean some change will not make it into this release (though we do assume it will be in the next one). Finally, we also realize that some changes are harder than others (though there are, of course, those developers or vendors for whom every change seems difficult and costly). 

And experienced UEs also appreciate that negotiation is an inevitable part of any process. They pick and choose their battles. No use falling on your sword for a missing comma or a particular shade of yellow.

Those kinds of UEs also realize that not everything is worth changing. In fact, I think there’s no surer way of showing your greenness than by expecting that all issues are equal, and that you will get your way with everything that came up in the test just because … it came up in the test. 

(That last bit is especially a problem for UEs who think a report is a simple dump of everything that happened. I’m always amazed at the number of UEs who seem to feel obliged to report one-offs or simple, straight-up observations. Yeah, that’s interesting – especially if you’re a researcher – but may not be that actionable to your audience.)

So, all we ask is that you seriously consider what we heard back from YOUR USERS!  Don’t like our suggested fix? That’s fine. Do address it somehow though. Got a good reason for going with something else? No problem. Do tell me a little more about that though please.

I once did an audit (at a former company) looking at which clients actually acted on issues and suggestions from test reports and which did not. Interestingly, the one client who complained the loudest and dragged their heels the most were the ones who made the most changes. Conversely, the one who seemed the most enthusiastic, spoke our language, and got along with us the best rarely made any.

In other words, the latter seemed to think that simply running a test was what usability testing was all about. Maybe it was an exposure thing. Maybe it was interesting in itself, but not really worth getting all worked up about. Maybe it was just magical thinking. 

The former, though, realized that their job was just beginning after a test was over, and that they were actually going to have to roll up their sleeves and do some hard work. Funny … Looking back, I think I actually preferred working with those guys.



Thursday, May 30, 2019

The most important consistency is consistency with user expectations. (Bill Buxton)

So, internal consistency is definitely important. And consistency to standards is huge as well.

But there is one final consistency to keep in mind. And that is consistency with the user’s mental model and with their own actual experiences. And that consistency just so happens to trump all others.

Let me give you an example. I work a fair amount with mobile teams. And, for some reason or other, those teams include a lot of Apple fan boys and girls. Whatever the issue, everyone always seems to defer to Apple standards – even when those standards are woefully inadequate or just downright wrong. It didn’t matter if 10 out of 10 users had the same problem with something that met standards, the team just wouldn’t budge. 

Another example comes from accessibility. I’ve worked at a couple of companies that took accessibility very seriously. And that means that they didn’t just stop at following all the WCAG guidelines. I found very early on in my career that those guidelines are necessary, but not sufficient. Testing with disabled users typically uncovered issues that, though the team had followed all the guidelines, could still stop them in their tracks. 

In general, I am a huge fan of standards. Users do not want to think (thanks, Steve Krug), and predictability is often their best friend online. 

In some cases, though, there is something else, something important that needs to be addressed but can often be overlooked. And that is the actual users’ experience. Trying to shoehorn these users into something that just doesn’t fit their own experience and way of thinking is going to cause no shortage of blisters, cramps, and sore feet. 


Canadian Bill Buxton is one of the early pioneers of HCI
(and is currently at Microsoft)

Wednesday, April 17, 2019

Easy is hard and hard is easy. (Unknown)

In particular, what’s easy for the developers, or the design team, can often be hard for the user. If you didn’t put some time into knowing who your users are, put plenty of thought and work into your design, and then test it to make sure it actually works, you’ve left the effort mostly on the user’s shoulders. They’re the ones who will have to figure out what you’ve slapped together. 

Conversely, what is easy for the user typically had a ton of work put into it. Systems that truly understand their users’ needs and wants and address them directly and elegantly don’t just happen on their own. You first have to make a concerted effort to find out who your users are, what they want, and how they operate. You then to have translate all that into an experience that will, if not delight them, then at the very least not draw negative attention to itself.

And that’s the interesting thing here. You can put a ton of work into designing something, and then count it a roaring success if the user never even notices it. Users come to your website or use your software to get something done. If they’re able to accomplish their goal without too much fuss, you've won!

(As a usability engineer, I’m always struck by how brief users are when something goes smoothly – “That was nice,” “Pretty easy,” “I like that.” On the other hand, users are never short of words when something doesn’t go right.)

If, however, your UI frustrates them in their goals, you have effectively made them work for it. And people don’t like that. Humans are inherently lazy creatures. Sure, we can accomplish quite a lot if we put our minds to it. Figuring out a poorly-designed system just to buy or sign up for something is not typically where we would care to do that.

Training for a marathon? Sure. Learning a second language? You bet. Spending 30 minutes trying to figure out how to expense that last business trip or register your car? Definitely not.


For some reason, this quote seems to be popular with gamers

Monday, March 25, 2019

We rushed our redesign, solving one problem but creating many others. (Evan Spiegel)

Ah, the wonderful world of unintended consequences. One of my favorite topics.

Now, if you’re not familiar with Evan Spiegel, I’ll just let you know that he’s the CEO and co-founder of Snap Inc., the company that brought us Snapchat. He was also the youngest billionaire in history, at age 25, back in 2015.

What is he talking about? Well, back in the last quarter of 2017, Snap released a new design of their popular app. To make a long story short, it didn’t work. I’m talking losing 3 million users, a dip in brand impression from 30 to 8, and ad views and revenue going down 36%. Ouch!

I won’t go into the gory details of what they actually did, but suffice it to say that it was a perfect example of unintended consequences. I mean, the company certainly didn’t mean to lose all those users and revenue now, did they?

How did it happen? Once again, I won’t go into the details. Heck, I don’t even know them (though I certainly could guess). I looked around, but I’m not sure that’s something the company felt comfortable sharing.

Now, my first question, as a usability engineer, is, of course … DIDN’T ANYBODY DO ANY TESTING?  How did they know this redesign was going to work? Where did their feedback come from? Did they get any feedback?

Now, Spiegel points to rushing things, but I think there’s a lot more to unintended consequences than just that. Hubris, for example. Or denial. Or short-term thinking. Or what have you …

Now, of course, you can put a lot of thought into something before you attempt it. Honestly, though, I don’t think you can still predict everything that might happen. And that’s why I think it’s so important to get something usability-tested. A/B might work, of course, but that means it’s live. Testing lets you get some feedback in a “safe space.”  Might even give you some idea why it wasn't working.

Whatever you do, though, do something! Get some kind of feedback!


For some reason, most pix of Evan also feature his wife

Thursday, March 7, 2019

It’s not what you don’t know that hurts you. It’s what you know that ain’t so. (Will Rogers)

Sometimes I prefer my clients to be ignorant. In my experience as usability engineer, user researcher, and even instructional designer and tech writer, I’ve just found it so much easier when my clients are blank slates.

Of course, clients who really know what they’re doing are the best of all. Those, however, are pretty few and far between. It’s much more common to get somebody in the middle. And, to throw in another quote, “A little learning is a dangerous thing” can definitely apply to that middle zone.

I’m always amazed at how many things people “in the middle” just don’t get, or don’t get right. There’s probably a number of reasons why however.

The first may simply have to do with exposure. Clients may have simply heard of an idea only in passing – a mention at a conference from last year, an article they once read, a conversation in the hallway. In those situations, subtleties and true understanding are really hard. Overly broad strokes and misconceptions, on the other hand, are really easy.

Usability engineers always know, though, that “it depends,” and things are never as simple as they appear. A good example here might be the number of clicks rule. A couple of years back, marketeers fell in love with the idea that everything should be a couple of clicks away from the homepage. On the surface of it, this actually made some sense.

Some unintended consequences of that, however, included some particularly dense homepages and menus. Further, results from testing showed that users didn’t really resent (or were even aware of) the number of clicks, and were happy to go their merry way as long as they felt confident where they were going. Ironically, this idea of “information scent” could be stronger with a deeper IA than with a shallower one. 

It may also have a lot to do with where you got started. A perfect example here is personas. If you have some background in marketing, when you here the word “persona,” you automatically translate that into “segments.” It’s not the same! And it can be really hard to adjust gears and understand the difference. 

That actually reminds me a lot of the linguistic concept of false friends. Not to go too far off topic, but that’s when a word you know in English, say, doesn’t mean the same as a word in another language that sounds just like it. For example, don’t say you’re embarazada the next time you slip up with something with your Spanish-speaking friends. It means “pregnant”! 


Will Rogers doing a little man-machine research 
on some early radio communications hardware

Thursday, February 28, 2019

It is not how much information there is, but rather how effectively it is arranged. (Edward Tufte)

I agree with this statement up to a certain point. Of course, in a typical situation this is spot on. If I had a dollar for every time I’ve flagged “grey blocks of text,” I’d be retired now. Honestly, it’s funny how frequently and consistently that comes up.

I never really tried to analyze why, but off the top of my head, I would guess it’s how all writers are trained. And that goes all the way back to grade school. Think about it. What did Miss Thistlebottom at Woodrow Wilson Elementary School want? Big grey blocks of text – each preferably with topic and summary sentences (and none of those beginning with a conjunction or ending in a preposition)!  And something similar continued through middle school, and high school, and college. The whole point was to show that you had understood a particular topic by writing about it at length. You were also trying to impress teacher with just how darn smart you were. Wordiness was something to be encouraged. Long paragraphs and sentences were a good thing.

I’ve actually seen something even for college-level students who were in writing programs. And, here, I don’t mean creative writing, but journalism, and marcomm, and even professional writing. A newspaper article, a marketing brochure, a press release are not, however, all that different from what they were writing back in 6th grade – at least in terms of structure and look, if not in quality.

Everything, though, changes when you go online. We all know that people don’t want to be made to think (thanks, Steve Krug), but it just so happens that they also don’t want to be made to read. Instead, they are much more likely to want to scan and skim. 

Now, I’m not necessarily talking about an online article here (in those situations, readers are apt to “scan and swoop”). What I’m talking about is someone trying to complete a task – sign up for something, shop for something, pay for something, find some bit of information, make a decision, do something other than just read for pleasure.

In those cases, readers will scan and skim. And the smart writer will be sure to support that strategy. And that includes using lots of chunking, plenty of lists, more titles than seem necessary, and some way to emphasize keywords. There’s no better description of that strategy (and why it’s so necessary) than some research that Nielsen Norman started doing way back in 1997.

Returning to Tufte’s maxim … 90% of the time, he’s got it nailed. In some cases, though, there really is just too much stuff. I know. I’ve seen that too.


I’ll bet Tufte never thought in a million years that 
he would be roped into a discussion about writing