Any intelligent fool can invent further complications, but it takes a genius to retain, or recapture, simplicity. (E.F. Schumacher)

At work, most people tend to get rewarded for mastering the complex. Think of some internal system that only Joe knows how to use, some bureaucratic process that only Cheryl can understand, some hardware that only Trey can fix. Honestly, I’m pretty sure it’s behind why lawyers, accountants, and engineers all make the big bucks.

Unfortunately, for us UX types, it’s just not enough. Sure, the developers can get away with mastering C++; the lawyers with Reg this and Reg that; and project management with some unwieldy, macro-infested, homegrown spreadsheet horror. For us, though, we typically have to take all that complexity and turn it into something that our users can deal with and make sense of.

Thus, we often act as translators. So, not only do we need to learn that difficult source language of technology and bureaucracy and regulation, but we also have to translate all that into the target language of our users. 

Our effort is two-fold. First, we need to master the complex. Then, we need to turn that complexity into simplicity. 

Over the years, I’ve noticed that some UXers are great with that first part, but not with the second. To me, they’ve always seemed like frustrated techies (wolves in sheep’s clothing, if you will). Subsequently, their designs can often be great for themselves – and other techies – but maybe not so much for everybody else.

On the other hand, it’s hard to be a graphic designer without mastering PhotoShop, or an IA without being an Axure wizard, or a writer without knowing your content management system inside and out. What happens when you don’t?  Well, you might very well come up with user-friendly solutions, but you might also have a hard time translating those solutions into something workable. Heck, you might not even be able to fully grasp the complexity of the problem you’re trying to solve from the get-go, leaving out important pieces and ultimately making your solution harder, not easier, to use.

Face it, UX is one of those both-sides-of-the-brain disciplines. If your brain is structured that way, you’ll get a major kick out of both understanding the complex and then turning that it into something simple. If not, though, I can guarantee that at least one side of that equation is going to bug the heck out of ya.

E.F. Schumacher was an economist and statistician, 

but was also the author of Small Is Beautiful

Instead of assuming that people are dumb, ignorant, and making mistakes, assume they are smart, doing their best, and that you lack context. (Nicholas Zakas)

Actually, I sometimes like to think that it’s the designer (or developer, or client, or HIPPO) who is dumb & ignorant. Needless to say, I also keep that strictly to myself.

Those are definitely my thoughts, though, whenever I hear someone put forth the traditional, “Where do you get these idiots from?” (or something along those lines). How I actually do respond is to point out these are our users, we used a 10-page screener and paid a recruiting agency $1000 to get ahold of them, and that not everyone out there is as smart and tech-savvy as you guys. 

So, that usually takes care of the “smart” part. As for the “doing their best,” we sometimes do have users who are just there for the money, but that’s extremely rare. It’s usually totally obvious to anyone observing that 99 out of 100 users are taking things seriously and are genuinely engaged.

Now, as for “context” … Hopefully, the design team had some exposure to that beforehand. Personas, journey maps, and all that other great upfront research can give the team some real feel for their users – what they do and don’t know, what they like and don’t like, what their goals and fears are – and how to design something just for them.

Even if there has been that exposure, though, I try to push testing as an excellent way to get even more context. Even the best upfront research can be incomplete, or neglected, or misapplied. Testing, though, is the chance to really check things out, to get that final word. The more sophisticated teams I work with have no problems understanding that, and often see testing in this regard as simply fine-tuning.

It’s those teams who don’t do any up-front work, and who can be totally blind-sided by things that happen in the lab, that I really worry about. Hopefully, though, these teams can use that experience to learn to emphasize with their users a little more – heck, maybe even do a little of that up-front research and avoid those uncomfortable situations in the first place.

Just in case you were wondering what a HIPPO is