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?

What are the benefits of Hybrid Prototyping & Mocking?

• More reliable layouts that fit expected content layouts (better predictability)
• Quickly create complex and realistic widgets
• Rapidly develop new HTML controls
• Use each tool (expressions, notepad, Photoshop, illustrator, acrobat) to its strength

Step 1: Build Your Design Library?

When building a new web application, or widget I usually fall back on my base CSS styles for initial mocks. If you do not have a base set of styles. I suggest you build a CSS library. With only a few lines of code you can quickly create many different application widgets and their look. This is especially true if you have a standard corporate or company brand you need to follow. Here is just a quick sample of the table code I use when doing table structures.

/* Used by the other data grids */
TABLE.grid {
 border-collapse: collapse;
 font-size: 13px;
}
TABLE.grid caption {
 font-size: 13px;
 font-weight: bold;
 color: #F6F18D;
 vertical-align: middle;
 text-align: left;
 padding: 5px 0 5px 3px;
 margin-top: 20px;
 background: url(images/header_background.gif) no-repeat center left;
}
TABLE.grid TBODY TR {
 vertical-align: top;
}
TABLE.grid TBODY TR TH {
 font-size: 11px;
 font-weight: bold;
 vertical-align: top;
 text-align: left;
 border: 0px 0px 0px 0px;
 border-style: dotted;
 border-color: #B8660B;
 padding-top: 10px;
}
TABLE.grid TBODY TD.alternate {
 background-color: #EEEEEE;
 padding: 2px;
 height: 14px;
}
TABLE.grid TBODY TR TD {
 font-size: 11px;
 padding: 4px;
 height: 18px;
 text-align: left;
 border: 0px 0px 0px 0px;
 border-style: dotted;
 border-color: #B8660B;
}

 The above code is just a small example. The goal is to build out the code enough so you can simply class/id at the top of your table and then let the cascade ripple through the table elements. If I simply removed the <tfoot> or other elements I can quickly make my table look twenty different ways with only the simple class /id  at the top.  Using this same process I would build out divs, legends, fieldsets, and form elements.

I can mock up a drop down in Photoshop in about 10 minutes, or using this method I can do it in about 10 seconds. If I put more widgets to use In this way I can build out custom screens very rapid. Even more to the point I am using my actual library so I may be coding real world code that could easily be used in the final web application.

Step 2: Screen Print Is Your Friend and So is Screen Capture

Now that I have some custom widgets built and displaying on the screen I can capture the screen and begin building out my widget folders in Photoshop. I usually would create new Groups (folders) inside my Photoshop work space.  An example folders structure: Data Examples, Search Bars, Buttons, Grids, etc..
Using our little friend cut and paste I’ll start placing my pieces into the appropriate folders.

The goal is to get frameworks of your widgets. You can then use Photoshop to “spice em up,” or change them into other designs. You could even create some text examples to lay on top of your various frame-worked widgets. I usually end up creating my containers, and supporting images in Photoshop / Illustrator since that is the best tool for this job.

 Step 3: Build It Out and Tie It All Together.

Start building out your new application interface. I’ve found that using both an HTML design tool and Photoshop in tandem I can quickly pull together a design in a matter of hours. The quick benefit of this is that your design nows uses actual sizes and even actual (potentially production) code.

When you have some screens you like save them out as JPG’s. Next your are going to open up your JPG’s inside of Adobe Acrobat. Merge all of your related screens into a new PDF. Now go ahead and go to your first page and look for the interaction point you are looking to simulate. For example clicking a link pulls up an AJAX edit screen. Select the “ARTICLE” tool and draw an area around your interaction destination. Be sure to name it something you will remember. Now you want to go ahead and select the “LINK TOOL” and draw a link area around where you want your interaction to occur. You should see a popup.  Choose the following “CUSTOM LINK > ACTIONS > READ AN ARTICLE > Your named article area. Repeat this process and you now have an Interactive PDF MOCK.

Summary

In this article we looked at why Hybrid prototyping can get you to a visual interactive mock faster. We learned about creating a CSS library to speed up the process of creating these mocks. We learned how to create an interactive PDF.

The House that Jack Built…Is Crumbling Down

Let’s say you are a contractor building a new home for an unknown family. Looking at your deadline you realize you aren’t going to make it on time. It’s time to do something to solve the problems. What can be cut first?

Perhaps you get cheaper wiring, maybe the concrete on your house didn’t dry before the rest of the foundation had set. Because you are behind schedule you feel the only way for you to “catch up” is to cut corners. Cut one corner and you have opened up Pandora’s Box. It’s so easy to cut more and more. You begin a process of jamming things in just to meet the deadline. One year later the house catches fire and you are sued because you cut those corners.

Elevate Your UI Design To Another Level

The same holds true in UI design and in the UI design process. Frequently you can get rushed to put an unfinished design to the test with real users, even though you are aware of other issues with the design. It may be slow, it isn’t usable, lacks cohesiveness, tries to do too much, is hard to understand, is missing key features of a process. All of these are symptoms of a rushed and hurried design. You can see this in pretty much any application.  Your goal is to minimize this but how?

Give Your UI Time To Mature

This is one of the big concern designers have with an Agile development process. The same can also hold true in a Waterfall management process. The rate of development and design is fast and it’s extremely tricky for the UI designers to stay ahead of the development cycle. What’s even scarier is if the business fails to understand the importance of re-factoring and retesting a design. Rarely, is a UI design perfect the first time. It should and must be tested preferably by the people, person, that are going to be using the application. The problem is getting those that have direct interest in the application to buy-in( I’ll cover more about this later).

Dress your UI Design For Success or Send it Back to the Orphanage

It’s important to somehow let the client know that the first impression of an application is the most important. This is your adoption point (your such a cute design yes you are). If your customers don’t like the product at this point you have to work three times as hard just to gain them back!

Please Come Back I’ll Do Better Next Time I Swear!

Think about the last time you purchased a product and were dissatisfied with the outcome. You probably returned the software, car, clothing, food, etc.. and refused to ever purchase that product again. You probably even refused to purchase a different product made by the same company. This is especially important to your web application and UI design. Yes, features are important, but if my car has 3 steering wheels, 5 extra tires attached, and everything is labeled in Japanese are you going to think it’s usable?

Act Like The Customer Think Like the User

A customer tries to answer two quick questions about your software before purchasing, or using it.

1. Does it do what I need it to do?
2. Can it do it easily?

These are simple core concepts, yet look how many UI designs struggle with this. Look how many Interaction Designers wrestle with these ideas. Think back to the last piece of software, or product you have used. Do you have it in your head? Now think back to the reason you purchased it.

For myself the last item purchased was a tennis racket. These were the thoughts going through my head.

1. Can it hit a tennis ball? – Question Answered – [FEATURE]
2. Is it lightweight, balanced, and does it feel right to use? – [USABILITY]

If I was able to answer the above questions and after repeated use (learn-ability, memorability) could continue to perform and even excel then the design was in essence “great for me.” Why did I put this in quotes? Well as UI designers we have to find that common ground to support the vast majority of users. Are you really really going to find a UI Design that supports 99.9% of your users. You may find a a design that meets all the goals of your (persona’s -fake users), but even that is a rarity.

So What Makes a Design Great?

It’s the combination of a great feature set that has a high level of usability and has an aesthetically pleasing design. It’s about a design that delivers direct answers to the questions.

Does it do what I need it to do?
Can I get it done easily?

So the next time someone says just jam that feature in to the design. Feel free to send them to this post so they can see what really happens and how many aspects of the software you effect because of quickly rushing a design. Your adoption point or the first release of your application is your first impression. Fail at making a good one and what was the point of even producing the software?