An interesting, challenging, and fun project that I worked on while at ClubCorp was a system of interactive digital information kiosks. The original concept was the brainchild of the then EVP of business clubs, Dolf Berle, now the CEO of Topgolf, who wanted touchscreen-based kiosks placed within business clubs that allowed members to interact more with their clubs.

The Club Hub concept

The idea was that the kiosks would be “club hubs” of information for customers. They would provide access to the clubs’ calendars allowing member to find events they were interested in attending, provide membership-benefit information, and—eventually—provide expanded services, like making dinner reservations, placing orders, etc. Due to technology and priority challenges, the kiosk project had laid dormant for a year or two, but after successfully launching a redesigned web presence for ClubCorp’s 160 clubs, the project sounded like a great thing to do next.

What did the research say

The first thing I did was dig up and dive into the customer marketing research that was behind to the origins of the concept. There was some revealing data points about information needs that were later incorporated into the final implementation, but no data or insights about form factor, platforms, or use cases. Without those basic requirements, I realized why this application had been dormant, but we didn’t let that stop us. 

Our bootstrapped plan for a kiosk

So, after some research, stakeholder meetings, and a lot of whiteboard-level brainstorming, we compiled a basic plan to what the product would become. The kiosks would be a web-based application that leveraged the website’s recently-deployed content management system. Using the CMS solved a whole host of content and management issues, so that was a no-brainer, but using web browser for the application’s frontend was going to be a tricky solution for a touchscreen. Although the technology stack for the application this isn’t the the point of this article, I’ll just note that we deployed each kiosk using a 1 GB thumbdrive with Gentoo Linux running Google Chrome in kiosk mode. The deployment was really quite geeky cool, but that’s a whole other story.

After about a week, we had a working prototype that was using the CMS as its management tool and pulling data from the system. Luckily, I was able to procure a 46-inch touchscreen computer system (that’s a whole other story too) on which we could be test the app. So, I got a new addition to my office, a giant iPad—that’s what I called it—and a whole lot of new visitors.

Unexpected behavior voyeurism

Since we needed people (users) to start interacting with the kiosk so that our whiteboard assumptions of what the use cases and experience should be could be tested, I invited just about everyone in the company to my office. Over the next few weeks, with the continuous flow of wrangled-up testers, we made iterative changes to the system and it slowly began to become a real product.

The unusual situation whereby so many motivated people with deep industry knowledge and a diverse technology background showing up in my office to check out an in-development large touchscreen application provided me a unique opportunity to routinely and casually observe human-machine interaction. I quickly became aware of my good fortune and began logging the interactions and making notations about those that provided particular significance. In a way, I became a voyeur—a behavior voyeur—in my own office.

User observations and UI iterations

In a short time, I began seeing common patterns of behavior, but the single behavior that permeated across all user subsets was that of what I labeled “reach reluctance.” Let me explain. In our early iterations of the user interface, interaction controls—buttons, icons, etc.—were distributed around the screen. The controls were contextual and positioned relative to the module/component so it was obvious to the user which module they were associated with and controlled.

That control-placement strategy was logical, and from observation and inquiry, users intuitively knew which controls controlled which modules. However, in a “public” setting—my office while I and often others watched, they exhibited a strong reluctance to engage with controls that required them to reach away from their bodies.

About 75% of the time, before a user would reach for a control, they would ask me if engaging a control would yield a particular result. They had intuitively predicted what the control would do before they touched it, but they were reluctant to do it. The behavior pattern became so predictable that I began telling people what controls would do when I saw them looking at them because I knew that they were about to ask. Once I started doing that, I knew I had a behavioral challenge that needed to be solved.

Our solutions

After a few iterations of control placement changes, the final solution was an approach that I named “control consolidation.” This approach moved a module/components controls to a position that allowed them to centrally consolidated. We found that when the controls were relative and visually associated to the module they controlled and centrally located so that engagement did not require the user to reach too far outside of their body frame, reluctance was mitigated.

Secondly, since the physical dimensions of the screen were so large, we created two adjacent “interactivity zones.” Each zone was designed to allow for separate and simultaneous user interactive sessions. Doing this reduced the size of any one area of the touchscreen which inherently required less reaching by the user.

Final word

If you ever find yourself having to design a large touchscreen kiosk that will be in a location where the user will be visible to others or in a public setting, consider incorporating a mix of having multiple interactivity zones and centralizing and consolidating module controls. You’l find that usage metrics will increase and your users’ experience satisfaction will improve.