skip to main |
skip to sidebar
I'm a big CSI (Crime Scene Investigations) fan and I'm starting to come across some parallels on how the usability profession is very much like solving a crime - or in this case, the crime of un-usability. So here's my take:
Where this parallel starts is when product support finally tells the development team that users can't take this frustration any more. "Do something about it!" they would cry. So the manager comes to the usability professionals after determining it might have something to do with usability - usually because it wasn't covered before.
So, as usability professionals, we start investigating. We first look at the data given to us by support - do some supposition and hypothesizing, some reflection, some research. We also use observational techniques, question those suspects that may be violating the usability laws.
We pour some heuristic phenol into the samples and find out there is blood - instant proof that someone has bled from the unforgiving usability issue. Let's just hope the user doesn't have carpel tunnel because of it!
We conduct more tests to prove or disprove our hypotheses. "Let the data tell the story" is our mantra. Through this, we can find the culprit - the issue that's holding us back to release 6.0 from version 5.9.0.3.
The blue UV lights of remote testing tells some more, uncovering and unraveling more than we wanted. The task flow DNA tells us little molecular and granular stories that something is fundamentally wrong.
"So what did you find?" Grissom Neilsen would ask.
An eyebrow goes up in surprise as the team hands him the final paper, the usability finding.
The issue is then resolved by confronting the developer user offender. He/she sweat in their pants for minutes in the interrogation room before he/she finally gives it up. They can't take it anymore!
The offender confesses.
The difference is, no one goes to jail. No one gets reprimanded. Usability on anything can always be improved.
So please, feel free to confess before going through an episode such as this - unless of course you want such entertainment.
One thing I discovered - Training is a means to organize your thoughts so the communication is clear.
How I've realized this is because I have this innate ability to recognize and use my instincts, based solely on experience to design whatever it is that needs to be designed, but without all the language. Basically, it's second nature to me and to justify it can sometimes be a task in itself. Artisans don't really need to explain themselves or justify their work unless they're in the selling stages. Since usability has an art and science, on my part at least, the science and the art of communicating that science is more clear, simply by taking a training course on a heavy subject that takes three days to cover.
Now there are words and groups of words that form an explanation of how and why usability works. Knowing the why is half the battle. Explaining it to anyone else other than yourself, in an objective, non-opinionated way is the other half.
So for those who are still apprehensive into taking extra courses, let me just say that if you're not open for this kind of learning and relearning, you really have no business in the usability field. Actually, to take this further, those who think they "know-it-all" will find themselves stuck when all of a sudden they discover they don't and now is in need of additional knowledge or resources, but it is inaccessible because you haven't bothered to take the time to learn more than you already know.
For any kind of success, in business or in life, and in this case, user experience design or however you want to call it, growth is the key.
Take that extra course. It will change your life.
I'm writing this at MicorTek right now, a common place where companies can use the facilities to train their people. At this instance, I'm in the course for application design held by Human Factors International. even though I have an extended background on many industries, I felt the need to brush-up on some of the principles. Not only that, since the material is quite heavy, it's a great precursor to knowing the material for the Usability Analyst Certification Exam. It's just another one of those "nice to haves" under your belt when you're a professional.
One thing I've already learned today was to bring this kind of information back to our developers so that they get a perspective as to how involved this process can be. Well, HFI has a course for that too, where in just 6 modules, you can be a certified trainer and teach this material to basically anyone. I'm up for that!
Okay, back to class. I've got a week before I head back.
After reading Donald Norman's first chapter of his new book, I realized a couple of things:
- What I'm designing right now has no catastrophic consequences if things go wrong for the user or the system;
- What I'm designing can be referred to as "low impact" because of the nature of the product (administration). Functionality is more driven than usability at certain times.
- The only thing I can affect is the bottom dollar, directly dependent on learnability.
Yes, I think in fundamental ways. I can also tell you that I've designed systems or products where catastrophic failures can occur. When this happens, more and more scenarios go through my head to anticipate every situation imaginable. And from Donald's new chapter, it can only come from the designer's head - that is why having usability analysts are important.
Anticipatory design is what we do. Solve it before it becomes a problem. But then that means automation in certain respects - by autofilling users' previous entries, by autocalculating cruise control speed on a car in approaching traffic. The objective is to meet the users' needs even before they start to complain - like a decent waiter at an exclusive restaurant.
While I won't be saving lives (directly) with what I'm doing (as opposed to developing airplane systems or auto-cruise control on cars), I will be improving some people's attitudes by creating a more pleasant and usable interface. Not that administration work is in itself pleasant, but perhaps then, less evil.
It's been on my mind for quite some time, and in fact, I've taken a position that best suit me and the company I work with:
"To be involved with user experience in a company that is in the middle of growth, you must serve everyone."
And for this, I don't mean to cater to everyone's beck and call. I mean to make an actual difference. To empower as well. What I did was to have actual leadership training, or more specifically, Servant Leadership training. It's funny because most people equate being a leader to be someone who "takes command" like in this article. Not so. I can tell you right off the bat, while you do need to have accountability on your plate, you don't have to take full command like that of a dictator. A dictator is not a leader.
In actuality, being a Servant Leader means to listen to people. Being a Servant Leader in the User Experience field means to listen to your users, your development team, your product managers - you get the idea. Not only listen, but also understand and compile the feedback and the data and whatever else research you do in order to come up with the best solution.
Indeed, it does take a lot of energy, time, patience and people-skills, but more importantly, also vision, fortitude, self-accountability, growth, and an ability to change at a moment's notice.
One could also say we are the mediators between the users and the developers. We make the graphical language simple to understand for the users, and our knowledge is enough to understand the complexities from the developers. This knowledge comes from experience and exposure - part of the Law of Gestation. It also comes from taking nothing for granted.
One also might say we're the software private investigators, asking a million questions just for the sake of knowledge and understanding in an unwavering belief in that when the truth is revealed, it will set the software application free. Free from any troubles, reducing support calls and training time, increasing profits so that our share also becomes larger, hopefully. (But I digress.)
So when someone asks you want you do, and you tell them you're in user experience development, what kind of vision are you painting?
If you don't have an answer, you might be in the wrong field.
Well it looks like there's some consensus with letting the interface do the talking. Take a look at this article:
A lack of user-friendly technology in the marketplace is exacerbating a digital divide in the workforce between those who can use technology effectively and those who can't and is likely to provoke a backlash among users, according to a new Technology Predictions for 2007 report from consultancy Deloitte, released today.
Read more...
Hmm..15 days after this article was posted, I write about that fundamental issue in another way. Perhaps that's how long such energy from Europe takes to traverse the Atlantic.
You'll have to read the article to connect the dots.
I've been hearing it time and time again and it never seems to escape me - probably because it's my profession that draws out such magmatic words.
"Intuitive. It's needs to be more intuitive!"
Of course, I am referring to interface design. Almost every usability test ponders upon the idea of intuitive design or how much intuitiveness is inherent in the design. But really, how much of this "intuition" do we really use?
I read the article by UIE and it gives a great visual as how much intuition we really use. Based on this article, in fact, we do not use our intuition, but more so upon our knowledge. Take it further and we actually base all our reactions on experiences. Our conscious and cognitive ability is as follows:
1. See the situation (without interpretation);
2. Recall and relate to past experiences (with some interpretation);
3. Base a decision (with full interpretation);
4. Act on the decision.
When this is considered into the Fundamental Thinking Process, can we honestly say then, there is something in the design that needs to be more intuitive? Perhaps in this context, intuitive only means a gathering of our past experiences with applications and programs that we have already used. Which, in this case, provided that we all have the same experiences - most likely not, then to achieve such intuitiveness in our designs is a complete fallacy.
So really, there is no such thing as intuitive design.
