Feature
In today’s IT alphabet soup, why would something as ordinary sounding as “customer experience” become a hot topic?Haven’t “customers” always experienced using computer systems?So what’s different?
The answer lies partly in the Internet’s evolution from information resource to transaction platform, and partly in its transformation from “system-centered” to “user-centered.”
Growth of the Transaction Internet
Historically, the Internet was like a virtual library.If you found what you wanted, fine; if you didn’t, you kept looking or gave up.User experience was a “soft variable” and if users didn’t succeed, they seldom complained.
Then, in the 90s, the Web evolved from information/research tool to transaction platform including functions previously available only via mail, phone or at the “next window please.”
Beginning with simple e-Commerce, the Internet expanded to new accounts, licenses, contributions, payments, permits and all manner of transactions.Unlike research, when transactions fail, there are tangible impacts, some quite serious.
Rise of the User-Driven Web
Beginning with Web 2.0 in 1999, the Web refocused Internet based systems from designers and managers to users and consumers. Users began to demand systems that function as they wanted, and were willing to retaliate when things didn’t go as they expected. This changed the way system developers had to approach their design and development efforts.
Needed: A New Development Model
Web development, from it outset, had been a “soft system” activity largely lacking design or development rigor.
But with user demands escalating and organizations adding more transactions to their Internet presence, increased rigor in the Web development process became mandatory.With little available on the Web-centric side, it was only natural to look to the business system community and it’s stable of rigorous, proven development methodologies.
The Web system community began applying various system development tools to their tasks … with end-to-end results often less than they had hoped for.What could be wrong?
The answer has only lately become clearer: the methodologies work as they should, but the challenges they face often fail to meet the core assumptions on which the methods are based.
Finding Rigor in a Messy Content Life Cycle
Unfortunately, the content life cycle with which Web-based systems must deal doesn’t come close to the level of predictability or symmetry possible, or expected, in business systems, including the following:
- Business system design is normally controlled by the designer, but Web-based systems are often controlled by their intended users and, to a lesser degree, by the providers of the information involved.
- Business systems, supply chain management, A/R-A/P, payroll, etc., are normally internal to their organizations; every involved group is expected to help make the system successful, but Web-based systems must often deal with outside users and providers, with their own goals, preferences and prejudices; and with a range of computer savvy and resources from high to virtually none.
- Business systems are often -- and previously always -- designed with an implicit assumption that a support group will be available to help users cope with system problems, but Web-based systems increasingly cannot assume that level of support, requiring that whatever support the user gets is built into the system.
Getting the Context Correct
Facing the two-headed monster of uncontrollable providers and users on one side, and the need for rigor in system design on the other, the Web world has struggled, often ignoring whichever side the particular designers are least familiar with.
In truth, both must be accommodated in a single project; and both can be by dealing with each in the right way and order.
Projects first need in-depth understanding of both user and provider populations.This must be done first, probably meeting neither the criteria for application of classical system development methodologies nor the usual timelines assumed in software development efforts.
Users in the Driver’s Seat:
In a world where systems are increasingly defined by what users want; users become the drivers that define system requirements.Knowing about them is critical, including:
- Who and where they are and how this affects the nature of systems they are asked to use.
- What they want from the system; do you have it, and what they are likely to do if they have difficulty using the system successfully.
- What range and predominant level of computer savvy they present and what levels of help they will need to complete transactions successfully.
- What, if any, level of motivation they have to use the system, and how much, if any, control can you exercise over their use of your systems. A good starting point is “little or one.”
- The impact of their failure to use the system successfully -- on them and you; will they take their business elsewhere; will they complain; will they sue; will they give up, miss deadlines and pay fines or late fees?
Any of these outcomes will be bad for both them and you, and you must anticipate them in your design.
This partial list of characteristics may sound pretty straightforward, but it can be complex and difficult to determine with any level of clarity.One thing is for sure, it isn’t an afternoon session with the IT group where rank assumptions are made before the effort charges off into the unknown.
Moreover, it isn’t something you can ignore in your design in the hopes that you can fix the problems as they arise after implementation -- once broken, a Web-based system takes a long time to repair if that is even possible.
Providers as System Limiters
While not all systems use and deliver large amounts of content, in virtually all cases the providers are the limiters of what the system can deliver, at what cost and with what level of user-acceptability.Failure to understand the provider community can have devastating impacts on any system dependent on content for successful operation.Among the key provider factors are:
Learning Opportunities
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
Webinar
Jun
13
Learn How to Deliver Dynamic Video Experiences at Scale
Learn how to convert existing assets into video experiences in near real-time.
Webinar
Jun
20
3 Steps to Unlock Your Customer Data and Drive Revenue
Discover how Twilio Segment’s #1 Customer Data Platform helps implement data-driven strategies.
Webinar
Jun
21
Retail Reinvented: A Masterclass in Creating Digital Experiences That Click
Hear how online retailers architect their digital experience infrastructure for peak traffic and demand
Webinar
Jun
21
The Feedback Loop: Accelerating Personalization for Exemplary Customer Experiences
Are you ready to harness the power of feedback in your personalization strategy?
Webinar
Jun
22
How to Succeed in Today's Engagement Economy
Doing true personalization at scale with marketing automation
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
Webinar
Jun
13
Learn How to Deliver Dynamic Video Experiences at Scale
Learn how to convert existing assets into video experiences in near real-time.
- Who and where they are.Their proximity cannot be assumed, and providers are often important remote users, with their own set of needs and limitations.
- Their willingness, staffing, training and funding to provide content in the forms and volumes your system needs.In many cases, system needs may be far down on their list of importance.
- How aggressively they are likely to resist change.Get this one wrong and you could find your new system in a battle you can’t win.In many cases, provider groups perceive negative impacts even if that perception isn’t fully warranted, and it is the perception that drives their response to the systems effort.
- How much control you do or can have over what they do.A good starting point here as well is “little or none.”
- The impact of their failure or refusal to provide what you need; on you and system users.If you don’t find consensus with your subject matter provider groups, the ensuing battle may be one you can’t win.
This set of questions is perhaps the most often overlooked characteristic of Web-based system design, especially where the providers are part of the same organization.
Content: the Raw Material of a Successful System
Content flowing through your systems environment is the primary way your providers, managers and users communicate.Your users will usually be most happy with the most elegant content possible while your providers will often prefer offering content in forms close to what they are already creating, minimizing impact on their operations and staffs.
Just as you need to know your users and providers directly, you need to know their willingness to provide and work with content in your systems environment.Chances are very high that the demands from your drivers will be higher than offerings from your limiters, setting up a negotiation that you must control to end up with a workable system environment.
Negotiating a Consensus Systems Environment
While not usually a formal negotiation, this part of the systems effort is critical.Users often must live with information based on something less than what they would prefer: less elegant forms, less metadata and external links, fewer updates, etc.
At the other pole, providers often must accept changes to their procedures in order to create, and fund, content closer to users’ demands.Finding the balance between these often opposing positions must be handled carefully and with respect for the needs of both.
For sure, it cannot merely be dictated by the system designers as is too often the case.
As painful as it can sometimes be, this phase can be successful if the project managers keep their wits about them and their eyes on the prize: a workable system at acceptable cost and risk.
Now Use a Rigorous System Development Methodology
Once the issues above have been fully resolved and the results clearly documented, the effort is ready to move into a traditional system design phase, using the formal methodology with which the IT group is most comfortable and capable, based on the clearly documented results of the investigation and negotiation phases, giving it a good chance of success in meeting both user and provider concerns.
The path won’t be smooth; what is suggested here will drive some IT people nuts; and discussions with provider groups about what the system needs in its content will often be difficult, even acrimonious.But experience and accumulating evidence indicates that unless these steps, and the time and resources to properly complete them, are built into the design of Web-based systems, the results will often be short of successful.
There’s an old saying that “what is worth doing over is worth doing right the first time.”In Web-based systems development, these should be words to live by.
Editor's Note: Barry speaks from experience. To read more of his thoughts, try The Battle for Data Supremacy: The Cost of Ignoring XML