提示：如果用户通过键盘手动输入条形码，但尚未通过按 Enter 键完成输入，然后尝试扫描另一个条形码，则应该发出蜂鸣声，以便用户可以先接受或取消待处理的项目。
A couple of thoughts from a couple of projects I've worked with:
For the touch screen ensure that each button can be pressed by someone with "fat fingers" as easily as smaller ones (some layouts encourage the use of thumbs at particular locations). Also highlight each button when it is pressed (with a slow-ish fade if you have spare CPU cycles).
Bigger grids are better than smaller ones. The numeric pad should always be in the same place (often the bottom right). The Enter/Tender/etc. "transaction" keys should be bigger than the individual numeric keys - (1) make it more obvious where it is, (2) it will be pressed more often than other screen areas and will wear out (a bigger area will last longer on average; this was more important with older style touch screens; newer technology is more resilient).
Allow functions/SKUs to be reassigned to different grid positions; the layout that works well for one store will likely be wrong for a slightly different one.
Group related functions by colour, but use excellent contrasts. Make sure that the fore/back combination looks good at all angles (some LCDs "bleed" colours left-to-right and/or top-to-bottom angles).
Positive touch screen feedback with sounds needs to have configurable volume and sound sets. Muted tones might be better in an quieter upmarket store, but "perky" sounds are better in a clothing store with louder background music/noise, etc.
Allow the grid size to be specified in percentages or "grid-block units" instead of pixels and draw everything with vectors, etc. since some hardware combinations may have LCDs with better resolution. (One system I worked on was originally specified as 640x480 but shipped at 1280x1024, so my design pre-planning saved a lot of rework later.)
And of course look at the ready-made solutions first (especially if you can get demo software/hardware for evaluation). Although they can be expensive they've often implemented a lot of things that'll you'll have to work through later, and may be cheaper in the long run, even after creating custom add-ons for your system.
Also:
Our UI supported a normal keyboard/mouse combo too (the touchable buttons were just standard button controls sized appropriately). If you pressed a number key it would trigger the same event as clicking the screen-pad button; other hotkeys were mapped to often used button commands (Enter, etc).
If run on a non-POS desktop (e.g. backoffice) the window could be resized too (the "POS desktop" maintained the same aspect ratio, adding dead space at the sides if needed). A standard top menu was available for additional administrative tasks, reporting, etc.
The design allowed everyone to build and test the UI before the associated hardware was finalized. And standard UI testing tools would work too.
Even More:
Our barcode scanners were serial/USB rather than keyboard-like, so each packet from the device raised a comms event. The selected "scanner type" driver class used the most secure formatting that the device could give us - some can supply prefix, suffix and/or checksum characters if programmed correctly - and then stripped this before handing the code up to the application.
The system made a "bzzzt" noise when the barcode couldn't be used (e.g. while cash drawer is open).
This design also avoided the need to set the keyboard focus to a specific entry area.
A tip: if the user is manually entering a barcode via the keypad, and hasn't completed it by pressing Enter, and then attempts to scan another barcode, it should beep instead, so the user can accept or cancel the pending item first.
Based on the above and other literature, here is my list of guidelines for POS design. [it would be nice if we grew this list further]
User Performance Priorities (in order): efficiency (least time to transaction conclusion) effectiveness (accurate info & output) user satisfaction (based on first 2 in work context) learning time (reduce time to learn system by making it simple)
GUIDELINES
Flexible Transaction Building - don't force a sequence to transaction wher possible. Place product orders in any order & allow them to be changed to a point.
Optimise Transaction Rate - allow a user to complete a transaction as quickly as possible (least clicks are not really the issue as more clicks could mean larger value of transaction, which makes business sense)
Support Handedness / Dexterity - most users have a dominant hand and a weaker hand in terms of dexterity. Allow the UI to be customised (on a single click) for handedness. my example: a L->R / R->L toggle button which moves easy features like "OK", "Cancel" in nearer proximity to weaker hand.
Constant Feedback - provide snapshot feedback which describes current state of the transaction and calculated result of transaction (NB: accounts) before & after committing a transaction.
Control "Volume" - control volume refers to the colour saturation/contrast, prominence of positioning and size of a control. Design more frequently used controls to have larger "volumes" relative to less frequently used controls. e.g. "Pay" button larger than "cancel" button. E.g. High contrast & greater colour saturation increase volume.
Target Findability - finding & selecting targets (item, numeric key) is key to efficiency. Group related controls (close proximity), place controls on screen edges (screen edge traps pointer), emphasise control amplitude (this dimension emphasises users normal plain of motion) and colour coding make finding & selecting targets more efficient.
Avoid Clutter - too many options limits control volume and reduces findability.
Use Plain Text - avoid abbreviations as much as possible (only use standard abbreviations e.g. size: S, M, L, etc.). This is especially true for product lookup.
Product Lookup - support shortcuts for regular orders (i.e. burger meal), categorised browsing & item name search (least ordered items). Consider include a special item: this is any item where the user types what is wanted (i.e. specific whiskey order) - this requires pricing though.
Avoid User Burden - the user should be able to read answers to customer questions from the UI. So provide regularly requested/prioritised feedback for transaction (i.e. customer asks: "what will be the the outstanding balance on my account if I buy this item?" It should appear in UI already)
Conversational Ordering - customer drives the ordering not the system. So allows item selection to be non-sequential.
Objective Focused - the purpose of POS is to conclude the transaction from a business perspective. Always make transaction conclusion possible immediately with "Pay" button. If clicked, any incomplete items will be un-done: user then read order back before requesting cash/credit card)
Personas - there are different categories (personas) of users of POS systems like (i) Clerk/Cashier and (ii) Manager. The UI should present the relevant options to that logged-in persona according to these guidelines i.e. Cashier: large volume on transaction building controls; Manager: large volume on transaction/user management controls.
Touch Screens - (i) allow for touch input with generally larger controls to supported a large finger tip as pointer. (ii) Provide proprioceptive feedback - this is feedback that indicate the control pushed (it should have a short delay on it fade: user finger will be in the way initially). (iii) Auditory Feedback (optional) - this helps with feedback especially with regards errors in pressurised environment.
User Training - users must be trained to understand business protocol & how the POS supports that protocol. They are the one's driving the system. Also, speak to POS users to design & enhance your system - again they are experienced users of the POS system
Context Analysis - a thorough analysis of the context of use for your POS system should be performed to best implement the POS heuristics mentioned above effectively. Understanding the user (human factors), the tasks (frequency, duration, stress factors, etc.) and environment (lighting, hardware, space layout, etc.) should be comprehensively conducted during design and should not be assumed. Get your hands dirty & get into the users work space!! That way you can develop something your specific users can use effectively, efficiently and satisfactorily
I hope this helps everyone.
To all respondents, I really appreciate your feedback! Please give me more wrt to this answer. Thanks
I ran across this question, and I thought I'd add my two cents since some of my work has been mentioned here.
I agree with most of what's been said, but it's important to remember that most everything mentioned represents heuristics. That means that while they're good principles to follow, there are likely times when (a) specific rules should be broken, and (b) there will be contradictions between rules. The trick is being able to weigh conflicting principles and apply them to the appropriate degrees (as you noted in a previous comment).
In the end, it's a matter of balancing the business requirements and user needs in a way that produces optimal results. And in the real world, I find that this can never be achieved through heuristics alone.
Here's an example: I recently finished POS designs for Subway, Wendy's, and Starbucks (see Case Studies at POSDesigns.com). All of these designs used solid heuristics, but all of them came out very, very different because of differences in the business goals and requirements, the users' needs and background, the environment in which they work, the technology being used, and a whole host of other differences.
You can never create a great design in a vacuum. For each of the clients mentioned above, I traveled around to a lot of different types of stores in multiple countries to get a feel for how the users' worked, how the systems would be used, how customers ordered, etc. All this information - along with sales and other data provided by the company - was invaluable in creating a highly usable solution.
Here's another example: Guideline #3 you provide previously ("Support Handedness / Dexterity") is fine as a heuristic (though I have to say that I question the conclusion of swapping simply OK/Cancel). But in visiting Subway stores, we discovered that in that context, the location of the register actually plays a greater role in the hand employees prefer.
In other words, registers that were squished against a wall on the right side tended to produce left-handed users, even when the users were right-handed for every other task. This had implications for the way we allowed the UI to be flip-flopped...and who had control of it. There are tons of examples like that, but we never could have achieved the gains that the user interfaces have produced - like 90% reduction in voids, near zero training, increased speed, accuracy, and check sizes, etc. - by following heuristics alone.
One more point (sorry...you've got me going now :-). Many times heuristics are incomplete without more data as to how to apply them. Consider your guideline #11, "Conversational Ordering". There's much more to this guideline than just providing flexibility in order entry. For instance, one of the many things you have to consider is that not all paths should be presented as equally probable.
We analyzed the way Starbucks' customers ordered in various locations across the United States and United Kingdom. Then, we optimized the system for the most commonly spoken patterns. If we had allowed all paths to have the same "volume", we would have sacrificed usability in other areas, since the design would have appeared more cluttered. The new POS system now supports almost all possible order patterns, but the most probable paths are presented at a higher "volume" than those that are less probable.
OK, it turned out to be more than two cents, but the bottom line is this: If you have a chance to visit the environments in which your POS will be used, analyze customer/employee interactions, etc. ...you should take it. Contextual observations and analysis are invaluable in correctly applying heuristics to your situation.
Good luck!
Dr. Kevin Scoresby
FYI - I'd enjoy talking further about this if you or anyone else in the group would like. My office phone number is on my "About Us" page at POSDesigns.com, or you can use the form to initiate an email conversation. Feel free to call anytime during business hours U.S., East Coast Time.
Devstuff already provides some great answers. In addition:
Create a prototype design (can be simply color-printed on paper) and test this in a scenario that is as realistic as possible, i.e. in a store, with a real future user. Enact a few common scenarios and ask the user to really 'use' your prototype as he / she would use the final product. Obtain feedback through interview and observation.
One way to evaluate your design is to check if you have applied the CRAP principles of design. This article discusses how this can relate to user interface design.
In addition to what has already been posted, here are some tips we picked up along the way.
We use two distinct UI's, one for touch-screen with large bold buttons and one for mouse/keyboard entry. the code behind them is the same just the layout is different.
For touch screens
Try not to have pop-up messages that take focus away from the main form, as users may not be looking at the screen, for example if they are chatting with the customer. we found that if this happen users will continues scanning products unaware that they are not been entered into the sale.
If using a bar code scanner be aware that they sometimes send an enter key after the bar code, that will active focused controls (saying yes/no to pop-ups). To help prevent this we disable the enter key-press on buttons, so only a mouse/finger press will fire the click event. we also turn tab stop to false (may be called different in you language), to stop controls that are touch only from getting focus.
As far as colours go we try to stick to bold button and font colours that can easily be distinguished/read in poorly lit rooms and on screens with glare, as most times users are not in the position to move the screen should they have problem reading it.
Anything you can do to speed up/ help the user is a good thing, for example on our payment screen, as well as having 0..9 keys for payment entry, we also have £1,£2,£5,£10 etc so users don't have to add up the money they are given, they can just press the key for each coin/note they received from the customer.
The best tip I can give is to remember that you are designing for a completely different environment form a desktop application, that would be used in an office. and that users may of never used a computer before. since POS systems are usually locked down, try to make it as easy to use out of the box as possible.
another thing to consider is personas (as introduced in cooper's "the inmates are running the asylum").
essentially, you make up a few canonical "users". give them names, hobbies, skills, a picture, and use them as the people you are designing for.
ie:
billy the cashier: has some computer experience (playing on his ps2). he's in high school, may go to community college. he's a primary user of the system, and wants to be able to learn the new system quickly.
cyrus the manager: needs to manage the cashiers. needs a way, with only his authorization, void transactions and be able to review logs of the sales for making reports as well as managing "shrinkage" (theft). he has 2 kids, lives out in the suburbs so has a 45 minute commute; therefore he doesn't want to spend extra time wrangling the system.
you may need three or four personas; any more than that and it becomes hard to design for.
I highly recommend the book "inmates are running the asylum", plus cooper wrote another book: "about face"; which I have yet to read.
I would recommend doing some sort of usability survey amongst your current user group. There is no need for this to be a complicated or highly scientific survey. Present them with simple questions to determine:
The users priority when using the system (accuracy of task, speed, aesthetics)
Preferred input devices
Work flow through such a system
Level of education and domain knowledge
I have found that a lot can be learnt from a simple survey like this and can be applied to your UI design to ensure that the users usability experience is satisfactory.
Great comments from everyone else. I'll just add that there's also an article by Dr. Kevin Scoresby titled "How to Design a (POS) System that Everybody Hates" that discusses usability of POS systems and adds a few points to what people have already mentioned, such as:
Don't punish the employee for customer choices
Avoid creating conflicts with the real world
Avoid color coding (1 out of 10 males has a form of color blindness)
I've also discovered lots of helpful POS design tips at POSDesigns.com. One thing I found interesting is that by focusing too much on the number of button presses, you can actually impact speed--which is often a primary goal. There's also a tip titled "Five Factors that Influence Speed" that I found helpful.
There are already some really good systems out there i.e. Tabtill for Win 8 http://www.tabtill.com or Shopkeep for iOS http://www.shopkeep.com. The fewest number of clicks your user need to do the better. As I am also involved in coding for such solutions and having worked with clients using various POS systems, some can be really frustrating. Remember watching cashiers in a bar tapping 10 times just to take payment for a couple of items, their fingers are hopelessly hovering over the screen trying to find the right colourful button. Keep it simple! Allow sorting of your visible product range, categorize them or use barcode reader. Keep at least 5% gap between buttons and don't let silly animations slow down your UI. Either invent your own or just copy what is already out there with your own twist.
发布评论
评论（9）
来自我参与过的几个项目的一些想法：
对于触摸屏，请确保“粗手指”的人可以像较小的手指一样轻松地按下每个按钮（某些布局鼓励在触摸时使用拇指）特定地点）。 按下时还要突出显示每个按钮（如果您有空闲的 CPU 周期，则会缓慢淡出）。
较大的网格比较小的网格更好。 数字键盘应始终位于同一位置（通常位于右下角）。 输入/投标/等。 “交易”键应该比单个数字键更大 - (1) 使其位置更明显，(2) 它会比其他屏幕区域更频繁地被按下并且会磨损（更大的区域平均持续时间更长；这对于旧式触摸屏来说更为重要；更新的技术更具弹性）。
允许将功能/SKU重新分配到不同的网格位置； 对于一家商店来说效果良好的布局对于略有不同的商店来说可能是错误的。
按颜色对相关功能进行分组，但使用出色的对比度。 确保前/后组合在所有角度都看起来不错（某些 LCD 会从左到右和/或从上到下角度“渗色”）。
带声音的主动触摸屏反馈需要具有可配置的音量和声音设置。 在安静的高档商店中，柔和的音调可能会更好，但在背景音乐/噪音等较大的服装店中，“活泼”的声音可能会更好。
允许以百分比或“网格块单位”指定网格大小而不是像素并用矢量等绘制所有内容，因为某些硬件组合可能具有分辨率更高的 LCD。 （我开发的一个系统最初指定为 640x480，但出厂时为 1280x1024，因此我的设计预先规划节省了后来的大量返工。）
当然，首先查看现成的解决方案（特别是如果您可以获得演示软件/用于评估的硬件）。 尽管它们可能很昂贵，但它们通常会实现很多您稍后需要完成的事情，并且从长远来看可能会更便宜，即使在为您的系统创建自定义附加组件之后也是如此。
另外：
我们的 UI 也支持普通的键盘/鼠标组合（可触摸按钮只是尺寸适当的标准按钮控件）。 如果您按下数字键，它将触发与单击屏幕键盘按钮相同的事件； 其他热键映射到常用的按钮命令（Enter 等）。
如果在非 POS 桌面（例如后台）上运行，窗口大小也可以调整（“POS 桌面”保持相同的宽高比，如果需要，在侧面添加死空间）。 标准的顶部菜单可用于额外的管理任务、报告等。
该设计允许每个人在相关硬件最终确定之前构建和测试 UI。 标准的 UI 测试工具也可以工作。
更多：
我们的条码扫描仪是串行/USB 式的，而不是类似键盘的，因此来自设备的每个数据包都会引发一个通信事件。 所选的“扫描仪类型”驱动程序类使用设备可以为我们提供的最安全的格式 - 如果编程正确，有些可以提供前缀、后缀和/或校验和字符 - 然后在将代码交给应用程序之前将其剥离。
当条形码无法使用时（例如，当现金抽屉打开时），系统会发出“bzzzt”噪音。
这种设计还避免了将键盘焦点设置到特定输入区域的需要。
提示：如果用户通过键盘手动输入条形码，但尚未通过按 Enter 键完成输入，然后尝试扫描另一个条形码，则应该发出蜂鸣声，以便用户可以先接受或取消待处理的项目。
A couple of thoughts from a couple of projects I've worked with:
For the touch screen ensure that each button can be pressed by someone with "fat fingers" as easily as smaller ones (some layouts encourage the use of thumbs at particular locations). Also highlight each button when it is pressed (with a slow-ish fade if you have spare CPU cycles).
Bigger grids are better than smaller ones. The numeric pad should always be in the same place (often the bottom right). The Enter/Tender/etc. "transaction" keys should be bigger than the individual numeric keys - (1) make it more obvious where it is, (2) it will be pressed more often than other screen areas and will wear out (a bigger area will last longer on average; this was more important with older style touch screens; newer technology is more resilient).
Allow functions/SKUs to be reassigned to different grid positions; the layout that works well for one store will likely be wrong for a slightly different one.
Group related functions by colour, but use excellent contrasts. Make sure that the fore/back combination looks good at all angles (some LCDs "bleed" colours left-to-right and/or top-to-bottom angles).
Positive touch screen feedback with sounds needs to have configurable volume and sound sets. Muted tones might be better in an quieter upmarket store, but "perky" sounds are better in a clothing store with louder background music/noise, etc.
Allow the grid size to be specified in percentages or "grid-block units" instead of pixels and draw everything with vectors, etc. since some hardware combinations may have LCDs with better resolution. (One system I worked on was originally specified as 640x480 but shipped at 1280x1024, so my design pre-planning saved a lot of rework later.)
And of course look at the ready-made solutions first (especially if you can get demo software/hardware for evaluation). Although they can be expensive they've often implemented a lot of things that'll you'll have to work through later, and may be cheaper in the long run, even after creating custom add-ons for your system.
Also:
Our UI supported a normal keyboard/mouse combo too (the touchable buttons were just standard button controls sized appropriately). If you pressed a number key it would trigger the same event as clicking the screen-pad button; other hotkeys were mapped to often used button commands (Enter, etc).
If run on a non-POS desktop (e.g. backoffice) the window could be resized too (the "POS desktop" maintained the same aspect ratio, adding dead space at the sides if needed). A standard top menu was available for additional administrative tasks, reporting, etc.
The design allowed everyone to build and test the UI before the associated hardware was finalized. And standard UI testing tools would work too.
Even More:
Our barcode scanners were serial/USB rather than keyboard-like, so each packet from the device raised a comms event. The selected "scanner type" driver class used the most secure formatting that the device could give us - some can supply prefix, suffix and/or checksum characters if programmed correctly - and then stripped this before handing the code up to the application.
The system made a "bzzzt" noise when the barcode couldn't be used (e.g. while cash drawer is open).
This design also avoided the need to set the keyboard focus to a specific entry area.
A tip: if the user is manually entering a barcode via the keypad, and hasn't completed it by pressing Enter, and then attempts to scan another barcode, it should beep instead, so the user can accept or cancel the pending item first.
聚合 POS 设计指南
基于上述和其他文献，以下是我的 POS 设计指南列表。
[如果我们进一步扩展此列表，那就太好了]
用户性能优先级（按顺序）：
效率（交易完成所需的最短时间）
有效性（准确的信息和输出）
用户满意度（基于工作环境中的前 2 个）
学习时间（通过简化系统来减少学习时间）
指南
我希望这对每个人都有帮助。
对于所有受访者，我非常感谢您的反馈！ 请给我更多关于这个答案的信息。 谢谢
Aggregated POS Design Guidelines
Based on the above and other literature, here is my list of guidelines for POS design.
[it would be nice if we grew this list further]
User Performance Priorities (in order):
efficiency (least time to transaction conclusion)
effectiveness (accurate info & output)
user satisfaction (based on first 2 in work context)
learning time (reduce time to learn system by making it simple)
GUIDELINES
I hope this helps everyone.
To all respondents, I really appreciate your feedback! Please give me more wrt to this answer. Thanks
我遇到了这个问题，我想我应该加上我的两分钱，因为这里提到了我的一些工作。
我同意大部分内容，但重要的是要记住，大多数提到的内容都代表启发式。 这意味着，虽然它们是值得遵循的良好原则，但有时（a）特定规则应该被打破，以及（b）规则之间会存在矛盾。 诀窍在于能够权衡相互矛盾的原则并将其应用到适当的程度（正如您在之前的评论中指出的那样）。
最后，这是一个以产生最佳结果的方式平衡业务需求和用户需求的问题。 在现实世界中，我发现仅通过启发法永远无法实现这一点。
举个例子：我最近完成了 Subway、Wendy's 和 Starbucks 的 POS 设计（请参阅案例研究） POSDesigns.com）。 所有这些设计都使用了可靠的启发式方法，但由于业务目标和要求、用户的需求和背景、他们工作的环境、所使用的技术以及整体的差异，它们的结果都非常非常不同。还有许多其他差异。
你永远不可能在真空中创造出伟大的设计。 对于上面提到的每个客户，我走访了多个国家的许多不同类型的商店，以了解用户的工作方式、系统的使用方式、客户的订购方式等。所有这些信息 -连同公司提供的销售和其他数据 - 对于创建高度可用的解决方案非常宝贵。
这是另一个例子：您之前提供的指南＃3（“支持惯用手/敏捷”）作为启发式是很好的（尽管我不得不说我质疑简单地交换“确定”/“取消”的结论）。 但在参观赛百味商店时，我们发现，在这种情况下，收银台的位置实际上在员工喜欢的手上发挥着更大的作用。
换句话说，压在右侧墙上的收银机往往会产生左撇子用户，即使用户在执行其他任务时都是右撇子。 这对我们允许 UI 翻转的方式产生了影响……以及谁可以控制它。 类似的例子有很多，但我们永远无法实现用户界面所产生的收益 - 例如空隙减少 90%、接近零的训练、提高的速度、准确性和检查大小等 - 仅凭启发式方法。
还有一点（抱歉...你已经让我继续了:-)。 很多时候，如果没有更多关于如何应用启发法的数据，启发法是不完整的。 考虑一下您的准则#11，“对话式排序”。 该指南的意义不仅仅在于提供订单输入的灵活性。 例如，您必须考虑的众多事情之一是并非所有路径都应显示为同等概率。
我们分析了星巴克顾客在美国和英国不同地点的点餐方式。 然后，我们针对最常用的说话模式优化了系统。 如果我们允许所有路径具有相同的“体积”，我们就会牺牲其他区域的可用性，因为设计会显得更加混乱。 新的 POS 系统现在支持几乎所有可能的订单模式，但最可能的路径比那些不太可能的路径以更高的“数量”呈现。
好吧，结果超过了两美分，但底线是这样的：如果您有机会访问使用 POS 的环境，分析客户/员工交互等。...您应该采取它。 情境观察和分析对于正确地将启发法应用于您的情况非常宝贵。
祝你好运！
Kevin Scoresby 博士
仅供参考 - 如果您或小组中的任何其他人愿意，我很乐意进一步讨论这个问题。 我的办公室电话号码位于 POSDesigns.com 的“关于我们”页面上，或者您也可以使用该表单发起电子邮件对话。 请在美国东海岸时间工作时间内随时致电。
I ran across this question, and I thought I'd add my two cents since some of my work has been mentioned here.
I agree with most of what's been said, but it's important to remember that most everything mentioned represents heuristics. That means that while they're good principles to follow, there are likely times when (a) specific rules should be broken, and (b) there will be contradictions between rules. The trick is being able to weigh conflicting principles and apply them to the appropriate degrees (as you noted in a previous comment).
In the end, it's a matter of balancing the business requirements and user needs in a way that produces optimal results. And in the real world, I find that this can never be achieved through heuristics alone.
Here's an example: I recently finished POS designs for Subway, Wendy's, and Starbucks (see Case Studies at POSDesigns.com). All of these designs used solid heuristics, but all of them came out very, very different because of differences in the business goals and requirements, the users' needs and background, the environment in which they work, the technology being used, and a whole host of other differences.
You can never create a great design in a vacuum. For each of the clients mentioned above, I traveled around to a lot of different types of stores in multiple countries to get a feel for how the users' worked, how the systems would be used, how customers ordered, etc. All this information - along with sales and other data provided by the company - was invaluable in creating a highly usable solution.
Here's another example: Guideline #3 you provide previously ("Support Handedness / Dexterity") is fine as a heuristic (though I have to say that I question the conclusion of swapping simply OK/Cancel). But in visiting Subway stores, we discovered that in that context, the location of the register actually plays a greater role in the hand employees prefer.
In other words, registers that were squished against a wall on the right side tended to produce left-handed users, even when the users were right-handed for every other task. This had implications for the way we allowed the UI to be flip-flopped...and who had control of it. There are tons of examples like that, but we never could have achieved the gains that the user interfaces have produced - like 90% reduction in voids, near zero training, increased speed, accuracy, and check sizes, etc. - by following heuristics alone.
One more point (sorry...you've got me going now :-). Many times heuristics are incomplete without more data as to how to apply them. Consider your guideline #11, "Conversational Ordering". There's much more to this guideline than just providing flexibility in order entry. For instance, one of the many things you have to consider is that not all paths should be presented as equally probable.
We analyzed the way Starbucks' customers ordered in various locations across the United States and United Kingdom. Then, we optimized the system for the most commonly spoken patterns. If we had allowed all paths to have the same "volume", we would have sacrificed usability in other areas, since the design would have appeared more cluttered. The new POS system now supports almost all possible order patterns, but the most probable paths are presented at a higher "volume" than those that are less probable.
OK, it turned out to be more than two cents, but the bottom line is this: If you have a chance to visit the environments in which your POS will be used, analyze customer/employee interactions, etc. ...you should take it. Contextual observations and analysis are invaluable in correctly applying heuristics to your situation.
Good luck!
Dr. Kevin Scoresby
FYI - I'd enjoy talking further about this if you or anyone else in the group would like. My office phone number is on my "About Us" page at POSDesigns.com, or you can use the form to initiate an email conversation. Feel free to call anytime during business hours U.S., East Coast Time.
Devstuff 已经提供了一些很好的答案。 另外：
Devstuff already provides some great answers. In addition:
除了已经发布的内容之外，这里还有我们一路上学到的一些技巧。
我们使用两种不同的用户界面，一种用于带有粗体大按钮的触摸屏，另一种用于鼠标/键盘输入。 它们背后的代码是相同的，只是布局不同。
对于触摸屏
尽量不要出现将焦点从主窗体上移开的弹出消息，因为用户可能不会看屏幕，例如在与客户聊天时。 我们发现，如果发生这种情况，用户将继续扫描产品，而不知道它们没有参与销售。
如果使用条形码扫描仪，请注意，它们有时会在条形码后发送回车键，这将激活聚焦控件（对弹出窗口说是/否）。 为了防止这种情况发生，我们禁用按钮上的 Enter 按键，因此只有按下鼠标/手指才会触发单击事件。 我们还将制表位设置为 false（在您的语言中可能有不同的称呼），以阻止仅触摸的控件获得焦点。
就颜色而言，我们尝试坚持使用粗体按钮和字体颜色，以便在光线不足的房间和眩光的屏幕上轻松区分/阅读，因为大多数时候，如果用户在阅读时遇到问题，则无法移动屏幕它。
你可以做的任何事情来加速/帮助用户都是一件好事，例如在我们的支付屏幕上，以及有 0..9 个用于支付输入的键，我们还有 £1、£2、£5、£10等等，因此用户不必将他们收到的钱加起来，他们只需按下从客户那里收到的每个硬币/纸币的按键即可。
我能给出的最好建议是记住，您正在为与办公室中使用的桌面应用程序完全不同的环境进行设计。 并且用户以前可能从未使用过计算机。 由于 POS 系统通常是锁定的，因此请尽量使其易于开箱即用。
In addition to what has already been posted, here are some tips we picked up along the way.
We use two distinct UI's, one for touch-screen with large bold buttons and one for mouse/keyboard entry. the code behind them is the same just the layout is different.
For touch screens
Try not to have pop-up messages that take focus away from the main form, as users may not be looking at the screen, for example if they are chatting with the customer. we found that if this happen users will continues scanning products unaware that they are not been entered into the sale.
If using a bar code scanner be aware that they sometimes send an enter key after the bar code, that will active focused controls (saying yes/no to pop-ups). To help prevent this we disable the enter key-press on buttons, so only a mouse/finger press will fire the click event. we also turn tab stop to false (may be called different in you language), to stop controls that are touch only from getting focus.
As far as colours go we try to stick to bold button and font colours that can easily be distinguished/read in poorly lit rooms and on screens with glare, as most times users are not in the position to move the screen should they have problem reading it.
Anything you can do to speed up/ help the user is a good thing, for example on our payment screen, as well as having 0..9 keys for payment entry, we also have £1,£2,£5,£10 etc so users don't have to add up the money they are given, they can just press the key for each coin/note they received from the customer.
The best tip I can give is to remember that you are designing for a completely different environment form a desktop application, that would be used in an office. and that users may of never used a computer before. since POS systems are usually locked down, try to make it as easy to use out of the box as possible.
另一件需要考虑的事情是人物角色（如库珀的“囚犯正在管理精神病院”中所介绍的）。
本质上，你组成了一些规范的“用户”。 给他们姓名、爱好、技能、图片，并将他们作为你设计的对象。
即：
收银员比利：有一些电脑经验（在他的 PS2 上玩）。 他正在读高中，可能会去社区大学。 他是该系统的主要用户，并且希望能够快速学习新系统。
经理赛勒斯：需要管理收银员。 需要一种方法，只需他的授权即可使交易无效，并能够审查销售日志以进行报告以及管理“缩水”（盗窃）。 他有 2 个孩子，住在郊区，所以通勤时间为 45 分钟； 因此他不想花额外的时间与系统争论。
您可能需要三个或四个人物角色； 如果超过这个数量，设计就会变得困难。
我强烈推荐《囚犯经营精神病院》这本书，另外库珀还写了另一本书：《关于面子》； 我还没有读过。
祝你好运！
another thing to consider is personas (as introduced in cooper's "the inmates are running the asylum").
essentially, you make up a few canonical "users". give them names, hobbies, skills, a picture, and use them as the people you are designing for.
ie:
billy the cashier: has some computer experience (playing on his ps2). he's in high school, may go to community college. he's a primary user of the system, and wants to be able to learn the new system quickly.
cyrus the manager: needs to manage the cashiers. needs a way, with only his authorization, void transactions and be able to review logs of the sales for making reports as well as managing "shrinkage" (theft). he has 2 kids, lives out in the suburbs so has a 45 minute commute; therefore he doesn't want to spend extra time wrangling the system.
you may need three or four personas; any more than that and it becomes hard to design for.
I highly recommend the book "inmates are running the asylum", plus cooper wrote another book: "about face"; which I have yet to read.
good luck!
我建议在您当前的用户组中进行某种可用性调查。 这不需要是一项复杂或高度科学的调查。 向他们提出简单的问题来确定：
我发现可以从系统中学到很多东西像这样简单的调查，可以应用到你的UI设计中，以确保用户的可用性体验令人满意。
I would recommend doing some sort of usability survey amongst your current user group. There is no need for this to be a complicated or highly scientific survey. Present them with simple questions to determine:
I have found that a lot can be learnt from a simple survey like this and can be applied to your UI design to ensure that the users usability experience is satisfactory.
其他人的评论都很好。 我只想补充一下，Kevin Scoresby 博士写了一篇题为“如何设计每个人都讨厌的 (POS) 系统”的文章，讨论了 POS 系统的可用性，并对人们已经提到的内容添加了几点，例如：
我还在 POSDesigns.com。 我发现有趣的一件事是，通过过多关注按钮按下的次数，您实际上可以影响速度 - 这通常是一个主要目标。 我发现还有一个名为“影响速度的五个因素”的提示很有帮助。
祝你好运！
凯尔
Great comments from everyone else. I'll just add that there's also an article by Dr. Kevin Scoresby titled "How to Design a (POS) System that Everybody Hates" that discusses usability of POS systems and adds a few points to what people have already mentioned, such as:
I've also discovered lots of helpful POS design tips at POSDesigns.com. One thing I found interesting is that by focusing too much on the number of button presses, you can actually impact speed--which is often a primary goal. There's also a tip titled "Five Factors that Influence Speed" that I found helpful.
Good luck!
Kyle
已经有一些非常好的系统，例如 Tabtill for Win 8 http://www.tabtill.com 或 Shopkeep适用于 iOS http://www.shopkeep.com。 用户需要的点击次数越少，效果越好。 由于我也参与了此类解决方案的编码工作，并与使用各种 POS 系统的客户合作，所以有些解决方案可能真的令人沮丧。 还记得酒吧里的收银员为了几种商品的付款而敲击 10 次，他们的手指绝望地在屏幕上徘徊，试图找到正确的彩色按钮。 把事情简单化！ 允许对可见产品系列进行排序、分类或使用条形码阅读器。 按钮之间至少保持 5% 的间隙，不要让愚蠢的动画减慢您的 UI 速度。 要么发明你自己的，要么只是复制已有的东西并加入你自己的创意。
There are already some really good systems out there i.e. Tabtill for Win 8 http://www.tabtill.com or Shopkeep for iOS http://www.shopkeep.com. The fewest number of clicks your user need to do the better. As I am also involved in coding for such solutions and having worked with clients using various POS systems, some can be really frustrating. Remember watching cashiers in a bar tapping 10 times just to take payment for a couple of items, their fingers are hopelessly hovering over the screen trying to find the right colourful button. Keep it simple! Allow sorting of your visible product range, categorize them or use barcode reader. Keep at least 5% gap between buttons and don't let silly animations slow down your UI. Either invent your own or just copy what is already out there with your own twist.