User interfaces are essential to get right – and that applies to documents as much as to software.
System designers know that good user interfaces are critical to the success of new applications. It’s fiendishly difficult to come up with a new, distinctive approach that’s both visually appealing and highly functional, but it’s essential; a me-too approach just gets lost among the alternatives. However, it’s not enough to present information and functionality options in ways that are perfectly clear to the developers; they have to make sense to the user above all else. What does the typical user want to do, what information does she need, where is she most likely to want to go from here?
Encouragingly, modern hotel management systems designers have taken these principles to heart and have come up with some remarkably improved UIs. Older approaches ranged from a proliferation of simple but confusingly similar grid-style displays to wildly crowded and colorful screens that tried to cover all possibilities on one screen. More current systems combine visual appeal with a useful, usable set of data and options at each stage.
A key driver behind this improvement has been a stronger focus on the role of the individual user, and on his specific needs for specific tasks. The screens provide hints to help him know where he is, how far along he is through any major process and what are the most likely functions he’ll need from that point.
However, that focus often seems to be lacking on Internet booking sites. Sure, there’s a strong awareness of visual appeal, with plenty of gorgeous photography and interesting videos. Too often, though, clunky functionality makes the guest experience frustratingly awkward. Beauty isn’t only skin deep; it also arises from graceful behavior. People may be attracted to a site by its visuals, but it must work the way they want to use it or it becomes ugly in their minds.
I wrote recently about a booking experience where a hotel chain’s website forced me to book a room type I didn’t want even though the property had one that I did, and then tried to make me cancel and rebook when I wanted to shorten my stay by one night. The chain’s goal was to encourage me to book through the website instead of calling the hotel, but the software design sent the opposite message; the site got in my way instead of helping me, and calling the property was the simplest and quickest way to resolve each problem.
If an older reservations system can’t handle a change in length of stay (is this such an unusual request?) could not the website at least be able to hide that fact, running a separate availability check in the background to let the guest know if the change would be possible without throwing him back into the jaws of a system that’s already failed him once? It might be easier to code the software to allow only cancel and rebook, but having developers adopt the mindset of the typical traveler really shouldn’t be that hard. After all, most of them are travelers, too.
It’s not just software, though; every touch point with your customer involves a user interface, and that applies to marketing pieces and sales proposals as much as to any mobile app. As with software design, every piece of such documentation needs to be appealing, and to provide the customer with information they find interesting and helpful – from their viewpoint, not from that of the person who wrote it. Brochures and ads need to present a clear message and an inducement to act, not a confusing array of images and text that has no clear theme or call to action. Amazingly, sometimes it’s even hard to spot a company’s logo in its own ads.
Vendors’ system proposals also often lack a focus on the customer’s viewpoint. A proposal, just like a software application or a marketing piece, is a tool with a user interface, something that clients need to understand and interact with in order to do business with you. As with older system UIs many proposals present either too little or too much information, and are seldom formatted in a way that’s either attractive or useful to the customer. Far too many look like what they are: worksheets intended to help the vendor pull its numbers together, not to present information in the way the client needs it and can best use it.
Some form of internal worksheet is clearly essential to calculate prices quickly and accurately for different configurations, but it’s distracting to expose the client to all the fine detail and arcane calculations that lead up to the final numbers. Some level of background detail can be helpful if it’s clear, complete and relevant, but it’s not the first thing buyers want to know. The fundamentals, the things they need to see right up front, are (a) do you offer everything they asked for in the RFP, (b) how much does it cost to buy, install and support, and (c) do you offer any other options or modules that are specifically relevant to their operation as described?
The latter are always of interest, as they may cover useful functions the client hadn’t been aware of when she compiled the RFP. However, they and their purpose/advantage need to be clearly (and succinctly) described, not just listed with a software-only price or, worse, presumptively included in the proposed total without discussion. The vendor may genuinely believe the extras to be really worthwhile, but the client still has to balance their benefits and costs. It’s strange how difficult it can be to get that information out of a vendor; is it really that hard to think like a customer?
Maybe it is, if you’ve spent too much time too close to your product. Usability testing by someone who wasn’t involved in its preparation can pay as many dividends in documentation as it does in software design.
Jon Inge is an independent consultant specializing in technology at the property level. He can be reached at jon@joninge.com or at (206) 546-0966.
To read more about this experience: please visit the August 9, 2013 Siegel Sez: http://bit.ly/16KONa4
