Realistic expectations for enterprise user experience

Back in 2009, I started to tackle the problem of slow adoption for user experience methodology and design thinking in the enterprise and government.  While both enterprise and government had unique needs from a UX perspective, it quickly became clear to me that they had more in common with each other than all other UX areas of practice, i.e. internet startups, media companies, mobile applications, etc.

Ultimately the craft and tools are the same regardless of where it is applied. The difference I am referring to between enterprise UX and consumer applications is perhaps akin to the differences one might find between a commercial aircraft and a two-seater prop plane.  Inevitably in different domains there are a unique set of constraints and complexities that come with designing application interfaces and these are magnified when we expand across the spectrum of an intended user experience.

The second part of the complexity in the enterprise domain is that there are a significant percentage of people in leadership, marketing, product and development roles who do not believe user experience is important at all.  Perhaps rightfully so, given their role and the company they work for, they focus instead on cutting cost out of the supply chain, reducing the cost of taking products or services to market and speeding projects out the door in order to maintain competitive footholds.  Let’s put that thought aside for now, mostly because there are a growing number of business professionals who do see great experiences as differentiators, design thinking as a way to either save or grow a company, and user experience as the evidence of a broader focus on great customer experience.

UX professionals may be partially at fault for this problem in the enterprise – the purity of craft and focus has lent itself to disregard for the complexity of the realization for the ‘user at the center’ edict that they work so hard to craft.  Few user experience documents, wireframes or prototypes come with a set of options to make it easier for IT to implement nor safer for the business to adopt.

Having realistic expectations is left to the overall owner of the project who now sits between three equally squeaky wheels each with unique problems, constraints, needs and goals that are often at conflict with the user.  Registration forms, for example, are consistent and constant proof of the tension between UX, IT and business needs.  At the simplest level here are three distinct views I have seen come up again and again in discussions about a registration form:

1. Business: The business would like to capture as much data as possible, generally in order to qualify that someone is a lead or valid customer.  Much berated fields like household income and company size are examples of a business need.
2. IT: Technologists may want the form to be completely distinct and separate from customer databases from an architectural perspective.  This is a measure of protection for customer data and avoids expensive look-ups and connections to back-end systems.
3. Users: Users want as few fields as possible, auto-population wherever possible and no personally identifying information whatsoever , until such time as they are actually providing that out of necessity. i.e. shipping address.

I honestly believe that the best way to establish guidelines for effective adoption of user experience within the enterprise is to consistently balance the needs of the 3 groups from the onset.  Over time this has the effect of actually seeding user-centric capabilities into IT systems and business processes, and has the short term effect of quickly arriving at needed approvals to move forward with projects.  A project that is well heeled in the corporate culture that funds and supports it, is not only more likely to see the light of day, it is actually more likely to succeed and to be revisited and optimized over time.

There is already an expectation for agility between the business and the needs of IT.  BPM and SOA already co-exist; in fact many thoughtful leaders (how I like to think of thoughtleaders) argue that the two are inextricably bound together in all successful IT departments that serve global, profitable companies.  Now we add this new complexity of pure customer focus and the craft of user experience.  Fortunately there are two associated skillsets and outcomes that help with the translation of need to expectation and its resulting outcome.

Between UX and IT we need to establish and observe guidelines for Information Architecture.  This ensures IT has a voice in the realization of great experience and ensures that users have a voice with the systems they interact with.  Done correctly, IA frees the flow of user information in exchange for information assets and digital properties in a harmonious trade-off of complexity and utility.
Between UX and the business we take advantage of existing business processes (BPM) to build models of ideal interaction and this is the point of inflection for Interaction Design to assert it’s command and control over unruly processes.  When we design beautiful interfaces and adopt familiar metaphors for interaction, this serves as a dialect for success and turns the infinitely complex into the seemingly effortless.

In the middle of these three distinct and different worlds is the land of realistic expectations – the acceptable complexity for users, the attainable throughput for business, and the desired governance for IT.  If three shake hands first and agree to disagree where necessary then we have a path for enterprise user experience that should prove successful – interaction after transaction after optimization.

Businesses with customer experience managed.
IT teams with wildly successful, instantly adopted applications.
Customers that are engaged and pleased with the way their goals are being met.

I find it both notable and no accident that from an enterprise perspective Adobe is building a story for customer experience management with a strong focus on user experience that is enterprise class, on a legacy of BPM leadership and on top of a set of enterprise server products that are built with and support the best practices of SOA.