Table of Contents

Project Proposal Team Members Kristina Cary Nick Hays Pirate Steve Teresa Spirek Problem Statement Users Initial Suggested Design Needs Analysis Introduction to the Problem Information Gathering Information Gathering Part A Information Gathering Part B Personas Randall Graves Alyssa Jones Brandi Svenning Lexicon Persona Goals Randall Graves Alyssa Jones Brandi Svenning Interaction Needs Task Matrix Scenario Process Comparative Analysis Initial Design Ideas Interaction Design Introduction Prototype Method TestMeasures Results Discussion Appendix A: Prototype Walkthrough Appendix B: Raw User Data Appendix B.1: Smilin' Tad Sparrow Appendix B.2: Jelly Legs Agnes Appendix B.3: Tax-Evadin' Laszlo Dawkins Appendix B.4: Pirate Dora the Pink Who Did what Interaction Assessment Changes Between Lo-Fi and Hi-Fi Heuristic Evaluation Hi Fi Prototype Walkthrough Hi Fi Prototype

Team's Website

Project Proposal

Team Members

Kristina Cary

Kristina Cary has prototyping and programming experience and an enthusiasm for engaging users in our design process. She will be the design manager, coordinating design aspects of our interface.

Nick Hays

Nick Hays is confident his familiarity with software and system level design and prototyping will contribute greatly to our project. He will be the evaluation manager, coordinating evaluation of our interface and the recruitment of potential users.

Pirate Steve

Pirate Steve brings extensive experience in programming and the use of self-checkout machines. He is certain that his expertise with graphics libraries, Photoshop, and Macromedia Flash will aid the project's prototype creation and that his past job as a cashier will also contribute to the group's understanding. As our group manager, he will coordinate the project as a whole, maintaining the big picture.

Teresa Spirek

Teresa Spirek has training and experience in observing complicated interactions and developing user personas. With strengths in communication and organization, she will manage documentation and coordinate write-ups.

Problem Statement

The self-checkout machines common at many grocery stores and other retailers are an interaction nightmare. Though meant to save customers time by speeding up the checkout process, more often they seem to confuse customers to such an extent it takes even longer than usual to get through a line. Even when people are familiar with the machines, small problems (e.g. cans getting stuck in the conveyor belt or not having the system recognize an item has been placed in a bag) still delay them because these errors cannot be resolved by the customer alone. Instead each requires intervention from the single cashier on duty who is responsible for multiple stations.


Our primary user group will include customers using self-checkout machines to pay for their orders. Secondary users to consider would include store clerks and managers. Though members of each of these groups might vary widely, with observation and interviews, we are confident we can come up with an effective persona to focus on in our design process. Because we have yet to begin further research and interaction with our user group, we attribute our own motivations for using self-checkout machines while shopping to other such users; first, curiosity, and later, a means of saving time.

Ideally, we would like to begin by observing users at stores using current systems. In order to do this we will need to go to stores in the area with self-checkout, beginning with Stop and Shop, and get permission from the store manager to observe and/or interview their users. After that we plan to approach and talk to individual users in the store, get their individual agreements to participate. If this proves difficult, we can also get people we know to go to the store and buy things using the self-checkout machine while we observe them.

Initial Suggested Design

Our primary proposed change to the system involves the creation of different software interfaces for different levels of users on the same self-checkout machine. One way of identifying more experienced users vs. first time users is through the use of store loyalty cards at the beginning of the check-out process. Many smaller changes will come from this such as the opportunity for experienced users to correct small problems without a cashier, or a faster way for people to move through the line who have already been exposed to the process.

Even though we have these initial ideas of how to improve the self check out system, we won't be able to determine exactly how the interface will allow for these changes until later in the design process. As we are a team made up of people who interact with a variety of software interfaces every day, we need to make sure not to become to set in our ideas, which could cause us to overlook the needs of less tech-experienced users.

Needs Analysis

Introduction to the Problem

The self-checkout machines common at many grocery stores and other retailers are an interaction nightmare. Though meant to save customers time by speeding up the checkout process, more often they seem to confuse customers to such an extent it takes even longer than usual to get through a line. Even when people are familiar with the machines, small problems (e.g. cans getting stuck in the conveyor belt or not having the system recognize an item has been placed in a bag) still delay them because these errors cannot be resolved by the customer alone. Instead each requires intervention from the single cashier on duty who is responsible for multiple stations.

Information Gathering

Information Gathering Part A

To understand our users and design for them, we needed to begin interviewing people checking groceries with self-checkout machines. Not only interested in who was using these machines, what sorts of shopping trips they used them for, and what they found difficult or trying about the machines, but also who wasn't using self-checkout, whether they had tried it before, and what they felt was missing from such a system, we organized an interview plan. We wanted to begin by observing users at stores using current systems. Ideally, this would have been a straightforward process; going to stores in the area with self-checkout, getting permission from the store manager, and interviewing users. Unfortunately, when we talked to the Stop and Shop manager, they told us we were welcome to observe people using the self-checkout, but stipulated that we could not speak with or delay customers until they had finished their checkout.

We had thought we would introduce ourselves and talk to people as they were waiting in line, be able to speak to them as they checked their groceries, and also ask additional questions afterward. Also, we had planned on speaking to people in line at the normal checkout lanes. Instead, most of our time at Stop and Shop was spent observing users rather than engaging them in interviews. In order to have users we actually could interview as we had planned, we ended up accompanying users to stores and having them check out with self-checkout. Though we strove to have such interviews with a spread of people throughout some of the groups we noticed emerging from our observation-only trips, we were limited by our own connections.

Information Gathering Part B


In fleshing out our personas, we tried to develop them first in terms of their personalities and lives. From these initial sketches, we were able to identify their habits, needs and goals as shoppers.

Randall Graves

Randall Graves is a 20 year old college student majoring in mathematics. He's fairly comfortable with technology and uses it in his everyday life both for school work and for recreation and his girlfriend complains that he plays videogames too often. He lives in a dorm and is on a meal plan, so the majority of his shopping is for snack food type items or incidentals (toothpaste, deodorant, etc) and he shops fairly late at night. He doesn't have a car on campus, but lives in a pretty central dorm so he doesn't mind walking everywhere, including the grocery store. He smokes pot occasionally and has gone shopping while stoned a few times when the munchies struck and he was faced with an empty fridge. He worked as a video store clerk while in high school and now holds a part time job in the college library, mostly working at the front desk checking out books.

Alyssa Jones

Alyssa Jones is a 40 year old mother of two boys, 8 and 10 years old. She works mornings as a dental hygienist, but gets off in time to pick up her boys from after-school sports while her husband is still at work. Her family's health is very important to her, and she tends to try to work a good amount fresh fruits and vegetables into her weekly meal plans. When possible, she buys organic. She's always on the lookout for a good deal and uses both paper coupons from the Sunday newspaper and printed ones from an online bargain hunters' forum where she's a member. She shops from a list that she makes from her menu of planned meals for the week. Now that her boys are older, she looks for ways to engage them in the shopping process ("You can each pick out one box of cereal," "If this costs $3, how much will four of them cost?"), but when they were younger, she would keep them on child-leashes while she shopped. She makes one big shopping trip per week with her list (usually around 5pm on Tuesdays after picking the boys up from soccer), but usually stops by the grocery store at least one additional time per week to pick up items she forgot or has added to the week's menu list since her main shopping trip.

Brandi Svenning

Brandi Svenning is a 60 year old retired high school social studies teacher. She lives alone with the exception of her cat, Mittens, and tends to follow established routines. She's very uncomfortable with technology and would only accept hand written homework from her students while working as a teacher. She has arthritis for which she takes a number of prescription and OTC drugs. Every Sunday, she goes through the newspaper and clips coupons for the things she always buys, and puts them in an envelope that she keeps in her purse. Her shopping list varies very little from week to week as she knows what she likes, and she makes one shopping trip per week at around 11am on Thursdays. She only cooks for herself and tends to eat out at a restaurant if having dinner with friends. She wears reading glasses and has recently started reading large print books almost exclusively.


cash, scan, pop tart, snack food, coupon, produce, "paper or plastic?" credit card, cat food, receipt, instructions, scale, large order, conveyer belt, scanner, shopping list, store card, shopping trip

Persona Goals

Randall Graves
Alyssa Jones
Brandi Svenning
Interaction Needs

Task Matrix

Possible tasks during the grocery shopping interaction, and whether our personas will use them or not.

Key: [x] Every time [~] Some of the time [ ] Never

Randall GravesAlyssa JonesBrandi Svenning
Scan Couponsxx
Scan Value Card~x
Scan Productsxxx
Weigh Fruts/Veg~xx
Identify Fruits/Veg~
Accept Cashx
Accept Credit x
Accept Debit~~x
Prevent Theft~ ~
Bagging Station~xx
Receipt Printer xx

Out of our personas, certain tasks will only be performed by some of them, some of the time. Randall only does the barest of shopping trips, so he only really needs the system to be able to accept cash. However, he will occasionally need to purchase fruit or vegetables, and in those cases, he'll need the system to help identify what they are. He typically pays in cash, though if he doesn't have cash on him, and his bank account has enough to cover the trip (it's frequently quite low), he'll use his debit card. Theft prevention is needed for him, since he's in the group least trusted by management, and so for them to let him use the machine, he'll need to have some theft protection, though he will probably never trip it legitimately, and it will likely only serve as a significant added annoyance.

Alyssa will need most of the features of the register. She typically doesn't carry cash, and since she makes larger trips to the grocery store, it doesn't make sense to pay in cash. She almost always knows exactly what kind of fruit or vegetables she is purchasing, so won't need the machine's help in identifying them, and wouldn't try to steal with her kids in tow, so the theft prevention mechanisms will only be there as an annoyance.

Brandi will use a similar set of features as Alyssa, however, she doesn't have a value card, and doesn't use a credit card. The theft prevention features are actually most likely to be useful against her, since, contrary to many peoples' belief, older women are the most likely people to commit petty theft. She can also be somewhat forgetful, and either not scan an item, or not realize when the scanner didn't pick up that an item was scanned.


Currently, we have one scenario worked through: our success scenario. Here, Alyssa is making a quick stop on her way home from work to pick up a few ingredients she missed and needed for dinner that night. She also picks up a couple other items in passing. Since there's a lane standing open and she only has a few items, she decides that self-checkout will probably be quicker to go through than waiting in line for a cashier. She wants to be on time to get the kids from school. Below, we have illustrated the screens Alyssa will go through during the checkout process.


To begin, the team thought of useful questions to ask. We talked about the various aspects we wanted to cover, as well as how we might get at those issues. The team then split up to interview friends, family, and strangers at the grocery store. After collected data we came together to discuss what we had seen and begin working on personas. As we begin to pull out the details, we began assigning them mentally to our various personas. If we weren't sure where something went, we made sure to write it down on a notecard, which we eventually attached to an individual persona. With our personas taking shape, we began to create back-stories for each of them, and finished by finding pictures from magazines to help us visualize our new mental model. We then moved to scenarios, where we walked our users through the process of self checkout, making sure to include situations from our earlier real world observations. After working out a simple flow diagram of potential user interactions, we created a storyboard containing each screen our persona might see.

Comparative Analysis

The current system of self-checkout machines is very similar to that of regular checkouts. There are a few differences, and they are generally designed for smaller loads. As can be seen in the picture to the right, on the self-checkout machine, there is a place to put down a basket, but not enough room to maneuver a cart into place and then load things onto the belt.

The majority of the action occurs right in front of the screen, with the basket, scanner, touch-screen prompter and money collection devices (credit, debit and cash), plus a place for change to come out under the scanner, similar to the placement of the money return on most vending machines.

The scanner/scale combo is identical to the one that the cashier has, and due to the current weight-based produce purchasing system, and the laser-scanned-UPC-based product management system is a fairly essential part of the checkout process. There have been some improvements to the produce system in Stop and Shop, with weighing stations available in the produce section to allow customers to pre-weigh their produce and speed up the checkout process.

The current payment system allows for either cash or credit card/debit payment, and is a fairly standard setup, almost identical to the regular Stop and Shop checkout system in the case of the credit/debit payment system, and, other than having to insert change before bills, the cash entering process is identical to a typical vending machine payment process.

The current screen interaction ideally follows the pattern pictured here, where the user goes through, scans their value card, and then begins scanning their various items. There can be some problems here, when the system thinks that an item hasn't been placed on the belt or in a bag, or if the belt has filled up with items, and no more can go down. The system will then freeze up and after the user resolves the problem, they will have to talk to the cashier on duty, and have them certify that the problem has been fixed.

If the user wishes to weigh and purchase a produce item, they enter the produce screen, select their produce either by picture, knowing the name, or by finding the numbered sticker on the item, and matching it up with the one in the menus. On the Stop and Shop menu screen, the produce is ordered by popularity, even in the alphabetized menu, which can make less popular items difficult to find.

After the user has finished scanning all of their items, they go to the payment screen, select one of the payment methods, and finish.

Initial Design Ideas

One thing that has become clear through our user interviews and developing our personas is that while they all have the same end goal (buy groceries), they have very different needs that will influence how they can best accomplish this task. This is why one of our main design ideas moving forward is coming up with a system that accommodates different levels of users through the use of store loyalty cards.

At the beginning of the self-checkout process, users will be asked to scan their loyalty card. If they do not have a card, or are scanning it for the first time at a self-checkout machine, they will go through a "beginner" level process. After that first time through the system, they will be marked as a more experienced user and given such privileges as the ability to correct errors themselves without cashier assistance.

Since the loyalty cards also record information about past purchases, the new system can take advantage of this information. For example, on a produce identification screen, fruits and vegetables could be ordered based on the frequency with which the current user has bought them rather than by general popularity.

In many cases, loyalty card history is already used to provide the user with coupons or deals tailored to their needs based on the items that they commonly buy, but these usually only appear as part of the receipt after the purchase is complete. If these coupon codes were instead added to the user's file, it could eliminate at least some of the coupon scanning that users like Alyssa and Brandi would need to do and decrease what is one of the more confusing interactions in the current system.

There are a few other changes that we feel should be made to the interface that do not change the overall interaction. These include adding a way to change font size on the display and generally making the interface more accessible.

Interaction Design


Team (Nina Cary, Nick Hays, Pirate Steve, and Teresa Spirek) is attempting to revise the interface to grocery store self-checkout machines, which are becoming increasingly common in grocery stores across the country. They are a very difficult user interface design problem, since they are designed to be used by people walking directly up to them, must be accessible to people with all levels of experience, and the people using them are under social pressure from the people behind them in line. They also have the additional concern that they have to be at least somewhat resistant to people tricking them and stealing groceries.

In this experiment, we're using a paper prototype of a proposed interface replacement to collect data as to how our changes affect people's usage and satisfaction of our interface changes, which included a revised error structure, a few changes to the produce navigation system, and small levels of system learning (though these were difficult to implement in a mostly static paper prototype.)


For running trials, we created a paper prototype of our proposed interface. A full run through of all of the screens and running methods is available in Appendix A.

While we were creating the paper prototype, we attempted to maintain some similarity to the current interface, by using similar colors and button styles. Mostly we looked at the Stop and Shop interface when deciding on colors. As for sizes, we had an 8.5" by 11" paper that we put a "Cancel", "OK" and "Help" button on that would be common to all screens, and then each main screen was made of an 8.5" by 11" paper ripped in half to form two 8.5" by 5.5" sheets, which would overlay on the background to display windows. Props, and physical machinery were made out of words written onto 3" by 5" cards, and we asked users to simply use their imagination.

Some of the screens (most noticeably the produce screens) were actually produced in PowerPoint to give us access to higher quality images where we thought that our sketches would be too distracting. There was some discussion of doing the entire interface using a scripted PowerPoint presentation, however, we stuck to the real paper prototype plan. This allowed us to make changes, and add extra screens as we found they were needed without creating too much of a flow interruption.

While running through the prototype, we typically would separate the screens out into a few piles, one for the introductions screens, which show first, and greet the customer, a second pile for the walkthrough, a series of screens that introduce users to self checkout machines, a pile for the produce screens, a pile for the payment screens, and a pile of other miscellaneous screens (such as the error screens or guidance screens that were created on the fly). The introduction screen would go up first, and when the user started scanning, it would either go to the walkthrough or the main screen, depending on introductory discussions with the users.

The piece of the prototype that caused the most confusion was the physical machinery. We had added a flashing light post-it note to help the users determine which piece of hardware should be getting their attention, but still people had trouble mapping the physical system to the cards. Possibly in the future using a toy checkout machine or something that more closely resembled the real system would have been beneficial. Even a diagram of the system, as opposed to the Purely paper prototyping was not designed for systems with a large physical component, as it only considers the different screens, however, we're also going to need to solve this problem in the hi-fi prototype system.

The second most significant problem we has with the prototype was the number of simultaneous changes due to any action. Since a large amount of information travels between screens, (especially when moving to the main screen), each change would require movement of screens, movement of the pink "flash" post-it, and writing in costs and totals. This would often confuse the user who wanted immediate knowledge as to what was going on, and sometimes confuse the computer, who had to keep track of a large amount of information. These problems will disappear with the hi-fi prototype, as the changes are computerized, so are effectively instant, and a real computer is very good at keeping track of a large amount of information.


We tested the prototype several times (notes from the tests are in Appendix B) with many different users. We had originally desired to test the system with a representative cross-section of users, however, due to time and scheduling constraints, we were only able to test the prototype on members of the Olin community, specifically, two Sophomores, one Senior and a faculty member. We had scheduled meetings with Nina's family (aunts and cousins in the area), however, they were canceled for reasons beyond our control and have yet to be rescheduled.

Though we had a fairly small testing group, and we did not have the selection available to pick and choose a good cross-section of possible users, we believe that the tests we ran found the majority of problems with this design. It also may have been to our benefit that the majority of these people were familiar with engineering and technical systems, as the technical system of this prototype exists entirely in the users imagination, and a non-technical tester would have had more difficulty imagining the system.

When we tested the system, we told the user that they had already completed their grocery shopping. We would give them cards to represent their groceries, a value card, and a few methods of payment, we would then explain to them the principles behind paper prototyping (half of our testers had not seen a paper prototype before. The other half of our testers were very familiar and did not get this overview), and introduce them to our system. They would then be tasked at getting through the interface and purchasing their groceries. We chose the groceries that we gave them (1 lb red apples, one dozen eggs, one gallon of milk and one can of Spaghetti-Os) based both on a recent shopping list of one of the group mates (for realism), and to cover all of the possible tasks.

The first task that the user would typically go through is scanning their card, and the walkthrough. In the pre-test discussion, we would establish if the user had or had not used the system before, and how their behavior was (in one case, we ran through the system twice). This, combined with scanning their card, would affect the behavior of the system as the user proceeded (for example, skipping the walkthrough, which every test user did).

After the user had scanned their card and either run or skipped the walkthrough, they began scanning their groceries, in no particular order. The milk and the eggs scanned without problems every time (see Appendix A for the exact behavior), however, the apples and the spaghetti-os each had their own set of scripted problems.

The apples had the user proceed into the produce section, where they could either enter 'item view' (which shows each item separately), 'category view' (where produce is separated into heirarchial categories) or 'Enter SKU', which is a feature where advanced users can enter the SKU number of the produce (the SKU number is a typically 4 digit number written on stickers on the fruit and displayed on the produce section labels. This is how actual cashiers enter fruit and vegetables into the system for weighting and checkout, and as many users are previous cashiers, or are intelligent enough to figure out the system, giving them the ability to enter SKUs can save them time). This section had the most difficulty with the user not thinking about the physical machine as the interaction proceeded, which motivated the creation of a "Please place your apples onto the scale" popup "window" out of a 3'' by 5'' card. This is actually fairly important, as in the physical system, there are a large number of sensors, attempting to keep users from cheating the system. These sensors and their errors cause the most difficulty when using these systems.

The second somewhat contrived task, was when the user places the can of Spaghetti-Os onto the belt. When the user placed the Spaghetti-Os on the belt, we would describe them as having become stuck while moving towards the bagging area, which would create an error. Since most testers weren't thinking about the actions of the physical system, they would take a few seconds to catch on to what had occurred. The error window would then pop up, instructing the user to remove the item from the belt, hit OK, and then replace it. This, again, caused many difficulties, but since physical errors are the main source of problems in the current system, they were tasks that required testing. This task could likely have been improved if there was more of a physical machine, as opposed to 3" by 5" cards representing the machine's components.

After the user had finished scanning all of their groceries, the final task was to pay for them. Thankfully, we had no users attempt to steal their groceries, or even mislead the machine that they had purchased fewer than what they were leaving with. The payment process was left virtually unchanged from the payment systems we observed in use, which themselves were nearly identical to the payment systems on vending machines or ATMs (for cash or card, respectively). The one change we did make was a 'default' selection for people who had previously used the system and expressed a clear preference.

Test Measures

While conducting our interaction interviews with users, we observed and recorded the entire process but paid special attention to and asked follow up questions about a few key parts of the interaction: the walk-through dialog (or lack there-of), navigating the produce selection menus, and error correction without cashier assistance. For example, the point at which the user declined further assistance in the form of a walk-through was recorded, as well as their reason for doing so in some cases. In the case of the produce menus, the new produce selection and weighing interaction had multiple paths that the user could take depending on preference and this path was recorded by the observer(s) during the interview. Whether or not the user could determine how to fix their own error (in our script, a can caught on the belt) was also recorded for each interview. Much of what we questioned the user about and recorded during the debriefing at the end of the interview was qualitative; dealing with their reactions to and feelings about these key parts of the interaction.


We conducted four tests of our low-fidelity prototype, three with Olin students, and one with an Olin professor. Our raw notes from these tests are included in Appendix B. Because all of the people we interviewed either had a technical background or used technology on a regular basis, our results will be skewed, however, we believe that many of the problems that they face will be common to most people. In addition, they are closer to the target audience of the self-checkout machines, the younger shopper who is only getting a few items.

The first task the users had was to scan their shoppers/value card. Half of them were confused, as we had "VALUE Card" written on the prop, but "Shopper's card" written on the screen. The other two realized that they only had one card, and scanned that. After they scanned their card, a walkthrough, intended to instruct new users on how to use the system would pop up, however, every single test user skipped the walkthrough, two saying that they felt that the "walkthroughs were for idiots". However, most of the users had questions that were answered in the walkthrough process.

No user found the scanning process complicated, and were able to understand and use it fairly quickly once their mental model was complete (realizing what the scanner/scale/belt cards were). However, when we came to the produce process, there were many more complications. Three out of four of the users commented on not being certain what the different options meant (the remaining test user simply clicked the first one that seemed appropriate, without reading). Once they navigated into the produce screen, two out of four were confused by the different options for "Apples". This is concerning, as they had a card that had the text "Red Apples", as opposed to physical apples, which would have required the user to remember what kind of apples they had selected.

Even after they had selected "Apples", two out of four of them didn't know what to do with the apples. After the first two users (who had the problem), we created an error screen instructing the user to place their apples on the scale, and once we brought up the screen, people placed their apples on the scale, and the process continued as we had planned for it.

The one screen that every user had a problem with was the Error screen. The screen wasn't made very well, and didn't tell the users what we wanted them to do. We modified it as we ran more tests, and in the final test, it was actually two screens, each with a set of instructions. However, the user that tried this system was still somewhat intimidated by the error system, and confused as to what to do.

Once the user had entered all of their groceries, three out of four had no problem with the payment system. The final user didn't see the "Pay" button on the main screen at first, and when the user entered the payment screen, they selected an option other than the one they wanted, and didn't realize that they did this. Two users were somewhat disconcerted that the payment screens didn't ask them to OK the charges to their credit/debit cards, however, this was due to the lack of fidelity in the prototype, and so wasn't seen as an interface problem.

Overall, all of the users were able to successfully navigate the system. All of them appreciated the "flashing" around the different parts to indicate what they should be doing at any time, and before it it was added, people wanted audio feedback (a "beep") to indicate when the system had accepted some kind of input. This was added into the later two tests by the computer saying "beep" when it changed settings.

The one component that we were mostly unable to test was the ability of our proposed system to remember different aspects of the user, as linked to their shopper's card. We asked users for comments on this aspect, and all of them said that it would be somewhat disconcerting if the system reconfigured itself (reordering the produce, or certain buttons getting larger) without telling the user why. One user said that he would find it creepy that the stores were storing all of this data on his usage patterns.


In testing our low-fidelity prototype, we learned several things. To begin with, we found it difficult to find people unfamiliar with technology to test our interface. For future tests of our high-fidelity, we expect to put more time and planning into testing a larger part of our user group. In the tests we did run, we learned about a number of specific problems with our interface. These are discussed in more detail, in the context of changes we plan on making to the prototype below. Finally, in some ways, our low-fidelity prototype was so complex, that moving parts around and writing things down and moving that post-it became more important than watching the actions and expressions of the user, especially in the first couple of tests. Our high-fidelity prototype should not be so involved that we lose sight of the user.

Based on results, there are a number of changes we expect to implement in our high-fidelity prototype. To begin with, we aim to purge our new prototype of small inconsistencies; in one such instance, we gave those testing our system a note card labeled "value card", but referred to it as a "shopper's card" on our screens. In making our high-fidelity prototype, we will get another chance to check for these small wording mistakes. We also plan to increase clarity by improving titles and labels on buttons, particularly on the Produce screens, where button labels and screen titles were especially unclear. Also, our high-fidelity prototype will probably not include a detailed walkthrough. Each person testing our system exited out of the walkthrough, yet often went on to ask questions the walkthrough might have answered. Thus, we have concluded including short relevant instructions at appropriate points might prove more effective. Our error messages would also benefit from such added short instruction, letting a user know how they should respond to the error or, at the very least, how to find assistance, rather than only informing them that the system has an error. Next, we think adding audio feedback to indicate success or error for button-presses, scans, and produce-weighing will improve the usability our interface. There were issues with the mapping between pieces of our low-fidelity prototype to a physical self-checkout machine. We may choose to simply focus on the computer screens for our high fidelity prototype if unable to see any way around this particular problem. Finally, to cut down on the "creepiness" of unexplained personalization, we plan to explain that certain features of our interface will be personalized to a shopper's account.

There were a few things our low-fidelity prototype tests were not able to make clear. As discussed above, our prototype failed to map to a physical self-checkout machine. Thus, observing users' interactions with non-screen items like groceries and money did not grant much insight into how they actually interact with those items while shopping. Also, the different parts of the system, like the scanner, the belt, and the scale were not placed in positions or at distances that corresponded to where they would be in a self-checkout system. Finally, each test was conducted sitting down at a table, rather than standing in front of a vertical interface. Next, the only individuals that tested our self-checkout interface were engineering students and an engineering professor. Because of this, we learned little about how someone more unfamiliar with technology might interact with our prototype.

Appendix A: Prototype Walkthrough

Appendix A

Appendix B: Raw User Data

Raw user data, in order that it was collected (some of the problems were fixed between sessions).

Listed by psudonyms generated by the Pirate Name Generator. Names generated using the real name of the interviewee, to make them more memorable.

Appendix B.1: Smilin' Tad Sparrow

2nd Run with Tad

Overall Notes

Appendix B.2: Jelly Legs Agnes


Appendix B.3: Tax-Evadin' Laszlo Dawkins

Post interview thoughts:

Appendix B.4: Pirate Dora the Pink

Who Did what

Kristina Cary:
Test measures, notes on interview B.3
Nick Hays:
Took notes on Interviews B.1 and B.2
Pirate Steve:
Introduction, Prototype, Method, Results, paper prototype walkthrough and compilation/formatting
Teresa Spirek:
Discussion, Notes on interview B.4

Interaction Assessment

Changes Between Lo-Fi and Hi-Fi Prototypes

In revising our system into our high-fidelity prototype, made changes with the following intentions: including relevant customer-instruction where and when necessary (but only then), improving the mapping between our prototype and a functional checkout system, and toning down qualities perceived as "creepy." Though we also discussed what changes might make our Produce-check less confusing, we did not implement these in our final prototype. Due to the number of images and screens and interactions between screens involved therein, we felt our time was better used improving other aspects of our system. To note how our system was limited, we decided to have our produce-button lead to a screen with the options we would have liked to implement. These options included alphabetical order, a customer's most commonly purchased items, produce grouped by category, and an SKU look-up. Our hi-fi prototype also did not include a phone number look-up for shoppers' accounts.

For purposes of customer-instruction, we decided not to include the tutorial, and implement instructional images on every screen instead. These images do not cause extra clicks or spend more of a customer's time, but do stand in as instruction when a customer becomes confused. We also improved error messages, including specific instruction for the customer instead of simply, "ERROR," with an otherwise blank screen. To increase user-confidence that they are using the system correctly we added audio; that is, a beeping sound follows successful scans. Finally, we also fixed those naming inconsistencies found; for instance being told to scan their "shopper's card," while holding a "value card" led to confusion.

Next, we worked on the part of our prototype representing the physical checkout system. By and large, this was not the focus of our project; therefore, we did not make a detailed physical system for our lo-fi prototype. However, users testing our system were unable to follow what parts of the self-checkout system various pieces of paper and 3x5 cards represented. For our hi-fi prototype, our group decided a more detailed physical prototype would have a better mapping to the physical system. A few cardboard boxes, two pairs of scissors, some packing tape, a permanent marker, and one Nina-in-the-Box later, we had a prop that mostly resembled a self-checkout system, complete with a moving conveyor belt. We used a flashlight to light up relevant parts of the machine instead of our lo-fi sticky note. Though fairly complex, changing the physical self-checkout system's interface was mostly not the intent of our project. We made this part of our hi-fi prototype more elaborate in order to add to the test's "reality."

Aiming to make our hi-fi prototype less "creepy," we made a few minor changes. Instead of automatically bringing up your most recently purchased produce items, we made bringing up that screen one of four options; in this way, the store knowing your shopping history is not as immediately apparent, and also more easily ignored. We did not include the most-recently-paid-with feature on our payment screens; as it did not always help the customer and was deemed "really creepy," we decided it took more away than it added to our system.

Heuristic Evaluation

In terms of the categories of changes made, the feedback received from our heuristic evaluators may be broken down in the same manner as changes made to our system: enough, but not too much instruction, correct physical mapping, and the ever important "creepiness" factor.

In terms of receiving enough instruction and feedback from the system to correctly move through checkout, we succeeded for the most part. There was confusion about how to scan the shopper's card. Though the scanning location was highlighted in our system-illustration, more precise instruction may be necessary to make the correct action clear. Other suggestions included including a "help" button and making the "Pay" button more obviously different than that for "Produce." On the other hand, feedback for our color scheme was overwhelmingly positive.

Generally, our heuristic evaluators were distracted by our physical prototype. While it did add to the "reality" of our run-through, it was the only thing those evaluating the system wanted to talk about. I worry that due to such distraction, we missed out on valuable feedback about our electronic touch-screen interface. When the flashlight flickered brightly enough to show up in our well-lit classroom, it seemed to help those testing the system find where to place things. For the most part, though, the improved physical mapping was what really helped people know where to place things.

As far as "creepiness," of our system, it was not a specific characteristic they found particularly alarming, but rather that what they were buying was being kept track of at all. In fact, as we did not include a produce interface in our hi-fi prototype, uses of that information in our interface did not really occur; however, the above was the evaluators' response when we asked where the limits of "creepiness" might be. Using shoppers' cards to track shopping history is not a new innovation from us; rather, it is already characteristic of most of the larger grocery chains and some convenience store chains to have such systems, though usually the only reminder is when coupons print out with your receipt. Thus, while our group feels like we made the right decision in excluding the Know-How-You-Pay feature, we still feel like other parts of checkout, particularly produce would greatly benefit from the use of this information.

Hi Fi Prototype Walkthrough

Hi Fi Prototype Walkthrough

Hi Fi Prototype

Hi Fi Prototype

The Hi Fideltiy prototype requires the user have both Python and PyGame installed.