A client has come to me wanting an interactive installation featuring a large (50"+) touch screen interface, one on a wall, and one built into a table. I've seen lots of touchscreen overlays on the market that work with Mac or Windows, but don't have any firsthand experience with them.

  • What kind of risks or concerns should I know about?
  • What are common and reliable Hardware requirements?
  • Is there a better place to ask this question?

Details about me: I'm an experienced interaction designer & developer (HTML5, and many years before advanced Flash/AS3) and I have some physical computing experience with Arduino and Beaglebone (Wiring/Processing Language) type projects.

I've designed and programed Flash based interactive kiosks for Museums, but it was on existing hardware, and I wasn't involved with setting that part up.

I'm also experienced with furniture design and production including CNC milling, and would like something that I can build into a custom frame rather than an all-in-one solution.

UPDATE: The location will be indoors, in a museum-like lighting environment, and we can actually make suggestions as to lighting needs to some degree.

We're looking at the Multitaction style rear projector display because we'd like to have object detection capabilities, and table style interaction as well, but have no experience with this particular hardware.

  • Interesting problem. Your question is a little too broad to really "answer" right now, so you might want to fine tune it a bit and possibly break it out into more than one. Aug 12, 2015 at 21:42
  • 4
    More a comment of the physical placement of large touch screens than on the hardware. In a past project, we have a 50" touchscreen for browsing product information. It wasn't immediately apparent for some people that it's interactive because it was placed flat against the wall. It looked too much like a digital ad display. Putting a slight tilt makes it more inviting.
    – nightning
    Aug 12, 2015 at 21:42
  • I'm going to a first meeting today, I'll update my question this afternoon with details. Thanks so far.
    – Nilloc
    Aug 17, 2015 at 12:02

3 Answers 3


What kind of risks or concerns should I know about?

When I completed my first kiosk project I neglected to think about the uptime requirements and the boot process. Specifically:

  • what hours will the kiosk run?
  • who will start/stop the kiosk?
  • what happens if the power goes out?

It is critical to pick a platform that you can write an automated boot process for and that can return to a desired state if the power goes out. The kiosk must be able to lose power without corrupting the software, or when it restarts it won't work. If a device ever says "this device was improperly shutdown the last time it was used" then it may be too risky to use as your kiosk platform.

Another requirement to think about is power consumption. Selecting a device that draws little power can save your client a lot of money and make it easier to control the temperature in the room with the kiosk.

Think about a screen saver and how people expect to "wake" a computer where the kiosk will be displayed. Initially, I had my kiosk set to turn the screen blank when not in use. People interpreted a blank screen to mean the device was off! I installed a screen saver and usage suddenly spiked. Be careful of user login habits though because if people are used to pressing ctrl + alt + del to login to a sleeping computer, or a similar key stroke, they may unintentionally launch an administrative mode and get confused or do damage to the running software. It may be worth disabling certain keys to prevent such situations.

Run the kiosk for a week or so before your grand opening. Computers come with lots of alerts, pop-ups, timers, and configurations that run by default. You'll want a chance to catch configurations that ruin the user experience or put the kiosk into a state that it can't be used.

Reviewing a few touchscreen vendor websites, a couple more requirements seem important for your specific touchscreen use case:

  • will the screen be used outdoors in unusual weather?
  • will light or sunlight create glare on the screen?
  • is the screen likely to be struck, hit, or touched with dirty fingers?
  • will the screen be high enough resolution to display a quality image at an arms length, which is a very close viewing distance for a display over 30 inches in size
  • An Arduino Yún can be a nice solution for smaller kiosks, even allowing custom physical controls like buttons, switches, or dials. Aug 21, 2015 at 4:12
  • A Raspberry Pi 2 Model B can make a nice kiosk if configured properly to auto-boot (I'm still learning how to do this). Aug 21, 2015 at 4:13
  • Something like an Intel Compute Stick might make a nice kiosk, especially if it can draw power from the HDMI port. Aug 21, 2015 at 4:15
  • I'm not familiar with large touch screen displays. I did try the Microsoft Pixel and the display was very nice, but the early version I tried didn't have adequate uptime reliability. Aug 21, 2015 at 4:16
  • Planar displays seem promising: planar.com/products/touch-displays Aug 21, 2015 at 4:20

you could use..

Microsoft Pixelsense (previously called Microsoft surface) http://www.microsoft.com/en-us/pixelsense/default.aspx

if you got more space and a more interactive application you could try using combination of a projector and cam or a kinect for motion/body detection


however like nightning mentioned, it depends on the environment as well. projectors work optimally in darker environments.

like in all big projects, another issue is obviously budget.

How many people will be using it. If many people will be using it simultaniusly you could consider multi touch feature on the hardware as well as your application.

  • The MS Pixelsense doesn't appear to be in production any longer. All versions I've seen for sale are used. Thanks for the suggestions though.
    – Nilloc
    Sep 7, 2015 at 14:20

There are a bunch of factors that make designing for large-format touch screens different and interesting, and a lot of them come down to the hardware. Based on your question it sounds like you're still evaluating your options for hardware; until you do, do not expect anything at all from your software (there are so many knock-on effects from the hardware technology that will affect your design that you'll only end up making unreasonable design decisions early on).

From a hardware UX perspective, you mostly need to consider:

  1. Accessibility of the display

    Think about the space the kiosk will be deployed in. What are the lighting conditions? Are you affected by ADA regulations or anything similar?

  2. Do you need multitouch support?

    Multitouch is far from a given on touch screens (some screens are marketed as 2-point multitouch despite being functionally useless for multitouch gestures like rotation due to technical restrictions). In many kiosk environments that's not a big problem, but if you're doing something like displaying a map it's a reasonable expectation that you support pinch to zoom (at least).

    Be aware, too, that there are advantages to multitouch that aren't necessarily immediately obvious. On-screen keyboard performance is dramatically improved with a multitouch screen (not only because of chords—things like Shift+A in one operation instead of two distinct touches—but also because you can receive input for the next key press before the previous one is fully lifted off the screen).

  3. How affected will you be by parallax error?

    This is a tricky one to describe, but I used this diagram on a few previous answers, describing the cause of parallax error on projected capacitive touch (PCT) displays:

    Diagram demonstrating how parallax error arises in a PCT display

    Parallax error is pretty common on large-format screens like kiosks, because for practical reasons the touch surface is often not bonded to the display, but instead to the outside of the kiosk chassis/enclosure. You can often design around this problem but you definitely need to be aware of it, especially while you design the display's orientation and angle of recline.

  4. Do you need your hardware to be waterproof/vandal-resistant/shatter proof/theft-resistant etc.?

    This is one of the key impacts that affects nice kiosk hardware design; the more impervious the unit is from outside damage, generally the less usable it is for normal users. You have thicker glass (affecting parallax), lots of articulated doors/covers on inputs, heavier gauge steel, heavier mounting, etc. that all affect the experience.

  5. What's the heat profile of your environment?

    How hot does it get in normal operating conditions? What about extreme conditions it may experience? Does it get turned off at night when the air conditioners are turned off, or does it run hot all night until they're turned back on?

    Solving this problem often requires internal air conditioners inside the unit which has a substantial effect on both noise and footprint, and can make moisture a factor.

  6. Are the units going to be used unattended or with some supervision?

    A vending machine can't be designed to require an attendant be present, but a self-checkout at a supermarket often has one attendant generally in the vicinity to supervise/cope with exceptions.

    Some kiosks are designed explicitly to replace human staff, others are designed to allow a smaller staff to scale more easily to support more customers (e.g. after hours). Others still are simply a way to provide a more automatic/smart solution to an existing problem to allow customers to solve their problems more quickly. Quite a lot of the time, kiosks are intended to solve problems for, say, 80% of customers so that the human staff can focus on the 20% with specialised needs, but rarely do clients think about what the kiosk will do to differentiate between each kind of customer without frustrating the user.

    Unattended kiosks are much trickier (most of the work you'll do will be handling edge cases nicely), and you need to think about the process of escalation to allow a user experiencing a problem to fix it themselves, report it to someone or work around their problem some other way.

  7. Will the units be used by multiple users at once?

    This naturally affects the design of the kiosk so it can be accessed from multiple sides at once, but that causes the next issue…

  8. How will users queue?

    This is the single most annoyingly underconsidered part of any kiosk development job. Most kiosks will—at some point in the day—end up with a queue of users behind them, hoping to use it. How do you describe to users what the kiosk does from afar so they understand what the line is for? Do waiting users benefit from seeing the current users interacting with the kiosk to learn how to use it, or is that a privacy concern? If you have multiple users at once, do you have multiple queues or some mechanism for pairing/grouping users together? How are multi-user groups handled (e.g. a family where only one person will use the kiosk but the whole family needs to stick together to avoid getting lost)?

  9. What's the maintenance like?

    This is both routine and exceptional maintenance. Think about consumables like receipt paper, cash, printer ribbons. Think about IT trying to diagnose a network issue. How about replacing a dead component? Fixing a paper jam?

    This is the main reason that kiosks are designed as big steel boxes instead of nice, usable flows (because maintenance is prioritised above usability), so you need to have a plan for solving these problems nicely before insisting that the user's needs are all that matters (from experience).

As far as software goes, I've already written up an answer on that, and also a blog article on my company's website. It's long so it's difficult to summarise here, but the main gist of it is that you can't use mobile/tablet conventions in your design because kiosks are designed to be shared by many different users unlike a personal mobile device, and there aren't any standard guidelines to fall back on (because people tend to turn the branding dial up to 11 on kiosk software design). That makes testing super, super important, and it also means you have to quickly communicate to the user what (if any) conventions your software has instead of depending on them leveraging their existing knowledge.

The other (big) consideration is help. If your software is intended to be used for a long time each use you'll want good help. If your software is intended to process users quickly, you'll want very good wayfinding and on-screen demonstration illustrations/animations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.