Friday, October 5, 2018

If there is a “trick” to it, the UI is broken. (Doug Anderson)

Unfortunately, there are a lot of tricks out there right now. And I blame mobile.

Honestly, though, mobile really does have to get creative. The lack of space, if nothing else, means that we can’t be super-explicit about each and every function – there just isn’t enough room. So, it only seems logical to rely on a trick or two – gestures, swipes, double-taps, tap-and-holds – if we’re going to cram in all the functionality we want to give the user.

But how do users learner about all that stuff? Well, if it’s not “intuitively obvious,” you might have to rely on some kind of support – coach marks, demos, help … 

You know what I see a lot though? Basically, people seem to learn the most just from other people. And where I’ve seen that the most is with teenagers. They love to show each other the new app or feature they’ve just downloaded or discovered. 

Unfortunately, we are not all teenagers. So, how are the rest of us to learn?

Well, there is definitely some sharing going on within other generations (and lots between) as well. And users are definitely more apt to experiment these days (and without thinking that they’re going to “break” something).

I do worry, though, that we might simply be leaving some of those great features on the table. And, you know, that might be just fine. 

My thought here is twofold. One, we may not need to pack all that functionality in in the first place. Remember, apps are supposed to be a simpler, more streamlined version of desktop functionality. Second, we might want to limit functionality that is hard to discover to things that are more nice-to-haves, and less crucial operations that make or break anything.

All that said, I still think Doug is right. “Tricks” do not make for good UIs or good user experiences.

You put your right foot in,
You put your right foot out ...

Tuesday, September 18, 2018

You don't want to have to acknowledge that the printer is out of paper when you're trying to shut down the nuclear reactor. (Russ Benel)

Ah, yes, prioritization …

As a usability engineer, I typically see prioritization as a matter of ranking the severity of issues that I uncover in tests. I think most of us in the field recognize the need for this, though I am always surprised at those usability engineers who see it as somewhat optional.

From my standpoint, I just assume that the audience for my reports would very much like to know my opinion on which issues were particularly thorny for my users. We could set priorities as a group, but I figure they will come up with their own estimation of impact (if they’re the business) or technical feasibility (if they’re IT) on their own. What we need to do, as a team, is to identify all the variables that are in play. And for that, the team’s going to need your honest opinion – as the expert – for the usability side of things. 

Is this less important in these days of sticky-note reports, continuous collaboration, and 2-week sprints? Possibly. I don’t think Agile and Lean methodologies obviate the need for severity ratings altogether though. I mean, they might be more informal, or developed more as a group effort, but there’s absolutely no reason for them to simply disappear.

Are severity ratings subjective? Well, yes, they could be. There are, however, some fairly agreed-upon standards. The best ones are typically simple (i.e., high, medium, and low) and fairly operational (usually centering around whether the user can complete their task and how many users have that same problem). Whichever you use, though, you do need to be consistent – over time and for all your reports and report authors.

Another objective I’ve heard is that severity/prioritization can be very evaluative. In other words, I know I’ve had some reports where the executive summary had a ton of red on it. I think the objection here was that this will make an audience defensive and possibly even shut down right off the bat.

At the same time, though, a report with an executive summary like that is pretty rare. And when they do come up, I think it’s essential to get my audience’s attention and communicate that, yes, there is a very real problem here.

In particular, I want them to know – very clearly – that one issue (a major mismatch in mental models, say) really is the equivalent of a core meltdown, while another (faulty punctuation in an error message) is not exactly the end of civilization as we know it (and probably more like that dopey printer confirmation modal). 

Tuesday, September 11, 2018

Users don’t hate change. They hate our design choices. (Jared Spool)

Change does not necessarily always equal good. Something new does not always mean innovation.

Consider the poor transfer user. These are simply folks who have gotten used to doing things a certain way. Then along you come with your improvements. 

But, are they improvements? Or are they just one more thing in the user’s way that day? Do they actually make the user’s job easier? Or are they just one more thing they have to figure out and deal with? Do they add new functionality? Or have you simply added something that no one will ever use, and made the interface that much more busy in doing so? Is it better than before? In your eyes? In the user’s?

Sometimes change comes for all the wrong reasons. Perhaps the higher ups simply want a new look and feel, a refresh.  Or you could simply have been shanghaied into somebody’s pet project. I often accuse my marketing friends of monkey see, monkey do.  Perhaps management is simply flailing away. They know they need to be innovative. But how to do that other than issuing the directive to “go innovate!” might be beyond them.

True innovation comes from seeing what users are having issues with. The brainstorming and ideation (I really don’t like that word) can help you come up with a creative solution, but unless you’re trying to solve a real problem, you may simply be creating new problems.

Even if you have a good idea, though, you still need some kind of change management. As a former instructional designer (who mostly worked on new internal systems for banks), I actually spent as much time on rollout as I did on anything else. I’m always amazed at how little that’s thought of, though, in good, old-fashioned B2C. And I don’t mean just training here, but communications and even selling. 

Other ideas to support what Jared calls “embraceable change” include tours; demos; coachmarks; complete mock systems; allowing the user to switch between the old and new systems whenever they feel like it; making small, incremental changes over time rather than one big one … There are no shortage of ideas. You do, however, have to come in with a mindset that change is not always welcomed with open arms, and that it is up to you to make sure that the changes that you make really do add value, and that you are presenting them in such a way as to maximize their benefit – and minimize their disruption – 
to the user.

Tuesday, September 4, 2018

The misplaced creativeness of designers never fails to amaze. (Don Norman)

Just solve the problem! Honestly, people! What is wrong with you?

So, that’s what I want to say. What I typically say instead involves some lame hedging about standards, KISS, design patterns, never having tested that particular design before ...

Interestingly, this issue does often come up when a team is tasked with fixing something that came up in usability testing. And, in that context, my response is usually to compliment them on their effort but to point out that we won’t have to time to test their complete redesign of the system with just that one user coming in at 4:00 on Friday afternoon.

In other words, what you’ve come up with may solve the problem, but I can’t guarantee it. In fact, I honestly have no clue if it hasn’t introduced new problems. So, instead, I usually just try to get them to solve the problem, or – in Steve Krug’s great advice – to do the least possible to do so. And that is actually something I can feel pretty good about. 

Maybe it’s a digital creative thing. I know we are all encouraged to be innovative these days. And simply making an easy fix is probably not going to impress the higher ups or look good in your portfolio or make you feel all warm and tingly inside. If it solves the problem, though, why not just do it? You can then save all the creativity and innovation for something that really needs it.

Interestingly, Don’s quote was actually in the context of his famous doors. “Norman doors” are doors that are so poorly designed that they give you no affordance of whether to push or pull them. They were the example par excellence in his ground-breaking book The Psychology of Everyday Things, and have pretty much come to be the poster child for poor design. (“Norman Doors” would also be a great name for a band, by the way.)

Now, there are plenty of examples of “misplaced creativeness” in industrial design (where I guess doors would fall). Lately, though, I’ve been seeing lots and lots of examples of it in software, websites, and apps. And this is as functional a space as that for doors, and coffee pots, and stoves, and bathroom fixtures … and all the other real-world stuff Don liked to talk about. 

So, UX designers:  save the creativity for where it’s really needed. And if that means the print shop or potter’s wheel or woodworking shop that you hit only on the weekends, so be it! 

And then there’s this

Monday, August 27, 2018

God is on our side, but we can help him. (Rolf Molich)

One thing I always liked about doing usability is the knowledge that we are fighting the good fight. In our own small way, we are actually helping to make the world a better place. 

I mean, it’s not like we’re curing cancer here, but we are doing our own little part. If we make some poor user’s life a little bit easier, we are part of the solution – and maybe can even sleep a tiny bit better that night.

It’s not that there aren’t challenges in this space though.

For one thing, the battle isn’t over when you’ve run a test, or created a report, or delivered that report. Resistance is just human nature, whether the result of pride, stubbornness, or just plain laziness. You have to do a little selling, if not some follow-up and then even more selling. Hey, if that great suggestion of yours is actually going to help anybody, it’s gonna have to be implemented, right?

There is also a challenge that is fairly new to our work. It used to be that usability and UX were primarily about making a user’s tasks easier to do. These days, though, there seems to be a real emphasis on selling things – get ‘em in the funnel, get ‘em to click the call to action, get ‘em signed up, take their money …

Now, a more streamlined process is what users often want themselves. I’m really surprised, though, how often that’s not the case. Often, they want a little bit more information on something before they sign up. They might click on Apply Now just to see what the process is like. Quite often, they’ll even want to call to get their questions answered. 

Personally, I know I’ve often been the victim of buyer’s remorse on the Internet. I tend to be an impatient, slapdash kind of buyer to begin with. As a result, my garage is now full of stuff that wasn’t quite what I thought it would be. 

There is, however, often an additional result, something which is often not talked about. In addition to the cluttered garage, I’m also often left with a bad taste in my mouth, especially around the brand of the company whose website I was on or whose product I bought. So, congrats, guys. You got the sale. Unfortunately, though, you also lost the customer. Honestly, short-term thinking like that drives me crazy sometimes.

In general, I think it’s great to offer a streamlined process for those who want one. At the same time, though, we also need to provide the details that another set of potential personas need, want, and expect. Just include that information in a link, or on another page, or in some fashion that doesn’t necessarily slow down those first users. Heck, you might even make even more sales that way!

Buy before midnight tonight!  Not sold in stores!

Tuesday, August 21, 2018

While hard data informs the intellect, it is soft data that builds wisdom. (Henry Mintzberg)

Sometimes I feel like a Freudian analyst in a Big Pharma world. Bear with me on this metaphor …

We are so awash in hard data these days – just like we are awash in psychotropic drugs. Now, while both of them are actually pretty good at treating symptoms, we’re not always sure how they did so or how we got ourselves into a situation where something needed to be fixed in the first place. There’s definitely some why missing in both cases.

As an old-fashioned usability engineer, though, I place great value on the why. If nothing else, I figure that, if we know why something didn’t work, we have a much better chance of not doing that again on the next project. 

And sometimes that why really needs to sink in too. I know, for example, with writers, it usually takes more than a few tests for them to finally realize that people really just don’t want to read their stuff. Once they “get it,” though, they can then incorporate some ways to make their copy more attractive – slimming it down; supporting scanning and skimming by using lists, bolding keywords, chunking, using more headers … 

Would we ever have figured that out, however, just from combing through web analytics? I doubt it. Similarly, it’s nice that an SSRI is helping you sleep and feeling better, but it’s not going to be much good and getting at the issues you have with your mother. 

That last bit brings up a very important point. Most therapists these days try to combine the two methods – prescribe a drug to handle the symptoms, then work on the issues so that the symptoms don’t come back when the drug is eventually taken away.

So it is in UX. Use your data to identify problems (a poor conversion rate, say). Then, use good, old-fashioned usability testing to see where those problems come from (e.g., too many steps). Finally, use data again to see if the solutions you came up with (fewer steps) actually addressed the problem (a better conversion rate).

Henry Mintzberg is a biz school prof at McGill

Monday, August 13, 2018

It is difficult to see the picture when you are inside the frame. (Wendell Castle)

It’s really hard to believe I’m fighting this battle again. 

One of the principles of Design Thinking, though, seems to involve designers testing their own stuff. They are encouraged to do this in full-on guerilla mode – grabbing people in coffee shops and thrusting screen shots in front of them.

Now, I will admit that their heart is at least in the right place. They are getting some feedback. It's also good for the designers to interact with their actual users. And, finally, I’m all for informal methods.

This is not, however, usability testing. First, testing cannot be done just by anyone. There are some real skills involved, skills that need to be seen, learned, practiced, and critiqued. It is very easy to bias your user, to ask the wrong questions, to intervene at the wrong point, to generally muck things up. Heck, I’ve seen my share of “professional” usability engineers who couldn’t get it right.

I’m also a firm believer that it takes a certain kind of personality as well. I’ve mentored a lot of folks over the years who have expressed an interest in becoming a usability engineer. Some people were total naturals. Others (often because they were too extroverted, or impatient, or unfocused) struggled and struggled.

Second, humans are simply not very good at objectivity. There are dozens of proven cognitive biases that show this – the IKEA effect, confirmation bias, the backfire effect, belief persistence, denial … And based on the resistance I sometimes get from mere observers, I can’t imagine that having those folks leading the tests instead of me could possibly do anything other than make things worse. 

One of the stories I like to tell in this regard involves a favorite designer of mine who was asked to play the “computer” (i.e., shuffle the papers) in a test of a paper prototype. His body language was comical. At one point, he actually spun around in his chair when the user, who had been struggling mightily with a task, finally got it right. A brilliant designer who has since gone on to a very successful career, I might add. I wouldn’t ask him to test his own stuff though. Heck, it would probably never occur to him to do so anyway. 

Tell you what … Give the usability engineers the tests and we’ll let you guys do some of the upfront research. It’s a lot harder to muck that up, plus it can really help you get to know and build empathy with your user. Just stay away from your designs though. And don’t be afraid to ask us for advice.

I have to give this guy credit, as Wendell Castle was actually a designer himself (and of art furniture, no less)