Like most folks out there, I spent many years not understanding what UX (User eXperience) was and, more importantly, what the difference between UI (User Interface) and UX was. Over time I came to realize that what was being commonly delivered as a UI in the AV world did not translate to good customer experience. And I REALLY came to hate ANY comment relating to “training my users.”

But like most of us, I didn’t possess sufficient knowledge to put these concerns into words. I just knew there was something wrong. As far back as 2000, I would make comments when teaching classes at Extron regarding how poor many of these interfaces were. One common refrain was “there are really only four touch panels out there, then with different color schemes!” And you know what? Nobody ever disagreed with me. In fact, most folks laughed and nodded in agreement.

Now I put ZERO blame for this on the heads of the programmers out there, they have been trained to build a touch panel, and mainly just copy/paste old panels.

What allowed me to see the light as far as UI/UX was when I worked at a tech company about 13 years ago and needed to redo the CEO’s conference room and, of course, the touch panel. This one was particularly bad. It was so bad that when execs had a meeting in there, they would show up 30 minutes early as nobody could ever figure things out.

As it happened, I had recently done some work for our usability lab, and they owed me a favor. So I asked them to assist me in coming up with something clean, intuitive and easy to use. Easy to use is a dangerous concept, though. It’s not easy for me or another AV person, but easy for a random nontechnical person to figure out.

Before I get into the learnings as to what makes a good UX, let’s rewind a bit.

Part One: The Wayback Machine

I remember the first custom user control panel I ever had to deal with. The year was about 1995, the panel was a York Controls button panel, and it controlled a REALLY fancy boardroom. The company in question was the world’s third-largest gold company at the time. So they had the money to spend. It was a custom black box with a brass cover and something like 25 buttons that each performed a different function. All we wanted to do was lower the projector from the ceiling so we could service it. That was painful! Four AV rental/staging guys, and we had to get the in-house AV guy to do it for us.

All my experience before that was mostly slide projector remotes: Kodak EIII “pickles” or the AMX wireless ones. The Kodak ones had a forward, reverse and a toggle for focus. The AMX had four buttons. And in these humble beginnings, I learned my first lessons about the differences between a User INTERFACE versus a User EXPERIENCE!

My simple definition is this: User interface is the series of buttons/sliders/controls that you are presented with to operate whatever gadget you are facing. User experience is how you feel after having to accomplish whatever task you needed to accomplish.

When faced with the boardroom example, the user interface was undoubtedly … “impressive?” But the user experience was terrible and made me feel like an idiot, and made me feel like whoever built it was a moron. So I count that as a UX fail. To be fair, based on options available today, they were limited in what they could do.

So let’s talk about a staple of that era of the AV world — the humble slide projector, there were only three functions (forward, backward, focus) so it was super simple, and anybody could figure it out, right? Wrongo!

In the rental and staging world back then, slide projectors and medical conferences went together like peas and carrots (apologies, Forrest!). So, doctors would come in with their slides, and we would then inevitably have to reverse all of them for rear projection, remount some of them in proper slide mounts, etc. Then they would go on stage and … get confused.
Why? Because they couldn’t figure out what button was which, they’d get flustered, then try to walk away from the podium (wearing a wired microphone, or if there was a podium mic so they could no longer be heard). With that, they’d maybe drag the light pointer with them (before the days of lasers, these things had a fairly short cord on them) — it would crash to the ground, and their presentation about some new advancement in heart surgery would get messed up.

Cue the backstage crew of largely non-college educated numbskulls (myself included) laughing at how dumb the world’s most preeminent cardiothoracic surgeon is!

Something here doesn’t add up!

So while the UI was what it was, and the UX for us was good, it was clear that it was not for the doctor. You know — the customer!

Lesson 1. UX is dependent on the audience. What works for the IT group is not what will work for the doctor. It is not about brainpower; it is about familiarity and expected results.

I remember starting to use the Dsan products, and while on one level, they were pretty similar in performance to the AMX slide cue box, there was one big difference … the Dsan product had a huge green forward button and a little tiny red button for backward. And they skipped the focus because we didn’t need or want those buttons. (In this use case!)

That’s the thing about UX; it will vary with use cases and users. So things that might be critical with a teacher and their mixed slides on one type of slide projector (focus adjustments) were a horrible idea when using a commercial-grade slide projector with proper slide mounts in a quality slide tray.

Lesson 2. UX varies based on use case. The same user might need certain features in one use case, but not in another.

Part Two: REAL (as we know them) Control Systems

My first real eye-opener in the world of UX was when I worked at a home theatre company called Kaleidescape. We made (and they still do) a server that you put in your home/yacht/plane that serves up your DVDs/Blu-rays to whatever displays you have. One of the many things that really made their system stand out was that ANYONE could walk up and figure things out. There are videos of three-year-olds finding their movie and starting it.

This was a system that was a UX all-star. But why?

There were two sides to this fantastic UX outcome. One was the systems onscreen display. With a remote, anybody could figure it out — it was just so easy that anyone could take the remote and start using it. The other part was where they REALLY made things sticky. While visiting customers and dealers, it became apparent that the interface that was designed by dealers and even (especially) the control systems manufacturers themselves was just not getting the job done. It was a UI with no thought to UX — just a series of buttons crammed into the page. (Cue flashback to the York control board) it was no wonder that customers were not getting full benefits. All the fantastic things that had been built into the API were just being ignored.

So, the CEO decided that they needed to take ownership of the UX. As a result, the company hired an awesome programmer and made it a company priority to build out an interface for Crestron and AMX (to start) that took full advantage of all the features. They mirrored the onscreen layout; they made use of live video (when the panel allowed it) and created an experience that was second to none. This resulted in dealers selling more control systems. And they gave it to the dealers as a tool for deploying the systems at no extra cost. Some dealers signed up simply because of that control program. There was far more to it than that, but the main point is that this company took control of the UX when the UI was frequently failing. But who was the audience that they designed it for? It certainly wasn’t the folks at the company. It was their kids, spouses, etc. and they always ensured that part of the product focus was on that UX side of things.

*Brief note to manufacturers selling complex solutions like collaboration, etc.: Embrace the touch panel, take control of YOUR UX, hire UX folks and a programmer and build out programs for the dealers that lean into your systems. Don’t rely on hundreds of different people to develop a UI that makes sense. OWN IT! Kaleidescape went from being a single page in a control system layout to being the heart/home page of that system.

Lesson 3. A useful UI that drives a great UX is invaluable! Don’t hope that others MIGHT get it right.

Part Three: I Need to Build a Good UI with Great UX

So here we are, mid-2008 or so … it’s time to deal with the CEO’s touch panel. I know these two things for sure:

1. It can be better, much better. In fact, it HAS to be better.
2. I have a usability lab staffed with folks that have degrees in design and HCI (Human-Computer Interaction) that are willing to assist.

Knowing this, I started with a single idea that had bugged me for a long time about most panels. Many of them seem to be designed with a focus on the equipment in the system. This seems a logical assumption since the folks creating them, for the most part, have a background in the gear since (correct me if I am wrong) the career progression of an integrator is so often Warehouse Installer –> Lead Installer –> Project Manager –> Programmer. All they know is gear. For the most part, all panels make sense to them — as they look at them every day and know the equipment inside and out. Customers, though, do not know the gear. Case in point: I have seen a panel where the switching/routing page was called “AV MATRIX,” and this was on a customer-facing control panel.

So, my thought was to approach it from a task-based perspective. Honestly, my mindset was shaped by the Windows 95 taskbar. START … task. That’s where I started. I won’t lie, with the first few iterations, the folks in the lab laughed at how bad they were and may have inferred that I didn’t know the first thing about UX! And they were right. But over a series of about 20 iterations, we got closer and closer to something that the lab team liked and could live with.

In the end, I had a design that totally made sense. We tested it against folks like our receptionists, some VPs, even a few random people who had come into the lab for another testing. (As a side note, should you ever get a chance to play with an eye-tracking monitor, definitely do it.)

Now came my first big hurdle, the integrator. Of course, the sales folks were fine with it, (who argues with the customer?) but the programmer … I think it is safe to say that my design offended him deeply. He fought me on just about every point. I explained to him how I had come up with it, why things were the way they were, etc. but it flew against the things that he “KNEW” to be true. And this got us into a few issues.

One of the other concepts I adopted (besides task versus gear-oriented) was the concept of expected behavior. This bugged him and caused some friction. Let me explain: If you are on the phone, and you hit the mute button, what happens? The microphone mutes. EVERYONE knows this. If, however, I am watching TV and I hit the mute button — the same button but guess what, now we shut off the speakers. If I am in a videoconference, what does the mute button do? Yes, the microphone shuts off.

There are expected behaviors we already understand through our daily interactions with all types of devices, lean on those.

Lesson 4. Leverage expected behaviors.

If you don’t do that, then you get in trouble. Let’s say, for example, that the programmer was REALLY bothered by the use of mute for different functions on different pages and in a service call to fix something else. Let’s say he changed it and added a privacy button beside the mute button as he felt that was better. (privacy=mic mute, mute=speakers off) and let’s also say that he didn’t tell me. And now let’s pretend that the CEO has a call with an analyst that maybe he doesn’t have the fondest feelings for … and mid-call he hits the mute button to say something disparaging about that analyst. I wish we could pretend that it didn’t actually happen. That was a bad day for me.
Notwithstanding the PRIVACY faux pas, once the panel and the room upgrade was complete, the first test was when my CIO had a CEO staff meeting the morning after completion. She called me after to tell me that she was mad, as what had usually taken 30 minutes to get set up took 90 seconds. So she got to work 30 minutes early. I will take that one as a UX win.

Part 4. Who is responsible for this UI/UX dilemma? 

I said earlier that I don’t blame programmers. They are just trying to put together something that works. Most integrators do not have the resources to bring in industrial designers and HCI experts. Setting up a usability lab is a pretty significant endeavor. Not to mention, really expensive. An eye tracker monitor can run to over $20,000 easily. (Not to mention the software, etc.)

I have had casual conversations with folks at all the companies that make touch panels about the concept of setting up a usability lab, staffing it with the right people, allowing dealers to submit panels for usability studies, publish white papers on touch panel research, and I’ve gotten comments along the lines of “Yeah that would be cool.” But clearly, this has not been important to our industry. Primarily, I am guessing, because it would not result in more sales. And let’s be honest, that is the main driver for anything like this.

One conversation, though, was clear. In talking with a friend, he responded (QUITE tongue-in-cheek), “Why would we want to do that? It might conflict with things we KNOW to be true?”

So while I honestly would love to push back and suggest that the folks that make these panels start putting much more effort into the UX world — that is a massive part of what we deliver to customers — I won’t hold my breath waiting. But as we get more and more into purely software-based solutions, the differentiators will become harder and harder to find. And as people are more and more used to their phones and tablets, they will have the same expectations on UX in their AV stack.

However, if you have a customer that has a usability lab, drop the idea in their head that a consult with those folks might make a big difference in the outcome. We can’t all be experts in all things. But if you can justify the headcount, even on a temp basis to build some better starting points, look to find a UX expert to help you get to a better place. And honestly speaking, with some of the less expensive technology available today, nothing is stopping you from developing your own UX lab. Or at least doing some UX testing.

Lesson 5. Always test your interfaces with NONTECHNICAL folks.

Summary

The primary takeaway here is that we can all do better. We can deliver better results to our customers if we start looking at things differently.

Lesson 1. UX is dependent on the audience. What works for the IT group is not what will work for the doctor. It is not about brainpower, it is about familiarity and expected results.

Lesson 2. UX varies based on use case. The same user might need certain features in one use case, but not in another.

Lesson 3. A good UI that drives a great UX is invaluable! Don’t hope that others MIGHT get it right.

Lesson 4. Leverage expected behaviors.

Lesson 5.  Always test your interfaces with nontechnical folks.

As a final note for anyone that may feel that this strikes a chord: I have a generic touch panel layout in Google Docs that I created to help explain how to approach many of these points. I would be happy to meet over video and go through it all to illustrate where I am coming from in this.

As always, I hope that this was useful, and please add some comments if you agree or if you think I am off base. The dialog is the most essential part.

*One more small thing. I read an article a while back that talked about Apple University (the company’s internal training to get folks thinking about the Apple way of design). And in that training, they used a drawing of Picasso’s to illustrate the overall concept of continually simplifying while still maintaining the essence of the original. This idea can be taken into account when looking at anything — whether it’s fewer words, fewer options or just simpler graphics.

You can read about it here.