4 Keys to a Successful Interface Design

One of the most important — though frequently overlooked — aspects of modern touchpanel interface design is the user.

In the world of high-end systems integration, touchpanel control devices are the standard. One of the biggest advantages they offer is customization. You can design the interface anyway you want.

Unfortunately, with this freedom comes the ability to make the interface nearly impossible to understand … or use. So, each design and layout requires some serious thought.

Touchpanel interface design is a very broad topic. So, focusing on the key requirements of a good design is a good place to start.

Interfaces should be intuitive, efficient, consistent and tailored to their primary users. Indeed, while there is technically no right or wrong way to design a touchpanel interface, you will find that nearly every aspect of an effective and easy-to-use touchpanel directly contributes to one or more of those four objectives.

Keep them in mind as the interface is constructed, and they will undoubtedly have a positive effect on the final product.

Intuitive Operation

The word “intuitive” is widely used in the field of systems integration in reference to user interfaces. It is more or less agreed upon that any “good” interface is also “intuitive” to operate. While this is true for the most part, it is important to differentiate between what is intuitive and what is simply familiar.

There are numerous interface design elements that are considered intuitive solely because they are so common. Everyone knows how to use them because everyone is familiar with them. Some of these standards, such as the telephone style layout for a numeric keypad, are very widely accepted and should generally be incorporated.

Some controls, however, are worth experimenting with (transport buttons, for example) in order to develop new and better configurations.

Quite often, that which is familiar can get in the way of that which might come naturally.


Objects should be easily distinguishable from other types of objects on the page. A text field or digital readout, for example, should have a different appearance than an object with which the user interacts, such as a button or slider.

The Apple iPod provides a good example. The iPod’s scroll wheel is a wonderfully efficient way to scan through a large list of information. It could be considered quite intuitive to slide a finger forward or backward, at varying speeds, in order to control displayed information.

Even so, many users didn’t realize how to operate the iPod at first because they had never encountered this kind of touch-sensitive control. Nevertheless, Apple showed people a new way of interacting with a device and, in turn, redefined the “intuitive” standard.

While most systems integrators don’t have the influence over the masses that a company like Apple can have, they can still decide which standards and norms they are going to accept and which ones they will do their own way.

Efficiency

In the realm of touchpanel interface design, efficiency usually refers to the number of button presses required to complete a specific task. As a general rule, no action should take more than two presses to perform.

For example, if the user wants to watch television, it might take one press to select between “audio” and “video” menus and a second press to select “WATCH TV.” Moreover, once the user is watching TV, he should always be just one or two presses away from selecting a different source or turning the system off.

Though violations can sometimes occur (especially when switching between control of A/V sources and environmental controls), the two-presses rule is, generally, pretty easy to follow.

Let’s say the user is watching a DVD, and he wants to adjust the lighting. This operation should be as simple as one press to jump to a lighting control page and a second press to return to the DVD controls after adjusting the lighting.Using the same button location on the screen to perform both page flips enhances efficiency even more. A common practice that should be avoided is putting environmental controls, such as lighting, on the source page itself. While this may seem to improve efficiency by eliminating a page flip, it usually results in a cluttered panel and it will undoubtedly be confusing to the user if the controls appear on some pages and not others.

The only exception to this is on panels large enough for the environmental controls to be somewhat distanced from the source controls, and they should be available from every panel page to maintain consistency (which is covered in the next section).

There is another aspect to panel efficiency that is very important, but quite often overlooked. The interface should be designed to work well on the specific touchpanel device it is intended for. Device attributes such as screen size (not to be confused with screen resolution), how the device is physically interacted with and the location of “hard” buttons are of utmost importance when thinking about the efficiency of your interface.

A panel design that is 320 pixels by 240 pixels that works great on a 6-inch, handheld device might be very difficult to use on a 4-inch, in-wall device of the same resolution because the objects on the screen will be much smaller. Spend time playing with the device you are designing for and take notes on things you notice about it. Is it held with one hand or two? Will it be operated primarily by the user’s thumbs?

If so, perhaps the buttons need to be larger than you would normally make them. In the case of an in-wall or kiosk-style touchpanel, think about at what height the panel will be. Will most users be looking down at the panel or will it be closer to eye-level? If you normally put text labels below the buttons, perhaps they should be above them instead so the user’s finger doesn’t block her view. As you can see, it’s very important to keep the physical attributes of the device in mind as you design your interface.

Consistency

Any well designed touchpanel interface will be consistent in several areas. As mentioned in the segment on efficiency, the location of frequently used buttons should remain consistent across the entire panel. This may seem like common sense for controls such as “volume up/down” and “mute”, but this logic is often forgotten when it comes to controls for individual devices.

Many devices share a common set of commands. Placing these commands in exactly the same location on the panel across all devices that share them will make operation of the interface much easier for the end user. If the user learns that the “channel up/down” buttons are in a certain location for one device, she may be frustrated if those commands are in a different place for another device. This usually occurs when device pages are combined from several projects or a programmer makes pages for a new device without looking back at previous layouts.


The most commonly used buttons should be made more obvious through color or size variations.

This problem can be easily avoided by simply “proofreading” your touchpanel projects carefully from job to job. It also may be helpful to take notes in the form of a spreadsheet that you can refer to every time you create a new device page. This will help to keep button labels consistent from one device to another too.

If you’re not paying close attention, it’s easy to label a page flip button “next” in one place and “more” in another. Not to mention the common mistake of placing a “go back” page flip button in one location on one page and somewhere else on another. It’s important to keep in mind that the overall objective of being consistent between touchpanel pages and projects is to develop a system where learning how to operate one device makes learning subsequent devices much quicker and easier for the user.

Tailoring

This last objective is perhaps the most important because it determines the figurative “tool set” you will have to accomplish the other three objectives. The process of tailoring the interface for its audience, the clients, should begin very early on in the sales process with a meeting between the programmer, and the client. This is another situation where a carefully thought out spreadsheet or checklist of variables to be determined can be very beneficial.

Among other things, this meeting should be used to determine the overall look or theme of the panels. You should discuss what device controls are necessary for the customer and which ones can be eliminated to reduce panel clutter. Perhaps oversized buttons and text need to be used if the client has poor eyesight. Ultimately, the goal of this meeting should be to establish a game plan or “blueprint” for designing the best possible interface for the client in question. Many integrators rely on the salesperson or project manager to gather this information, but most often programmers will ask questions or think of potential problems that their peers will not.

Another key factor in tailoring a touchpanel design for a particular client is determining the style or “skin” that will be used. Most programmers have several templates or themes for their clients to choose from. It is important to make sure that you can achieve all four of the aforementioned objectives with each of the templates you offer.

For example, if one of your templates doesn’t have any oversized, button graphics and a client with poor eyesight requests it, you won’t be able to tailor the design appropriately to that client’s needs. Some projects might require custom pages that need to be created. In this situation it is a good idea to make some simple pencil sketches of what the page will look like before creating the actual interface.

This allows the programmer to give the client a preview of what they will get in case they have concerns or suggestions. Perhaps more importantly, it shows the client that his satisfaction is of utmost importance. Tailoring the interface to the client is no doubt time consuming and depending on the disposition of the client, it can be frustrating at times; but it will almost always pay off in the form of referrals, reduced instruction time and service calls.

There are no hard and fast rules when it comes to designing touchpanel interfaces. Many strong and varying opinions exist on the topic and what works for one user may be completely wrong for another. No matter what an interface ends up looking like, or what techniques were used to devise it, the four objectives outlined in this article will almost always need to be addressed — and the best interests of the client should be the highest priority when addressing them.