Employee v.s Machine

Initially, an employee walked us through and showed me the usage of the machine. While my friend stood by and casually joked
“Does the food come out the back?” They all laughed. Personally I thought that would have been awesome, but no they still have to cook it. All the while I was thinking here we are 2009 and no Jetson’s technology yet, oh well. And now back to the topic at hand.

The Interface

The interface was quite pleasant to use. The initial screen had very large buttons with images depicting the various type of food categories. Each touch passed you through to the next round of choices. After studying the menu on the wall I decided I wanted a #6 combo. I noticed the image button with white and black outlined lettering with the word “Combos.” Easy enough so far.

As I proceeded onto my next select the system spoke very loud and let me know my current location (bread crumbs may have helped here). My design brain kicked in at this point and I thought. Awesome so far this system seems to be on the right track, let’s see what else it can do!

I next choose my combo size which the system graciously suggested three size options. I choose “large”, and was asked to choose a drink followed by my side item (free curly fry upgrade for using the system? Hell, yeah that’s incentive!)

Now came the true test, the system presented me with two buttons on the bottom Pay – Customize ( I’m not sure of those were the exact names because I’m trying to remember the system).The employee kindly showed me how to customize the order by touching a “customize” button.

I have sketched out this part of the UI from memory because, I only decided to examine the UI after the fact. Essentially, I was presented a screen with the items I ordered and a scrollable list that allowed me to choose 1-4 options for each of the items on my hamburger. I found the mustard option and set it to none and then clicked “Pay now.”

I was then presented with 3 buttons credit card (no debit card?), cash, and one more which escapes me. And since there was a ton of available real estate on the screen I thought these buttons could be even larger, and the addition of an arrow or text could point towards the actual manual interface options on the machine. In this case the credit card slot.

I proceeded to swipe my card the “wrong way”, like so many of us do. (Perhaps someone could build a better system for swiping cards – double strip maybe?). The ticket then was manually handed from the employee to the person cooking the food. I believe this was simply an issue that the machine wasn’t fully integrated yet with existing point of sale systems at the store. It was odd to have the order ticket handed to the back, but oh well. Next thing I knew my purchase was complete.

The Experience

To my surprise a lot of things went right. The system was friendly and the voice cues left me feeling confident about ordering. I was moved around the screen without issue, and even if the employee wasn’t there I still believe there would have been a fast and rapid transaction.

The UI never left me guessing if the previous selection was done correctly. This was especially important, since I had a pre-conceived notion of what my experience would be like. And like any other user experience that is a tough roadblock to get over.

The customization order screen was clean, not cluttered only showed me the options I could configure. Had I struggled at any point in this process. I would have probably never used this machine ever again.

Many of us have experienced or designed systems that attempt to automate the human interaction and fail miserably. This was not the case with this system. I actually believe I could order faster over time. Jack in the Box could even take this process to a whole other level where the system could recognize your name login ID or something and you could have a one button order of your favorite food. This is actually one of my favorite options on my ATM machine. It saves time and thought.

A Designed Experience With Thought

Let’s face it, the lunch crowd is probably the perfect audience to try out this machine. The only reason I felt guilty using this machine was for the simple fact that it does such a good job. A better job then other automated systems that have been around longer.

How many times have you been trying to race out of the grocery store at the “AUTOMATIC” checkout line only to be thwarted by this “friendly messages.”

“please place the item in the bag.”
“please wait for attendant.”
“please put the item back on the scale.”
“your coupon could not be scanned” (yep happened today)

When it comes to these grocery store touch interfaces it’s about a 50% satisfaction rate for me personally. I would much rather wait in line because the machine just usually ends up telling me to “wait” for human interaction to solve my issue. Beyond that how hard is it for the store to build in extra space so you can have room to put your groceries. Just like in any interface you don’t want the “ERROR: You Are Stupid.” to pop up on the screen.

The next time you are at the grocery store using the automatic checkout. Take a look around and see how many people it takes before the designed interaction of the system fails to produce the required user response. In fact, take a look at other touch interfaces around you and see what their failure rate of failure is.

Conclusion – Cheeseburger Harmony

Jack in the Box put some thought into this design, or at least hired a company that did. And that my friends is what a well thought out interface does.
This is the experience you want all your customers to have. And any UX person worth their cost should know that slapping a UI onto a product, application, etc… is just going to bite you in the ass.

In the case of J&B the return was not only well thought out but delicious.

Related articles:

1. Blog Response: What’s Your Design Sign?
2. How Can I Speed up Proto-typing & Visual Design Mocks with Hybrid Design Proto-typing?
3. Book Reviews: Neuro Web Design What Makes Them Click.

Usability is nothing new. What is new is the use of the term usability by anyone and everyone. It has become the de-facto buzzword across the design world. There are so many definitions and differences of opinion across the web on what usability actually means. Let’s take a look at the dictionary definition:

Websters defines usable as the following:

1. capable of being used
2. convenient and practicable for use

As UI designers, we draw upon a few more concepts to define this idea further. My personal definition takes into account the following:

• Learn-ability
• Memorability
• Performance
• Expected Interactions
• Consistency
• Repeatability

Yes, I know that’s a lot of “abilities”.  I will discuss this in future articles,but right now let’s just focus on what falls into the category of usability from an application standpoint and how it can directly impact adoption of our application.

Here’s A Feature, There’s A Feature, Every where’s A Feature

Many notable UI Designers, Interaction Designers, and User Experience Designers have talked about the problems of “featuritis.” The term simply refers to the rapid increase of features beyond either application need or user desire. This can occur to almost any product you can think of.  The goal is to minimize and avoid user frustration by understanding what it is the users really need. After you have identified what is needed it’s important to categorize your features, functions, etc into primary and secondary interactions ( I will talk more about this in a future article.)

Even The Best Applications Have Skeletons In The Closet.

Let’s examine some existing products on the market and identify some problems with these applications. Im sure many of us have used Illustrator, Photoshop, 3dsMax, or Bryce. These applications have a high user competency. You may need classes, formal training, and many years of experience to produce professional results. That is not to say these companies have “driven usability off the cliff.” In fact, many follow the same “menu” toolbar structure seen in 100’s of applications. Each application may have their own slight twist and or added access to complex functions. Regardless, there is no doubt a very important process has taken place at some point during the development of these applications to priortize the location of menu features. Hopefully, this process involved usability groups to actually figure out what the priorty was.

Take 3Ds Max for example. 3DS max is aimed at highly competent designers with modeling, mathematical, computational, and visual skills.  One version of 3DS Max I’ve used contained many complex context menus with alternating functions to complete as expected complex design modeling tasks. Personally, I’m glad I’m not a 3D modeler working with Max or Maya. The interfaces may be some of the most difficult UI’s I have ever encountered. Multi-Tiered cascading menus, complex keystrokes, and alternating views of wire-frames.

Let’s take a look at Photoshop. Pretty much every designer I know has used this behemoth of an application. The sheer power of the tool led to a lot of acceptance of any short comings. Yet, with the creation of CS 3 Adobe redesigned many core menu structures. One simple example is the tool bar that can now be set to a single strip along the side. This was one of my pet peeves. I would frequently run into the tool bar constantly being in the way. This small change (to the user interface) has saved me many minutes of productivity, and eliminated a major annoyance.

We The Users Will Not Stand For UI Mediocrity

Alan Cooper’s Book “The Inmates Are Running the Asylum“-(published in 1999)  talks about the complaceny users of software faced when working with web applications. of course, it is now 2008 and a more recent study by Jakob Nielsen points out that users have lost thier patience. No longer will users stand idly by and wait for that 30 second flash splash screen to load. Poor UI designs and convoluted interfaces, face a growing demand to be made better. It’s our job as UI designers to improve and invent new and easier methods of interaction. If any feature proposed as a usability enhancement fails it is much easier for users to swich prdoucts.

There was a time in the past when humans were pleased by simply improving complex processes with the use of a computer and software. The novelty has worn off, and now users expect much more out of the software they buy.

Think back to the last time you waited for a web page to load. Did you wait patiently? Maybe you tried to click faster in hopes the page would load faster. If you are like me, you simply go to one of the billion other web sites.  It’s reasonable to assume loyalties will shift and applications that fall to the road-side and allow usability to suffer will ultimely loose users.

The Dreams That Dreamweaver Dashed

For many years I was an avid Dreamweaver user. The tool allowed me to code faster than notepad, and did not overwrite my code. Adobe became comfortable with it’s lead on the market and the tool never really pushed the bounds of innovation.

Each subsquent upgrade lead to more features, but what I really needed now was a tool that could read my complex CSS style sheets and visually give me a good in program rendering engine. This would allow me to not have to constantly switch back and forth to my browser to check my designs.

So after years and years of program use I switched to Expressions Web. The CSS rendering engine was  amazing. Sure, it was an entirely new interface to learn not to mention Microsoft’s insistence this was not a FRONTPAGE tool but instead was directly aimed at professional designers. I hesitated making the final switch, but haven’t looked back. That being said now Expressions is falling behind on delivering the best software experience. I may have to take a look back at Macromedia.

Don’t let your software and usability become a fat pig. Conduct usability groups and determine where to go next with your application. When you have your list of features be cautious.

All Features Are Not Created or Treated Equally

Imagine you are in the market for a new luxury car. The list of features reads something like this:

• Power Steering
• Anti-Lock Brakes
• Rear View Mirror Camera
• Internal GPS
• IPOD Connection
• Stereo CD Controls
• Cruise Control
• Defogger
• Air Conditioning
• USB Ports
• Extra Outlets
• Block Heater
• Light Panel
• Spare Tires
• Microwave Oven

This is a top of the line luxury car. It has items you may never need. The engineers believed it was best to have two spare tires. One attached to the roof, and one in the trunk. They reasoned with the manufacturer that because of all the extra features the tires are not the best quality, but we did get all the features in. Occasionally, the operator of the vehicle may turn on the brights when adjusting the radio. They may short out the battery if too many items are plugged in to the outlets. They may burn fuses, but “everything” asked by the car manufacturer was included. Some pieces are less reliable then others, some have some major bugs, some even may cause system failure.

You may laugh at this example, but sadly it is very true. So many times features are the prized cow at the fair. They are the desired outcome of a super speed, fuel injected, development cycle.

Now let’s fast-forward a week later to the purchaser of this vehicle. His initial reaction was WOW it offers me all of these things? That’s a lot of stuff. Sure I may not use many of them, but oh well. I may need them some day! (just what the engineers, and developers wanted them to think). In The past they would have drank the kool-aid! OH YEA! Today that car is going right back and guess who just lost a sale and millions in investmetns?

The next time you want to jam that feature or expand that application. Stop! Think a moment about what the cause and effect will be.  Not to just the current implementation but future expected implementations. You may just prevent your application from careening off a cliff!

*Author’s Note – Due to the size of this article I was a bit late in publishing.

Related articles:

1. Features In The Front Usability Get To The Back
2. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?
3. Design Lessons: Should You Rush Your Design To Market or Stall it for Great Design?

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.

1. Do other similar applications exist? If so can I do it better?
2. Is the target market so small that the potential for profit or usage by clients is marginal?
3. Will the cost of maintaining the application outweigh the cost of producing and running the application?
4. When do you expect a return on your investment?
5. How can the application design be kept simple, teachable, and learn-able?
6. Will there need to be training to use the tool? (Just because something is usable doesn’t mean everyone will understand the usage).
7. 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.

Related articles:

1. Design Lessons: Should You Rush Your Design To Market or Stall it for Great Design?
2. The Most Important Questions to Ask When Building A Web Application UI.
3. So what is this corporate thinkers site all about?

Part of this comes from knowing what the common design pattern is for a particular widget. Another part is knowing how and when to stretch the limits of what is considered to be “common usage.” Any time you do something outside of the user expects is when your usability can start to plummet.

The Naked Anatomy of a Check box

Let’s take a look at a simple example our beloved friend the check box. There are two states to this standard check box that are considered common.

• If an item is checked it can indicate either something was accomplished.
• If the box is unchecked you are undoing or indicating you do not want to follow through on an action.

Generally you will find a check box in an unchecked state. Suppose for an instance that we reversed the common usage. A check box when checked now indicates to the user they are NOT SUPPOSE TO DO SOMETHING.  Applying this to the example below we see that because the current state is checked I would un-check to save my selections. Not only is this conter-intuitive but see how hard it was to explain that. You may have to read what I wrote twice to figure out what we are trying to accomplish.

Save Selections:

The same holds true for the most minute details in your application design and ultimately in the widget you choose to use. Going against the common accepted practice has already introduced unneeded complication and confusion.

In future stories we will be looking at a number of controls and how they should be used effectively.  Soon I will have a forum setup (next few weeks) to continue on the discussions outside of the articles written here.

Related articles:

1. When is it the Right Time to Use Icons?
2. SXSW Interactive 2008 – Pre-Morning Wakeup Planning
3. Did You Know Paper-Prototyping Adds Value If Done Right?