Jesse James Garrett (jjgdotnet) Mon 16 Jun 03 22:31
Surface, the realm of visual design, encompasses the aspects of user experience that people are most likely to think of when they hear the term "Web design" -- color palettes, layout, typography. These are essential issues, to be sure, but smart visual design solutions can only succeed when they're built on smart choices about the underlying planes. Skeleton issues form the most complex set of interrelationships among the Elements. We use narrower terms like interface design, navigation design, or interface design because having precise terminology helps us talk in meaningful ways about problems we're trying to solve. But in practice, these issues can be nearly impossible to disentangle from one another. To some extent, the same goes for the whole Elements model. Each box in the diagram is really just a facet of the larger problem of creating a successful user experience. There's a kind of push and pull, a tension and balance between the elements on each plane. Similarly, there's a ripple effect up and down the planes, as choices made in one area create inevitable consequences in others. People have often looked at the Elements model as a description of some sort of idealized development process. But to be really successful, our process has to be much fuzzier in its treatment of the various concerns than this model is. We have to allow for those interdependencies, and build a degree of flexibility into the process.
Kevin S. Eves (kevins) Tue 17 Jun 03 07:16
Hello Jesse. Thanks for joining us in inkwell. Also, thank you for your work with the Elements of User Experience (EUE, if I may), both the 1-page pdfs on your site and the New Riders book. They are very accessible and should do a great deal to make advance the broader understanding and appreciation of the discipline. I also applaud the decision made by your company, Adaptive Path, to make the Beyond Usability Workshop Assets generally available. I come to this conversation as one of the business-side advocates, though one with much to learn. I've worked for a large financial institution for 10 years, in various roles - traffic coordinator in marketing, business analyst, programmer analyst, and now a manager with both application development and intranet responsibilities. The EUE has been helpful of late, as we are in the early steps of moving our intranet from it's producer-centric, decentralized first stage to -- if all goes well, a user-centric model. There's been some attention the "business people" here, though I note that EUE consciously avoids using business objectives in favor of site objectives, since not all sites are in the service of business or commerce -- but do have sponsors -- someone's in charge. There's another constituency that needs to understand the value of design, specifically interaction design and information design, in addition to the business people: the technicans -- the programmers and/or engineers involved in making the project manifest. EUE addresses strategy, and construction, to a degree, but not as explicitly as it addresses design practices/stages. In thinking through the application of EUE in our environment, I'm wondering what sort of software engineering/systems analysis practices you've found to be compatible/incompatible with EUE.
James Leftwich, IDSA (jleft) Tue 17 Jun 03 09:15
Interesting points you bring up regarding the Skeleton plane, Jesse. Being between the Surface aesthetics and the supporting Structure, the fundamental needs expressed in the Scope, and the underlying Strategy, it's where many things must be brought together and balanced. It's in this act of integration, and in bringing it all to reality under significant time pressure, that the real skills and experience of designers come into play. I'm now in the beginning phases of developing a large-scale emergency response system. It will involve wearable systems, communication, coordination, and information gathering capabilities. It will be embodied in wearable components and mobile command centers. I'm going to be experimenting with integrating the Elements model into our traditional development process. I expect that it will be of significant value in helping to identify and communicate a well defined model of the evolving system to the members of the development team and other stakeholders. To that end I will look forward to another conversation in the future. My belief, based on previous design and development experiences and in light of Jesse's book, is that the Elements model has great potential for application in a range of interaction, information, and experience design endeavors beyond the field of web sites.
James Leftwich, IDSA (jleft) Tue 17 Jun 03 09:17
And now that Jesse has touched on the five Element planes presented in his book, and since our audience is increasingly eager to join the conversation with a range of interesting questions and issues, I'm going to open up the discussion now. In order for our conversation to proceed without undue confusion, I'm going to ask that our WELL readers help give Jesse the room he'll need to answer questions. With so many issues and aspects surrounding and related to experience design, we will have to be careful not avoid having questions pile up and cause cross-topical confusion. Thanks in advance for your help and cooperation in this. As Cynthia mentioned earlier, folks reading this who aren't WELL members can participate in the conversation with Jessee by sending their queries or comments to: firstname.lastname@example.org And to recap the links to Adobe Acrobat .pdf files that Jesse provided to help readers follow along with the ideas and model he's here discussing: - First, here's a version I call the "simple planes" diagram that takes a very high-level approach to the Elements model: <http://www.jjg.net/elements/elements_simpleplanes.pdf> - There's more detail in the original diagram I did back in 2000: <http://www.jjg.net/ia/elements.pdf> - And still more detail in Chapter 2, "Meet the Elements", from the book: <http://www.jjg.net/elements/elements_ch02.pdf> I and the Inkwell.vue hosts will do our best to guide the conversation and help keep our threaded discussions from becoming tangled. So again, I'd like to thank Jesse for a great introductory discussion and the floor is now open for wider audience participation.
Jesse James Garrett (jjgdotnet) Tue 17 Jun 03 13:32
Jim, I look forward to hearing how the Elements are received in the course of developing such a complex (and important!) interactive system. Kevin, I have to admit that I haven't done a lot of work toward integrating the Elements with traditional software development methodologies. Most of the technical teams I have worked with have not had a formal development methodology in place. Except in organizations with a strong pre-Web technical legacy, Web development teams and processes have really evolved in a rather ad-hoc fashion, and formal methodologies are only now starting to find adherents. I have heard from other people who have tried to integrate the Elements (and more broadly, user-centered approaches in general) into their existing processes. The two methodologies I've heard the most about are the Rational Unified Process (RUP) and Extreme Programming (XP). As the names suggest, these methodologies represent the extreme ends of a spectrum, from highly rigorous and formalized in the case of RUP to more iterative and improvisational in the case of XP. Both RUP and XP have rough analogues to the artifacts seen in user-centered design processes, such as RUP's use cases and XP's user stories. The difficulty in aligning these methods with user-centered design is that the fit between them is imperfect. They overlap in some areas, they diverge in others, and layering one method over the other creates a certain amount of duplicated effort as well as a lot of head-scratching as the team tries to fit one method's outputs to another's inputs. Some people consider the entire field of software development methodologies relatively immature, so it will be interesting to see how these methods influence each other over time.
James Leftwich, IDSA (jleft) Tue 17 Jun 03 18:21
While we're waiting for another question, issue, or comment from our audience, I'd like to add a bit to your points here. One thing that I've found consistently among people who have come into the software, interaction, interface, or user experience fields from other traditional fields, is that they often bring perspectives, approaches, and models from those other fields. Having been educated and later experienced in the field of product and industrial design, I naturally looked at what looked like a new field (in the early to mid-1980s) using the historical model of architects becoming industrial designers in the early part of the 20th century. I saw it something like traditional architecture -> industrial design -> interaction design. And I saw both a natural overlap with the physical aspects of products, and at the same time an opportunity to apply the same approaches and thinking to non-physical, dynamic interrelationships. I remember being extremely excited about this model as I started working in this area early on. Later I realized that people, such as Brenda Laurel, were bringing an entirely different perspective and exciting package of ideas and thinking to interaction. Her approaches came from the theater world, and so brought with it this rich set of ideas about experience, presentation, story, etc., that I found very enlightening. Then I met actual former architects that came into the interaction and programming fields. They brought a lot of ideas and perspectives in wayfinding, flow, space, along with many of the same system ideas I'd been taught. I also discovered that much of the architecture world, being so mature, is rich in theory and architects such as Michael Benedikt in the early 1990s with his book, "Cyberspace: First Steps" and Peter Anders in the late nineties with his book, "Envisioning Cyberspace" brought an enormous number of ideas and interaction/interface examples and concepts to light. And there are, of course, many additional fields. Each of which, I imagine, bring yet more ideas and concepts to the table. Another subject, of which I have a fairly strong opinion about, is the issue of how best to teach and bring up new software designers and architects. I come from a tradition of mentor/protoge with a strong "work alongside" ethic. I learned the basics of consulting and designing (in a real world context) from co-consulting alongside other, older and more experienced consultants. I'm happy to say that now, twenty years into my career, I've had many opportunities to do the same for younger designers, and am also still gaining many insights and much knowledge from others. So I guess I have a natural affinity towards software as a craft, in that there is so much to do and refine in such increasingly short periods of time, and there really needs to be an ongoing mixture of hands-on apprenticeship together with derived methodologies and models. It's an exciting time for us to have the opportunity to participate in the beginning period of a field as important as this.
Jesse James Garrett (jjgdotnet) Wed 18 Jun 03 12:51
You're right, Jim. It's exciting to be able to participate in the confluence of all these different traditions, perspectives, and ideas as this new field emerges. The downside is that we probably won't get to see how the story ends -- if the history of other creative fields is any indication, it will take generations for the practice to stabilize and mature. The question you raise about training and preparing new practitioners has been a burning topic in the information architecture community for a while now. Some initial projects are underway to establish academic programs for IA, though what the curriculum for such a program might incorporate remains a matter of some debate. Even if the curriculum question were eventually settled, I'm not sure how successful these programs can be at producing good information architects. In my experience, what really counts in this work is not what you know, but what you *can do* with what you know. Academia does not strike me as the right sort of environment for that necessary skills development. An apprenticeship model seems like the right solution to me. But this carries its own challenges, not least of which is a matter of economics. These days, it's hard enough to convince management to pay for a single IA on a project, let alone two. Ultimately, we'll arrive at a set of practices accepted across the industry -- hopefully sooner rather than later.
James Leftwich, IDSA (jleft) Wed 18 Jun 03 15:34
Good points. Having been trained in an intensive, hands-on, broadbased studio/academy institute, I think that there are many positive benefits to that type of design education. Still, I had received a lot of engineering and science education in a traditional university, and computer science at another college, so I had a very smorgasbord kind of college experience. And regardless of what type of educational training you receive in college, you're always going to have to resign yourself to continually learning for the rest of your life. So to the extent possible, I think we all need to seek out younger designers to mentor and be sounding boards for, even while we ourselves continue to seek out the wisdom, perspective, and advice of others. Jesse, to return to <bslesin>'s question earlier on regarding user testing, can you speak a bit about the process your team goes through in rolling out a designed site? Do you break it up into chunks and test certain implemented portions? Do you try to get a framework up and running and test on that, or in conjunction with rough prototypes, etc.? Also, where do you find the most exciting developments happening today in website and internet-based design? Are you spotting trends you see developing further?
Brian Slesinsky (bslesins) Wed 18 Jun 03 17:08
And what about Mike K's book? :-)
Jesse James Garrett (jjgdotnet) Thu 19 Jun 03 10:48
Mike K's book (Observing the User Experience: A Practitioner's Guide to User Research) is fantastic. It's the most comprehensive resource for user research I've seen, and it's eminently practical to boot. We often don't get to do as much testing as you might think. As consultants, our focus is often limited to one part of the overall product, or one phase of the development process. Our testing is usually qualitative rather than quantitative; that is, we're more likely to be probing patterns of user behavior instead of timing tasks with a stopwatch and calculating error rates. Given the inevitable time and budget limitations, we're always trying to help our clients understand which questions are best answered through testing, and which can be approached in other ways. Also, because people tend to call Adaptive Path for higher-level strategic work, we are more often testing prototypes of a projected future state rather than fully functional, finished products. We do strongly advocate small-scale, incremental testing of features as they evolve and are refined, but we typically don't get to see those plans through. Our clients generally prefer for us to put them on the, er, path and show them how to go forward from there. I see a few nascent trends that are going to be influential over the next few years. One that I mentioned earlier is the shift to Flash as the interface engine for Web applications. For content, Web standards like XHTML and CSS really seem to be gaining momentum. Interoperation between sites through the various RDF-based initiatives also looks like an area rich with possibilities. One trend in particular that I expect to have a dramatic influence on user experience work is the increasing emphasis on user behavior data. User testing has always been something of an imperfect tool, used to glean insights in an artificial setting because we haven't been able to examine how users behave when they're using the product in the real world. We're starting to develop more sophisticated techniques for gathering data that reflects how users interact with the products we develop. Some people see this leading to a reduced role for the information architect, as sites start dynamically reconfiguring their navigation automatically in response to statistical analysis of the latest server logs. But it seems more likely to me that this data will instead be a new source of insight and inspiration for the creative processes information architects are already engaged in. Understanding statistics will be as important for the next generation of information architects as understanding research methods has been for the current generation.
James Leftwich, IDSA (jleft) Thu 19 Jun 03 15:20
Perhaps the evolution to sites that can self-configure based on gathered user data will provide "metadesign" opportunities. That is designing the rules by which the self-configuration occurs, and tuning the same. The underlying reality that this issue emphasized though, is that design is an ever changing field, requiring designers to constantly learn, adapt, and synthesize new approaches. This is not only for the benefit of the products and systems we design, but also for ourselves as a profession. There will always be areas requiring design thought and attention. That's good news for us! Jesse, I'd like to hear your thoughts and experiences in dealing with the issues of keeping the "whole whole." That is, making certain in the end that each of the parts is reconciled and properly balanced and interrelated with one another and again to the whole." This, to me, has always seemed to be the most difficult overall goal to stay on top of. In your book you allude to "Design by Default," "Design by Mimicry," and "Design by Fiat." Reading through those I was reminded of the many times clients or stakeholders would, from the outset, make some fiat regarding a certain way some aspect was to be carried out. The government is particularly fond of this approach. This can often thwart the actual necessary opening up of the whole problem at the beginning in order to reach a truly whole solution. Another familiar stumbling block is getting near the end of a project where the team has managed to wrestle the system into a balanced and logical whole. Then along comes a major stakeholder who demands or decrees some change that essentially "leaves a hole in the whole." That's a phrase I've used on a number of occaisions. I find myself having to explain why it's then necessary to go back through the entire system and rebalance and re-reconcile all the consituent parts amongst themselves and to the whole. Many clients and stakeholders (as well as narrow specialists and sometimes engineers that are also on the team) are resistant to this process. I maintain that the end user experience is in large part dependent upon a well reconciled and interrelated whole. Early on in my career I remember having to fight pretty hard to get this process (which was often seen by others as unnecessary or delaying) pushed through. Today, with increasingly compressed deadlines, the pressures against reconciling the whole is often greater. Can you speak to these crucial issues and possible strategies for dealing with them?
Jesse James Garrett (jjgdotnet) Fri 20 Jun 03 18:17
Holistically successful experiences display two major characteristics. One is consistency -- similar parts working in similar ways. The other is cohesiveness -- parts meshing together to form an integral whole. Both qualities improve the user experience by helping prevent unexpected surprises as users interact with different aspects of the product. Keeping the whole whole is definitely one of the biggest challenges in user experience work. Like you, I've fought this battle over and over again and, frankly, lost more times than I've won. It's a tough problem: Why don't more business people recognize the importance of maintaining consistency and cohesiveness in the user experience? One approach is to persuade them of the importance of these qualities *before* it becomes a point of contention. Gather examples of competing products that display good consistency and cohesiveness, and contrast them against examples of products that don't. Lobbying for these qualities early on makes it harder for people to fight against them later in the process. Ultimately, though, I have to concede that shipping a product with some inconsistencies in the user experience is probably not the worst offense we could commit. But we have to make a commitment to correct those inconsistencies in future versions. Otherwise, the user ends up contending with something like, well, just about any Microsoft product: a teetering tower of contradicting conventions that threatens to topple in on itself at any moment.
Jon Lebkowsky (jonl) Sun 22 Jun 03 21:32
> Gather examples of competing > products that display good consistency and cohesiveness, and contrast > them against examples of products that don't. Jesse, could you give an example of cohesive products vs products that lack cohesion?
Jesse James Garrett (jjgdotnet) Mon 23 Jun 03 19:02
Cohesiveness can be a tricky thing to put your finger on. It's about, as Jim notes, an almost intangible sense of "wholeness" to the product -- that's it's not just an agglomeration of features, but that the relationships between the components has been thought through. The structure of any product -- its information architecture or interaction design -- reflects a mindset, a way of thinking about the subject matter or the task at hand for the user. That mindset, in turn, has its own internal logic. Cohesiveness is lost when parts of the product don't follow the logic dictated by the overarching structure. For example, I've never worked in a photographer's darkroom. But when I was learning Photoshop, I picked up quite a bit of knowledge about darkroom techniques -- because those techniques were the models for many of the tools in Photoshop. In the early versions of the product, this conceptual model allowed users familiar with the darkroom to quickly adapt to working digitally. Photoshop is cohesive because each of the individual parts reflects a common way of thinking about the task of manipulating digital images. On the other hand, a site that keeps related information in separate architectural silos lacks cohesiveness. If you've got one organization scheme for your product lines in the support section and a completely different one in the storefront (and those differences aren't explicitly connected to user tasks), your site won't feel like a cohesive whole. I'm interested to hear Jim's take on this, since it sounds like he's encountered the same issue in working on some very different kinds of products.
James Leftwich, IDSA (jleft) Tue 24 Jun 03 12:54
Cohesiveness is definitely an important and crucial goal in the human interfaces of products, devices, and systems. There are probably a number of areas where development programs for the type of products and systems I design differ from websites. In many products, there's generally more of an emphasis on workflow functionality, tasks involving configuring operational parameters, monitoring, and hands-on interactive control. Generally, there's less information access. But not always. In the handheld medical screening device I just finished, there's a record produced for each screening. The result information is then available for review in another mode, where it's presented in a formatted embodiment. Early on in my career I had to really struggle to try to gain control over the various decision areas necessary to maintain cohesiveness of all of the interactive structure and flow. My approach was simply to be very aggressive and push it through. I generally tried to line up high-level stakeholder support for my being able to do this, and that often came in handy. There's a lot of discussion and opinions (and I believe outright misconceptions) surrounding the issues of design, control, consensus, cohesiveness, etc.. I've generally taken a very firm directorial and design approach. Given the complexity of systems and the pressure on getting it done (and correctly) in shorter and shorter periods of time, I discovered early on that if you want to maintain control over the details of the whole system, you've got to own the map of the interactional system, and make certain that all the implementable resources are done within a consistent process and style. That often means doing it yourself, which is what I had to do for the majority of my career. In other words, it's been my experience that you can't hope to achieve a radically whole, refined, and optimized complex human interface if you don't own the process. Again, I go back to my model - that of traditional building architects. They organize, conceive, develop, and present a full architectural plan for a large-scale building that's then built. That's the approach that I take out of necessity of time and resources, and while it's a very grueling process, it definitely achieves usability success and cohesiveness. Of course, group-oriented design process, collaboration, and consensus are more often held up as the way to approach design. My method is often mischaracterized as "lone wolf design," and overlooked as a way to achieve high-level results in a short time and with the constrained resources that all real-world projects face. I rely on my many documented projects to show clients what they can expect, both in terms of complexity and thoroughness. This also allows a prospective client to see the range of differences between the interactive aspects of different products and systems. I try to achieve buy-in and control at the beginning, so I'm not left begging for it during the crucial development and implementation phases. Design, as I practice it, is a full-contact sport.
Jon Lebkowsky (jonl) Tue 24 Jun 03 20:28
I'm getting that there's a politics of design, the matter of getting consensus about getting buy-in... Jim, you've mentioned consensus, and I'm thinking there's different potential levels of consensus, depending on the client... either consensus about who controls the vision for the site or object, or consensus about a methodology for describing and implementing a vision, or consensus about actual elements of design. Jesse, what's the usual in the projects that you take on: do the clients tend to defer completely with your vision, or sign off on your methodology? Or do you find that they want to collaborate 'closer to the bone'?
Jesse James Garrett (jjgdotnet) Tue 24 Jun 03 20:52
There's a lot of talk about collaboration in user experience development because so few organizations have designated someone to own -- take responsibility for and be held accountable for -- those decisions. Without someone clearly identified as the accountable decision-maker, everyone involved fears that, should upper management be displeased with the results, the blame might somehow fall in their lap. So they overcompensate, second-guessing every user experience decision without thought to the larger ramifications of the choices they make. That's how you end up with what I call "design by fiat", wherein the rationale for every user experience decision is "Because I said so." When nobody is in charge, everybody takes charge. That powerlessness is actually the source of a lot of the problems I hear about from information architects. On one hand, of course it's important and necessary to draw on the strengths of a diverse team to create a product as complex as a Web site. On the other hand, I have certainly seen situations in which "not working collaboratively" was code for "not rolling over when instructed".
James Leftwich, IDSA (jleft) Wed 25 Jun 03 00:51
Regarding these issues, there's also a number of differences between being someone on the inside of a corporation, perhaps working on an internal design team and someone who's an independent design consultant or part of a consulting team. Internal designers generally face a number of buy-in challenges and political barriers to the level of control necessary to establish and implement a large-scale design vision. Even visions that are very collaboratively fed and organized. I believe the model in Jesse's book provides a useful conceptual scaffolding to map a design solution to the understood needs and goals of a company. Communicating that mapping to upper management at the beginning is crucial to successful development and implementation. It favors experienced designers with both design experience and situational power. Design "power," if there is such a thing (throw-weight might be another synonymous phrase) gets built after years of work. Hopefully work that designers, or design teams, are taking time to adequately document, especially as to what was aimed for and what was achieved. Also, directly pursuing relationships with people in upper management positions, capable of waving away many otherwise troublesome middle- management obstacles. Take time to make design an ongoing conversation. Make these conversations an opportunity to educate about design and its relationship other corporate goals. A designer or design team that's serious about using design as a tool for improving business, should document the successes achieved and demonstrate those in the business language that upper management can understand. Demonstrated results are what it takes for a designer or design team to be given control of larger projects. These are sort of the things they don't teach you in design school, and that aren't acknowledged and discussed nearly enough in the design field.
Jesse James Garrett (jjgdotnet) Wed 25 Jun 03 13:38
Jon, as you suggest, there are degrees of buy-in -- not just from client to client, but from person to person within the client organization. Occasionally, our clients are surprised at the amount of time we spend early in the project just talking to people inside the organization. We tell them it's important for us to get as many perspectives on the problem as we can, but there's another reason for spending time talking to so many people. We're not just gathering information, we're evangelizing our work and our methods through these sessions. Building consensus around the idea that user experience is strategically important and valuable is more valuable than having consensus on any particular user experience issue. Moreover, making that case early on makes the later arguments about the details easier to manage. One pattern we've seen is that stakeholders will be very supportive and affirming in the early stages, when the solution remains largely abstract. Then, as it becomes more concrete through the development of details in the higher-level planes of the Elements model, they start to really understand the consequences and get nervous. That's why it's important to keep communicating the connections between the concrete aspects of the user experience and the underlying abstract considerations throughout the process. It's a way of maintaining that early consensus all the way through to the completion of the project.
Kevin S. Eves (kevins) Thu 26 Jun 03 09:14
Let me play the business person role with a devil's advocate twist: in #37 you asked, "Why don't more business people recognize the importance of maintaining consistency and cohesiveness in the user experience?" If it's not recognized by business people, then the value hasn't been made self-evident enough or defined in terms that are meaningful in a broad enough context. In #39 you note, " Cohesiveness can be a tricky thing to put your finger on." In the last couple paragraphs of #44 you acknowledge that understanding at the abstract is incomplete -- for those not accustomed to thinking in abstractions, or perhaps even in the specific abstractions of the user experience design process, what is meant by cohesiveness and consistency may not be intuitively understood. In many cases, I think we're still often in a position of "I know it when I see it", and that may be a lucky case (with too many instances of I don't know it when I see it, still occuring). Elements, and others books like Krug, are useful in providing accessible, understandable models for the non-practioneer, but are also scalable to the support the more robust needs of the practioneer. Let me ask about a vexing issue; familiarity. Let's say an intranet application/product has been in use for a significant period of time (say, 2 years). Let's say the labeling strategy was ill-conceived at launch (ie, launched with a vague/meaningless entry point "Content Services", instead of a more meaningful, task-oriented label like "Policies and Prodcedures"). An opportunity to revisit that labelling decision presents itself: say you test, and you find that new employees find "Policies and Procedures" to be significantly preferable to "Content Services" but more tenured employees prefer "Content Services" because that's what they are familiar with. How would you approach such a design decision when user testing may provide conflicting guidance?
Jesse James Garrett (jjgdotnet) Thu 26 Jun 03 22:42
Kevin, you're right: articulating the value of our work is one of the biggest challenges facing user experience practitioners today. But even if we had a stronger argument, I still suspect it takes a special kind of executive to hear it. Consider that the 20th Century saw case after case of companies deriving essential (and, in some cases, decisive) competitive advantage from an investment in industrial design; and yet so few companies even today make industrial design central to their product strategies. And the industrial designers have a hundred-year headstart on us. Your problem of trying to reconcile the expectations of users familiar with a bad interface with the needs of new users is an interesting one. What happens in situations like this is that the old users learned a difficult system the hard way: by rote memorization. In other words, they aren't really *reading* those labels in the navigation at all. They've just memorized the labels that correspond to the site features they need. 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. If you know this will be an issue going into user research, you have to plan for it. Otherwise, the data will just tell you that the labels the users prefer are the ones they've memorized -- which of course you already knew before you ever did the testing. The key is to divorce the subject matter as fully as possible from the cues they've memorized. Don't show them a prototype that looks like the current site with different items in the navigation. Instead, try giving them written descriptions of site features and asking them to fill in the labels. Get them thinking about the subject matter, not the interface they've been habituated to.
James Leftwich, IDSA (jleft) Fri 27 Jun 03 13:24
> 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?
Jesse James Garrett (jjgdotnet) Sat 28 Jun 03 19:10
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!
James Leftwich, IDSA (jleft) Sat 28 Jun 03 22:06
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/>
Cynthia Dyer-Bennet (cdb) Mon 30 Jun 03 08:18
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.
Members: Enter the conference to participate