UI DESIGN GUIDE - Web Application Design, Design Examples, Design Lessons » User Experience Design

UI Design Dissection: Jack in the Box Self Order Machine

uidesigner — Sat, 08 Aug 2009 18:20:52 +0000

Today for lunch I decided to swing by Jack in the Box. Little did I know I was about to have a unique UI experience. Upon arriving we were introduced to the brand new (at least in this area) self order system. And thus began my customer experience.

My initial reaction was one of horror. I don’t like ordering what is “on the menu.” I like to order a customized combo. All I could keep thinking was how well was this machine and more importantly the touch UI going to hold up to my customer demands? Join me as we dissect the Jack in the Box Self Order Machine.

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.

UI Design Lessons: Are You Driving Your Application Usability Off A Cliff?

uidesigner — Fri, 04 Jul 2008 19:52:18 +0000

If I had a million dollars for every time a client asked me to add more features, or more appropriately stuff and jam more features into an already bulging application, I would have published a book, bought a mansion, and maybe a small island somewhere in the South Pacific.

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.

Design Lessons: Should You Rush Your Design To Market or Stall it for Great Design?

uidesigner — Wed, 09 Apr 2008 00:46:24 +0000

What makes a good design? Is it the process of creating the design, the aesthetic, or the usability? Does increasing a complex process for design force it to be good, or hinder a web application’s creative possibilities?

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?

Features In The Front Usability Get To The Back

uidesigner — Fri, 15 Feb 2008 15:01:17 +0000

Almost daily I face this this challenge. In fact it is infuriating about how many times in the day a usability concern is locked into the backseat. New features almost always seem to win versus making a new product better simply by improving the usability of an application.

Think of it like Jenga. In the game Jenga you must pull out the bottom blocks and place them on top. Every time you place a new block on top the structure becomes shakier and is unable to support the weight until it eventually all crumbles to the ground.

Imagine an application that is under this same pressure. You start out developing and have an ok UI that “seems” to support the weight of the tool and then you release the product to the consumers. They begin to complain of slow load times, confusing UI interactions. Back in the design room discussions are held about how to improve the usability. And the #1 thing brought up is add new features. No, No, No!

Take another look! You may not need to start from ground zero but, the foundation on which the application has been built is weak and trembling already and about to collapse. The last thing you should do is throw more weight on top of the impending disaster.

This is exactly what seems to have happened in more places then you can imagine. You eventually reach a point where the application looses it’s ability to scale to the increasing features. Sometimes you have to just close your eyes walk away and wait for the impending I told you so.

At this point you should be utilizing real user feedback, comments, and in house usability testing first hand to see what problems are plaguing the user. Sure some features that may be missing may be the culprit, but more often then not the tasks we perceived to be simple are way too complex and the base functionality of the application MUST be revisited to support future growth.

Kathy Sierra talks a lot about this in her blog.

I still have yet to find ways to counteract this line of thinking, but it’s just human nature – more is a perceived better. Any more ideas on how to combat this line of thinking?

User Experience Design in an Agile Development Cycle

uidesigner — Thu, 29 Mar 2007 21:16:16 +0000

The title pretty much says it all. After working for a while now in an agile development model. I’ve discovered several disturbing things that really cause a loss of sanity. The agile development cycle is quite fast. Depending on your team it has different lengths. Most iterations seem to be 1 week long. During that week developers develop working software. Notice I said working software and not “USABLE.”

The primary prescribers to the agile method believe that the UI should pretty much just be slapped on at the end. I paraphrase but something to the likes of “Leave The UI out until the last possible moment.” I find this to be extremely scary. Especially when the thought process behind the agile development methodology is to think of the end user. So to put this all into perspective. We have one side of this method that says leave out the UI until the end but keep the user in mind when creating the story (feature). I know when I first heard this I was a bit shocked by the contradictory nature. So like any process I attempted to make it my own and mold the process to my own needs.

more to come…

Why Did My Design Fail Miserably and Other Not Nice Things?

uidesigner — Wed, 28 Mar 2007 01:41:00 +0000

So as I was laying here sick in bed and thinking about design stuff. That’s the great thing or a curse about having a design based job. Even while you are sick you can’t always turn off your brain. So unless asleep or staring at the tv you are always thinking.

So the concept I was pondering this evening was design patterns and innovating existing user interface design patterns and widgets. I think web designers and user experience designers tend to fall into a pattern. “My ways are the best why change?” I know this has been the case with myself. I find it easy to fall into my design mantra. Constantly justifying the re-usable controls, grids, design parts and pieces as all of a “consistent” design. That is the trap! Limited time to come up with a new design before moving onto a new project just makes that trap even more self-fulfilling.Â Now that the trap has been identified how can we escape it?

Well, one method is this blog. That is one of the reasons this has been put out here. So here is the first design challenge. We don’t have many readers yet, but I have faith! Think of a complex design that you had to break down into an easy to use web application.

Why was it considered not user friendly?
Was the applications activity fully understood?
Who was the user base?
Was the technology proficiency of this user group under or over estimated?
What do you think was your #1 reason for failing in this design?

My most recent experience is with an account application. I knew after spending over 15 different screen mocks and numerous in person sessions that the design was overly complex and we were trying to do way too much. I voiced this, but eventually just gave up under the weight of pushing the application through development, Quality Assurance, and into demonstration mode. I should have pushed harder, but so many voices were in on the design that it took on a solid form and any variation outside of what was deemed “approved” was not really up for debate. So I pushed on with the design knowing full well it could be better.

As it turns out the design was even complicated to implement programmatically.Â It was obvious that we had to take a radically different approach to this design. The business wanted to include so many features andÂ I knew from my experience the usability of the application would suffer. After numerous issues of real internal users trying to use the application that had never seen or been involved in the intiial development. It was quite obvious that we needed to take another crack at it. So I came up with another 3-5 hours worth of designs. I was still adhering tightly to our existing model because code had already been written and we didn’t want to toss it and because we had to stay inside our approved designÂ model and within the timeline. On this second pass, or maybe it was third I lost count. The same initial problems were maybe cleaned up a bit but within the existing framework there was not enough outside thinking to turnÂ the app around. Features that were determined to be core feature sets were insisited to remain.Â Even thoughÂ I felt how feature bloated the application was I could not make a dent in radically changing the design from what was the pre-concieved and accepted design.

I hope to someday go back and redesign this application, which probably currently only has an adoption rate of 1% users. And that adoption is not because of usability but because of shear necessity. That’s probably the #1 thing you will hear from developers and programmers it works! Working isn’t good enough, especially when you want to have pride in your design and the ability to make the task it was designed for quick and painless.

There were several reasons this design failed. The activity for which the design was built for became way to large. It was imposisble to account for every scenario evenÂ though the mentality was that we needed to.Â We should have focused on the the top 2-3 primary activities and make the application do those like a pro. Any other functionality should have been carried by the main application and not handled within the management. I knew this from the start but couldn’t get the dreaded buy-in I needed. And in a corporate environment buy-in is the key to getting your voice heard. Eliminating those less important features would have made the User Interface extremely flexible.

Another downfall revolves around the understanding of the primary application goal. My understanding became so muddled as we added more functions and features I started to loose site of the users and what they would be doing. I was trying to balance the primary features and elevate the lower level features as high as the primary application function. This caused a complete blurring of what the whole product was meant to do. And more importantly what path the user would take to complete task A – Subtask B – Subtask C – all in hopes of reaching end task F. Then repeating this cycle for another user. That looks complicated just reading it in text!

So please feel free to share your stories and info!

The Haves, Have Nots & Feature Bloated User Experience.

uidesigner — Sat, 24 Mar 2007 03:55:17 +0000

Imagine with me a minute that you have just identified in your Book Keeper 2.0 web application that too much information and functionality is jammed into the “add new book” page. The business analysts insist that everything needs to be available to the user. They “need” to have the ability to do numerous things on 1 particular web page.

Book Keeper 2.0 – Keeping Books Since 2006

Feature List That Needs To Exist On New Book Add Page:

User Needs:

to add a new book in rapid succession
to delete a just added book
to Edit The New Book Entry
to create new book categories
to add reviews to the new book
to maintain a registry of who has original book copy
to search for books
to manage categories
to manage users

Now it’s quite obvious that some functionality may be used 1% of the time. And thus begins the battle between UI designer and business analyst or the client. The number one problem I have faced personally is unnecessary features in non-logical places. A virtual Swiss army knife. They client or BA may want a Swiss army knife, but what does that really mean. Well, if you have used a Swiss army knife you have to remember where all the tools are, and pull up the right tool in the right sequence, while making sure that other tools don’t get into your way. Basically, you have to find what you need by memory, or worse luck. Think how easy would be if you needed a knife and you had a pocket knife in your pocket and that’s all you had.

The same is true with our development process. Why should we put 20 features into one application process, path, when they may never be used by the common user. Couldn’t that time be spent on other application development cycles. Things like speed improvements, or gasp improving and revising your existing UI.

The hard sell in corporations and even to a client wanting you to build an application is the concept and mentality that “more is better.” Our application can do 50 things! What we fail to illustrate or tell is: it’s confusing as all hell to use, only 1% of our user base are advanced users and they might use more than 10 features in every given application usage sitting.

What can be done to convince these non-designers, non interaction developers, that more is not better? That tossing the usability out the window, or just tacking it on at the end is really not good enough? There are a few ways to do this and one way is to just let it all hang out and see what happens. Let the application go live and then learn from the failure. In a corporate environment you don’t have that luxury unless you hate the people you work with and you may.

Excluding the option above you need to find a way to convince these other groups that usability and the design of the application is more important then adding 50 extra features that 1% of users may use. So how do you do that?

Tune in later as I examine more on this topic.