You get to a certain point in your career, and you say to yourself:
"Wow. I've been doing this a long time."
I've been thinking about publishing my experiences in UI/UX for quite some time. What took me so long to get going? I'm not sure: my best guess is the work itself. The field of UI/UX has always been fast-moving and exciting--to me, anyway. There's more to learn, something new to try, a new approach to debate, another project to work on; it never ends. But the urge to write about it never subsided, and since life has quieted down a bit these days, I've found myself more inclined to get it rolling.
You may be surprised by some things you'll see me write about. For instance, I won't tell you to try and "delight your user."
I know; shocking! "But...isn't that what UI/UX is all about?"
Thirty-plus years of experience have shown this to me in no uncertain terms:
No, it isn't. Not at all.
But then, what is it all about? What should we focus on when designing and building a UI?
That's what I'll be writing about, and I'll provide tons of anecdotes from the trenches to make it (hopefully) of interest and maybe even amusing.
Ok, but what is ProcessUI? Is it just the name of a publication, or is it a "thing" of some kind?
In a nutshell, ProcessUI is a methodology that suggests mapping business requirements to explicitly defined user processes--generally in the form of process maps--is the best way to ensure you're building the right tool for your users. It replaces the notion that comps and user stories are the best and primary artifacts for developing a UI.
Why?
Because, in most cases, users don't want to go to your web application, clap their hands and shout, "How delightful!" They want to know they're in the right place, find necessary information quickly, engage and complete a required process without figuring it out, and be confident it worked. They want a tool that gets those processes right. Beyond being clean and uncluttered, users generally don't care about aesthetics or other efforts to "delight" them.
That's it. Ergo, the name of this publication: ProcessUI.
The benefits of this approach extend beyond the front end. You will enhance the likelihood of designing a productive tool for users, and those process artifacts can inform your entire system. I've often uncovered severe disconnects between business requirements, what users must do to satisfy them, and the technology implementations that serve it all up, simply by presenting a "current understanding" process map. It's incredible how people working on the same system for months can have a completely different mental model of what it does and how it works. By leading with process mapping, you can identify and sort those disconnects out early, not after the eighth bi-weekly demo or some other time shortly before the project budget runs down.
It sounds so simple, I know. But almost every organization I've worked with defaults to practices generated from old-website-style marketing think (at least initially, sooner or later realizing they need specialists). I mean every kind of business; major financial and tech firms, hospitals, media, retail, insurance, employee safety, pharmaceutical, recruiting, cloud, you name it. Many names I could drop would amaze you, as you probably think such significant players discover fire daily and do all this as a matter of course.
In terms of UI, believe me when I say; very, very few UI efforts get started in a manner that doesn't inevitably lead to trouble. I've had this conversation with many people doing this work for a long time, and we all say the same things.
Now, on to my post about shifting focus away from "delightful" and towards "useful, pretty painless."
As always, thanks for visiting. Feel free to reach out at tcoz@tcoz.com for any reason.