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:
- 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.
- 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.
- 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.
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.
Posts
2 comments:
In my experience with enterprise ux, the challenge resides in competing priorities with stakeholders in marketing. Specifically around deciding how the web application or service will support customers at a fundamental level. For example, trying to build in multiple personalities into one product when two separate products would serve customers better.
Another fallacy in enterprise thinking is that they only have one shot at success with one giant release. In reality, smaller and frequent releases with a focus on a specific customer need reduces risk if failure. This approach also minimizes costs for the IT arm if the enterprise.
Does that make sense? I don't see it as an IT problem. I see it as a collaboration issue where the enterprise is an octopus that cannot coordinate the motion of all of it's arms.
Michael,
I like the take on double-clicking into marketing requirements. In my take I had lumped them into the business and optimistically assigned them to a business process that needed to be interacted with.
I think you are adding a couple more key insights here actually.
One is that the function of the BPM is not holistically owned by marketing and therefore a web front on an application gets subjected to another set of rules outside of approved process. Secondly the release issue which I completely agree with. I had lumped that under optimization and the need to involve UX professionals directly in that process.
A lot of the discussions I have been in lately indicate that UX teams are simply moved on to the next project and often lack the valuable insight and ability to act on that insight that comes from staying on a project after deployment.
On the IT point, I don't see IT as a problem specifically, especially if they are already working with UX teams directly. I do however see the tension of having different requirements that may be hard to inject after the fact without damaging the vision for the experience.
Great discussion points. Thanks for commenting.
Post a Comment