The most important part of User Experience is the latter.
That is the perennial truth that has lurked up on me over the years, and now is pouncing at me like cat playing with its target. It's not that I haven't known or noticed this before, it's more about how all-encompassing it has become!
So, for many years I've done all parts of the "making something for the web" cabal, from the technical stuff to the more esoteric "this bit here, this bit there" and "let's talk about some feelings here" kinda stuff, from the hardcore inner technical magic to the outer more fluffy marketing double-speak we wrap actual content in. I've done it all, but with an innate twang towards a user-centred design process of sorts. I take no pleasure in this innate twang, though, because people don't want "twang", they want a documented process.
Over the years, after much twanging around, I've settled on the perennial truth that the process - indeed, the only process! - worth talking about, is the non-process part of UX. And by that, I don't mean the glittering wonderfulness of UX-based processes, or even user-centred design processes, or derivatives. All of those are, well, fine, I guess, and they do what it says on the tin, but there's something ... eclectic about humans that eludes most processes, and we must not forget this.
As UX people (and I'm speaking, of course, to UX people now) we can't lose sight of the most important thing; the experience itself. You can't wrap a subjective experience up in something like a mostly objective process. Sure, we'll get a lot of things right that way, but ... (and here it comes) well, at the risk of doing things a bit less awesome than if we didn't.
And this leads me to a sad truth, one that makes me worry and long for the days when I didn't know anything (as opposed to the crumbs I think I know now); all processes are wrong. Some processes are useful.
So when a customer asks about your process, I know fully well we can point to some list of things we do, some order in which we do it, and some conceptual deliveries we think we should deliver. I've worked with such processes most of my career, and indeed seem to do what it says on the tin. Want some IA? Here's what we do. Want prototypes with that? Here's how. Oh, you want some testing? Follow these steps! Build the darn thing? Sure, this is how we do it.
But.
These processes gives us all a false sense of security. Most people in the know that I talk to know fully well how they claim to be process driven, and do whatever they normally do (ie. make it up as they go along) anyway (mostly by wrapping "what they normally do" up in a language that sounds like a process, and slaps a few numbers into it to give the sense of direction and order. And this despite whether that fits into some preconceived notion of a process or not. So, do we enjoy lying to customers because it makes them feel safe? Ok, so a lot of them also follow some process - maybe some high-concept process with big, broad shoulders - and then tweak it and alter it and, well, fudge the concept of "the process" into "a process that fits this challenge." That's what it comes down to, isn't it? At the top of the UX profession sits people who are able to cobble together a number of things in various orders and importance and pull it together in ways that normally wouldn't fit in a straight-forward process. We call that a process as not to scare the customers, of course, but isn't that what we do?
Now, don't get me wrong; following a process will deliver, and probably good stuff, too, but most processes cater to some middle way. Big talent will be working down to it, and everyone else will work with or up to it. Content and structures again is drawn towards this middle point. Surely that doesn't deliver something spectacular? Or special? Or awesome?
I've done that for years. Now I've stopped. Now I'm setting aside time to custom-make every project, and then I wrap that up in a "this process" language later. I hate selling bullshit when the truth is so much more interesting!
No comments:
Post a Comment