Wednesday, December 5, 2018

Design is the art of gradually applying constraints until only one solution remains. (Anonymous)

And that, basically, is the difference between art & graphic design. That said, I do, however, meet a lot of graphic designers who wish they were – or were trained to be – the former rather than the latter. Now, this may be no more harmful than the copywriter who’s working on that novel at home, but it really does seem to be something to watch out for. 

When you’re doing art, there are no constraints. You can put a crucifix in a jar of your own urine, make a Madonna out of elephant dung, or cover a skull in diamonds and post it for a cool £50 million. It’s totally up to you.

That said, your first constraint may be whether you want to eat or not. So, unless you are Andres Serrano, Chris Ofili, or Damien Hirst, you may want to try something a little more salable – something you could hang on a wall, say, or place on a nice pedestal. 

And if you’d like to eat something nice, well, you might go so far as to get a real job, like being a graphic designer for a large corporation, where they may very well ask you to work on their website. Of course, that’s likely going to be a little bit of a comedown from the woodcuts you made back in school.

But don’t give up on it just yet. It can actually be pretty interesting stuff. And, you know, when you were doing woodcuts, you definitely were working with some constraints too – primarily for the medium involved.

In a commercial space, you will have even more constraints. You will need to think about the limitations of the web and of Photoshop, but you’ll also need to think about your audience, and their goals, and your company’s goals, and your team … and all sorts of things. 

Now, you may feel have no free expression left. But here’s another way to think about it … What you’ve got instead is a chance to solve some problems. Yup, all those additional things you have to think about add interesting little wrinkles to your process and what you deliver. In fact, it can be quite a task to juggle all those things at once. But once you’re done and you’re delivered something successful, it can be very gratifying.

One thing you’ll need to look out for, though, is opting for the “elegant,” or “creative,” or “cool” solution. If it genuinely solves the problem and doesn’t get in the user’s way, great! Sometimes, though, what can seem elegant or creative or cool to you can be less than clear to your user. Just make sure you’re actually solving problems, and not inadvertently creating them.


Damien actually got $100 million for it

Wednesday, November 28, 2018

If all you have is a hammer, everything looks like a nail. (Abraham Maslow)

Abraham Maslow? You mean the hierarchy-of-needs guy? He came up with this quote?

Indeed he did. In particular, it was in his book The Psychology of Science, which came out in 1966.

Needless to say, it’s quite an old idea. But Maslow surely made it his own. His quote is a great example of, as Alexander Pope put it,  “what oft was thought, but ne’er so well expressed.” 

Indeed, the sentiment is so basic and well-accepted in psychology that it has its own law – The Law of the Instrument. 

And how, pray, does that fit in with usability? Well, I don’t believe it’s something that usability engineers and user researchers are guilty of.

Instead, it seems to be quite a common behavior from clients. In the old days, for example, they were often much more familiar with focus groups than with usability tests. So, they would ask for a focus group when they wanted feedback on a new system ... and then keep calling it that up to the test, during it, and often after!  Steve Krug’s got a hilarious video on that right here.  

These days, it’s more likely that they’ll want a usability test – even when a card sort, or some ethnography, or whatever is more appropriate. And something I’ve seen a lot recently is that they’ll take some particular form of testing – remote unmoderated, 5-second, one-click, etc. – and ask for that instead. Hey, those are typically cheap and quick, right?

So, the approach I usually use here is to first ask them what problem they’re trying to solve. I then try to help them realize that I’ve got a huge toolbox – with screwdrivers, and hammers, and wrenches, and even the occasional shingle froe. And that if we talk about it a little, I’ll make sure they get the right tool for the job.

In other words, what I try to get across is that I’m a consultant, and not just an order taker. You know, kind of like with your plumber, or electrician, or lawyer, or doctor. In other words … Please Mr. or Ms. Client: bring me a problem, not a tool. 


I always thought he must have been a great guy to have a beer with

Thursday, October 18, 2018

The purpose of life is not in making it go faster. (Gandhi)

There’s something that bothers me about technology these days. And I’m hoping that that’s more than just a reflection of my age.

I think Gandhi’s on to something here. Have humans ever been so busy as they are right now? 

Does that describe you? Are you always in front of a screen – desktop, laptop, or mobile? Do you use multiple screens at the same time? Are you triple-booked for everything? Do you constantly multi-task?

Did you know that you also might not be doing your best work? There is a ton of research out there that says that humans really can’t multi-task. Note that that means not that we’re not good at it. We simply are incapable of it – and we fool ourselves whenever we think we are. 

There is also plenty of research that says that reflection is on the wane, but also that time for reflection makes for better decisions. And also for more creative decisions – the kind that might lead to out-of-the-box solutions and real innovation. 

Making life go faster is certainly all the rage these days – what with Agile, and fail fast, and lean UX, and “move fast and break things” … Now, that might all be good for startups.  But is it good for larger companies, like an Apple?  I actually understand that Apple does not use Agile.  Hmm …

Now, more importantly, do you contribute to all this with your work? Is your company’s goal to make addictive UX? Are you in the business of short-circuiting users’ thought processes and just getting them to click on the call to action? Is that badge really necessary or is it just a shameless ploy to get the user to open up your app? Is your work distracting? Need it be? Why?

Are you part of the solution or part of the problem?  


Gandhi’s idea of technology

Let me end with this quote of his:

I hate not the machines, but this growing passion for machines. I hate the passion for the machines which work upon diminishing manpower. Some talk about machines which could spare manpower when thousands of people are thrown jobless on the streets. Yes, I want the human toil and time to be spared not just for a sect of people but for humanity. I want the wealth to be accumulated not just in few hands, but for all the people in the world. Today machines favor putting a handful of people on top of thousands.

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!



 Also from Rolf:

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)

Tuesday, August 7, 2018

No one ever listened himself out of a job. (Calvin Coolidge)

Boy, people sure do love to talk. For a usability engineer, though, that’s a great thing. If they didn’t do that, the think-aloud method would have never seen the light of day, and I’d have probably had a career doing something else entirely.

I probably don’t need to tell you all that however. In the lab, listening is our main duty. Not only do we need to listen though. We also need to listen in the right way. 

You’ve probably heard of active listening before. It’s really just a set of behaviors we can use to make sure that listening isn’t just simply a matter of waiting for our turn to speak. It includes things like demonstrating attention, monitoring body language, paraphrasing, asking open-ended questions, probing, and watching for emotional impact. And that’s a great start. 

Some other things we can do include simply shutting up. (I’ve often said the best tests are the ones where I don’t say “boo.”) And when we do intervene, we need to be brief and completely unbiased. Our real job is simply to keep the user talking. Three particularly valuable tricks (which I learned from Judy Ramey, at the University of Washington) include:

  • Simple saying “uh-huh”
  • Echoing what the user just said (“You like that feature …”)
  • Repeating the user’s incomplete verbalization (“You think that …”

What usability engineers sometimes forget, unfortunately, is that they can apply those same skills outside the lab as well. And, when I say that, I’m not just referring to on-site testing or field studies either.

We can definitely use those same skills when we interact with the people we work for and with. An obvious spot to do so would be a stakeholder interview. It can also, though, come in handy in meetings, phone conversations, hallway drive-bys, and in pretty much any interaction we might have.

In fact, at this point in my career, I’ve become so good at it that I have colleagues jokingly accuse me of pulling “jedi mind tricks” on them. And, who knows? Maybe they’re right.




Our 30th president was after all
also known as “Silent Cal”

Tuesday, July 24, 2018

Creating a good UX is not a design problem, it’s a power struggle. (Alan Cooper)

I like to joke that I work in a sausage factory. Now, the various companies I’ve worked for over the years have produced some mighty tasty sausages. Our customers would be shocked, though, to know what actually goes on behind the scenes in the creation of their particularly delicious software, website, or app. 

It’s really not too surprising if you think about it though. First, there are usually way too many chefs in the kitchen – the client, upper management, the design team, IT, legal, usability … And everyone has their own opinion – if not axe to grind.

Further, there’s typically no set recipe. Oh sure, everyone tries to formalize the process somehow. But what all that usually devolves into at some point is a good, old-fashioned knockdown, drag-out fight. 

And I think that’s just human nature. We all pay lip service to collaboration, but there are always going to be dominant types who fight for their way as they climb up the corporate ladder. Ever been exposed to the DISC personality typology? It’s the only one I know that actually is quite honest about all this –  with D meaning dominant, S submissive, and C compliant (I is for influencers, by the way – sort of dominant types who are also pretty nice). Other folks may simply have fallen in love with their own design, want to get their own two cents in, have poor impulse control, or just possess an overly sized ego. 

I have noticed, though, that some companies are a little better at managing this than others. A lot of them, for example, have solved the problem by simply being very hierarchical. Of course, unless you’re the U.S. Army, this really isn’t the optimal solution. (To tell you the truth, though, I actually prefer this structure to the Darwinian free-for-all.) And I’ve also worked at some companies where people were actually pleasant to each other, weighed the evidence, and tried to make the right decision. Shocking, I know.

Well, one thing a usability engineer always has going for them is the evidence. I find that can have a lot of weight, even in the middle of those knockdown, drag-out fights. And as for those types who aren’t interested in evidence and live in a alternative fact-free universe? Well, those are fights I don’t care to even get involved in.


Though it’s definitely not just Microsoft

Wednesday, May 30, 2018

It got so easy it got hard. (Gayle Wellborn)

Gayle Wellborn was simply a former exec I worked with at one time. Unlike a lot of execs, though, she seemed to really get usability. For some reason, it was just very easy for her to identify with the user. I’ve never met another exec – with their MBAs, or technical backgrounds, or bean counter creds – who was able to accomplish that so easily.

This particular comment came out at some review, and though we all kind of laughed at it at the time, I found that the more I thought of it, the more I became aware that she had really put her finger on a very important principle of design.

Now, most tech I deal with has just the opposite problem. It’s just too darn complicated. Sometimes, though, a design team has learned that lesson, and has gone just a little overboard in the opposite direction.

In particular, I find that this is an issue with graphic designers. Often, they want a nice, clean, aesthetically pleasing interface. And, sometimes, to get that, they might throw away some parts of the UI that were actually pretty central for the user to understand what exactly was going on. So, though the UI might look super simple on the surface, it actually makes the user’s job a little harder, forcing them to guess what some things might mean, or how to do something, or what to do next … when we could have made it so much more easy for them.

I see this a lot, in particular, with mobile. Now, I realize we’ve got a lot less real estate to work with, and the last thing we want to do is make it cluttered. But just thinking back to the struggles my users have with hamburger menus, or kebabs, or the tiny little dots that signal a carousel … 

And it’s not a matter so much of simply deleting affordances. There are also features that don’t appear until you mouse over them, using one feature to do multiple tasks, an over-reliance on icons (and a subsequent aversion to labels), gestures … 

But how can you tell when it’s so easy it’s hard? Well, one thing is to keep your target audience in mind (and realize, of course that they will be different from you). Personas are great for this. Second, test it out. See what’s hard, what’s missing, what needs a little boost – and then fix it. 



Tuesday, May 1, 2018

Under carefully controlled laboratory conditions, any lab subject will do exactly as they wish. (Caroline Jarrett)

And that’s why we love them. It’s what makes our job fun.

I’ve always said that the great part about usability is that we get to work with the two most complex things in the universe – humans and computers. There’s no telling what we’re going to get.

But we wouldn’t have it any other way, would we? Living, breathing human beings, with all their quirks and complications, make for very interesting work. 

In fact, I like to tell new usability engineers that out of every 10 users, they’re probably going to get at least 1character. But characters are fun, are not too hard to handle, and can help brighten up a long day.

Of course, I also point out that 1 in 100 is going to be a crazy. And that, for 1 in 1000, you’re going to need to call security. Both do make for engaging stories afterward though.

It’s also why I take a fairly relaxed approach in the lab. No lab coat for me. No voice-of-god mic. No clinical lab setting. I just like to sit with the user, engage with them to the degree they need it, prep them properly, then sit back and see what happens.

I know they’ll go off script sometimes. And, usually, I let them. I’ve gotten some good stuff over the years that way. That said, I have also developed a number of good tips and tricks to get them back on track without their ever knowing it.

Heck, after 3000 users, I kind of like it when I get a bit of challenge. Honestly, though, there’s probably nothing I haven’t already seen before.


Wednesday, April 18, 2018

Please forgive the long letter; I didn't have time to write a short one. (Blaise Pascal)

Huh! I always thought it was Voltaire.

Anyway, one thing I’ve noticed over the years that this is a very common problem with new usability engineers and user researchers. And what that means is both too many pages (in reports, of course – not letters) as well as too many words on that page.

Now, I do have a hunch of where this comes from. And that would basically be school. Think about it. Throughout everyone’s academic career, we are usually awarded for over-delivering. It’s basically the standard way to show how smart you are and how much work you’ve done. Hey, nobody’s awarded gold stars for 16-pt type, wide margins, and something slightly under the mandated page count, right?

I guess I’m kind of lucky in that I happened to round out my academic career with a graduate degree in tech writing. The difference between what I learned in that program and what I learned as an undergrad English major could not have been more stark. 

In fact, it was only as a grad student that I first learned the basics of the rhetorical situation – audience, purpose, and context. So, who is this for? What are you trying to accomplish with it? How is it being delivered? How will it be processed? How likely is it to be accepted?

In other words, in the real world, the point of writing is not to impress the teacher and get a good grade. It’s to get things done – to impart information, to offer suggestions, to come to an agreement …

And what’s an effective way to do that? How about a PPT where you can get through every slide in an hour? A presentation where the amount of information on each page is not a distraction to what you are saying? Something where an audience member might remember 3 main points 10 minutes after the presentation is over? 

To tell you the truth, this is advice that is not just for junior team members. I just sat through a presentation where a very seasoned team may have gotten through 10 slides of a 40-page presentation.  

And it’s definitely not easy either. It takes a brave (and experienced and humble) soul to take all of that great work they did and distill it down to something that their audience can actually relate to, process, and value. It’s truly something every UE and UX researcher needs to remember though – it’s not about you!


Yup, that's him alright!

Monday, April 2, 2018

It depends (every usability engineer ever)

I’ve often joked that I want this on my tombstone … Even though I feel a little conflicted by it.

On the one hand, I see my offering this statement as a good thing. It means people are coming to me with questions. So, basically, I’ve gained their trust. Yay!

On the other hand, though, there are some things that make me cringe a little when I have to say this. Probably the main thing is that my clients seem to be thinking in black and white terms. Alternatively, they may also simply be wanting a thumbs up / thumbs down from yours truly.

One of the things I feel like I am always trying to get across to my clients is that the world is a complex place, and a lot of it is very situational. In particular, I like to get across that usability issues are often contextual in nature.

For example, who is this system for? A technical audience? Well, they may be just fine with it. Your average Joe or Jane? No way in heck!

In addition … What is the user’s goal? How motivated are they? Where will they be doing this? Have they seen stuff like this before? 

What are your goals? Are those in conflict with the users’ in any way? How should we prioritize? Who is making the decisions?

How hard is it to the make that change? Do you have time to do that? Is it worth the effort? What are the goals of your project?

Overall, how is this decision being applied? In just this particular situation? Across the board?

And on and on and on.

You know, maybe “it depends” is just a good way to begin the conversation. Maybe a better way to word that simply would be, “Tell me more.”


Ha ha!  Very clever, funny developer guys!

Thursday, March 29, 2018

There are three kinds of lies: lies, damned lies, and statistics. (Benjamin Disraeli)

I have a mixed relationship with statistics. 

On the one hand, I know their an important part of our history. I also know there some of us out there who still do a bang-up job with them (Jeff Sauro and Jim Lewis come immediately to mind), Finally, I also realize that stats definitely have their use.

I myself, however, am much more qualitative. I generally like to leave stats to things where they are a much better fit – surveys, web analytics, A/B testing, big data ...  I’m more than happy with my rich, why-based qualitative data.

That said, I do use stats.  Because of the qualitative nature of my data and the much smaller number of participants I typically have, though, my stats tend to be much more on the lighter side.  For example, if I’ve got my typical 10 users, I think it’s good for my audience to know if it was 2 users who had a certain problem versus 9 of them.  

I also typically eliminate any 1-offs. I find they typically draw too much attention to themselves by their mere inclusion.  That also has the added benefit of making my report easier to write, and easier to read as well. 

I also might do error rates.  Once again, though, I try to keep it simple.  If the user aces a particular task, that’s a 100.  If they veer off somewhere but eventually get back on track, or if they complete everything but miss 1 small part, that’s a 50.  If they give up and look to me (and even then complete it with some help from me), that’s a 0.  I add ‘em all up, and then generally use a simple academic grade scale – 90 and above is an A, 80 to 90 a B, and so on.  I just want to give my audience a rough idea of how the system performed.  (BTW, time on task – because of think aloud – means absolutely nothing to me.)

Finally, I also like to do a SUS. Note, though, that scores for individual tests mean almost nothing on their own.  I do keep a running total of all tests we run however. And that let’s me compare 1 particular score to all the rest, to an average for the type of system or user group, or for previous tests of the same thing. Very helpful.

So, yes, I do use stats.  But only in the simplest, most direct ways that pretty much anyone – business types, developers, writers, graphic designers … could understand.  


I have no idea why he’s on a phone case, but there you have it

Tuesday, March 20, 2018

Do the right thing. (Digital Equipment Corporation)

My first job out of grad school was at Digital Equipment Corp., or DEC. For those of you who haven’t been around as long as I have, I like to tell people that it was the number two computer manufacturer in the world at that time, and was something of the Google of its day.

Google, in fact, has a similar motto, “Don’t be evil.” Well, DEC’s is a little more positive, of course. But it's still the same general idea.

Now, we might contrast those two that with the motto of Facebook. Their motto was originally “Move fast and break things” (they’ve since come up with some bland official pablum). 

Well, I guess they've managed to do both, haven't they? They moved very fast, and they seem to have broken many things – the ability to go more than a few minutes without looking at your phone, any sense of personal privacy on the Internet, journalistic objectivity, the democratic process, civil discourse …

I think this is particularly ironic as Facebook is a social media company – a company who’s purported purpose is to bring people together. Of course, there is also their business model. And that revolves around addiction cum targeted marketing – basically hooking people then delivering them to large corporations so they can extract your hard-earned dollars (and yen, and euros, and yuan) from you in the most efficient manner possible. You know, maybe their motto ought to be, “Profits before people.”

So, what does all this mean for the average usability engineer out there? Well, there was a time when our main job was to make things easier to use, for users. In essence, we made the world a friendlier, nicer place. These days, though, it seems mostly to be to sell, sell, sell. That moral high ground we used to occupy is steadily eroding. 

So, what can we do about it? Well, when your company, or project team, or colleagues, appear to be blindly headed down that path of moving fast and breaking things, perhaps you can be the still, small voice of conscience. In other words, don’t be afraid to raise your hand. Ask them about the implications of what they’re proposing, what effect something might have on your brand, how that UI change will fit into the customer journey. Remind them, too, that there is more to the world than profits, that a handsome paycheck does not absolve you of all moral obligations, that there is still a possibility for UX to make the world a better place.


The only wrong thing former DEC CEO Ken Olson did was to bet against the PC  :^(

Wednesday, March 7, 2018

Agile is twenty cement mixers pouring feverishly while somebody looks in the Yellow Pages under "architect." (Roger Belveal)

I have incredibly mixed feelings about Agile

On the one hand, I know people are making it work with usability. I have even done something like that myself.

On the other hand, though, I know it was developed without usability in mind. Now, you can make it work with usability, but you really do have to make a separate, concerted effort.  It is not baked in.

Out-of-the-box Agile does not guarantee usability. This worries me, as I am often struck by the zealotry of a lot of Agile advocates.  In fact, there seems to be a certain fundamentalism within Agile that implies that you have to do Agile only in its purest form.

So, what does Agile have instead? Well, there are the user stories. And they are a great way to turn requirements into something that ties in real users trying to do real tasks with real goals in mind. So, that does loop the user in when it comes to creation and design at least.

But how about the evaluation part? Yes, Agile does a great job making a tweak here, a tweak there, then rushing it out to market to see if it “moves the needle” with actual users. A/B testing is an even more sophisticated version of that.

Note, though, that this is totally correlational. You know that something worked better, but you have no idea why. Design, then, becomes a simple shot in the dark. Throw it on the wall and see if it sticks. Run it up the flagpole and see who salutes. I was hoping we had come a little further than that in all these years. Sigh …

Now, there’s plenty out there about how to make usability work within Agile, and it does make a lot of sense (and, like I said before, I’ve done it myself). I do really worry, though, about the people who aren’t super-sophisticated about UX who hear about Agile, can’t wait to jump on the bandwagon, and want to “do it right.” Unfortunately, that last bit often means not even thinking about something that took years to finally become adopted in IT and which has proven its value many times over. For me, it almost feels like starting from scratch in a way. Maybe I’m naïve, but I honestly thought I’d never have to make those arguments again.


In addition to being a kick-ass UX professional,
Roger Belveal is also a pretty talented artist
(these are his iPhones made out of concrete and steel)

Friday, February 16, 2018

However beautiful the strategy, you should occasionally look at the results. (Winston Churchill)

And isn’t that what usability testing is all about? 

Of course, there are other ways to get that information as well, especially these days. For one thing, you can simply put it out there and monitor the heck out of it. 

A kind of old-fashioned way to do that is Voice of the Customer – popping up surveys, including “give feedback” links, and so on. These days, you can even monitor social media. It’s all good stuff, but there’s also no shortage of possible drawbacks. I already wrote a post going over those in great detail, so I won’t repeat all that here.

You could also take a look at web analytics. (I wrote about that, to some degree, in another post.) The main thing with analytics, though, is that, though you might have tons of data showing exactly where users went and what they did as they actually used your system, you totally lack why they did so. And that can be pretty darn important.

It’s the same problem with A/B testing. Once again, you get reams of real data, all tied directly to the bottom line, and in this case, totally actionable. You are, however, relying totally on correlation – which, in my opinion, means relying totally on conjecture. We know that A performed better, but why? How can we tell with just the numbers? What were users thinking when they went with A?

And then there’s usability testing. It’s the prime way to get feedback before release, but it also provides super-rich data that can be used to completely understand your users, identify and understand their issues, and then come up with legitimate solutions to address those issues. 

That said, if you are getting some kind of feedback, you are way ahead in the game. What really worries me are those companies out there who basically don’t do any of this.

By the way, when Churchill was talking about strategy and results he was actually not talking about usability testing (I know, hard to believe). I would imagine he was talking about something like war plans, or economic strategy, or political campaigns. Unfortunately, we may never know. There is actually no evidence that Churchill ever said that (and I’m not sure who did). But it certainly does sound like something he would have said.


Bet you had no idea that the Daleks were a secret weapon during WWII
(or that Churchill looked anything like that)

Thursday, February 15, 2018

Mobile is a magnifying glass for your usability problems. (Josh Brewer)

There are designers and developers and UX researchers out there whose whole world seems to be totally encompassed within the mobile space. Now, that is definitely a fact of life these days. At the same time, though, that’s also a tad unfortunate as well.

For some of these folks, mobile is a brave new world, where they are intrepid explorers creating their own rules. Now, mobile definitely is terra nova. It is not, however, terra incognita.

For someone who’s been doing this as long as I have, mobile is really just the latest whatever. All the things that we learned about green screens, CLIs, GUIs, the Internet … they pretty much all still apply. Yes, there are new things like gestures, but affordances, mental models, proximity, hierarchy, information density, legibility … all that great stuff has not somehow magically disappeared overnight.

Reinventing the wheel is not the point with mobile. In fact, designers need to think, not about being innovative so much, but more about handling the old principles within the additional constraints that mobile involves. 

And what are those? Well, the main one by far is simply the huge difference in screen size. And what does that mean relative to UX? More than anything, I think it takes the old KISS formula and makes it absolutely paramount. Complexity that you might have been able to get away with on a nice big screen is simply going to blow up in your face on mobile.

Less central – but certainly not unimportant – issues include awkward input, new environmental contexts, and several others. There’s also one thing I’ve noticed which probably doesn’t need to be an issue at all. For some reason, some designers took the new context of mobile and decided to just ditch the idea of affordances altogether. 

What do I mean by that? I just seem to see missing pieces on every mobile test I run – or as simply a user myself. In fact, just this morning, I was testing out a prototype for a test I’m running next week on an iPhone …

First, though, I had to clean the screen up a bit, and get rid of some old icons on the home screen. Now, how to do that? Why press and hold those icons, of course (I somehow remembered that from the last time I had to test an iPhone). That puts you into delete mode, where the icons wiggle and have litte x’s in their top-left corners. Okay, this I can figure out – an x is a pretty darn clear affordance. But what do I do to return to normal mode? I would imagine I would press a wiggly icon again. Nope, you press the Home button (had to really think about that one).

Now I can type in the URL of my new prototype. I do that, bring it up, then wonder how I can put an icon for it on my home screen. Oh, it’s the little box icon with an arrow in it (had to ask an iPhone user for that). What do I click now (interestingly, the iPhone user couldn’t help me there). Oh, that little bar of icons on the bottom – looks like I can slide it over (had to ask an iPhone expert for that one). Now, why didn’t they signal that somehow? You know, like with a >, or a little bit of the next icon, or practically anything? 

And all this is before I even get to start in on that prototype. And after that, I then get to try it all over again on an Android, which I least am familiar with, but which also has its own way of doing things, and its own set of affordances to ignore as well. Ugh, it’s gonna be a long day …


Josh was once the principle designer at Twitter

Tuesday, January 9, 2018

Our inventions are wont to be pretty toys, which distract our attention from serious things. (Henry David Thoreau)

Over the past few years, I’ve noticed something rather disturbing.  I noticed it with my 20-something sons, my wife, and even at times myself. 

People seem to be addicted to their phones and computers. I don’t mean this in a metaphorical way, but very literally.

I actually followed up these observations with my own, very informal field research. Out to get a bite to eat for lunch on the streets of my mid-size metropolis, I counted the number of single pedestrians (people tend not to do this in crowds) who were busy staring at their phones. I did this several times, and don’t recall ever getting a number under 50%. And this is people walking, on crowded city streets – and generally fairly oblivious to other walkers, cars, signals, or anything other than their phones. 

With the exception of a few (mostly older) friends, however, I’ve mostly kept these thoughts to myself . I mean, I’m in high tech. I work for an online-only bank. I do usability tests all the time on mobile phones. The people I work with are all just a little older than my kids (and are really into their mobile devices). Ergo, the last thing I’d like to be known as is a Luddite.

Recently, though, I see the tide turning, just a little. This morning, I read an article about two investors threatening to sue Apple because they made “addictive devices.”. And, just a few weeks before, former Apple exec Tony Faddell got in the news bemoaning his role in making what is basically a tech version of casinos or cigarettes or opioids.

There’s also no shortage of books out there on the subject as well. You remember those things, don’t you? It used to be that these were few and far between. Lately, though, it seems like that’s all I’ve been reading. Just looking at my reading list, I’ve got Think Before You Like, The Know-It-Alls, The Hacking of the American Mind, iDisorder, iGen, Technically Wrong … So, at least I feel like I’m not alone anymore. 

But if you think about it, this is probably a necessary, and overdue, correction. There’s really nothing surprising here. Basically, there is no shortage of examples of society rushing to adopt technical wonders – especially those that might be highly financially remunerative – focusing solely on the positives, and without really thinking about any other possible implications. 

So, what I’m saying is not that smartphones are bad necessarily, but that we really do need to realize that they might come with some costs, and that we need to be super thoughtful about how we use them.