Abstract:  Interaction designers sometimes limit their design artefacts to screens and software.  In fact, the most important interactions that take place, between a customer and a business, might not involve software at all.  These need to be designed into flawless, smooth, business process flows and for the software to seamlessly connect to these off-screen interactions.  Ideally, all engineers and business process implementers need some training in and mindfulness of interaction design thinking, so that all customer interactions are designed well and provide a good customer experience.

A lot of what a business does has nothing to do with the forms users fill in and the buttons they push, on a screen, be it through a web, desktop or mobile application.  Much of what your business represents and delivers, to its customers, are human-to-human interactions, loosely associated with your on-screen applications, but outside of its flows.  The value your business provides is in the totality of the customer experience, not just in their interaction with your applications, though your software, if poorly designed, can actually degrade the value of a customer interaction with your company.  Many interaction designers and engineers make the mistake of thinking the entire business is contained and takes place within the software they create.  It doesn’t.

For example, if your business involves the handing over and redemption of keys, the delivery of physical goods, the need to gain access to certain company assets and so on, then when these things happen in the real world, interaction designers need to ensure that there are well-defined and seamless processes available, should things go wrong, so that the customer experience can be remedied, simply and satisfactorily, without undue delay.

Where the company’s enterprise software has to be updated with new information, in response to a real-world transaction, this also has to fit into the software-modelled business process flow, without disruption and provide graceful recovery paths, accessible to the user, should the transaction be in any way exceptional, incomplete or in error.

What is completely unacceptable is to drop the customer on the ground, if the real world transaction doesn’t fit nicely into a pre-defined software application user interaction design.  So-called “happy day” flows are of no use, when things go wrong.  It is possible to anticipate and design interactions to deal with “sad day” user experiences, yet so few enterprises do.

If your enterprise delivers physical products to customers, then the way these products actually work, how hard they are to live with and maintain, and what sort of troubles are encountered, post-sale, are all part of the user interaction with your enterprise.  It matters little if you deliver a slick pre-sales experience, only to inflict the archetypical “product from hell”, which nobody is able to help the customer with, after the sale.  Rest assured that this is likely to be the last sale of a product your company will ever make to this customer.

Out of date and incompletely tested drivers, cursorily dumped on an obscure and barely navigable “afterthought” support web site, mandatory automated software updates that fail and cannot be undone, and impossibly complex parts ordering and service processes are all interactions that are, today, usually designed very badly.  These contribute to sour, bitter, unsatisfactory customer experiences.

The job of the interaction designer is to consider all customer-to-business interactions, especially the interactions that have no software involvement at all.  Unfortunately, this leads to a problem, because many of the implementers of the off-screen processes, or even those that must code the on-screen experiences, have no interaction design skills or training.  This is dangerous, for a business.  It can lead to no design, poor design or highly inconsistent design, for the customer interactions with your business.

Leaving users of enterprise software with no options to remedy an exceptional transaction is the same as losing an otherwise loyal, happy and lifetime-valuable customer.  This applies whether the software is customer-operated (self-serve) or operated by a business representative.

Nothing infuriates a customer more than having to guess which particular ad-hoc rules du jour apply, to any given request or transaction they make with the company.  They also hate having to repeat themselves, or enter the same information at multiple steps in their experience of dealing with the business.  It wastes the customers’ time and it leads to data inconsistencies, when different answers are given to the same questions, through human error, in different parts of the enterprise software.

Worse still is the error recovery workflow that takes the customer on a futile, wild goose chase, which ultimately wastes more of their time, does not solve their problem at all and leaves them with a very poor user experience, unable to complete the transaction they want to complete with the business.

Lastly, if during a customer transaction, “computer says ‘No’”, leaving no possible way to complete the transaction to the satisfaction of the customer at all, even the most forgiving and loyal repeat customer can blow a fuse.  It doesn’t take too much intelligence to realise that something really could be done, but that the remedy is being obstructed by the unnecessarily rigid design of the software orchestrating the customer experience.  Nobody likes being prevented from reaching a sensible outcome, because there is no button to press to permit it, or no form to fill which would enable it.

”Design-led” companies have tried their best to address these failings.  They typically establish a hard demarcation between the designers and the engineers who create their enterprise software, because the skill sets are very different.  The consequence is that the company either winds up with design inconsistency across the enterprise, because separate designers are assigned to different engineering teams, or else you get broad brush stroke design, as a single internal design consultancy tries to serve all engineering teams simultaneously, leaving detailed design to the individual engineers.  Both approaches have disadvantages to the customer.

It’s actually better if every developer is mindful of those user experiences, especially the ones that take place off-screen, instead of leaving it to designated interaction designers, because what possible argument can there be for disregarding the user experience, at any stage of building the technology the business relies on to deliver its value?  The same applies to any related processes.  Everybody needs to be a customer advocate and to see user experiences from the customers’ point of view.  Their individual insights into how customers experience the company are as valuable as those of the designers.

Inconsistency of user experience is still a risk, with this decentralised interaction design approach, but at least the customer is less likely to be totally abandoned, when things don’t go according to the “happy day” plan.  Interaction design guides, prepared by the interaction design authorities, in the enterprise, can go some way toward addressing the inconsistencies in separate user experiences.  A slightly peculiar customer experience is, by far, preferable to an extremely bad one, in any case.

Engineers and business process analysts must embrace interaction design thinking, or else achieving customer experience consistency will become impossible, especially for the off-screen interactions.  When the customer experience of a company becomes bizarre, Byzantine or schizophrenic, customers take their business elsewhere, if a better overall user experience is available.  Nobody needs to tolerate sheer stupidity and nobody likes dealing with an enterprise that appears to be inflexible and bone-headed, due to the poor design of its interactions.  It doesn’t matter how pretty the web site looks.