POSitivity: System Design Report by Philip Jones

Human Factors in System Design: Chris Monk

POSitivity Reflecting on a restaurant computer redesign.

Philip Jones 12/14/2010

Contents System Description ...................................................................................................................................4 System Objective ......................................................................................................................................4 Goals .........................................................................................................................................................4 Information Gathering..................................................................................................................................5 Personas .......................................................................................................................................................5 Persona 1: Casey Robbins, Young Server..................................................................................................5 Persona 2: Jessica Fulton, Bartender........................................................................................................6 Persona 3: Ron Walker, Manager.............................................................................................................6 Design Language...........................................................................................................................................7 Task 1: Serving ..............................................................................................................................................8 Problem Identification..............................................................................................................................8 Design Requirements and Solutions.........................................................................................................9 Task 2: Bartending ......................................................................................................................................11 Problem Identification............................................................................................................................11 Design Requirements and Solutions.......................................................................................................12 Task 3: Managing........................................................................................................................................14 Problem Identification............................................................................................................................14 Design Requirements and Solutions.......................................................................................................15 Recommendations......................................................................................................................................17 Big Ideas .................................................................................................................................................17 Finally…...................................................................................................................................................18 Appendix A: ................................................................................................................................................19 Detailed Personas and Context Scenarios ..............................................................................................19 Server persona:...................................................................................................................................19 Server context scenario: .....................................................................................................................20 Bartender persona:.............................................................................................................................20 Bartender context scenario: ...............................................................................................................21

Manager persona: ..............................................................................................................................22 Manager context scenario:.................................................................................................................23 Appendix B..................................................................................................................................................24 Extra diagrams and figures .....................................................................................................................24 References..................................................................................................................................................24

Introduction System Description Restaurants have come a long way since the bad old days of scrawling shorthand on a piece of paper, manually sending a copy soaring across to the kitchen, and adding up the total in one’s head. There are now dozens of integrated software systems on the market that automate and organize much of the tedium involved in tracking this type of customers. Today’s restaurants use Point-‐of-‐Sale (POS) software that must track checks assigned to a user, print orders to other stations for preparation, print checks with gratuities or split orders, process credit cards or other types of payment, run reports, and track data regarding stock, labor, and sales.

POS software typically displays items and prices in a sale, handles taxes, returns, voids, payments (including credit card processing), layaways, and discounts, generates accounting reports, and tracks inventory. Restaurant POS software allows you to create checks by diner or table, place special orders, track orders per server, move diners from the bar to a table, generate waiting lists, and more. (BuyerZone.com, Inc., 2006)

System Objective Successful POS software ensures that all restaurant employees can perform the tasks relevant to their position. Superior POS software does so through an integrated system that presents users with an appropriate interface, customized to address the idiosyncrasies of each role. In this sort of existing market, the practical way to scope this redesign process will involve iterative usability improvements through user-‐centered design principles, rather than attempting to “reinvent the wheel.”

Goals Goals from a management perspective include painless assistance for servers/bartenders “on the floor,” simple but powerful reporting functionality, and intuitive fine-‐tuning of the POS configuration itself. Servers primarily require functionality that allows them to send potentially modified orders to other employees for food and drinks, recorded by table, and receive payment from the appropriate parties. After “closing all checks,” the employee must record tips for tax purposes and exchange cash with management in order to receive said tips. From behind the bar, employees will need the ability to quickly ring in repeated drink orders (along with occasional food) that may be paid for immediately (with cash or credit) or “tabbed” and settled when leaving. At the end of the shift, tips are totaled and reports are generated, so that the bartender receives the correct amount of tips in cash. The foreseen implementation of the POSitivity system into Nine Toes Restaurant & Bar will attempt to address all of these basic functional needs, while going beyond the basics through a goal-‐directed design process that will seek to interview stakeholders and subject matter experts and incorporate findings into an easy-‐to-‐use, time-‐saving system.

Information Gathering The information necessary to develop an accurate concept of a POS system was largely acquired through interviews with and direct observation of representative system actors. Employees were observed at Hard Times Café Arlington and Eleventh, as well as informally at the Clarendon Grill and Cactus Cantina. Innocuous conversation about existing systems during use was effective at yielding surprisingly compelling information. While the interview team consisted of one man with a notebook and camera, a great deal of relevant data was acquired, informing the underlying assumptions regarding this design project. Restaurant employees that were interviewed included: • • • • • • •

Liz, a server at Hard Times Café Arlington Elizabeth, a server at the Clarendon Grill Justin, a bartender at the Clarendon Grill Mark, a bartender at the Clarendon Grill Sean, a bartender at Ireland’s Four Courts Chris, a manager at Hard Times Café Arlington Chris, a manager at the Clarendon Grill

The three job categories that were encountered seemed to self-‐select into the three tasks that would be explored. While bartenders and servers reported usage of similar functionality, their workflows were markedly different, and customizing the presentation and behavior of several diverging needs will be a major priority. Furthermore, management positions required an entirely deeper branch of functionality, and the differing interaction style will necessitate a relatively different approach.

Personas For full personas and context scenarios, please see Appendix A.

Persona 1: Casey Robbins, Young Server Nineteen-‐year-‐old Casey Robbins enjoyed her freshman year of college, and decided to find a part-‐time job this past summer. She has now worked at Nine Toes into the fall semester, and is annoyed every time she’s scheduled on a weekend night, but appreciates the opportunity for extra cash. She usually tries to get off early to go out with her friends and only works a few times a week, due to her shoe and concert addiction, despite her parents’ support. If only she could figure out how to use the POS system as quickly and efficiently as Tony, she’d love to feel more secure and less worried about pleasing her bosses. She’s perfectly competent with her Macbook and Blackberry but realizes that she probably just needs more experience with the computer. She’s getting pretty good at doing the basic tasks one at a time, but it’ll take a while to get into a rhythm of integrating many tasks into a unified workflow. If a system isn’t messing her up, Casey appreciates feeling

competent when she can intuitively learn what to do, and is generally just happy to get through a task, off the clock, and on with her life.

Persona 2: Jessica Fulton, Bartender It takes a little while to get to know 31-‐year-‐old Jessica Fulton behind her superficially warm bartender personality. Working at Nine Toes for years has not only attuned her to “working” the system, but she’s seen so much employee turnover that she must be impressed enough to have a real conversation. She works four evenings a week, as well as one “long day,” and loves the freedom and unique environment her job offers since she doesn’t have kids to influence her schedule. At closing, Jessica usually claims the physically relieving task of sitting at the computer, entering credit card tips into the computer. She likes to feel useful and figure out how much cash she’ll have left over for to go out with her friends after the power bill gets paid. She’ll often finish off the night at a different bar with a couple coworkers, leaving enough time to sleep before her errands and shift the next day. She feels secure in her job, as the owner likes her and her performance, which relieves her from the feeling of having to go out of her way to please management on every task. Since she’s in a comfortable environment, Jessica’s primary goal is to perform confidently and efficiently. She hates spending forever searching the menu, and is frustrated that the work computer doesn’t operate as smoothly as her iMac. As long as she can rapidly get on and off of the computer hundreds of times without getting in anyone’s way, she’d be happy with a responsive system that makes sense.

Persona 3: Ron Walker, Manager Forty-‐one-‐year-‐old Ron Walker likes the opportunity to run Nine Toes with an emphasis on light-‐hearted productivity. Being a jokester at heart in a full-‐time salaried position, he enjoys the time he spends with long-‐time employees that have become friends. His other main connection is with his two kids, aged 11 and 17, whom he’d love to see full-‐time, though he must split custody with his ex-‐wife. His main priority is to please the owner, but since he usually feels responsible and in charge, there is no need to be overly concerned with the minutiae of everyday business. He’s able to shrug off minor issues, and is only frustrated at high-‐level, inefficient patterns that some of his daily tasks involve, especially when the system doesn’t follow an intuitive workflow. He is grateful that the current version of the software rarely crashes the computer and requires little maintenance, as well as the fact that he’s been able to figure out the style it requires. He would love for the computer to help streamline some of his usual responsibilities, but mainly appreciates a system that “just works” in a simple, consistent manner.

Design Language Development of a design language must be preceded by an understanding of the components of the system at hand. As with the majority of today’s point-‐of-‐sale systems, POSitivity allows interactivity through an LCD touchscreen (for servers and bartenders) as well as a keyboard/mouse combination (for managers). There will also be peripherals including USB credit card scanners and USB receipt printers, as well as connectivity to standard desktop printers. The choice of touchscreen revolves around the two currently popular styles. Capacitive screens, such as that sported by the popular iPhone, have a reputation for being more accurate and more expensive, but will not accept pressure by anything other than a body part. Resistive screens are the cheaper options that accept more input methods (like a pen), but require more pressure and are less accurate. The recommended touchscreen technology is to be discussed at the next stakeholder meeting, and will be considered undecided for the purposes of this report. That being said, this decision has an impact on the range of interface styles available to designers. Advanced touch mechanisms like swiping, pinching, and tap-‐and-‐holding were considered, but ultimately relegated to be secondary, “power user” options, if at all included. The unintuitive, nonobvious nature of these sorts of commands does not seem to be a good fit for new users like Casey that need to “see it to believe it.” Plus, since requiring this sort of style implies that a capacitive display will be present for all installations, it would not be prudent to design any functionality to be exclusively activated in this manner. Every function must be triggered through a single tap or click, though additional input mechanisms may be considered for the purposes of scaling to expert users. The primary motivation in terms of visual design is to avoid the multicolored, haphazard style endorsed by so many competitors. Beyond that, several principles were identified as valuable directions to explore. Primarily, the system should be integrated holistically in terms of visual and interaction design. The use of imagery and minimal color emphasis allow natural relationships and associations to be formed between and among features. Repetition of these elements breeds familiarity and a sense of unity. Experience attributes were developed as a semantic method of clarifying stakeholders' impressions. While considering such essential design characteristics as pragmatic, elegant, and effortless, several broader descriptors were prioritized. The design team is promoting the adjectives reliable, responsive, modern, and obvious as influences in forthcoming design directions. Reliability is of utmost importance in any business setting, and one of the essential precursors to a positive perception is trust in a system’s consistency and ability to function without interruption. Simply put, a system with beautiful design and amazing power will never make it off the shelf if it has a reputation for crashing or introducing major difficulties into owners’ lives. Responsiveness is almost a subcategory of reliability, in that it is rarely noticed until it is interrupted, but this attribute plays a major role in ensuring the connection that a user feels with a tool. Unnecessary pauses, slowdowns, and erratic behavior are sure to frustrate and distract an employee with no time to let computers get in her way.

Modern styling is another gambit by which confidence and satisfaction may be attained. Though some materials in this report are at the level of mockups and the rest could use the influence of experienced graphic design talent, the intent of this project is certainly to align the software one uses in the workplace with the current environment of increasingly sleek and attractive interfaces ever-‐present in the rest of the world. Obviously usable functionality is obvious. As a range of employees spanning the breadth of personalities and cultures in the United States are likely to use this software, it would be irresponsible to obscure functionality behind advanced gestures, menus, or series of commands. The finite scope of allowed actions indicates that each has its place in a well-‐organized interface, and there is certainly no excuse for failing to consider the range and depth of workflow behaviors in this pursuit.

Task 1: Serving Problem Identification Waiting tables is a very common job for people of many backgrounds, so functionality must be presented in the most intuitive and manageable format possible. Formal interviews with servers as well as excessive observation facilitated ideation regarding methods of increasing reliability, responsiveness, modernity, and obviousness. Primary frustrations seemed to be centered on inconsistencies in the relationships between the system and the “real world.” Potential for improvements were also identified regarding large parties (something that has not been specifically addressed in any existing surveyed systems) and the login process. Unofficial statistics indicate that a substantial proportion of orders involve modifications of one sort or another. This is an opportunity for a system to bridge the gap between intention and execution, as several different methods for communicating alterations were identified in interviews. Furthermore, discussions with Liz from Hard Times Café included complaints about difficulties with mapping an order to the physical pickup location–in their case, two different bars serving different types of beer. Too often, systems were often found to limit servers from interacting in an expected manner. For example, several POS systems are unable to begin a new table if that table number is currently assigned and has not been closed, which evokes a situation that tends to arise during transitions between parties. This trait is also evident when servers are forced to use a physical card to login to the system. While this “feature” may save time in some circumstances, more often it will frustrate users who lose or temporarily put down their card elsewhere, must share a login number. The “big idea” in POSitivity that affects server behavior is incorporating accommodations for handling large parties. Issues were often identified where multiple servers are forced to share one user’s login number and physically communicate about the status of the table. Splitting checks is also extremely common in large groups, and proportionally more time-‐consuming and difficult, especially when the software’s gratuity calculations are misleading or unhelpful. Finally, once the shift has ended, the totaled tips from that table (which may be split over several checks and gratuities) must be split evenly to all of the servers that were primarily involved.

Design Requirements and Solutions In broad terms, this concept has already been done by dozens of competitors. POSitivity must go above and beyond to connect the impression that a user takes of the system with that server’s mental model of their job in the real world. This idea sounds easier than it is to implement, and will only be successful if the details are considered. For example, alterations shall be specified using the modifier that fits the situation. These options include the first choice, tapping modifier keys that have been pre-‐defined, as well as the backup option of typing short notes with the on-‐screen keyboard. Finally, a user may simply choose “See Server,” and verbally communicate unique changes. Obviously, this increases the cognitive workload of both the server (who must remember to follow up their ticket with the kitchen or bar) as well as the employee(s) preparing the order (who must coordinate and remember the modification without a visual reminder). In discussions with subject matter experts and interviewees, it was determined that all three types of alteration are used in different scenarios, and it would be unwise to limit users’ options in this all-‐too-‐often-‐seen situation. Thus, the “Modify” button will contain the latter two options as further details alongside a comprehensive list of predefined potential “mods.” The combination of adjectives and nouns in this situation is seen here in a competitor’s version, though the intention for POSitivity is to continue the theme of a top row of function buttons with a scrolling vertical columned list of ingredients. Another detail to consider is the separation of appetizers from entrees. Many systems force the user to add a line with something like “-‐-‐-‐-‐-‐-‐ APPETIZER-‐-‐-‐-‐-‐-‐“ after the starters have been entered, which can not only disrupt the workflow The Modifier popup in the Aloha POS system of entering items in the order they were written down, but also requires deletion of later items if an appetizer was omitted at first. To rectify these shortcomings, a “tagging” system will be implemented, by which a user may assign an appetizer attribute to certain items, which will be printed on a separate, clearly labeled ticket in the kitchen. This removes any need to micromanage the order of entry, as well as proposed solutions involving dragging items around on the screen into an appetizer “bucket.” While this covers a scenario in which a kitchen will receive multiple action items from one order, interviews discussed the need to keep in mind the location of every type of beer when multiple pickup locations are possible. Thus, a subtle visual notation will be added to the background of items that will be delivered at the alternate location. Rather than cluttering every order with “Bar 2” or “Upstairs Bar”

information, a subtle visual difference will remind a new server to walk to a different location, while staying out of the way of an experienced server. Further, experienced users expressed frustration at being forced to close an order associated with a particular table number before being able to begin a new one. Instead of this simple-‐minded protection, a logical solution is to warn the user of the existing check while offering options that align with this foreseen workflow. A popup informing the user that “Table 6 has an existing check” would then offer the options to begin a “New Check” or “Open Existing”, as well as the ability to “Cancel” if the number was mistyped. In terms of the login scenario, the most prudent recommendation is to allow authentication using either a login number or a physical card. Enforcing one or the other appears to limit interaction styles unnecessarily, though the number-‐based login is to be the recommended situation, particularly for servers and bartenders who may login to the system hundreds of times in a shift. Since there may be cases where employees are not to be trusted with watching the manager type in her number or the manager simply has an easier time of keeping a card on hand than a server or bartender might, the card option should remain present.

POSitivity Server interface: Check+Menu screen

Addressing the “Big Idea” of large-‐party functionality requires a modicum of creativity. A primary issue that arose during the design process was that multiple servers are often assigned to the same table, and yet no surveyed system offered the option to assign a check to more than one user. While this will have to be exhaustively tested in prototyping due to potential issues with money-‐ and responsibility-‐tracking, it seems simple enough to offer users the option to share a table, in a similar manner as existing functionality allows transfers between users. Thus, servers may login using their own number, preserving the one-‐to-‐one relationship between a person and their username, and modify a table that they have been offered. This could alleviate issues with splitting tips at the end of the night, particularly if that information was transparently supplied for employees to decide the course of action. Issues identified in untrustworthy gratuity calculations would also need to be addressed. Furthermore, it seems that future iterations of the system could include item highlighting or a note sharing area, to increase communication, particularly in large restaurants when frequent verbal communication may be limited. Finally, a feature that lends itself well to large parties as well as those of all sizes is simplified check splitting. When a server is not notified of a party’s intention of paying separately, it often falls to their memory and records of who ordered what, when dividing the check into subsets. This captures another “Big Idea” by suggesting powerful sorting options. Servers may opt to sort the list of items in the bill by name, price, or entry sequence, while choosing the option to group by item type. Even when just re-‐ entering repeated items, servers may find it helpful to quickly find an item by price or type. This merger of design themes encapsulates the appeal of redesigning a system such as POSitivity around the minutiae of a server’s everyday workflow in order to better serve their needs.

Task 2: Bartending Problem Identification Interestingly enough, interviewed and observed bartenders seem to have less variation in personality and approach than the unlimited range of people that are found waiting tables. Not only have most bartenders been forced to wait tables before being promoted (which improves familiarity with the computer and environment), but they are most often between 25-‐45 years old and place a heavier emphasis on getting to know their customers (as they rely on regular business). Observations such as these were composited into Jessica Fulton, who was introduced earlier as the primary persona considered when making design decisions about a bartender’s needs. She is often frustrated at the amount of time it takes to find a tab as well as the constantly changing appearance of the software interface. While she remembers a certain percentage of her regulars, she has also realized that Nine Toes could do a better job of tracking and accommodating these repeat customers. A major issue noticed during on-‐site observations was that instantly finding a tab is an ongoing design problem. Customers with a tab will order a drink and refer to their last name as a means of identification. Then, the bartender looks through the list of tabs, which defaults to sorting by the time the check began, trying to remember how long that customer has been ordering to get a sense of the specific location to search. Traversing this table may require two dozen taps on a scroll button or awkward fingertip positioning to drag a WIMP-‐style scrollbar left over from the Windows environment.

While it is convenient that swiping a credit card to begin a tab also populates the tab name with that person’s last and first name, it can have a negative impact when certain cards reverse this order and obscure the visual scanning process. This entire process often takes more time than is available, and backs up customers into an ever-‐growing cluster waiting to order. Another “time suck” for bartenders is the visual search for modifier keys or menu items. When a new type of beer or liquor is added, it can often disrupt the spatial expectations that a user relies on when finding the correct button to tap. While this may seem like a minor issue, it sabotages humans’ automatic ability to speed up interactions, and interferes with the consistency and trustworthiness of the system as a whole. On a related note, the lack of consistency in placing cash registers can occasionally hinder employees’ ability to speedily process transactions; again, diminishing the overall perception of the system. Finally, one often-‐missed opportunity is the ability to keep track of customers across multiple visits. Regular patrons in particular are treated as anonymously as anyone, unless the bartender remembers them, and employs the option to offer them “promotional” drinks. Since bartenders can only by nature remember a percentage of regulars (and usually only the ones who actively converse), the quiet or less-‐ dedicated customers fall through the cracks. These and other repeat visitors have no emotional or financial incentive to return, which fails to improve business for the restaurant.

Design Requirements and Solutions While bartending has similar functional needs as serving, the intricacies of this workflow demand particular attention when designing a customized interface. Though each employee will begin checks, repeatedly order food and drinks, and accept payment, the context and frequency of each of these broad tasks differs remarkably when in a bar environment. The implementation of the “Big Idea” of improved sorting and searching functionality addresses perhaps the primary complaint among interviewees. Finding tabs can make up a large percentage of time spent on the computer, so reducing the time wasted on this task could have a dramatic impact on the ability of a bartender to get on and off the computer as quickly as possible. The system shall include functionality to sort as well as search for tabs by first or last name, item, and check number. Furthermore, fields for the first and last names, whether read from a credit card or manually entered, will be separated to avoid entry inconsistencies, and accompanied by a “swap” button that corrects the order of the name. The obvious correction to the issue of inconsistent button placement is to… place buttons consistently. The root cause of this difficulty, though, lies in forcing the manager to design the interface. Any slight adjustment to menu or modifier options inevitably requires the manager to draw a rectangle, label, and place it in an appropriate spot. It is the design team’s opinion that this “layout design for the layman” allows too much fatal freedom in allowing managers to create a shoddy presentation for their team to use. While reworking this complex of a feature will surely require major iteration and testing, this frustration can be ameliorated by fixing the problem at its heart. This will be addressed to a greater degree in the section on management tasks.

The other issue with inconsistency, namely the lack of cash registers at every computer, can be improved in just as simple of a proposed solution: recommending cash drawer placement to accompany every screen. Though this may increase the workload of those employees responsible for ensuring the sanctity of the money and counting it at the end of the night, the restaurant installing this system should attempt to distribute as many cash registers as is feasible. A major addition to the POSitivity system is the proposed loyalty program. The lack of similar ideas at the restaurants visited was identified as a potential area for improving customer morale and repeat business. Customers are expected to be more likely to return where “they know me,” especially if common orders are associated with their information (to support bartenders’ memory of their favorite drinks and food). Further, management will have the option to enable a rewards program based on spending over certain time periods. While this may interact with other specials, it has the potential to be hugely successful in retaining frequent customers. The implementation of this idea is a tricky one; it may be difficult to convince visitors to carry yet another piece of plastic in their wallets. Thus, functionality will exist to store names and final 4 digits from credit cards, for the purpose of matching current business with past without necessarily requiring a customer to remember to bring in a physical loyalty card. Of course, this adds another requirement for security that will be hammered out in testing so that this information is not misused or stolen. If customer trust issues are able to be mitigated, this could likely have the most immediate impact on business, increasing the likelihood that restaurant management will choose the POSitivity software package.

POSitivity Bartender interface: Tab Finder

Task 3: Managing Problem Identification Managing in a restaurant requires use of the resident POS system in a much different style than that of other positions. This is where the software’s power and value proposition lie, and as such, is certainly one of the most important to execute well. The role, by nature, involves configuration and administrative duties, as well as financial and traditionally managerial tasks. Today’s integrated POS systems have brought a level of control over business that is essential for a management team, particularly with multiple locations and perhaps a headquarters. Even when used in a smaller context, this software has the responsibility of keeping a busy manager up-‐to-‐date on the essential statistics and their implications. Of course, a primary type of interaction is still using the computers “on the floor” to assist other employees with access-‐controlled tasks. “Voiding” an item that has already been sent for preparation is not allowed without an explanation, either verbal or written, and a manager must also login to discount or “comp[ensat]ing” a check. A more extreme example of manager involvement was relayed by Chris at Hard Times Café, who complained about the frustration of re-‐opening a closed credit card check. It seems that he must enter his username and password only on the computer in the office, search for and record the 16-‐digit credit card number by hand, and walk to the server station to type it in manually. These sorts of problems are often caused by a server’s mistake, which combined with interrupting the manager urgently may incite friction or stress in the workplace—the opposite of our goal of humane design. A less physical but no less indirect form of interacting with the computers around the building is when adding or adjusting certain elements of the interface, like menu items or modifier options. A toolkit for this sort of customization is required, to allow the manager to add, change, and remove buttons as necessary. What is not required, though, is the failure to guide the design in a usable direction by constraining / assisting (pick one) the user’s options. Perceptions of some systems make it hard to believe that there was any ‘design’ influence in the first place, however, which links this opportunity with the modern experience attribute. In a related vein, the other form of menu alteration occurs when the kitchen or bar runs out of an item, and certain menu items can no longer be ordered. This is generally a manual process of clicking to deactivate each button, relying solely on the manager’s understanding of which items map to each ingredient. If the kitchen doesn’t realize that they’re “86 blueberries” before a server puts in an order for blueberry pancakes, the ensuing scenario of voiding the ticket, apologizing, and receiving an alternate order is usually frustrating for every party involved. The reporting functionality offered by many POS systems could reduce the likelihood of this situation, but since it is not perceived to be easy-‐ to-‐use and worthwhile, managers reported that they don’t keep track of stock with as much granularity as they would like. (As a side note, future exploration is likely to cover the deeper workflow behind keeping track of recommended levels, noticing that a category is low, and placing a phone order to different merchants. Often, a representative of a large supply company will verbally confirm each item in meetings a few

times a week. This process is an opportunity to go deeper into the interactions outside of the restaurant, when dealing with both food and alcohol distributors, but will not be covered in the scope of this report.) Indeed, tracking and reporting functionality is one of the most essential parts of the system. Unfortunately, it is too often presented in a complicated, disorganized interface that offers few options. Managers that were interviewed discussed archiving reports with a hub-‐and-‐spoke interface for switching between them, little sorting or rearranging functionality, and very few options for comparing data over time. Payroll reports in particular were mentioned, as they are generated every pay period (usually two weeks) through a process that requires the manager to hand-‐write numbers on a sheet for the payroll company. These remaining gaps in behavior and presentation underscore the necessity of a thoughtful redesign.

Design Requirements and Solutions While difficulties interacting with the menu-‐and-‐check interface can slow down and frustrate servers and bartenders, the manager’s use of the computer can have a greater impact on those employees and the restaurant as a whole. Attention must be paid to the workflow that currently exists, while imagining both incremental and innovative improvements. The combination of administrative and managerial responsibilities provides a welcome challenge when organizing and designing a tool that gets out of the way and accomplishes its mandate. For the purposes of a manager’s interaction with the POS system when helping employees around the restaurant, it seems prudent to avoid requiring use of a specialized interface. They will naturally be able to access the full functionality of their position whether in the office or using a terminal on the floor. However, access-‐controlled features that affect a specific check, like voiding items off of a check, transferring between tables or employees, and discounting or “comping” a check, should be accessible through authentication via login number or card swipe. For that matter, reopening closed checks should arguably fall in the same category, absolving managers of unnecessary trips to the office. Even better, servers will have the ability to tag items as “To Void” by tapping what would be the “Delete” key (before the order was sent). The manager is able to clear the queue of action items with one swipe, using a simple explanatory overview of recent slips and mistakes. Management is also called upon to customize the menu and modifier interfaces. Desktop graphics software abilities like nudging pixels and freely resizing shapes are irresponsible in this situation, as the layout can be flexible and preprogrammed to handle any number of structural choices. A thoughtfully designed toolkit is to be provided to strike a delicate balance between control over customizations and constraints regarding proper location, sizing, and coloring. While it is not the intent to enforce frustrating, draconian restraints on restaurants with different needs, there is less of a need to express creativity and more emphasis on set-‐it-‐and-‐forget-‐it usability. The day-‐to-‐day impact on software representations of menu items comes when stock levels run low and an item may no longer be ordered. A manager specifies which ingredient is unavailable, and with appropriate prior setup, all menu items requiring said ingredient are rendered inactive. This most often applies to food supplies, though beer kegs often run out during the course of the night, and liquor shortages may impede the creation of any number of drinks. This is an opportunity for advanced

functionality, discussed earlier in the context of extra touchscreen capabilities. Reverse-‐pinching from a menu item offers bartenders the ability to “suggest” that an item is out, which visually discourages but does not disallow other employees from ordering it, and adds it to an action queue for the manager to approve at her convenience. A future version of this software will investigate the merits of adding a pop-‐ over menu to server/bartender interfaces that lists items that have been marked out-‐of-‐stock. Of course, these embarrassing shortfalls can be pre-‐empted by more accurate use of the stock-‐tracking functionality that is inherently more intuitive and less annoying to use in POSitivity. In fact, all reporting functionality has been re-‐worked to alleviate frustrations and allow more powerful actions. While the “Big Idea” of sorting and searching has been implemented in full in this domain, information visualization and comparison options over time are paramount to extracting important trends from the readily available data. Workflow notes, including the stated necessity to manually archive sales and labor reports, suggest that repeated tasks such as these may be done automatically at preset times of the day. The issue of hand-‐writing payroll report templates is easily bettered through options to print this data in the appropriate template for that company’s form. If it were possible to work with the primary few payroll companies, a much better solution might be to upload it online or even auto-‐complete a digital version, but this will remain under investigation for forthcoming iterations.

POSitivity Manager interface: Daily Sales Report

Recommendations As suggested before, successful POS software allows employees to accomplish their daily tasks. Superior POS software does so through an integrated system that presents users with an appropriate interface, customized to address intricacies of each role. In a market that has been stable for at least ten years, the scope of this redesign revolves around iterative usability improvements through user-‐centered design principles. Fortunately, there is no shortage of opportunities to improve upon existing paradigms. Understanding common causes of errors and mental model mismatches can make it easier to minimize them through specific design accommodations. Experience attributes were a major impetus when making design decisions. A reliable system is of the utmost importance when marketing a new software package that will be handling up to tens of thousands of dollars daily. The system must act and feel responsive to continue conveying the sense of trustworthiness down to the end users. Modern influences in the design confidently suggest that the system is up-‐to-‐date. Incorporating obvious characteristics like feature visibility, visual feedback and affordances for scrolling, clicking, and depth perception increases intuition and ease of use. As mentioned before, the interaction style of tapping a touchscreen will stay consistent; there will be no physically complex actions required except for the learn-‐one-‐and-‐it’s-‐done requirement of dragging to scroll. Combining these influences with the subject matter experts interviewed offers a uniquely powerful and well-‐thought-‐out process of creating a brand-‐new version of a POS system that “just works.”

Big Ideas Because point-‐of-‐sale systems have gone through several market cycles, and existing leaders hold a firm grasp in market share, the emphasis for this redesign must be placed on incremental usability improvements in workflow. The goal is to allow for consistent interactions (within a user’s view of the system) within customized interfaces (between different types of users) that are integrated together (into a broader system that assimilates all data). Several “Big Ideas” were incorporated into the design plans for POSitivity. A subtle feature that has been incorporated in numerous areas throughout the software is increased abilities to sort and search through data. From the major impact of this change in check reviewing and management reporting processes, to the consistency of allowing these options wherever tabular data is involved, these improvements bring a sense of modern data management to the grateful fingertips of any employee. Another iterative improvement to usability, specifically for bartenders, is the Tab Finder. While current systems necessitate manually scrolling and visually searching through hundreds of tabs, a separate interface to search by name, check number, and even items ordered provides bartenders with the flexibility of locating the relevant check as fast as possible. This will likely have a huge impact on the amount of time spent on the computer overall, as the all-‐too-‐common check-‐finding process has been found to eat up a large percentage of a bartender’s POS usage. An entirely new idea (in a restaurant context) is the suggestion of a loyalty program. Customers are more likely to return where “they know me,” so supporting bartenders’ memory of their favorite orders

has the potential to be hugely successful in retaining frequent visitors. Further, management will have the option to enable a rewards program based on spending over certain time periods. If the system is successfully implemented in a trustworthy manner, this could likely have the most immediate impact on sales, which in turn increases the likelihood that restaurant management will choose to adopt the POSitivity software package. Finally, another novel concept in the POS domain involves sharing tables among servers. While bar customers are not considered to be associated with a particular bartender (facilitating an even split of work as well as tips), checks opened in a server account are exclusively assigned to that user. Due to the prevalence of parties that are larger than a single server can handle, multiple users have often been accustomed to sharing one person’s login information in order to affect their check. Adding the ability to share tables among users will not only preserve the secure “one user, one login” ideal, but also has the potential to incorporate highlighting and note-‐taking functionality, as well as transparently communicating a greater amount of detail into tips and accounting procedures at the end of a shift.

Finally… The POSitivity system has evolved from vague dissatisfactions with current software into a set of full-‐ fledged design recommendations. This process incorporated information gathered from several subject matter experts into composite personas that offer clarity and insight into user attitudes and behaviors. The subsequent generation and analysis of theoretical context scenarios invites a look inside the day-‐to-‐ day usage of this proposed system, and were mined for details that play an important role in the perception of its usability and value. Notable trade-‐offs included a marked lack of testing for validation purposes. While this system design will involve further mockups and prototypes, real-‐world users have not had an opportunity to interact with proposed designs, and thus the true value of any of these recommendations remains yet to be seen. There is also the obvious necessity of restricting users to only the tools that they require to do their job, and only when access controls allow. Also, in-‐depth exploration of interactions between a restaurant and outside companies has yet to yield results. As it can be exponentially more difficult to influence multiple organizations, improvements to the payroll-‐generating and supply-‐ordering workflows have been limited to future investigation. The design process has prioritized structure and organization in order to present a consistent interface. Building the software around recognition allows for exploitation of prior knowledge and a decreased learning curve that accommodates both novel and expert users. The goal-‐directed design process has certainly had a positive impact on the creation of the POSitivity system, incorporating lessons learned from current systems into experience attributes and several “Big Ideas” that aim to positively impact all employees of a restaurant in their daily work life.

Appendix A: Detailed Personas and Context Scenarios Server persona: Nineteen-‐year-‐old Casey Robbins really enjoyed her freshman year of college, but she realized at the beginning of the summer that it was time to find a part-‐time job. She has now worked at Nine Toes through the summer and into the fall semester, and is annoyed every time she’s scheduled on a weekend night, but appreciates the opportunity for extra cash. Most of the time, she prefers to be one of the earlier servers on the clock, so she can get off earlier to go out with her friends, and because she isn’t used to standing for many hours on end. She usually only works twice or three times a week, partly due to her college career (supported by her parents), and mostly because she’s only financially concerned with her shoe addiction and going to shows. If only she could figure out how to use the POS system as quickly and efficiently as Tony, maybe she could feel more secure about her job, and absolve a few worries about pleasing her bosses. She’s not bad at technology, after all, as she is perfectly competent with her Macbook and Blackberry; she probably just needs more experience on the computer. She’s getting pretty good at most of the basic tasks (entering an order, running a credit card, entering tips afterward), but it’ll take a while to get into a rhythm of integrating different tasks for different tables into a unified workflow. As long as the system responds quickly, Casey appreciates feeling competent and is generally just happy to get through a task and on with her life. Behavior: energetic but low stamina, inefficient, inexperienced but quick to learn, want to please everyone, probably pretty tech-‐savvy, here sometimes for extra cash, may worry about little issues, computer = 80/10/10 drinks/food/money, stand at computer somewhat often for 20-‐150sec, gets off earlier and goes out to party •

•

Demographics: o 19 years old o College student w/ supportive parents o No kids o White Goals: o Fast response o Easy to learn/intuitive o Logical workflow of single tasks:  Enters order  Runs cards  Enters tips o Wants to feel competent

Server context scenario: As Casey arrives at work, she taps her ID code into the computer and confirms that she is working the night shift as a server. She notices on the home screen that Corona and Heineken are on special today, as well as the usual selection of discounted appetizers for happy hour. She cuts fruit in the kitchen, makes a couple dozen rollups of silverware, and walks around her assigned section of tables to ensure that they are all tidy and stocked. Her first few tables are taken care of without incident. She’s excited about the prospects of making money, but still slightly nervous, when she sees a group of sixteen being seated at a few combined tables. Unfortunately, she’ll be splitting the table with Tony, halving her tips. Tony has already approached the table to greet the group and take their drink orders, and is now entering drinks into the computer while Casey fills up sodas and waters. Two of the beers will be served from the upstairs bar, of which Tony was made aware while ordering them. Jessica noticed the printed ticket at the bar service station and poured the beers, allowing Casey and Tony to pick up and deliver all of the beverages. Casey announces the specials for the evening and hastily scribbles the combined appetizer and entrée order on her pad. Tony has identified her as a co-‐server for this check, so it appears in both of their lists of tables, which allows her to enter the order into the computer. The items from the appetizer menu are automatically grouped separately, although she corrects the quesadilla “tag” to an entrée. For most of the special modifications that were requested, she can press buttons for “No”, “Mayonnaise”, and “ALLERGY!”, or “Extra” and “Onions”, but she types in one customer request on the on-‐screen keyboard, and chooses the “See Server” option for a complicated alteration. Once the party has finished their meal, they decide to pay in three groups, which frustrates Casey, because this had not been previously specified. Casey assigns ordered items to different checks, and her frustration is eased by the sorting and grouping-‐by-‐item-‐type functionality. The default gratuity for a party greater than six has been applied and divided by check. Casey accepts and swipes credit cards in the built-‐in reader for two checks, and makes change for the cash payment of the third. She happily enters in the additional tip (on top of the gratuity) that was kindly left by one check-‐signer, and moves on to the next series of tables.

Bartender persona: While she interacts warmly with customers, it takes a little while to get to know 31-‐year-‐old Jessica Fulton behind her “bartender mask.” Since she’s worked at Nine Toes so long, she not only “plays the game,” but she’s seen so much employee turnover that it takes a while for a new employee to impress her enough to have a real conversation. She works four evenings a week, as well as one “long day,” and loves the freedom and unique environment her job offers. She feels secure in her job, as the owner likes her and her performance, which relieves her from the feeling of having to go out of her way to please management on every task. Since she’s in a comfortable environment, Jessica’s primary goal is to perform confidently and efficiently. Her “bad-‐ass” façade was nearly shattered the other day when she had to spend way too much time searching the menu to ring up a Harvey Wallbanger, but fortunately, she saved face with a

clever response. She’s been frustrated with the POS system recently, as she doesn’t understand why the work computer can’t operate as smoothly as her iMac. Like just now—a few guys walked up and asked for three Allagash Whites on “Smith’s tab,” which is frustrating because she can’t sort by name or search for specific items that have already been ordered. At least when it’s a simple order and an immediate cash payment, she only has to walk to one side of the bar to make change from the register. When the bar closes and everyone finds something else to do, Jessica usually sits at the computer, entering credit card tips into the computer. It’s not fun, but at least she gets to sit down at the end of another night. Plus, it feels useful and important to be the one to figure out how much cash she’ll have left over for tomorrow night out with her friends, after the power bill gets paid. She goes over to her best friends/coworkers and idly commiserates about a couple lousy customers, before suggesting a nightcap at the place down the street. Jessica can’t stay out too late, though; she has to work tomorrow… Behavior: good stamina, outgoing, tend to be more sarcastic/cynical, comfortable in setting (no pleasing, work system), probably slightly tech-‐savvy, here quite a bit for bills AND cash, complains about little things but doesn't matter, computer = 70/10/20 drinks/food/money, stand at computer very often for 5-‐10sec, closes and stays nearby to hang out •

•

Demographics: o 31 years old o No kids o White Goals: o Fast response o Efficient, straightforward o Doesn’t need power o Logical workflow o Single quick tasks -‐ Pair of drinks OR food OR run card o At end of night -‐ entering tips, reviewing records, managing and splitting money o Want to feel bad-‐ass and efficient

Bartender context scenario: Good thing Jessica set an alarm for her nap; it’s time to wake up and go to work. After cheerfully parking her SUV in the spot right out front (what a find!), Jessica walks behind the bar and clocks in with the touchscreen. She’s the second-‐to-‐last person on the schedule, so the bar’s business is already in full swing. Jessica recognizes her first customer, but can’t come up with his name. He’d like two Miller Lights and two Alabama Slammers. Jessica confidently pours the shots with flair, cracks open two bottles of Miller, and accepts a credit card: “Open or closed?” she asks. To keep Jim Atwood’s tab open, Jessica presses the appropriate “Tab” button, swipes the card, and corrects the order of the first and last names that were parsed from the card information. The system recognizes Mr. Atwood’s information and favorite

type of beer, and offers a 25% discount on his next round of Miller Lights. The next customer that comes up requests “another Bailey’s,” which Jessica rings up by searching for his tab by the ordered item. When Mr. Atwood and his date come back to order some food, she looks up his tab by sorting by last name and typing the first few letters. He orders a burger, medium well, with no onions and no aioli, while she orders the Asian salad with no peanuts (due to her allergy), both to go. Jessica quickly taps the appropriate modifier keys (which are easy to find due to their consistent placement), as well as the “See Server” key for the salad order, because she only trusts the kitchen to leave out the peanuts if she tells them in person. She closes their tab once the food is delivered, and makes change in the attached cash register. Time for the next order.

Manager persona: Forty-‐one-‐year-‐old Ron Walker likes the opportunity to run Nine Toes with an emphasis on light-‐hearted productivity. He’s tried to run an overly tight ship before when first starting the position, and not only does he not enjoy the time spent there, he’s found that his employees show their appreciation for the chance to be themselves in more ways than one. Being a jokester at heart in a full-‐time salaried position, he enjoys the time he spends with long-‐time employees that have become friends. His other main connection is with his two kids, aged 11 and 17, whom he’d love to see full-‐time. He’s been splitting custody with his ex-‐wife since they divorced six years ago, though fortunately they have a relatively functional relationship that has been forged through a mutual love for their children. Ron certainly values the bonds he’s made in the workplace, as they have helped him through some of the tough parts of his part. His main priority is to please the owner, but since he’s got the basics down to a science, there is no need to be overly concerned with the minutiae of everyday business. His need to feel responsible and in charge is usually fulfilled through his tools and experience. He’s able to shrug off minor issues, and is only frustrated at high-‐level, inefficient patterns that some of his daily tasks involve. The fact that the POS system doesn’t seem to help him through the workflow for things like changing stock and comparing reports can be irritating, though he’s never worked at an establishment whose computer had a thoughtful interface like that. He is grateful that the current version of the software rarely crashes the computer and requires little maintenance, as well as the fact that he’s been able to understand the way it wants him to carry out his common tasks. He would love for the computer to help streamline some of his usual responsibilities, but mainly appreciates a system that “just works” in a simple, consistent manner. Behavior: jokester, prioritize manager-‐bar-‐career-‐young interests, want to please owner: love 'JUST WORKS', know 'what to do'/work the system, here every day on a salary, don't necessarily notice little things (higher-‐level view), computer = handling money/employees/supplies, sit at computer for longer periods, closes and goes home: has to get back in morning •

Demographics: o 41 years old {30-‐50} o 2 kids (17 and 11 years old) o White

•

Goals: o o o o

Consistent response Simple but powerful No maintenance Logical workflow for various admin tasks  Changing stock totals  Generating reports  Balancing employees' money Want to feel responsible and in charge

Manager context scenario: Yawning, Ron flips several light switches and presses the magic button on the coffeemaker. After checking on the prep cooks, giving the restaurant a once-‐over, and sitting in the office checking restaurant supply records and email for an hour, the day begins in earnest. It’s Sunday, so he helps Jessica set up the TVs for NFL football, and contentedly watches the pre-‐game show. Once the rush [of customers] hits, he helps seat customers around the restaurant and in the bar. His usual expectation is to be able to hang out and watch his favorite team, the Philadelphia Eagles, while being periodically summoned for assistance with the computer. In fact, here’s Casey now, wearing a “don’t be mad” face. She needs help voiding an accidentally-‐ ordered item, as well as transferring an item from one check to another. Since she added these items to her “Manager To-‐Do List,” there is no need for Ron to ask “which table, which item, moving to which check?” and he simply swipes his card after reviewing the planned actions. He notices that there’s food up in the kitchen window, and continues to fill in the gaps, expediting it and running some himself to the bar counter. When he gets back to the kitchen, one of his cooks notifies him that the kitchen is out of Old Bay seasoning. “No, we’re not,” Ron grins, “check on top of the fridge. I saw on the Recommended Order report that it’d been a month since we last ordered it, so I got a backup in yesterday.” The cook retorts that they failed to foresee the more-‐than-‐usual demand for blueberries that day, which reminds Ron to update the computer, marking this ingredient as out-‐of-‐stock. This propagates throughout the menu, which “86’s” blueberry pancakes and ice cream with a blueberry topping, disallowing employees from ordering these. Once the last customers have filtered out, leaving the bar in triumph or disgust at their favorite teams, Ron ensures that Jessica and Tony are working on their final side work, or shutdown routine. He sits in the office, checking out the Daily Sales report, which offers the option of comparing today’s outcome with recent days, as well as recent Sundays, numerically and graphically. “How much are these deadbeats costing me?” he muses sardonically, glancing through the Labor Cost report. Finally, he decides that it’s time to go home, so he clicks the Close Day function, which displays and archives final reports. Locking the doors, he reflects on the opportunity on Sundays to get home early enough to see his wife and kids, and prepares for another long week.

Appendix B Extra diagrams and figures

References BuyerZone.com, Inc. (2006). Point of Sale (POS) System Buying Guide. Retrieved Oct 14, 2010, from http://pages.ebay.com/buy/guides/point-‐of-‐sale-‐pos-‐system-‐buying-‐guide/