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.