The WELL: inkwell.vue.186: Jesse James Garrett, _The Elements of User Experience_

#56: Jesse James Garrett (jjgdotnet) Thu 17 Jul 03 16:03

Thu, 17 Jul 2003 16:03:00 PDT

If usability tests didn't surprise us at least a little bit, they wouldn't be worth doing. Sometimes they don't spark great revelations, but they enrich our understanding of user psychology and behavior in ways that inform all our work, not just the current project. [Read entire topic]

#55: Jon Lebkowsky (jonl) Wed 16 Jul 03 20:43

Wed, 16 Jul 2003 20:43:00 PDT

I don't think we asked this before, Jesse: are you often surprised by usability test results? [Read entire topic]

#54: Jesse James Garrett (jjgdotnet) Wed 16 Jul 03 20:24

Wed, 16 Jul 2003 20:24:00 PDT

Bruce, the aspect of my work that really keeps me interested and motivated is the extent to which we can't predict how users think or behave. Information architecture in the real world has surprisingly little to do with logical and precise classification. Humans are messy, fuzzy thinkers, and any architecture designed for humans must reflect that.

Interface standards are good and valuable and necessary, but only as long as we understand their limitations. Good interface design doesn't require standardization for its own sake; it requires the intelligent application of standards where appropriate, and the exercise of professional judgment to determine where such standards might not be appropriate.

As for artificial intelligence, I wouldn't declare it impossible, but it certainly does seem to be a long way away. [Read entire topic]

#53: James Leftwich, IDSA (jleft) Wed 9 Jul 03 16:48

Wed, 09 Jul 2003 16:48:00 PDT

Bart, I'll send Jesse an email just to let him know you've posted some interesting issues and questions. [Read entire topic]

#52: Bruce Bartholomew (blackbart) Wed 9 Jul 03 14:25

Wed, 09 Jul 2003 14:25:00 PDT

Hi Jesse,

I*m sorry I missed the two-week period, however I hope you check your discussion to respond to those who missed listening to James Leftwich expound. I bring technical writing skills along with Web design and an information architecture background. I began designing from Netscape 1.0 and have suffered through the limitations of Html and the evolution of combining Web design with information architecture.

My question centers on the virtues of user experience versus a programmer*s mentality forced on to the user. We have seen the user interface pendulum swing away from a programmer*s mentality to the user via the GUI.

Specifically, how important must the simulation of the user experience compare with the user interface of the Microsoft paradigm? I agree that the period of gaudy Web site design with flashy buttons and cute graphics is not effective. Simulating the look and feel of a book or magazine adds the same background familiarity that simulating the Microsoft interface provides. Yet, sticking to flow charts and logical structures does not necessarily capture human intelligibility. The human experience is characterized by the workshop model. The user looks for standard tools and access to all parts of the Web site from one page. Having experienced the evolution of the user interface from DOS to the Microsoft GUI, you know how difficult it was to switch interfaces from Borland, Lotus, and Microsoft. I remember IBM had to do a complete redesign of their Web site because people were getting lost. I*m sure IBM had a logic and flow to their Web site at the time; however it was not a logic or flow that the average user could follow.

To summarize, would you comment on the importance of acknowledging:

How the user accesses information The merits of standardization Creating an intuitive interface

versus

Allowing the underlying code dictate both the structure and user experience The implementation of logic and flow charts

I do realize there are constraints, for example, the implementation of page layout with tables. However I agree that Flash may be the future of Web interface as the limitations of bandwidth ease up.

One last thing, are we still stuck in the illusion that the human mind and the computer can work side by side? The attempt to computerize common sense by Doug Lenat is a programmer*s wet dream never to be realized.

This may be another book in itself, but I hope you will offer some insight to this dilemma for the user suffering from information overload.

Thanks [Read entire topic]

#51: Jon Lebkowsky (jonl) Mon 30 Jun 03 15:52

Mon, 30 Jun 2003 15:52:00 PDT

Yes, thanks, and feel free to hang out and talk some more! [Read entire topic]

#50: Cynthia Dyer-Bennet (cdb) Mon 30 Jun 03 08:18

Mon, 30 Jun 2003 08:18:00 PDT

I'd like to add my thanks to both of you for joining us here in Inkwell.vue, Jesse and Jim. The last two weeks have zoomed by! The topic will remain open, unfrozen, indefinitely, so if there are any more questions or comments to add to the thread, please feel free to carry on. [Read entire topic]

#49: James Leftwich, IDSA (jleft) Sat 28 Jun 03 22:06

Sat, 28 Jun 2003 22:06:00 PDT

And thank you, Jesse. It's been a real pleasure to participate in this discussion with you.

The topic will remain open, so the audience is free to carry on the discussion.

And to recap, here are the links to Jesse's diagrams:

The "simple planes" diagram that takes a very high-level approach to the Elements model: <http://www.jjg.net/elements/elements_simpleplanes.pdf>

More detail in Jesse's original diagram from 2000: <http://www.jjg.net/ia/elements.pdf>

Still more detail in Chapter 2, "Meet the Elements", from his book: <http://www.jjg.net/elements/elements_ch02.pdf>

The main tool Jesse has evolved for working through structural issues is a diagramming system that's become known as the Visual Vocabulary:

<http://www.jjg.net/ia/visvocab/>

And here's the information on Jesse's book:

The Elements of User Experience User-Centered Design for the Web New Riders Publishing

<http://www.jjg.net/elements/> [Read entire topic]

#48: Jesse James Garrett (jjgdotnet) Sat 28 Jun 03 19:10

Sat, 28 Jun 2003 19:10:00 PDT

The concept of "reading" a system is connected to the idea I mentioned earlier that systems need to have an internal logic that helps the disparate features and functions cohere. That logic has to be manifested in the final product in a way that users can interpret and absorb it. Reading the system is the process by which this happens for the users.

Humans are pattern-makers; whether consciously or unconsciously, we are always trying to make our world make sense. If we can't make the products we use make sense, we get frustrated and annoyed and eventually resort to memorization as our only means of accomplishing our goals. But it's not enough for the products we create to have internal logic to their design. If that logic isn't communicated clearly to the users, it may as well not be present at all.

Ultimately, creating successful user experiences depends on our ability to forget everything we know about how the products we design get built and see them through the eyes of people seeing the finished product for the first time. Anticipating their questions, understanding their expectations, and reflecting the ways they think about their needs is the essence of our craft.

Thanks Jim, and thanks to everyone who participated. It's been fun! [Read entire topic]

#47: James Leftwich, IDSA (jleft) Fri 27 Jun 03 13:24

Fri, 27 Jun 2003 13:24:00 PDT

> These habituated users will be very resistant to change -- for > a couple of good reasons. First, they've got a legitimate fear that > the new system will require as much effort for them to learn as > the old system was (not an unreasonable conclusion, based on > precedent). Second, they'll actually make more mistakes with the > new system at first because they'll try to learn it by memorization, > which is hard. Once they stop trying to memorize and relearn how > to read, they'll perform better with the new system than they ever > did with the old one.

I wanted to requote your paragraph here Jesse, as you make several points that I see as absolutely fundamental in the design and redesign of all interactive systems.

It's a problem I've also run into frequently in product design, specifically medical devices. While I sometimes have the opportunity to design a medical device from scratch, there are many more that already exist and have significant user bases. Since it's extremely rare to happen upon an existing device or system where the interaction design efforts were tightly and properly integrated between the physical controls, visual displays, and functional interaction, the user experiences for these are often nightmarishly complicated.

Add to this the fact that you will often find existing "power users" who have, by whatever efforts or time was necessary, managed to scale the steep learning curves for operating or using these devices or systems. They then have some "power" by knowing the arcane or arbitrary tricks necessary to navigate and use some overly complicated device.

Their two comments against redesign generally fall into two categories:

1) (generally unspoken) "If you simplify this, then my specialist knowledge will no longer be uniquely valuable."

2) "Please, don't 'simply' this! You can only dumb it down and penalize me as a power user in order to spoonfeed the new, in experienced users."

Number two is definitely a risk, as many systems that have been "simplified" have actually been made childish, or constrained to highly sequential step- through models, which minimize error, but are inflexible and ultimately inefficient for experienced users.

The other thing that you mention, Jesse, is the power of having a system that can be "read." I've often spoken of my own designs as primarily being about the design of an "interactional syntax" and "language" from which the product or system is then the first expression of.

By approaching interactional systems like this, there is then the ability to logically extend and evolve the interaction using the same elements, rules, interrelationships, classes, and actions from which the original version was composed.

I suppose this is a form of "metadesign." But I'm very glad to see you making a point of this here. It's among the more crucial aspects to designing for ongoing improvement and extention, as opposed to a one-time, one-off system that has to be torn down and replaced once the needs evolve, or outgrow a fixed design.

Jesse, can you speak a bit more about your own concepts of what "reading" means, and some of the issues you've encountered in both creating systems like this and then selling them both to stakeholders and end-users? [Read entire topic]