Thursday, March 22, 2007

It's more than just a checklist

I had it in my mind that usability was nothing more than just a checklist.

I was wrong.

It wasn't just about heuristics or just developing then following a bunch of guidelines blindly. It's more than that. So I ask myself, what is it about this practice that makes it more?

There needs to be understanding - a total and complete removal of ego so that I am able to learn what I need to, asking the questions of "Why?" the whole time. And with this, I create an environment that is more open. What I attract around me are people that will think the same way by looking at the challenge in front of us and coming to a resolve.

Right now, we're in the midst of starting the first ever Agile Development methodology. It has never been tried on this end, while other companies have been doing for so many years. To be able to survive and then to thrive in this kind of methodology requires open-minded people. It's not really about "having their say" as much as combining the efforts together, to
mastermind ideas and form them into reality.

The challenge for me right now is whether or not reality can be created as fast as the mind can think.

I think I can.

Tuesday, March 6, 2007

Adaptive User Interface

I've just downloaded and installed the trial version of MS Office 2007 with the "ribbon" interface. In just a few minutes of playing around with it, I've learned that this is probably the first interface I've come across that has an Adaptive User Interface (AUI).

By adaptive, I mean the interface (in both high and low levels) actually changes based on the context of the activity involved. The actual menu items are not user-controlled - instead they are based on user behavior and their tasks. For instance, additional first-level choices appear when the user is performing, say, a table creation or edit, or a picture or art object creation or edit. Specific functions also change based on the object that is selected for either formatting or editing, resizing etc..

The idea is to have the system use anticipatory design practices to better predict user behavior and flow with the daily interactions. Whether or not the system becomes smarter with use is up to the time factor.

Taken this further, I can definitely see an AUI that has algorithms that actually anticipate user actions before they happen. But how could this be without digging into the human brain? This is where science fiction becomes science fact - and it seems we're getting closer to this every day.

As for actual AUI's being in use, I will have to research this subject more to give me my perspective.

** Okay, so by Adaptive, you can say the interface is adaptive if there's personalization functions (displaying or hiding toolbars) as opposed to what I'm thinking in full anticipatory design model, with use of perceived artificial intelligence.



Tuesday, February 27, 2007

Usability Findings is like an episode of CSI

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.

Why Usability Training?

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.

Monday, February 26, 2007

Usability Training

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.

Tuesday, February 20, 2007

The Impact of Design

After reading Donald Norman's first chapter of his new book, I realized a couple of things:

  1. What I'm designing right now has no catastrophic consequences if things go wrong for the user or the system;
  2. 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.
  3. 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.

Friday, February 16, 2007

Leadership in User Experience

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.