PinPoint Performance Solutions Blog (Legacy Content)

I never considered myself and early adopter. Everybody seems to have one in their life, either among their circle of friends or within their family, but I'm not one of them.

A little more than a year ago, Microsoft released its Vista operating system. When the product launched I didn't run out right away and install it on my company's PC's. I waited on the sidelines like a lot of other people and stuck to what I knew worked for me, met my needs and what I was familiar with. I didn't want to change to something that was unproven and had little to no guarantee that it will work with my software and other hardware devices.

Late last month, I upgraded one of my computers and chose the Vista OS. Actually, I had no choice with the box I purchased. It was either Vista or nothing. After a year in service, I thought it was time to give the OS a try. To me, the change was inevitable. Eventually I would have to make the change because Microsoft will quit offering XP and will no longer support it in the near future.

A recent PC World article titled Why Users Hate Vista explained how change in an operating system is more emotional (to the end-users) than technical (for the IT personnel). When it comes down to it, any technical change for an end-user is emotional. It's human nature to resist change. Just ask my friend who wrote a recent post on his blog about change. Bottom line: people are creatures of habit and will prefer to keep things status quo. At minimum they will be very selective about the amount of change they are willing endure.

In business and the IT world, change is unavoidable if you want to remain competitive. I don't recommend change for the sake of change, but if it improves your business processes it should be implemented with thought and consideration for the end-user. After all, it is they who will be leveraging the technology to drive the business processes that bring about success.

How does one implement a technology change despite the emotional reaction people will have to it? The answer is Change Management.

Here are some tips and thoughts I have on this subject:

• Focus on the people - consult with the end-users. Include them in the decision making process when making changes to the technology they will be interfacing with. Work with them to identify their needs, the obstacles they wish to overcome and their overall objectives.
• Communicate strategic messages - discuss the reason for the change and solicit feedback. Clarify how everyone will be involved in the change and give them ownership in the implementation strategy.
• Communicate and train - provide ample notice and support for the new technology measure the results. Above all, maintain open lines of communication to allow end-users to ask questions and voice their concerns. Address them promptly.
  

If you take careful consideration into what you are doing and who you are doing it for, you can be confident that the change will be embraced and implemented as it was intended.

Recently I found a great blog post on the subject of design. When we hear the word "design", what does it mean? Frank Spillers tells us in his post titled What is Design? (Yes, all 10 definitions!) at his blog, Demystifying Usability.

I hope Frank doesn't mind, but I commented and offered another definition of design (bringing the list to 11) that I think fits well within the framework of usability. How about instructional design?

When it comes to products, whenever we are able to support the transfer of knowledge in a logical, objective fashion or make it easier for people to learn how to operate products and apply them to their work, we increase the level of satisfaction surrounding the user experience. I know that usable products are supposed to be intuative and easy to learn in and of themselves, but there is always a need to support learning.

Just another definition of design to add to the list and I'm sure there are more to come.

A fundamental principle in usability design and interaction design is something called an affordance. An affordance is a term made popular by Don Norman in his book The Design of Everyday Things. Essentially, an affordance is the way an object looks, how it is designed or how it is presented to suggest a certain action or usage.

For instance, the angle or shape of a chair suggests that you use it to sit on. The rounded, softer and curved portion of a knife or hand tool suggests this is where you handle the instrument. Just take a look around and you’ll be surprised all of the affordances you see in the design of everyday items you use.

It’s even present in our technology.

Most software and web applications have affordances built into their interface to suggest certain actions or usage. Your typical web browser most likely has left and right arrow buttons near the top to suggest your web surfing experience is much like reading a book. If you want to turn back to the previous page you were viewing, you would click the left arrow button or “turn the page to the left”.

Good user interfaces will have these intuitive features built in. Still, there is a need for support systems to be in place in order to guide new users who may not hold the same paradigms or mental models of the persona you developed your application around. The support provided, usually through carefully designed tutorials or quick start guides, will give the user a sense of what is this (the application), what do I do with it and how will it be relevant to me.

That’s good support for any application.

As most of you readers know, my career within the last eight years started with designing training programs. Later, it moved to designing training programs to support software and web technologies. Shortly after that it transitioned to my current career where I know support the design and development of software and web technologies using the tools and techniques a training developer or performance improvement specialist would to create and effective solution.

I was e-mailed a question not long ago where I was asked my opinion on whether or not the ADDIE model of instructional design (a method to develop training) was compatible with user-centered design.

I thought I would share my answer to this question to see if I could garner support for my theory or spur some nice, healthy debate:

I think they are very compatible, but each of their intended purpose is different. ADDIE is targeted toward the development of instructional materials and content while UCD is focused on developing software or web-based applications that are designed around the target audience’s needs (tasks, objectives and obstacles they wish to overcome).

With that said, there is no reason why UCD can’t be applied to ADDIE – it simply would be concentrated in the A (analysis) and the first D (design) of ADDIE. This is provided, of course, the outcome you are trying to achieve is an instructional product delivered in an electronic format (software or web-based). I see that happening quite a bit where a lot of instructional materials and content are being delivered in web-based or electronic performance support systems these days.

The fruits of your labor using UCD in the A and D portion of ADDIE will manifest themselves in the D (development) and I (implementation) portions of the model. E, to me, is where usability testing comes in.

On a few occasions (like the one in this post) I have written about how best to train people on new technology once it is implemented in organizations. The subject has come up recently in discussions with potential clients looking for performance support systems and e-learning and it has reminded me of a model of learning theory I learned about years ago that best explains how to present training. It is especially interesting when you look at it through the prism of using multimedia to train end-users on software or web applications.

Edgar Dale was an educator who developed what was called the Cone of Experience Theory. The main idea of the theory is this -

The closer to the actual experience you can get your end-user to while they are learning will increase overall retention.

Think about it. Why do pilots train in flight simulators? Why do city, county, state and federal emergency personnel run disaster preparedness drills? It's a safe environment to learn in and reflect upon because they are doing the actual tasks that are as close as you can get to a real situation with little or no threat of causing critical errors.

It means much more to the learner if they can actually experience the situation they would be facing than to sit in a classroom, read books, listen to a lecture and watch videos or people demonstrating how to use a product. So, don't be afraid to put some prototypes or demos in the hands of your end-users. This is probably one of the easiest, most fundamental forms of usability testing you can do for your application.

More importantly, go back to your support materials and build some simulations. Let your end-users see, touch and feel (i.e. - experience) your applications. You'll be thankful you did because you'll provide your end-users a safe environment to practice in and as an added bonus you'll lower those support calls that are "how-to's", which can become time consuming for you and your business.

I want to apologize for being somewhat of a shill for my company and a Boise-area organization I support. We upgraded our website and we threw our support behind Kickstart, an entrepreneur event happening in April. Last week's posts has little to do with PinPoint Performance Solutions and our overall mission to help companies implement technology in their organizations to improve performance. Still, why be in the blogging game if you can't do a little self-promotion from time to time and advocate a cause or two?

This week, I thought I'd dedicate a couple posts to my "roots". I started out my professional career as an instructional designer and human performance improvement specialist. Those titles may seem a little foreign to you, but that's OK. Before the week is out you'll have a better understanding of where I'm coming from, how it all falls into place and drives PinPoint Performance Solutions. All you really need to know about my previous career is that much of what I was taught and what I practiced supported the human resources function of an organization (or at least that's where it originated). I had a strong interest in technology and over time I found ways to merge my interest and my profession.

It wasn't all that hard to do. The fields of instructional design and human performance improvement today leverage technology and use it as a driver for many of the solutions that are developed. I'm sure you heard of e-learning. Well, that's an instructional design (i.e. - training) solution and if it is determined after an analysis conducted under the umbrella of human performance improvement that it will benefit the end-user and the organization, true performance emerges that is objective and measurable.

So how does this all tie in to what PinPoint Performance Solutions is doing today? I feel that technology, whether software, websites or web applications, even hardware products like hand held devices, is sometimes hastily implemented. In other words, the technology solution is created for the sake of the solution and not to address the true need or real performance problem in the organization. We get so excited about the possible outcome, but we have a clouded vision of what lies between the perceived need and potential solution.

The model I use at PinPoint Performance Solutions to validate the need to implement a technology solution in business, is Gilbert's Behavior Engineering Model. The link will take you to a PDF file with a copy of the model I have posted on my website. Gilbert, Thomas F., is considered the father of human performance technology. It basically boils down to this - problems in the workplace usually stem from either the business environment or the individual. Each have three sub-sets or areas where the problem(s) is usually centered upon.

Environment:

• Information
• Resources
• Incentives / Consequences
  

Individual:

• Knowledge / Skills
• Capacity
• Motivation

When we look to implement a technology solution in an organization to increase performance (or change the behavior of our workforce - because they aren't doing what they ought to be doing), what we are doing is concentrating on validating the environmental factor of resources. In most cases it is a lack thereof or having the wrong tool to complete crucial tasks, poor supporting systems, inadequate procedures, time (moving too quickly, moving very slowly or not enough) or lack of reference materials to support the transfer of knowledge.

Technology is a tool and if it is determined that a tool will help people and an organization perform better, then it is the right choice. Otherwise, there may be other factors at play that are causing the problem that should be explored more thoroughly. Technology is an expensive proposition for any organization to undertake. If a solution can be developed that doesn't involve implementing technology, then it should be pursued.

It may surprise you that I'm talking about steering clients away from implementing technology solutions, but that's quite the contrary. It's about serving our clients the best way possible and making sure they are implementing technology solutions for the right reasons.

On the surface, it would seem that an analysis methodology such as user-centered design and a software development methodology like agile would be incompatible. User-centered design, after all, tends to rely heavily on research and documentation, identifying user tasks, goals and objectives as they relate to a software or web application. Agile software development is about delivering useful, functional software as quickly as possible. In other words, UCD wants to take its time to fully understand the road that lies ahead while agile is at the starting line with the engine revving ready scream down the highway.

It may seem as though I am criticizing agile development, but I'm not. In reality, both methodologies share a lot in common. Richard Cecil in a recent blog post discussed how these methodologies can co-exist to produce useful, functional software and web applications without stepping each other's toes. As an advocate for the end-user, I feel user-centered design and its many research methodologies are the best tools to support their needs. Research should be done before design and development begins. As Cecil reports in his post;

If we're defining users' needs during development - even in an agile development process - something has gone horribly wrong.

Once I read that, it took me back to my schooling in instructional design (basically, it's the 50-cent phrase for saying training development). As I was taught, the development of training can follow a simple model called ADDIE - analysis, design, development, implementation and evaluation. You can't do the "D-D-I-E" without doing the "A" first. If you do not who you are designing and developing for and the rationale behind your efforts, all of your work will likely be in vain.

I was recently asked by an executive of a software company if UCD and agile can co-exist. My answer was yes - I believe it can only if there is a mutual understanding between the two teams the the overall goal is to build to the end-user's needs. Much of that understanding comes from putting yourself in the shoes of the other person, whether it's the UCD researcher (user advocate) or the developer. The beauty of the two methodologies, in my opinion, is that it affords these concessions. The challenge to the UCD professional is to stay one or two steps ahead of the development team out of respect for the timelines established in agile.