In 1999, I was a 30-something user experience architect (though we didn't use that term those days) toiling for a national retailer. Gloria Gery, author and consultant, saw potential in me and recommended me to the American Society for Training and Development's article on up and coming folks in the industry.
This feature, short though it was and misspelling my name and all, led to greater exposure and a hunger to do more. As an indirect result, I left that company, formed my own consultancy, joined another consultancy and finally landed my dream job. Thank you Gloria!
Excerpted from T&D Magazine:
Gary Elsbernd saw the writing on the wall soon after joining Payless ShoeSource in 1989 as a training documentation specialist.
The computer system used by the company's 2,000 retail outlets was becoming more complex. The user population was diverse and dispersed. And employee turnover was as high as any retail operation -- 100% or more for part-time employees. Training employees on using the system would be an ongoing, expensive headache.
Fresh out of college, where he had earned a bachelors of public administration, Elsbernd began chipping away at the problem by working with the company's systems developers to improve the consistency of the user interface of its retail computer system. That early partnership with the programming staff led Elsbernd in pursuit of more substantial remedies for Payless's training challenges, the fruits of which are evident in the Retail Performance Support System, one of the most ambitious efforts to date in the EPSS arena. The system, which Elsbernd says provides powerful embedded tools that aid the performance and learning of store associates, is being rolled out in pilot form this spring.
Its release culminates an eight-year odyssey by Elsbernd into territories seldom charted by in-house trainers.
"I started thinking in terms of built-in software support and attended a conference in 1991 where I heard Gloria Gery describe EPSS principles," says Elsbernd. "I immediately recognized the situation she was describing--that we weren't going to be able to continue building software applications separately from training."
Elsbernd began pursuing development of online reference and learning tools in partnership with in-house programmers, but he also saw the need to lobby senior management on the value of the performance support approach. Together with his boss, Tamara Jarrow, he prepared evidence on the need to shift to a performance-centered approach to help meet the surging training demands of the fast-growing company.
Though he won some key adherents in the top ranks, Elsbernd and his staff faced ongoing competition for resources as Payless made several acquisitions and expanded into new regions, pushing the number of retail stores to more than 4,000. While his group struggled to stay on management's radar as they developed an initial prototype of an EPSS, Elsbernd says the system met stiff skepticism when managers reviewed an early prototype in 1995.
"Management wasn't convinced the system was going to solve the problem," Elsbernd says. At the same time, he realized he had drifted somewhat from his original objectives. "I personally got too caught up in gee-whiz technology. We hadn't tied what we were doing closely enough to business objectives; we were too busy showing what was technically feasible."
The team regrouped, renamed itself Retail Performance Support & Development and called in such EPSS luminaries as Gery and Paul Johnson of Ariel PCS to help make the case to management. The prototype system was reengineered to emphasize performance effects and subsequent management reviews met with growing admiration. The pilot system, currently being tested by more than 60 stores, provides an integrated package of applications that Elsbernd says a brand-new sales associate can navigate and learn from. The applications include "modular nuggets" of information in performance-support format, some CBT-style "teach me" modules and online reference tools. A conversational "agent" introduces the system to new users, whether they speak English or Spanish, as the entire system is multilingual. A French version is currently being prepared to support Payless stores in Canada.
The move to EPSS has allowed the training function to focus its instructor-led initiatives on people issues rather than "how to use the computer," Elsbernd notes.
The experience of pushing the project past many formidable obstacles has served to harden Elsbernd's resolve in the value of the EPSS approach. "I have become a firm advocate of designing systems and software so they reflect the way people work and think, instead of requiring people to change because the software was designed around another set of criteria."
He also admits that his passion has little to do with what he originally envisioned himself doing: stand-up training. "EPSS is a perfect marriage between technology and training," he says. "I guess I'm a geek at heart."
This is the beginning of an article outline/proposal I've been mulling over. I will continue developing until it escapes...
“The human mind is exquisitely tailored to make sense of the world.
Give it the slightest clue and off it goes, providing explanation,
rationalization, understanding.”
- Donald Norman
We all think we know how the world works. In fact, in psychology, the terms assimilation and accommodation are used to describe the process of adding a new bit of information to what we already know. In assimilation, we take a new bit of information and add it to our existing mental model of how the world works. In accommodation, we take the new bit of information and change an existing mental model or create a brand new one to explain the new knowledge we have.
Mental Models and how they develop
Mental models are the representations people have of themselves, others, the environment, and the things with which they interact. People form mental models through experience and accretion (when new information fits into an existing schema, and thus is quickly comprehended). A mental model can be developed, added to, or modified any time a person’s behavior and the subsequent results are connected in the person’s mind. In reality, users interpret results and sometimes form an accurate model of what is being experienced, sometimes the results are correlated but without a true cause and effect relationship, and sometimes the results are a coincidence. Regardless of the how’s and why’s, if the actions and outcomes are understood by the person as linked, a mental model can be formed or strengthened.
How do mental models apply to software systems?
Because there is more than one role involved in the design, development, and use of software, more than one mental model is imposed upon the system. Norman identified this and began to label the different models associated with software. Germane to this discussion include:
- The Design Model is the designer’s idea of how the system works and represents the true nature of the tasks.
- The System Model is how the system actually behaves and represents the nature of the tasks.
- The User’s Model is the mental model developed through interaction with the software (which incorporates aspects of both the Design Model and the System Model).
The designer expects the user’s model to be identical to the designer’s model, but if the system model is not clear and consistent, the user will end up with an incorrect mental model.
For example, a user's mental model is that creatures with four legs are dogs. When they come across a cow, they have a quandary.
When the performance model and the user's mental are not synchronized, the user believes "the system is broken" or impossible to use.
Equilibrium, assimilation, accommodation – Piaget
This conflict in models is known as disequilibrium, or a cognitive dissonance between how the user believes the system works and how it is behaving. The user has several options at this point, but assuming the user wants to keep using the system, they have to either assimilate or accommodate.
If the user determines that a cow is another animal with four legs, they can assimilate the new creature into their mental model by expanding their definition of four legged animals. If they saw a dog with an amputated leg, they could assimilate by seeing it as an exception the rule, but not a new kind of creature.
If the user sees a table with four legs, they must create a new mental model of four legged objects. This process is accommodation, in that they now have an entirely new construct to which they can assign instances.
Mental inertia and cognitive dissonance
Users resist both of these processes, especially with examples that are much less concrete than our dog/cow. If the user thinks they know how a system works and it behaves unexpectedly, it is easier to classify the behavior as a system error (another mental construct) than to change the model of how it should behave.
EVOLUTION VS INTELLIGENT DESIGN OF SOFTWARE SYSTEMS - provocative, yet descriptive, controversial?
This evolutionary process can lead to confusion and despair. Imagine if the same approach were applied to other areas – start building the house before you decide how many bedrooms to have – if you change your mind, adjust what you already have to accommodate the new plan. As ridiculous as this seems, complex computer applications are often built the same way.
Sometimes the reason has to do with scope, budget, time, vision. Describe examples of each...
Describe actions, results of each of these examples.
Scope - a new tool is developed with a specific set of functionality. After it rolls out, users see potential and start using it for other tasks. They then influence the developers to expand the system to encompass more and more of that new task (assimilation).
Budget/Time - no money to develop the system with full functionality. Analysis and development are restricted, leading to a incomplete understanding of the performance environment.
Vision - Related to budget/time and scope, if the developers are not looking to a future state roadmap, it is easier to develop a band-aid approach to solve the immediate need. Decisions about architecture, data schema and interaction design are secondary to solving the problem in front of them.
Complex applications and how they develop (software lifecycle)
Developing a new application (capability)
All design begins with a need. Successful software begins as an opportunity to do something users couldn't do before, or couldn't do quickly/easily. This new capability is enough for users, who are so delighted they will overlook long learning curves, cryptic codes and unfriendly error messages.
Upgrades (extended capabilities added without systematic plan)
Once the base need is met, the users start expanding their horizons. They ask for the next step in the process, utilities to handle exception cases and functions for additional user groups who now want their own lives to be easier.
User experience (disequilibrium, functional overload, rework the performance model)
At some point, there is a diminishing return on additonal functionality. At this point, the users become more discriminating and start demanding usability. The learning curve, the error recovery and the aesthetics all become important. By this point, however, the interia leads long-time users to resist any change, saying things like "The system does everything we want, why change it?" They have forgotten the pain of learning the system and would rather maintain their model in favor of making changes that would help future users.
The cure
The cure is to know where you are going before you start. A consistent roadmap, user interface design standards, understanding of performance environment...
- Enterprise architecture
- Roadmaps
- Standards and guidelines