Party City Registers Design Problems
For about 6 months last year, ending when the pandemic hit, I was working at Party City to help make ends meet. I noticed that whoever made the registers and other internal tools did not do a great job with the design within the constraints of a retail business.
I tried to figure out who to speak to about this, either at Party City or at the suppliers of the devices in question (Bluebird Corp), but had no luck. Now that I’ve had some time away from that job, I thought I would finish writing up the problems I saw and experienced, along with proposing solutions when I have them.
There were a few different problems.
- The touch targets on most of the touch screens were far too small, even for my petite fingers.
- The text on the touch screens was too small for the distance at which a cashier was typically standing.
- Some of the screens looked very similar, but the same actions that were correct at one would crash the program at another screen.
- Cashiers were to ask customers for their email addresses, but there was no way for the customers to know if cashiers mistyped something.
- The credit/debit card reader’s behavior at various points was very confusing and counter-intuitive.
- Finally — and much less frequently relevant — the interface to access internal tools and websites was very poorly laid out.
Touch targets
Register — lock screen
Here you can see the screen view that a cashier saw when they left a currently logged-in register and it locked.
Now you can see the size of my — fairly petite — pointer finger as compared to the login touch targets. I did intentionally show all of my finger rather than just the pointer just so that it was clearer how much of a difference in size there was.
Many of the other employees had larger fingers, and most were much less computer and touchscreen-literate than I. The store owner basically never managed to hit the password field without stabbing the screen 3 or 4 times, and never remembered that he could use “tab” after he’d filled in his username to get to the password field.
I’m familiar with various tricks to make hitting small touch targets easier (resting my other fingers on the edge of the screen, for example), but I still sometimes missed. Less so for login, and more so for selecting an item’s count to change it. I’ll show that shortly.
Register screen — unlocked and with a transaction
Once a cashier had logged into the register, they were prompted to fill in customer info, as per above.
Once they had either entered a customer’s information (which was itself problematic and will be discussed below) or cancelled out of that popup, they could access the options at the bottom of the screen and behind the popup — see below.
Here you can see what it looked like when an item was scanned.
Continuing with the theme, you can see the difference between the size of the target for the quantity field and the tip of my (fairly petite) finger.
When trying to touch the quantity field, it is clear that the size of my finger vastly dwarfed the size of the field. It was impossible to tell if one had actually hit the place one was aiming for (for reference, once I lifted my finger after the photo above, I had not managed to select that field).
You may also notice that I was resting other fingers on the edge of the screen so that I had a better chance of hitting where I was aiming.
Register Screen — UPC field
Next was one of the most commonly used touch targets after login: the UPC field.
The software on all but one of the registers didn’t realize that if a scanner was used, it should put detected information into the UPC field.
As a result, if one had just adjusted the count of something as per above or by using the Qty field to the right of the UPC field, scanning something would try to put the UPC code into that field. Which rightly complained that it wasn’t a valid quantity, but the software should have known this belonged in the UPC field.
See how much bigger the tip of my finger is than the field?
IPod ‘scan gun’
One of the internal tools was an iPod with tiny touch targets.
It was used for a number of different things, including the printing of sticker labels for various uses. The one that a cashier would most often be performing was that of printing out sample balloon labels: 1) a sticker on a display balloon with a price & short code for requesting the balloon, and 2) the same short code plus the UPC to label the container for the balloon in question.
This touch target was even worse than the register screen — my finger looks gigantic here. The “label #” section was used to specify the size of the sticker to be printed, so the name was very misleading. Given that the size varied depending on if it went on a balloon or on the container that balloons are stored in, one typically needed to adjust it when requesting a sticker label. One also had to remember which number was relevant for a particular sticker type — there was no way to select the use and have the software know what size you need.
There were other areas that were too small, including the menu to select which option one needed at that point in time. I do not have a photo of that, however.
Summary
I think it’s pretty clear here that the touch targets were simply too small. There’s a number of different guidelines on how to appropriately size touch targets for typical touch screen use, none of which seem to have been followed.
Additionally, due to a wide range of skill-set and familiarity, and the typical distance at which a cashier stands, I would bet that we would need even larger touch targets in a point of sales situation compared to most touch screen situations.
Text Size
The text was too small for the distance at which cashiers tended to stand. I was unable to easily explain this distance in a text-and-photos post, and the photos and this section are my best attempt.
In many cases, reading the text at this distance was tolerable, but not ideal. Most notably, if it was something that one was going to see frequently (like the ‘who is the customer’ screen — more visible in the next photo), then the lack of precise clarity was still sufficient.
However, one of the many tasks was to read back an email address to make sure that we had not made mistakes.
I always found myself getting very close to the screen to make sure that I was reading things correctly. This contributed to preventable back and shoulder pain in the cashiers.
I suspect that this was as much about the font type as the text size, but regardless it was not good. I was typically unable to tell the difference between a ‘rn’ and an ‘m’, and ‘l’ and ‘i’ were also far too similar.
I’m not sure what the solution here is, as I do not know enough to choose a good font or text size to read quickly at a distance. I believe that research on this should happen (if it does not already exist for point of sales situations) with people of varying ages, since near vision is one of the first things to go as you age.
Similar screens, wildly different behaviors
This photo shows the view of a logged-in register. I used it earlier to show what a cashier saw before they entered — or skipped entering— customer information.
I am including it here to show the difference between this and a register that has not been logged into. Specifically, you can see a pop-up with a red bar on top, stuff in the middle, and a cancel button off to the right. There is also a bunch of background actions and information visible at this point.
When you hit cancel in this view, you had access to all the buttons and actions behind that pop-up, as well as access to keystroke-based actions (such as the all-important time clock).
Here you can see what the screen looked like on a register that no one had logged into. Just like a register that someone has logged into, you had a pop up with a red bar on top, stuff in the middle, and a cancel button off to the right. Additionally, the background information was exactly the same as for a logged-in register, which implied that it should be just as accessible as before.
Unfortunately, in this instance, ‘cancel’ did not give you access to the buttons and keystroke actions. Instead, it crashed the program.
It is true that the available actions at this screen were not precisely the same as for when one was logged in. For example, there was a time clock button here, as well as two other buttons. However, if one had gotten used to hitting cancel to get at useful actions — as I certainly found myself doing constantly as a cashier — it was hard to remember that it was dangerous to do in this very similar view.
Proposed Solutions
I suggest hiding all the things that one couldn’t access anyway (maybe use a blank or dimmed background behind this pop-up). The line on the bottom showing the register info likely needs to remain visible, however.
I would also recommend either 1) prevent a software crash on cancel and instead provide access to the underlying buttons and keystroke actions or 2) remove cancel altogether.
Email addresses
Here you can see the interface for looking up a customer and adding a new one to the system. You could enter any of email, phone, last name, or party ID.
It was strange that these had the same implied importance in terms of visual hierarchy. I never had someone give me a party ID, and only used organization/last name when someone couldn’t remember which email address or phone number they had used for their account.
Email was the most commonly used identifier, but the customer had no way to see what I typed for their email address. While it’s true that I could repeat it back to them — and tended to do so — entering in an email address and repeating it back takes a lot of time.
Additionally, when it was especially busy it also tended to be loud, which meant that it was easy to have made a mistake even after repeating the address back. When a customer indicated that they had an account (usually because they had a discount of some sort), there was a better chance of finding and fixing a mistake because the system told you when an account didn’t already exist.
Finally, for emails with unusual spellings or which used names that I was less familiar with, the text size problem mentioned above made it harder and slower to read back the email to the customer.
Proposed Solution
Ideally, the screen on which they could see their items and pay for them with a card or other electronic form of payment would let them see what was typed. Better yet, let people type the email address themselves — it’s a touchscreen card reader, so why not add in a keyboard interface for this part?
It would be really handy if existing emails would offer an auto-complete for existing customer matches before one has finished typing. It would also help a lot with the speed of entering these addresses if there were common endings available to auto-complete, such as gmail.com, verizon.net, comcast.net, and yahoo.com.
Duplications and forced customer data editing
After you told the system to do a search (in this case, on my account), it displayed a list of matches. You had to chose even when there was only one match. Email addresses and phone numbers — the two most common ways to find a customer — are by their very nature unique. There should be no need to select an account if there is a single match.
There was also no way to remove duplicates or merge based on name, email, or phone number. Additionally, if one’s name was later in the alphabet than the default name (the store number), the correct one was after the default one and thus took more time and effort to get to it.
Even after selecting an entry, about half the time the system wanted you to take the time to fill in additional information. I’m not sure what bits of information were necessary to allow one to skip having this screen appear. I would have thought that name and email or phone number would have been sufficient, but this did not appear to be the case.
If the minimum requirement for skipping this was the postal address, this makes no sense for an in-person transaction. It interrupted the flow of normal actions and often meant that I accidentally scanned an item while in this screen. Scanned items tended to take the place of a phone number or email address, which then required one to ask the customer to repeat it again to fix it. For some reason, there was no undo (not even CTRL Z using the keyboard worked).
Worse yet, if one was dealing with an account with a postal address, there was a good chance that the system would ask you to select a state. The thing is, in every single case I’d seen this happen, the system already had a zip code. It should have been able to fill this in itself.
When one finally got past these screens, the normal screen for scanning items had a code in the “customer info” field immediately below the empty list of scanned items.
If one realized that they needed to edit customer information at this point, one was brought back to the initial — empty — email address request screen. If you made a mistake or you needed to add a particular kind of discount to the account (such as organizational or military), you had to request the info again. This was frustrating and time-consuming for no good reason.
When one finished the transaction and asked the customer if they would like their receipt to their email, editing the email field to correct a mistake only worked if the customer did not already have an account with the correct email. You couldn’t tell the system that you meant that customer in the first place, and the other email was a mistake.
Confusing card reader
The interface for entering a PIN for a debit card (for which I unfortunately do not have a photo) included a green button that everyone tried to select to continue. Unfortunately, clicking on it treated your card as a credit card instead of debit, and asked you to sign instead of enter a PIN.
Similarly, when you got to the screen above, it looked like you needed to select a payment type. However, as soon as you put a card in, it auto-detected it. It only needed you to select a card type if it couldn’t detect it. Almost every customer I had tried to select a type at this point — entirely needlessly.
Internal Party City page
Finally, the list of actions on the internal party city page was really difficult to distinguish and select from . Everything looked the same, were too close together, and were in no useful order. While there was an order, alphabetical was not a particularly useful order with this many options.
For those of us who were not in management, the one we typically needed to select was “Party School” — number 24 — which is kind of in the middle of the pile of options.
Anytime I saw anyone using this screen, significant amounts of time was spent trying to find the correct selection.
Summary
There were a number of problems with the interfaces that cashiers were using on a regular basis, most of which contributed to fatigue, frustration, and pain due to the actions required to accommodate those problems.
Whether relating to frustration when trying to tap on something, difficulty reading what was on the screen from the most ergonomic distance from the register, or the system behaving as if it needed information from the cashiers or the customers that was not actually required, there were a number of things that I believe could be improved to help those who work there now and in the future.
Time lost to actions that should be easier to perform or are entirely unnecessary is a waste of everyone’s time regardless of how much they are being paid — especially during the busiest times like those leading up to Halloween or graduation.
I wish I had been able to figure out who to send this to while I was still working there, but at least writing this up helped me be a bit less frustrated about it. I wrote most of this while I was still there, but tidied it up for publishing just now.
