Home
Archives
Archives before June 13, 2001
RSS Feed
Adaptive
Path (my company!)
About
peterme
Coordinates
Most of the Time
Oakland, CA
Interests
Current
American history around the time of the Revolution, figuring out how to marry top-down task-based information architecture processes with bottom-up document-based ones, finding a good dentist in San Francisco Oakland
Perennial
Designing
the user experience (interaction design, information architecture, user
research, etc.), cognitive science, ice cream, films and film theory,
girls, commuter bicycling, coffee, travel, theoretical physics for laypeople,
single malt scotch, fresh salmon nigiri, hanging out, comics formalism,
applied complexity theory, Krispy Kreme donuts.
surf
Click
to see where I wander.
Wish
list
Show
me you love me by
buying
me things.
Spyonme
Track updates of
this page with Spyonit. Clickee
here.
Essays
[Editor's note: peterme.com
began as a site of self-published essays, a la Stating
The Obvious. This evolved (or devolved) towards link lists and shorter
thoughtpieces. These essays are getting a tad old, but have some good
ideas.]
Reader Favorites
Interface
Design Recommended Reading List
Whose
"My" Is It Anyway?
Frames:
Information Vs. Application
Subjects
Interface Design
Web Development
Movie Reviews
Travel
| Can you purchase wisdom? Posted on 12/09/2002. |
|
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." COMMENT #1 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.
COMMENT #2 COMMENT #3 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".
COMMENT #4 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.
COMMENT #5 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.
COMMENT #6 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...
COMMENT #7 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.
COMMENT #8 COMMENT #9 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.
COMMENT #10 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
COMMENT #11 COMMENT #12 The sales pitch on that is that because the product incorporates best practices it will make it easier to do the right thing.
|
