Inkwell: Authors and Artists

    
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.
  

    
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. 


 
  

    

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.
  

    


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:  inkwell-hosts@well.com


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.
  

    
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.
  

    

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.
  

    
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.
  

    

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?
  

    
And what about Mike K's book?  :-)
  

    
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.
  

    

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?
  

    
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.
  

    
> 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?
  

    
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.
  

    

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.
  

    
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'?
  

    
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".
  

    

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.
  

    
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.
  

    
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?
  

    
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.
  

    

> 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?
  

    
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!
  

    

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/>
  

    
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.