Design Experiences: Don’t Rub Your Product Experience All Over Me.

The other day I was pumping some gas at the gas station only to be accosted by the latest in drive by guerilla marketing. Nowadays, it is quite common to find little kiosks setup  outside of major business selling everything from makeup to car polisher. It’s as if the strip mall has come to us. It’s like carnies are part of everyday life now.  And this is where my story begins  – (cue flashback).

All I wanted was gas, and I was in hurry. I’m pretty sure when I drove up I wasn’t holding a sign asking these kiosks to show me products. Nonetheless, I was molested and ask to partake of a product I had no desire to see.

What was I to do?

• A. Say no thank you politely?
• B. Hide and hope I wasn’t seen? 
• C. Say I have already seen the demo?

Since I had seen this demonstration two times already I was in no mood to even speak to the demonstrators.  I just kept silent and thought to myself.

“Yes, you have a great product. Awesome, but I’m not interested in your cross-sell.”

Every One Surrender We Have You Surrounded

Here I was as were many other patrons, a captive audience to a product experience. I felt all dirty inside, and almost ashamed for not buying the product. Is this how a user should feel? Should a user experience ever be forced? Are there sometimes when it is forced?

Admit it! You are a user experience  pusher. Over the course of many years I have come face to face with applications consisting of three tiers. The front-end (for users), the back end admin (for internal people, employees, etc..), and believe it or not Admin interfaces that admin the admin.  In many of these cases the users of the front-end were treated to the golden carpet . The internal people received the  tin carpet . The admin of the admins probably had no carpet.

The truth is application design takes time and when your audience is captive we very quickly remove features that improve the experience. This tends to happen much quicker and much easier on the internal side of things then it does for the end-user of an application.

Imagine you are one of those souls forgotten in the internal world. Your pleas for external quality software are often unheard and ignored. 

I Hear You Crying but I Don’t Care

Over the course of many, many, years. I’ve heard a lot of horror stories from internal users. 

“Why can’t our tool do this like it does for our customers?”
“Why do we have to use x system when it’s so slow?”

In many shops internal users are just not regarded as the highest priority.  Typical internal applications developed for these types of groups are shoddy, buggy, poorly constructed, confusing, repetitive, and scattered. They are the Frankenstein brand-child of quick whims, crazy ideas, and unreasonable deadlines.

A Web Application Only by Name

Imagine a cluster of  “dissimilar” reports:

These reports track customer information, data gathering, and user retention. Despite the different end results there should still be some commonality among these reports. The problem is the commonality is not properly identified. What happens is a person not trained in usability or any user centric process, has made the decision to lump these all into one system.

Why would such a thing happen? Usually, because it’s fastest way to just put “something” together.  They are internal users and not as important right? Wrong, just because a user is internal should you ignore the cries for competent, excellent software?

Hell No!  Poor applications can easily slow productivity, especially when an app is directly servicing front end clients.

Oh No You Didn’t Just Tell Us To Build Better Internal Apps

The hardest part about getting the same quality built into internal software as external software is getting buy-in from those in charge. Depending on the company there may be several layers of people involved – Managers, Bosses, Mafia. So what can be done to illustrate the power of providing a superior experience for a captive audience?

1.  Analyze your existing applications and identify existing and expected commonalities – This is especially true when you are presented with the opportunity to build enhancements, features, or even bug fixes to an existing application. How will you know there is a problem unless you can point it out in detail?
2. Use actual “working” applications and do a side by side comparison of proposed benefits for the new enhancements. Simply put, illustrate by using the current system why it is bad and then turn back around with multiple solutions to fix the “badity” (new word copyrighted).
3.  Cost V.S. Efficiency Improvement. This is a hard one to illustrate, but the suits (managers, mafia, etc) will expect to see predicted numbers. These numbers are most likely going to be way out of alignment with reality. It would be much better to show estimated time for current task completion with the old application process and then follow that up with your best guest estimate of the new functionality.

For example: We don’t have to go back to this 1 tool to generate the immediate on call reports for a customer on the phone. Now we can simply click this button and display all that information in the same interface. 

And another example: By isolating all of these commonalities in reports A – Z I’ve determined a logical grouping order and how we can provide one dashboard and a single input to access and run each report.

If none of the above works QUIT, or  build out the functionality in your own spare time. We all have pet projects going on in the background  and practice makes perfect!

Experience Cleanup Isle 5 Please Come Again

Fortunately, I can change my gas pumping experience by switching brands, stores, etc.  Generally, captive audiences don’t have that luxury. It’s your job to make sure the tools used external and internal are bult to exceptional levels of quality. Who else can champion the cause but the User Experience Guru?

Related articles:

1. Blog Response: IE 6 The Devil Not In Disguise
2. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?
3. The Haves, Have Nots & Feature Bloated User Experience.
4. User Experience Design in an Agile Development Cycle
5. Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?