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

uidesigner — Thu, 19 Feb 2009 03:29:31 +0000

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?

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?
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).
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?

UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?

uidesigner — Sat, 12 Apr 2008 00:23:49 +0000

Welcome to my first in a series of design processes instructions and examples. These are setup in such a way as to walk you through development cycles in relation to creating, producing, usability testing, and execution from a UI Design stand point.

I’ve been wanting to get back to the core of this blog for some time. I think I finally have made some time to do this. For anyone that has missed out the original core of this blog is to examine the brainstorming, creation, and execution of an application. This can easily be a process that any company or individual can follow when creating a web application. Size of the application has no bearing on whether these principles can be applied.

In our sample application we will begin working through the brainstorming, feature set creation, and mock layouts of new Cthinker App. The application I will be building in this example is a social aggregation tool. We will take a look at several social aggregation web sites as well as walk through the process of designing one from scratch.

Where’s The Vision

Not a lot of people talk about the vision when it comes to application design. It’s especially important though if you are looking to build an application better than your competitors. Without vision and a way to distinguish your product it makes it extremely difficult to truly produce the best software. It’s also important to make sure you have a large scale vision of where you may want to go with your product. Vision is something that should change and adapt to the times. Vision should keep up with both technology and trends.

What’s The Value?

Besides the obvious monetary ROI. It’s always important to come up with reasons that a particular application is valuable. This helps you to flesh out the cost or investment in the application and also helps isolate what potential profit can be made by launching a new application. Listed below are a few more items you should look at before considering the total value of the proposed application design.

Do other similar applications exist? If so can I do it better?
Is the target market so small that the potential for profit or usage by clients is marginal?
Will the cost of maintaining the application outweigh the cost of producing and running the application?
When do you expect a return on your investment?
How can the application design be kept simple, teachable, and learn-able?
Will there need to be training to use the tool? (Just because something is usable doesn’t mean everyone will understand the usage).
Are you going to build out the application in phases? If so make sure each phase is independent and contains your MOST important features while being highly usable.

Later we will explore how vision and value help you to build a successful brand. Branding is another aspect extremely important if you are constructing a suite of applications and are trying to create a overall consistent user experience.

UI DESIGN GUIDE - Web Application Design, Design Examples, Design Lessons » design planning