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.

During the course of this research I used many front-end UI interfaces and house databases. I came across one such search that was extremely tricky to use. Notice the image below and see that I am required to type in a zip code, but then I am presented with a GIGANTIC list of options in a multi-line text box (some 100+).

So here is the challenge to the community. If you want to participate great. For this particular problem your goal is to come up with a new and better design for the interface presented. If you want you can post a comment that goes to your design illustration etc, or you can simply e-mail me and I’ll be posting some of the entries here along with author and web site link.

There are no prizes. This is strictly for education purposes. There are no right or wrong answers. On To the challenge!

The Challenge:

Area Search OLD WIDGET

My Example:

In my example below I took two routes. One allows the users results to be filtered down to a smaller number by choosing the area in a drop down. The other route I added some interactivity with the mouse. Based upon the 2 filters search type, and area a user could click the “LET ME DRAW IT” and would be presented a zoomed map of the region. Then they can simply draw a box around the region of interest. Click search and then a number of different things could happen. A user could see houses pop up on the map, they could see a directory listing to the right. The point of this challenge is to design something different and hopefully better than the original

My New Design Prototype

Your Design Examples:

Related articles:

1. UI Design Patterns: Exploration of Data and Visual Imagery in Application Design
2. How Can I Speed up Proto-typing & Visual Design Mocks with Hybrid Design Proto-typing?
3. UI Design Dissection: Google Reader What Makes an Application Great?

The book takes a look at web design from a psychological point of view . Inside Susan covers topics ranging from how the brain functions, to what primary instincts are triggered by certain events we experience in our life.

If you have ever taken college psychology a lot of the material about brain composition, comprehension and the like will seem very familiar. What is great about this book is how Susan manages to apply these basic human survival functions to the usage of web sites.

Inside you will find a lot of research and case studies, each concept building upon the last and ultimately bringing home the abstract ideas to concrete web activities. 

One particularly interesting scenario revolves around product reviews and how we can structure these to appeal to a web users:

“Imagine you’re at a chain store looking for a HD flat screen television, a random bystander comes by and you ask him what he thinks of the TV.”

Perhaps you do this with thirty other people in the store, asking each of them what they think of the TV. It sounds kind of foolish, but how many of us repeat this scenario multiple times a day online?  We are easily swayed and influenced by the ratings and reviews of strangers online.  We just don’t know who or what the experience level is of people rating a product online. Yet, when we see the 130 people gave this 4 stars. It directly influences our purchasing decisions. Now that is power!

The book continues to take a look at this method and refines the concept because of the ever changing skeptical nature of web users. Now we may find the review rating backed up by technological, or subject matter expertise.

Overall this book  is a great read and should cause some re-reading if you really want to get the most out of it. The first 1-7 chapters really tap into your “old brain” and you may want to stop reading a bit and just sit and think about how you can apply them to your web site. I know  I did this.   Chapters 8- to the end really rein-force a lot of the concepts. What I found however is that my brain was so busy thinking of ideas, and ways to change content, etc I had already come up with a lot of the material that was covered in these subsequent chapters.

Bottom Line: Get the book, read it, and practice what you learn.

Related articles:

1. SXSW 2008 – Day 2 Summary -
2. SXSW Interactive 2008 – Day 1 March 7, 2008
3. Book Reviews: “Web Form Design Filling in the Blanks”

Let me back up a little and begin there. The other day I was driving home from work and recently started  on a new UI project. I was going through my normal routines  when presented with a  project.
I start to ruminate over all the things I can do and how all the various functions of this new application would tie together. As I pondered this in between paying attention to traffic and driving, one core question popped into my head. A light bulb snapped and thus this article was born. I realized just how many designers, and developers, forget to ask one magic question.
Maybe they are strapped for time, burned out, or whatever the reason might be. You need to ask yourself this question!

Would I use my own application?

Would  I use this application. At first glance it is such a simple question but extremely valuable and woven with complexity. By knowing the answer you begin to discover unknown paths, problems, and practical answers to otherwise obtuse solutions.

Frequently, when I’m working on a new application with a development team I have to stop them a minute and get them to think about what we are trying to build. Not from a developer, QA, BA, Interaction Designer, UI Designer, System Architect, SQL Developer, perspective but from the person using the tool.

Walk A Mile In My Application

I like to think of it this way. It’s easy to make a pair of shoes, especially if you don’t have to wear them. Nails can stick out of the heel and the fabric may be torn. I still get an A for effort right? WRONG!

Another comparison would be just like the athlete who advertises how great a product is then turns around and uses another instead. Wouldn’t you as a user / consumer feel cheated in some way?

A true life example recently involved a function and feature for inter-application navigation. The feature was supposed to allow the USER to quickly change between editing different individuals’ information.

“A user could quickly change between various people and edit them rapidly.”

It sounded like a safe idea on the surface, but here is where the problem existed. We started by examining all types of ways to make this feature work and be non-confusing to a USER. I tried chunking the information, grouping it in different ways, larger titles, more prominent text. No matter what was tried in the current framework it was still extremely likely for the USER to get lost and more importantly loose the context of the initial task they were trying to complete.

Should We Design for the Sake of Design?

So I sat back a while and thought about the problem. That is when the answer hit me. Why? Why are we trying to let the user do this? Why were we trying so hard to fit a square peg into a round hole? Of course, every group had their own answers:

• Developers – “It would be great if a USER could manipulate the data quickly.”
• QA – “It works and does not break functionality. What is the problem?”
• Business Analysts – “The user should be able to do this function (but why?)
• Interaction Designer – “There must be a solution to this to make it highly usable and fit into the requirements.”

Now let’s back up a second. What about the task itself? Why would a user care about editing multiple individuals quickly? The quick untested assessment was “Users sit down and want to edit multiple people at once.” That was the expected reality but taking a step back and analyzing the task step by step the team discovered that there was absolutely no need for 99% of the users to do this task. They just would not use this system or this feature in the way it was envisioned. If I was editing an individuals information it was because I was either:

A. Talking with a customer recently and discovered changes to this information
B. Made a mistake when entering information and wanted to correct the information.

In either case we had other methods to handle these scenarios. What we didn’t have is a way to mass edit a single individuals information (usability and focus group testing should be conducted to figure out if that is needed). No matter how much everyone wanted this feature we really had no need for it. It was cool but as you read in previous articles that is not enough to justify its importance in an application.

So when you are developing or building a new UI. Ask yourself these questions:

1. Would I use this application (feature)? If not why?
2. What are the tasks the user is trying to complete?
3. Are there too many tasks complicating a single workflow?
4. Does my UI or application framework have enough flexibility to support these new functions?
5. Have I been consistent in my UI framework?

So ask the question and challenge the team to give the “why”. Why are we building this application? Why should we build this application? Will our customers or more importantly will I use this application?

Related articles:

1. Corporate Conflicts A Cantakerous Cacophany of Confusion.
2. UI Design Lessons: A UI Designer in an Agile World, Get Me Out of Hell! – Part 1
3. Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?

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.

Related articles:

1. UI Design Software Review: Flair Builder v1.6
2. SXSW 2010: Live Stream Day 2 From SXSW 2010
3. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?