Among the things that have surprised me recently happened on a brief consulting gig. We had come to talk to them about a process for user-centered design for their websites (both external and internal). Among the problems they were facing on their internal websites were implementations of enterprise software to facilitate things like tracking human resources issues (vacation days, sick leave) and financials (payroll, accounts payable, etc.) The problem wasn't one of features and functionality -- the software did everything they wanted it to do. The problem was one of design -- learning how to use this system was quite difficult, and often ran contrary to how people currently worked.
In our presentation on user-centered design, we utilize the following diagram as an overview of a process:
Such as it is, the cycle "begins" with "Gathering Assumptions and Requirements." This is the step where you look internally to understand the business drivers of whatever project you're involved with. The thing is, that's pretty much where this company began and ended. They understood the business drivers, got a sense of the features and functionalities they wanted, and then would go out and buy software to solve it.
The problem is, as they learned, that the issues isn't with features and functionality, but with the software fitting into current work processes. What this means is that, when buying enterprise software, companies need to do more work, move forward along the cycle, to "Understand Goals and Tasks." This is where you observe user behavior and needs in order to understand the processes people engage in to accomplish their tasks.
What surprised the client was that they thought this was the responsibility of the vendor. Part of the reason they bought this software was for the "wisdom" the software was meant to have embedded within. That there was a "wisdom" in how the software presents work processes, and that the company ought to learn from that wisdom and adjust their work accordingly, taking advantage of this "wisdom."
This totally took me aback. How on earth could this enterprise software tell you how to do your work? It's your work! And, this is what the client learned, in a painful way. That software can't come in and change how people work--such software will simply be ignored, be rejected. Companies have to step up and take more responsibility for the integration of software within their organizations, because no one else knows how those companies work. This is something that content management system vendors have had to deal with, and has lead to a solution of separating the content/data and the presentation.
Remember, the problem with the software wasn't features or functionality, it was how those tools were presented. Unfortunately, the design of the system was hardcoded (which is shocking, since it is served through a web browser).
What will be clear, moving forward, is that enterprise software companies will have to follow the lead of CMS and provide a greater degree of flexibility in how people can interface with their tools.
12 comments so far. Add a comment.
Previous entry: "The Ballad of Adam and Nathan, part 2."
Next entry: "The more things change..."
"What surprised the client was that they thought this was the responsibility of the vendor."
Absolutely meshes with my experience in Japan, where clients genereally refuse to pay for a discovery phase, or even tolerate much in the way of a deep discovery process, on the logic that the consultant is ostensibly the expert, and should somehow come to the table with all the answers. Worse: that that knowledge is the sum total of the value you bring to the table as a consultant.
It's taken nearly two years of education here for clients to begin to see that we help them best by asking questions - even, sometimes, questions that strike them as unbelievably naive. But it's a Sisyphean labor in a culture that thinks this way.
Posted by AG @ 12/09/2002 06:15 PM PST [link to this comment]
Thanks, Peter. Once again, you're on the mark--and have expressed the problem I'm currently wrestling with. Nicely done!
On a related vein, I'm working on two things: the role of meaning in user experience and my premise that the term presentation layer is a flawed or at least useless engineering construct--real people don't experience Web sites or software as a layered experience. More on this later...but just wanted to hightlight how cool your comment is.
Posted by Joe @ 12/09/2002 08:49 PM PST [link to this comment]
Of course you should be able to buy "wisdom", especially from a Content Management Company with experience in a particular field, although I'd prefer to call them "lessons learned". Lessons like don't hard-code the "presentation layer".
Posted by Tom Smith @ 12/10/2002 01:29 AM PST [link to this comment]
Wow - and I was beginning to think that my current clients were the only ones who expect the software they've chosen to think for them!
And we're having much the same problem - a product with hardcoded design. I've met with these folks several times recently to discuss the need for an improved front-end on their product - or at least the support to give it a decent (appropriate) interface.
But, as usual, the greatest challenge seems to be getting clients to recognise that this "tool" will not miraculously change the way their people work.
Posted by Anne @ 12/10/2002 05:51 AM PST [link to this comment]
Peter, you have discovered what happens in government and large enterprise environments. I learned this lesson about three or four years ago, but thought I was the last to learn it. I learned by entering projects that were aimed at small solutions to fix problems of non-adoption of technical deployments. In every case there were a set of key users that did not adopt a large technology deployment that was aimed at easing their jobs, but the technology did not reflect how the folks did their job. The intended users did not use the tool at all and continued their work as they always had. Myself and others were brought in to provide a means of making these non-adopters work more effient. In every instance (which continues today) a technology was chosen to satify business requirements not work efficiency requirements.
The art of contextual design became a very important element to reach success, but it is one area that is lacking in application systems. Oracle has been a great offender with their applications and you had to adopt the Oracle method of running a business, not use their products, or void the warrantee to get the product to funtion as the business processes always had. The selection of technology often (in many real world situations) is based only on meeting business needs, but not mirroring business process or contectual work processes. The workflow and interaction patterns and flows must be integrated into any system for success. Understanding the information needs to so that the information is structured for reuse is another continual problem.
Today's economic environment is pushing folks in to these patterns still. Technology is still not maleable enough, or requires a great amount of integration work to be functional in a business information workflow process and a user contextual workflow. These are elements that are central to smooth business integration and user adoption.
It seems the user experience model you are using is missing the business process model analysis and the input/interface user's contextual work processes. These may be integrated in the Gather Assumption phase, but really should be split out as a separate step. I have been doing this for about three years and have had great success when it has been used.
It seems that there is currently a great amount of use of applications that do not meet low level requirements simply because the applications are already in house. Getting around this mindfield is equally problematic as the existing applications often solve one problem or two, but create even greater problems. One of the problems that older applications seem to be permeating is poor information structures that are not easily reusable. Over the past couple of years we have grown to better understand the structuring of information for reuse. Using XML, a database, or even well marked-up HTML/XHTML can provide easy access to information and situational reuse that Flash or PDF storage can not (these structures are improving, but still mangle information structures making reuse much more difficult than need be). Information reuse can be as simple as a information feed or as useful as mobile information use with out having to rebuild the information. Ease of information reuse within organizations and externally has been a desire for sometime, but application/technology selection and implimentation have not always met this desire.
Posted by vanderwal @ 12/10/2002 08:26 AM PST [link to this comment]
But...hmm...I thought (and maybe this is a knowledge-management perspective) that neither consultants nor some magic piece of all-seeing software were the repository of wisdom, and that rather we were to look for this wisdom in the client organization itself.
In fact, that's part of how I've always constructed my role as consultant: simply a facilitator, to help make explicit the things the client was already doing (at least sometimes).
Should we *ever* expect that software enable "ease of information reuse" out fo the box, in Thomas's phrase? That strikes me as curious...
Posted by AG @ 12/10/2002 07:05 PM PST [link to this comment]
I have only found a few organizations understand the relationships between business processes (as policy and as they are practiced), applications/technology, and information. Many desions that impact efficiency come from not understanding the relationships. The weak point not having a holistic understanding of business processes.
I agree with your approach as a consultant, having had success with it for many years. How we percieve our roles is very different from how many consultants, and particularly integrators saw their roles. This is getting better from the consultants perspective and from the client's perspective, but there still seems to be a 40% gap. Much of the gap remaining can also be attributed to funding for proper discovery/requirements or are using technologies that are older or not good fits with the decisions based on cost.
Adam, I tend to look at information reuse very early in any information solution approach. I have been through too many situations where information is stored in a format that requires much work to get the information in a clean format (pulling information from templates where it has been hard coded or from PDF and the structural format is lost or non-existant). Many clients have purchased information solutions to solve one set of requirements, but information is often repurposed for a completely different set o f requirements. Copy that is generated for salesforce training manuals may also be used for external publications on the Internet or Extranet. If the training manual is stored in a PDF rather than in a markup format that can easily be grabbed and repurposed with very little clean-up (or better yet has some descriptive metadata in the markup tags) there is much efficiency. I had spent a couple years working to put together an enterprise wide system that was centralizing data (also had no central definition of data classification). We had a lot of information turned over to us in formats that could not have the information extracted with any contextual understanding of that data. The data had been gathered and compiled into a proprietary format to publish a report. Information reuse was never a thought, the end product was the only goal.
I know many applications have lead us not to believe in ease of information reuse out of the box. Many clients have not thought of this as a requirement in the past, but after spending money to correct these problems it is a question that comes up often I am finding. Clients often ask which standard API can be used to extract the information and if the metadata can be extrated also. Information has needs of its own in order to be reused. Organizations do themselves a huge favor thinking of not only their own business needs and processes, but also the ability to reuse information.
Posted by vanderwal @ 12/11/2002 10:19 AM PST [link to this comment]
Why does "Information Architecture" come before "Prioritize Features" on this diagram? Wouldn't you want to prioritize the features before creating an architecture to support them?
Posted by Anne @ 12/12/2002 11:32 AM PST [link to this comment]
You want to create an information architecture that includes all potentials. You then want to prioritize what you do for *this version*, because you only want to do interaction design for that which will launch.
But you want to settle your IA before then, so that it can accommodate future versions that may incorporate features not designed in this version.
Posted by peterme @ 12/12/2002 11:58 AM PST [link to this comment]
buying enterprise software that you hope will make up for your lack of internal process is the same fallacy that causes dept. heads to believe that purchasing expensive project management software suddenly makes everyone a great project manager
it would be nice if the client could just throw money at the problem and it would go away, but it really takes work on the part of the client
Posted by markb @ 12/12/2002 12:44 PM PST [link to this comment]
Ah. I thought "prioritize features" was akin to requirements gathering. In your example, it's not, excactly. It's more like a phased launch. Semantics, semantics.
Posted by Anne @ 12/12/2002 02:49 PM PST [link to this comment]
So how about Fogbuz (by Joel Spolsky)? http://www.fogcreek.com/FogBUGZ/
The sales pitch on that is that because the product incorporates best practices it will make it easier to do the right thing.
Posted by PeterV @ 12/17/2002 12:36 PM PST [link to this comment]
Add A New Comment: