Monday, June 27, 2016

Nobody cares about you or your site. What visitors care about is getting their problems solved. (Vince Flanders)

This one’s a bit harsh, but I really believe harshness is what’s called for in this situation.

So, who should we start with?

How about graphic designers? For them, it seems like a lot depends on how long they’ve been out of school, or alternatively how artsy their program was. If it’s “not much” and/or “a lot” for those two questions, you may have a problem on your hands. What that actually equates to, often, is that the graphic designer will be creating something, not for the user, but for their portfolio instead. Scratch most graphic designers, and you’re likely to find someone who would really rather be drawing comic books or painting masterpieces, and is really only pushing those pixels around just to pay the bills.

Writers? Well, they might be even more problematic. Chances are, even if they came from a tech writing program, they got into the field because of their love of creative writing. Scratch most writers, and you’re likely to find someone who works on the Great American Novel in their spare time. Now, it’s not that they’re concerned about their portfolios so much this time, but that it can be a lot harder for them to get jazzed up about short, sweet instructions instead of short stories and sonnets.

A similar problem comes with writers with a communications or journalism background. Writing press releases about organizational changes or articles about city council meetings is not always the best preparation for trying to explain a website feature or sell a product. Yes, copywriting skills are very translatable online, but whatever you happen to be writing, you have to realize that, online, it’s a whole different ballgame. In the online world, the less there is, the better. That can be a pretty hard adjustment to make for anyone who ever had to work with word counts.

A final group you might have issues with are developers. They’re usually pretty good at just building what they’re supposed to, but sometimes they will fall in love with some widget or gizmo or some special way to code something.

In general, anyone on the project team – information architects, interaction designers, business analysts, clients, whoever – can become a little enamored of what they’ve come up with and lose sight of the fact that there is a purpose to the website, and that that purpose is not necessarily to create something “cool” or for you or the team to look good.

For all these groups, what’s needed is a realization that doing their particular thing is even more exciting when there are some constraints involved (with numbers one and two being what the users wants and what the business wants). That, though, makes the problem bigger, and more challenging, and – ultimately – more satisfying when you finally nail it.

A final thing to realize is that – and this may be the hardest thing to get comfortable with – is that you will ultimately be successful only when nobody notices you. Success is when your graphic design allows users to successfully pick the product they want from a comparison chart, your content lets users complete this from so they can sign up for that service they need, or really whatever you come up with simply lets users do what they came to your site to do.


The man behind the wonderful webpagesthatsuck.com

Tuesday, June 21, 2016

The only thing more expensive than hiring a professional is hiring an amateur. (Red Adair)

Not too many years ago, you needed some serious chops to pass yourself off as a usability engineer. In the beginning, you probably had a PhD, worked at someplace like IBM, and might even have had a white lab coat hanging in your closet somewhere. A little later, as usability really started to take off, you didn’t need so many formal trappings, but training at a real industry leader – like a Digital or a Fidelity or a Sun – was almost a prerequisite.

And then something funny happened … It was the days of the dot-com bubble, and all of a sudden, usability people were – well, not exactly rock stars – but well-known and somewhat respected people. Average IT and business people knew who Jakob Nielsen was, threw the word “usability” around right and left, and were willing to throw some money around as well to make their products “user-friendly.”

So, as it often does, the market responded by magically creating a supply to meet that new demand. People started sprinkling the word “usability” on their resumes, making sure they dropped it in interviews, and maybe even giving one of those usability test thingies a whirl all on their own. They didn’t necessarily have to study it in school, or train at an industry leader, or even read a book or go to a conference. Hanging out your shingle and making the claim that you “did usability” was often enough. Heck, the people hiring them had a hard time understanding the difference between usability testing and QA, so it wasn’t too hard to fool them.

Heck, it was just as easy to fool yourself. You have to actually know a little bit about a topic before you realize you don’t know squat. And that’s kind of what happened with this new crop of “usability engineers.” Now, some of them turned out to be great – they had the skills, and the motivation, and made an effort to educate themselves, and gained some real experience. But a lot of them were just awful.

I know. I saw them. I saw tests that were more like interviews and – in some especially awful situations – product demos. I saw facilitators who talked more than the users. I saw leading questions and body language that practically shouted. I saw tests that were run on the fly, and reports that were little more than transcripts. I know. I was there.

Now, usability is famous for abjuring purity in favor of results. In fact, this approach is really what’s behind Steve Krug’s Rocket Surgery Made Easy. Personally, I’ve often said that any test, no matter how quick-and-dirty or informal it is or how many things go wrong, is still going to give you some useful feedback.

The fact of the matter, though, is that there is a certain baseline to all this. No, you don’t need a famous brain surgeon to stitch up the slice on your hand you gave yourself working in the yard. But it’s not something you’d usually do yourself, is it? Chances are you going to head somewhere where someone with at least a little training and practical experience can set you to rights, right?


Yup, that’s what Red did.
Usability testing isn’t exactly in the same ballpark, but what the hey …

Tuesday, June 14, 2016

The fanatic preparation for the possible has the inevitable consequence of obscuring the probable. (Alan Cooper)

Ah yes, edge cases. AKA designing for the exception. I think we’ve all been there, right?

So, your project team has come up with simple, elegant design to – oh, I don’t know – make a payment of some sort. And now you’re presenting it to your client; or the higher ups; or your peers in IT, QA, legal, or what-have-you.

Holy cow! The things they come up with. What if it’s a bank holiday? What if the dollar amount goes into 12 figures? What if the user has more than 20 accounts to pay from?  What if it’s a full moon in a month with an “r” in it and Mercury’s in retrograde?

But that’s their job, isn’t it? Business analysts, QA types, developers, and others are typically focused on the far parameters of a system – how long should the field be, what if the user enters a date in the past, how many of this should we allow users to set up, how much of that do we need to say to be within the law?

Your job is to allow them to do what they do, but to be sure that the team also keeps the normal, the average, the expected in mind. Yes, what they’re concerned about will come up. They need to realize, though, that it will come up a lot less than they think it will.

They also need to realize that their edge cases do not need to drive the design. In particular, they need to be aware that, if they do insist on doing that, there will be consequences. Adding things in for once-in-a-blue-moon occurrences do not come free of charge.

That little change of theirs may, in fact, trip up all the other users who it actually doesn’t apply to. Those users may wonder why that part’s there, or if applies to them, or why you’re so bent on throwing all this extra stuff at them. In fact, those little changes may add up, and have a much larger impact, on a much larger group of people, than leaving all those edge cases out entirely.

So, how to solve for this? Well, just having these folk’s consciousness raised is sometimes all that’s needed. Pretty much everyone’s familiar with the old 90/10 rule, so I’ve found it’s always helpful to invoke that in these situations.

Another thing that I swear by is progressive disclosure. And all that means is that the user doesn’t have to see everything at once. You could, for example, hide the details behind links, or not show something until the user gets to a particular point.

Once again, though, just getting your team to realize that adding all those exceptions in does come at a price may be all that it takes to make them stop and think a little.




Alan also said:

Tuesday, June 7, 2016

People often test to decide which color drapes are best, only to learn that they forgot to put windows in the room. (Steve Krug)

Over the years, I’ve actually found that this is more of a problem with more experienced clients and observers. Newer ones are often happy to just be there. They often have no idea what to expect from a test. More experienced folks, however, often go into testing with preconceived notions of what the problem is and what testing is likely to find.

Here’s how it typically goes … One of these more experienced people will come to me and ask for a usability test to get at some minor detail in some design their team has been working on. To them, everything else is perfect, but there just so happens to be this niggling little detail that the design team just couldn’t get closure on. That's all it is ...

So, the first thing I normally do is try to get the client to step back a little bit. I usually just ask what the design is for, what it lets the user do, how it’s supposed to work.

I then get the client to agree to making the test more task-based. And that’s what usability tests do best – getting real users to sit down in front of a system and try to do real tasks. Now, that will get at the particular thing the client is interested in, but it will also get them feedback on the rest of the design, on the user’s whole experience, on things that might never have even occurred to the design team.

The final thing I have to do is to get the client to have an open mind.  ;^)

It really is a little ironic that I’m the one who always expects to be surprised. I mean, I’ve been doing this for almost 30 years, and spend at least 100 hours every year one-on-one with users. I should be the last person to be surprised.

That actually, though, may be the favorite part of my job. I’m always learning something new. In fact, if that wasn’t the case, and everything was predictable, I probably would have left the profession long ago. Maybe it’s because I’m basically a scientist at heart, but I always approach any test with an open mind. I really can’t wait to see what turns up. Surprise me, users!