Slate: Calculated Refinement or simple inertia

by:   |  Posted on

Before we get started, I just wanted to note that my comments are intended to supplement the diagram, rather than vice versa. So be sure to download the PDF version of the diagram to get a full understanding. That said…

No matter how you look at it, publishing content on the web daily is a lot of work. From an information architecture perspective, a daily web publication presents challenges and possibilities no newspaper editor ever had to face. As one of the longest-running daily publications on the web, Slate has dealt
with these issues for years. But it is unclear whether the site’s
current architecture is the result of calculated refinement or
simple inertia.

The architectural decisions here demonstrate one key assumption about the site’s content: the ‘shelf life’ of any given article is about seven days. Navigating to a piece during those first seven days is fairly easy; after that, it becomes very hard.

At a glance, the high-level architecture seems fairly straightforward. But a closer look reveals that the five primary ‘sections’ exist only in the tables of contents. These categories appear nowhere else on the site—not even on the articles themselves. Furthermore, the classification of articles into these
categories only persists for seven days from the date of publication. After that, the section to which a piece belonged is forgotten.

Note the absence of an ‘archive’ area. The only access to articles more than seven days old is through the advanced search page. In place of a browsable archive, Slate offers canned searches by “department” and by author. The author list page works well enough, though such a feature would only be useful in the event that a user already knew the name of the author of a desired piece; but if that were so, the search interface would be sufficient.

The department list page has a greater burden to bear. As the only persistent classification scheme employed on the site, the department list is the only element that can provide the reader with a sense of the range of content and subject matter covered on the site. But the page currently falls far short of this goal. What the user faces here is nothing more than a very long list
that makes no distinction between limited-run features like “Campaign ’98”; occasional, semi-regular features like Michael Kinsley’s “Readme”; and ongoing staples like “Today’s Papers.”

This problem is only exacerbated by the fact that, by and large, the department titles are too clever by half. Even the savviest user could be forgiven for having trouble remembering whether Slate’s roundup of opinions from movie critics was filed under “Critical Mass” or “Summary Judgment.” The cute titles would be fine if the site provided some sort of context for what was to be found inside; as it is, providing a plain list of titles like “Flame Posies”, “Varnish Remover”, and “In the Soup” does little to help readers find specific items or even get a general sense of what the site has to offer.

Letter-sized diagram ( PDF, 41K)

Note: The date on the diagram indicates when the snapshot of the system was taken. Slate may be substantially different now.

Finally, I wanted to find out what sites you’d like to see me diagram in the future. You can post your suggestions here.

Jesse James Garrett is one of the founders of Adaptive Path, a user experience consultancy based in San Francisco. His book “The Elements of User Experience” is forthcoming from New Riders.

The Age of Findability

by:   |  Posted on

The Third Annual Information Architecture Summit in Baltimore compelled my first visit to the new, state-of-the-art terminal at Detroit Metropolitan Airport.

As I approached the airport on a cold March morning, perhaps I should have been excited. After all, the $1.2 billion Northwest World Gateway was billed as the terminal of the future. According to Northwest Airlines, I was about to have “one of the world’s greatest travel experiences.”

But in reality, I felt dread. I was late for my flight and desperately needed a restroom and a cup of coffee in exactly that order. What I didn’t need was the challenge of finding my way in a new airport.

After circumnavigating “the largest single parking structure in the world ever built at one time” three times, in search of long-term parking, I finally broke down, asked a security guard, and was told the signs for international parking actually lead to long-term parking. Of course!

Several circles of hell later, freshly sprung from the airport security checkpoint and a full-body pat down, I emerged into the spectacular center of Concourse A. High-arched ceilings soared above. Luxury retail stores lined the hall. Straight ahead, a black granite elliptical water fountain fired choreographed, illuminated streams of water, “representing the connections made via global travel.”

Unfortunately, what I couldn’t find was a sign pointing to one of the 475 public restroom stalls inside this 2-million square-foot complex. To cut a long and painful story short, I was 30,000 feet in the air before I finally got my cup of coffee.

Name that pain
Jakob Nielsen might say this airport has usability problems. Conduct a heuristic evaluation, run a few user tests, fix the worst blunders, and you’re on your way. That’s the great thing about usability. It applies to everything. Websites, software, cameras, fishing rods and airports. It’s one hell of a powerful word.

Lou Rosenfeld might say this airport has information architecture problems. But he probably wouldn’t. While maps and signs fit comfortably into the domain of information architecture, it’s a stretch to include the structural design of an airport terminal or the solicitation of feedback from frustrated travelers. Like it or not, information architecture has boundaries. Unfortunately, our clumsy two-word label isn’t quite as flexible as Jakob’s.

That’s why I say this airport has findability problems. The difficultly I had finding my way dominated all other aspects of the experience. Like usability, findability applies broadly across all sorts of physical and virtual environments. And, perhaps most important, it’s only one word!

Post-Hum(or)ous self-definition
At Argus Associates, we built a consulting firm that specialized in “information architecture” and we wrote a book to explain and explore the topic.

In the past year, our company has been post-hum(or)ously accused of practicing “Content IA,” a pejorative label that bothers me.

It’s absolutely true that we Argonauts brought the strengths and biases of library science to the IA table. And, we certainly focused more on organizing sites with massive amounts of content than on designing task and process flows for online applications.

However, this focus was indicative, not of a love for content, but of a passion for designing systems that help people find what they need.

Unfortunately, we couldn’t declare this passion too openly, because in the 1990s most customers weren’t buying “findability.”

At first, they focused on image and technology. Remember the early days of glossy brochure web sites and hyperactive Java applications? Later, they learned to ask for usability, scalability and manageability. They had felt some pain, but not enough.

In order to create a big tent, we sold “information architecture,” striking a delicate balance between our clients’ needs and wants. But all along, we maintained a deep conviction that, in the long run, the most important and challenging aspect of our work would involve enabling people to find stuff.

So, if you want to label the Argus brand of information architecture, rather than calling it Argus IA or Content IA or Polar Bear IA, I humbly suggest that you call it Findability IA. Or else!

Arrows over boxes
True to form, I’ve always resisted attempts to canonically define information architecture. In an emerging field, the last thing you want to do is prematurely place its identity inside a box, or should I say coffin?

However, information architecture is entering a new stage of maturity. IA roles and responsibilities are firming up. The IA community is taking shape. While we insiders argue over the minutia, a de facto definition of information architecture has emerged and reached critical mass. There’s no going back.

On one level, this is wonderfully exciting. For many of us who labored in obscurity in the early 1990s, this is validation that our vision of the future wasn’t completely crazy.

But this is also frightening. With maturity comes rigidity. We’re finding ourselves trapped inside boxes of our own making. And those arrows that connect us to related disciplines and new challenges are looking mighty appealing.

After all, it’s a tough sell to argue that content management and knowledge management and social computing and participation economics are all components of the big umbrella of information architecture. The IA tent is simply not that big.

And yet, we information architects are fascinated by these topics. We yearn to escape our boxes and follow the arrows.

For me, findability delivers this freedom. It doesn’t replace information architecture. And it’s really not a school or brand of information architecture. Findability is about recognizing that we live in a multi-dimensional world, and deciding to explore new facets that cut across traditional boundaries.

Findability isn’t limited to content. Nor is it limited to the Web. Findability is about designing systems that help people find what they need.

The age of findability
Even inside the small world of user experience design, findability doesn’t get enough attention. Interaction design is sexier. Usability is more obvious.

And yet, findability will eventually be recognized as a central and defining challenge in the development of web sites, intranets, knowledge management systems and online communities.

Why? Because the growing size and importance of our systems place a huge burden on findability. As Lou posits “despite this growth, the set of usability and interaction design problems doesn’t really change…(but) information architecture does get more and more challenging.”

Ample evidence exists to support this bold claim. Companies are failing to deliver findability. For example, a recent study by Vividence Research found poorly organized search results and poor information architecture design to be the two most common and serious usability problems.

This resonates with my experience interviewing users of Fortune 500 web sites and intranets. Some of these poor souls are ready to burst into tears as they recount their frustrations trying to find what they need inside these massive information spaces.

At the IA Summit, usability expert Steve Krug also agreed with this bold claim, noting that his company’s motto doesn’t apply to the challenges faced by information architects. Designing for findability is rocket surgery!

In the coming years, our work will only become more difficult. But that’s a good thing. Consider the following passage from a fascinating article written by business strategy guru Michael Porter:

“Companies need to stop their rush to adopt generic ‘out of the box’ packaged applications and instead tailor their deployment of Internet technology to their particular strengths…The very difficulty of the task contributes to the sustainability of the resulting competitive advantage.”1

That last sentence applies directly to the work we do. We all have a great deal of difficult and important work ahead. There’s an awful lot of findability in our future.

Where do we go from here?
I wrote this article to explore findabilty as both a word and a concept. I’d be very interested in your reactions. Does findability strike a chord? Are you intrigued by the design of findable objects? Are you ready to become a findability engineer? Or does this pseudo-word annoy you? Is findability overrated? Do you prefer a future filled with expensive, beautiful airports that just happen to be unnavigable? Comments please!

For more information:

  1. “Strategy and the Internet,” by Michael E. Porter in Harvard Business Review, March 2001.
Peter Morville is President of Semantic Studios, an information architecture and knowledge management consulting firm and co-author of the best-selling book, “Information Architecture for the World Wide Web.”

Just How Far Beyond HCI is Interaction Design?

by:   |  Posted on

While reading a new textbook, “Interaction Design: Beyond Human-Computer Interaction” by Jenny Preece, Yvonne Rogers and Helen Sharp, I recognized my own reactions from several recent conversations, talks and “My concern is that the book misrepresents the field of interaction design and hence limits its potential.”papers. The feeling was familiar: the authors were adopting, and adapting, the “design” label a bit too loosely. The academic field of human-computer interaction (HCI) has strong roots in the traditions of behavioral science and engineering. Re-labeling it as interaction design does not in itself move it “beyond.”

Interaction design is a fairly recent concept, albeit growing steadily in terms of professional practice, higher education and even job descriptions. It clearly owes part of its heritage to HCI, even though the turns within established design fields—such as graphic design, product design and architecture—towards the digital material are every bit as important.

There is no commonly agreed definition of interaction design; most people in the field, however, would probably subscribe to a general orientation towards shaping software, websites, video games and other digital artifacts, with particular attention to the qualities of the experiences they provide to users.

The word “interaction” in interaction design captures the time-based, and at the same time, nonlinear nature of the digital, a quality that sets it apart from most if not all other design materials. “Design” is of course a word with multiple meanings, but some typical connotations in more mature design disciplines and in design theory include the parallel emergence of question and answer, the activity of exploring possible futures, the synthesis of reason and emotion, the intervention on many simultaneous levels in a design situation.

The scope of interaction design opens up possibilities for genuinely better user experiences of information technology. HCI has contributed a great deal to the elimination of obvious problems for the users, but its focus on goals, tasks and usability makes it rather limited in terms of positive innovation. My concern is that the book misrepresents the field of interaction design and hence limits its potential.

In the book, there are some excellent interviews with prominent representatives of the interaction design field. In one of those interviews, Gitta Salomon states that (p. 33) “interaction design is a design discipline.” This observation is not taken seriously in the book as a whole. Many issues taken for granted in HCI need to be rethought in an interaction design textbook.

In the preface, the authors define interaction design as “designing interactive products to support people in their everyday and working lives.” But does it make sense to say that a computer game supports people? Even if it “supports” the player’s assumed goals of experiencing excitement or challenge, how does it “support” the player’s boyfriend’s desire to see a bit more of his girlfriend? Is a teenager’s experience of spending time in an online chat community primarily a “supportive” one? Does a piece of techno-critical digital art, such as the work by Anthony Dunne and Fiona Raby, “support” the viewer?

My point is not that “supporting” is necessarily bad, only that it implies a certain ideology: an HCI perspective of goal-driven users whose use should be made as effective and efficient as possible. Interestingly, the same paragraph goes on to quote Terry Winograd’s suggested definition of interaction design as “the design of spaces for human communication and interaction.” The difference between the two definitions would be worth a book of its own.

On the nature of design, the authors (p. 166) rely on “the definition of design from the Oxford English Dictionary [which] captures the essence of design very well: ‘(design is) a plan or scheme conceived in the mind and intended for subsequent execution.’” This notion of design as a plan-then-act activity fits well with the software engineering approach permeating most contemporary HCI, but perhaps not so well with design theory. Planning is rather viewed as performed through acting, expressing, communicating. The execution is the planning; the planning is the execution. Together, they are part of the evolution known as design. The prominent design theorist J.C. Jones gives the following advice:

“First, recognize that the ‘right’ requirements are in principle unknowable by users, customers and designers at the start. Devise the design process, and the formal agreement between designers and customers and users, to be sensitive to what is learnt by any of the parties as the design evolves.”

The implications of this view for practical IT development are substantial and largely unclear. That is precisely why gifted researchers and writers should devote their efforts to it.

There is also the question of what to design. A HCI perspective encourages the view of adapting new technology as painlessly as possible to existing users and practices (p. 5): “one can be more principled in deciding which [interaction design] choices to make by basing them on an understanding of the users. This involves: taking into account what people are good and bad at, considering what might help people with the way they currently do things, thinking through what might provide quality user experiences, listening to what people want and getting them involved in the design, using ‘tried and tested’ user-based techniques during the design process.”

But design is innovative; it is about exploring possible futures, where the users as well as the technology are different from today. In some situations, it even makes more sense to think in terms of designing the users. As Terry Winograd points out in his interview (p. 71): “one of the biggest challenges is what Pelle Ehn calls the dialectic between tradition and transcendence. That is, people work and live in certain ways already, and they understand how to adapt that within a small range, but they don’t have an understanding or a feel for what it would mean to make a radical change, for example, to change their way of doing business on the Internet before it was around, or to change their way of writing from pen and paper when word processors weren’t around. I think what the designer is trying to do is to envision things for users that the users can’t yet envision. The hard part is not fixing little problems, but designing things that are both innovative and that work.”

Consequently, I’d like to make three assertions:

First, interaction design is a design discipline, which means something other than the science-and-engineering perspectives of HCI.

How, then, can we approach the question of quality in interaction design? How can we tell good from bad, and how can we devise development processes and cultures of practice to increase the chances of reaching good designs?

The HCI answer (p. 19) is to express quality in terms of measurable usability goals and to address “the rest” as we please: “Usability goals are central to interaction design and are operationalized through specific criteria. User experience goals are…less clearly defined.” But taking the approach suggested by the authors to address these less clearly defined user experience goals results in equating a desktop video conference system for distance learning with an online community that provides support for people who have recently been bereaved (p. 20).

A more well-grounded design approach would offer better ways of approaching the quality issue. Some useful starting points may be to view design as knowledge construction within a community of practice, to consider design-theoretical approaches to articulating the languages and meanings of products (so-called product semantics), and to consider product or use genres as knowledge-organizing systems.

An issue of particular interest is the possible role of critics in interaction design. One can imagine a field of interaction design criticism in analogy with more mature design fields such as architecture or graphic design. This appears problematic from a HCI perspective (p. 182): “Finding measurable characteristics for the user experience criteria is even harder, though. How do you measure satisfaction, fun, motivation or aesthetics? What is entertaining to one person may be boring to another; these kinds of criteria are subjective and so cannot be measured objectively.” However, it is possible to talk about good and bad interaction design also in broader contexts. A few examples exist of more relevant interaction design criticism, but there is clearly room for much development.

Secondly, the notion of quality in interaction design is not well developed. Neither are the social structures needed to develop and sustain the notion. A HCI perspective is not the most appropriate starting point.

The emphasis on usability and task support also carries a notion of aesthetic qualities as equivalent to visual embellishment. On the topic of simplicity in web design, the authors state (p. 27) “A certain amount of graphics, shading, coloring and formatting can make a site aesthetically pleasing and enjoyable to use… The key is getting the right balance between aesthetic appeal and the right amount and kind of information per page.”

But if aesthetics concern the sensual and perceptual qualities of experience as a whole, how can there be a tradeoff between aesthetic appeal and the right kind of information? “Right” is an aesthetic judgment in this context. In another interview in the book, Gillian Crampton Smith makes the following observation (p. 199). “Obviously there’s the aesthetic of what something looks like or feels like but there’s also the aesthetic of how it works as well. You can talk about an elegant way of doing something as well as an elegant look.”

Separating the usability of a system from how it affects its users, factoring out ”the aesthetics” in terms of “pleasing shapes, fonts, colors and graphical elements,” is problematic. Every interaction involves feeling as well as intellect; aesthetic qualities reside in the overall interaction, which is determined above all by the functions, structures, social action spaces and temporal qualities (the dynamic gestalt) of the system.

Third, it makes sense to talk about aesthetic qualities of interaction, even though we lack an adequate language as yet to do so. But the language of HCI is not the best place to look for inspiration.

To conclude, I think the book discussed here represents a larger movement within HCI towards design. My point is that this movement involves a shift in philosophical foundations as well as professional practice. The book is a very capable presentation of contemporary HCI, covering relevant technological developments as well as the growing insight that HCI “users” in fact do their (effective and efficient) work in social environments. It is pedagogically well structured and presented, and would be an obvious recommendation for any foundational HCI class.

But it does not go beyond HCI. More specifically, it is not a book about interaction design. Taking the philosophical and practical shifts more seriously will involve dealing with the issues I’ve raised if we truly want to go “beyond HCI.”

For more information:

AIGA Experience Design – Past, Present and Future

by:   |  Posted on

Clement Mok, widely considered one of the early leaders of the IA/UE movement, is the current president of the American Institute of Graphic Arts. He served as a creative director at Apple for five years before he founded Studio Archetype interaction design and branding agency in 1988. When Sapient “Can those who design experiences find a useful, lasting home within the age-old AIGA?”acquired Studio Archetype in 1998, Mok became Chief Creative Officer. Now consulting, he continues to shape Sapient’s long term strategy as Chairman of its Innovation Advisory Board.

Terry Swack, a 20-year veteran of the design profession as well as a leading digital strategist and designer, is the AIGA Experience Design national chair and serves on the AIGA board of directors. Formerly, Terry was founder and CEO of TSDesign, an Internet strategy and product design firm acquired by Razorfish in 1999. Terry now consults independently, is a contributing reviewer to Internet World’s Deconstructing column and is writing a book on the impact of experience design strategy on business.

In 1998 Terry and Clement, organized the Advance for Design Forum, an initiative of the AIGA. Its purpose was to ‘create a forum for the advance of experience design in the network economy and to define and build a community of practitioners who will shape and advocate for the role of design in a world that is increasingly digital’. In 2000 it formally became the AIGA Experience Design community of interest and now has a national membership with groups established in major US cities and London.

The two are uniquely qualified to elucidate the evolution and future of AIGA ED and to answer the important question: Can those who design experiences find a useful, lasting home within the age-old AIGA?

They recently talked with Erin Malone of Boxes and Arrows:

B&A: What was your original motivation for beginning the Experience Design community of interest?

Terry & Clement: Like many design practitioners in the mid-’90s, Terry and I were thrust into developing and evolving our respective design practices for the growing needs of online initiatives by our clients. Being early converts, we found ourselves in conferences, workshops and seminars preaching the Internet gospel and sharing insights and methodologies on creating order out of the inherent unstructured nature of the Internet.

Repeatedly, we found ourselves with other like-minded practitioners in hallway conversations comparing notes. We rarely had time to see each other’s presentations or have meaningful discourse about the challenges of advancing the practice and the profession. Each of us were making the same mistakes and essentially inventing the same methodology only with different labels. Terry and I were fed up with these chance meetings, and we were hoping someone would organize a conference that will bring together people who we admired and respected from afar, but we didn’t know what organization would do it.

Coincidently, Ric Grefe, the director of AIGA, approached both Clement and I to see if we wanted to develop ‘New Media’ design programming for AIGA. Despite the large number of AIGA members who worked in this arena, we felt this new community and practice was more than just media involving the integration or the complimentary use of different design processes with varying emphasis on different visualization and behavioral manipulation skills and disciplines. There was no obvious home for this community, but we had to start somewhere.

AIGA was willing to incubate this group as Clement and I envisioned it. The attendees of the first Advance for Design summit in Nantucket in 1998 were drawn essentially from our personal Rolodexes. They were from a range of design and design-related specializations: designers, clients and educators from corporations, agencies, user research firms and new media/Internet consulting firms. The background of the attendees represented the composition of the community we wanted to build-eclectic and diverse with a common passion for (big as well as little) design.

Interestingly, the attendees were surprised AIGA would sponsor Advance for Design, but it was clear these practitioners felt equally disconnected from ACM SIGCHI, IDSA (Industrial Design Society of America) or AIP (Association of Internet Professionals). So we opted to define our own community and appreciated the AIGA’s support. !!!!!

B&A: Why was it called Advance for Design?

Terry & Clement: It was not a conference or a meeting. All participants were presenters and attendees. The goal was to figure out how to learn and share knowledge among us. In short, to advance the profession and the practice of design … hence the name.

B&A: The AIGA Experience Design community of interest began over four years ago. Why has it taken so long to come into the mainstream IA/UE/UI community?

Terry & Clement: Yes, we’ve had four Advance for Design summits, but the group really did not become an official part of AIGA until after the third meeting. That’s when it became apparent that “Design”- the creating of form, the process, as well as the commitment to human-centered design and user experience-was the common thread. We all contributed to the design of experience. AIGA had already demonstrated its willingness to help develop the group, so we made the affiliation official and gave the group a name. So we see this as a two-year-old organization rather than four.

B&A: Do you feel change, inclusion and acceptance of this practice and organization is happening fast enough?

Terry & Clement: It’s relative to one’s perspective as to what’s fast. Behaviors and beliefs don’t change overnight. It changes at the speed of habit (that’s a Paul Saffo quote). We also don’t believe the practice and the organization are one and the same. Things happen at different speeds out in the world relative to the speed of a volunteer organization. 😉

B&A: How do you reconcile the notion of an Experience Design Community of practice with being sponsored/supported by the AIGA, which has a reputation out there of being solely the home of graphic designers?

Terry & Clement: AIGA has been around nearly a hundred years because it has adapted to the regular transformation of the design profession. “AIGA uses the term “Experience Design” to describe a community of practice-not a single profession or discipline.”AIGA used to be an organization about printing (graphic arts-the GA in AIGA). It changed into an organization about typographic design and publication design. It morphed into an organization for graphic designers in the ’70s and now it’s out to earn the reputation to be an organization about Experience Design.

Those who perceive AIGA as a home of graphic designers may want to look closely at its activities, membership, conferences and competitions. In recent years, it has become a leader in a number of areas that are not part of its traditional perception-visual culture, design for film and television, converging media and brand strategy.

And lastly, for those who simply have problems with the name, AIGA is not unlike SPRINT or IBM. Those companies chose to keep their historical names-through the use of acronyms-despite how they’ve changed over time. I’d wager to say that many people have never heard a mainframe computer referred to as a ‘business machine’. IBM is now the name of the company that invented “e-business”.

B&A: Do you think AIGA ED will ever branch off on its own, as a separate organization?

Terry & Clement: Simply put: AIGA has 12 staff and 17,000+ members. The organization is the membership. AIGA has put no limitations on who the community is or how it evolves. The Experience Design community’s growth is purely a function of who has chosen to be involved and what they believe is important-and it is largely made up of IA/UE/UI folks.

Despite this, we think the more important question is which institutional characteristics will serve practitioners best in achieving a sense of community, the ability to share information and the means to develop effective communication programs that will enhance understanding and respect for the role of the practitioners. These are the needs of a profession. We think the organization should have sufficient infrastructure to survive the ebb and flow of volunteer energy and be able to reach out to those in allied fields who share teams and who will advocate for the highest and best practices. Within this structure, one can be as introspective as one wants without becoming self-limiting on the reach of this new community. At the moment, it appears these conditions are better met within AIGA than on one’s own. There are many organizations with great intents yet no critical mass or influence.

B&A: The concept “A Community of Practice,” which was discussed at last year’s Summit, has a lot of value. How are you evangelizing this notion to the greater field?

Terry & Clement: AIGA uses the term “Experience Design” to describe a community of practice-not a single profession or discipline. Designing effective experiences requires many different types of professionals with a broad range of knowledge.

However, we now better understand the difference between a community of interest and a community of practice. This distinction has become an important question as we move forward in the community’s development relative to other user-experience professional organizations.

Posted recently to the SIGIA-L discussion list was link to an article titled Communities of Practice, by Martin White:

‘A community of practice is a way of developing best practice in a given area, established by members who wish to develop their specific expertise through open participation in the creation and exchange of knowledge. Of course best practice changes with time and with business circumstance, and so these communities will also need to adapt …

…. To be successful, online communities must show prompt and relevant benefits to both the employer and the employee. Communities constantly evolve and must be managed to keep them fresh and alive. Every community has a life cycle of infancy, maturity and death. It is possible however with good community management to prevent the death of a community by constantly evolving it with the changing needs of its members, and introducing new functionality, topics or subgroups.’

Martin’s article was written for a business audience (i.e., communities within one organization). This perspective helped us realize the statement’s relevance to us-how we should be looking at the communities within AIGA Experience Design.

It also distinguishes the two terms: community of interest (COI) and community of practice (COP). At the risk of contradicting ourselves, by this definition, AIGA Experience Design is really a community of interest made up of many communities of practice.

We are continuing to examine how AIGA Experience Design can support and advance the causes for discrete types of COPs, and which ones. A clear start are the role and knowledge presentations presented at the 4th Advance for Design, in 2001 (visit http://www.aiga.org/content.cfm?contentalias=fourthadvancefordesignsummit to download these presentations – which are all listed in the right column of the page). We will continue to refine those definitions and add tools, models and processes to support them.

B&A: There is a lot of work being done by both of you, by Lou Rosenfeld and others, to create a community that embraces the new collaborative discipline. Do you feel that the AIGA is the right home for this or should there be some sort of triad (AIGA, ASIS, CHI) coalition or even an organizationally agnostic new group created?

Terry & Clement: Given that experience design is about collaboration, we value the opportunity to participate in the group to determine how we collectively can serve the needs of the community. The group will have several meetings in the coming months with the goal of defining some actionable strategies.

That said, we started AIGA Experience Design specifically to build a community that draws from a variety of disciplines. Practitioners will be attracted to organizations that reflect the narrowness of their interests and/or their ambition for broader reach-and this will allow a number of institutions to fill the need. We believe that the interdisciplinary nature of experience design as we see it and the commitment to developing educational and professional standards, as well as communication and advocacy programs, is well supported within AIGA. Rather than agnosticism, we believe that an organization that can advance the community’s interest is the predominant attribute we are seeking. B&A: Recently there was an interesting discussion on the AIGAED discussion list that criticized the Graphic Design field for perpetuating the “Designer as Stylist” perception, through annuals and awards and the cult of personality that is so often showcased in the magazines. What is your reaction to“AIGA Experience Design is the community that brings all types of Experience Design practitioners together to focus on larger issues of business value and collaborative practice and methods.” this? How do you think the ED SIG can help change people’s perceptions of Design and the AIGA?

Terry & Clement: Design having a balanced focus on behavioral, social and visual esthetics is what’s important to us. There will be always be practitioners who will work at the extremes. It will require practitioners, educators and professional organizations to shape and redefine the new center of gravity for design. It’s hard work and it needs to be done if our profession will have any credibility in the marketplace. The ED SIG can’t do it alone. It requires changes at all level. AIGA is the only organization that has the critical mass and numbers to make the meaningful changes.

B&A: Do you think the party is too big? Are we fracturing the discipline too finely? The list on the AIGA ED page consists of:

  • Design planner
  • Design strategist
  • Business strategist
  • Brand strategist
  • Visual systems designer
  • Brand applications designer
  • Creative director
  • User researcher
  • Usability specialist
  • Information architect
  • Information designer
  • Interaction designer
  • Software designer

Terry & Clement: To the contrary- the party is not too big by virtue of being inclusive of those who tend to work together on teams to accomplish a solution within the practice of experience design.

AIGA Experience Design is the community that brings all types of Experience Design practitioners together to focus on larger issues of business value and collaborative practice and methods. Because of this, AIGA Experience Design members are designers who are interested in exploring new boundaries of their professions as they are evolving across multiple disciplines. This includes people who belong to other professional organizations, as well as people who don’t identify with a traditional profession and are looking for a new “home” community.

The list above is from last summer’s summit when we examined experience design ‘roles’ people might play in their organizations or on teams. The words serve to summarize skills and knowledge required to play them. As many of these roles have overlapping skills and knowledge, it’s not as important what they’re called, as long as we know what they do. You’ll find on our new Web site, coming within the next month, an even more inclusive and expanded list of skills-not roles or titles-found in the AIGA Experience Design community (following are just the headings for each section). Members of this community have skills from:

  • the online and digital industries
  • the software industry
  • the communication design and broadcast industries
  • the marketing/research/advertising industries
  • industrial design
  • exhibit design
  • the environmental/interior design industries

B&A: What happened to the Graphic Designer? Is this title good enough anymore? Is it too loaded within the software, IA, HCI field to be a respected member of the team?

Terry & Clement: The titles software engineer, programmer, information architect and HCI specialist are also loaded, so why single out graphic designer? People who call themselves graphic designers might also use terms like designer, visual designer, communication designer or communication strategist to describe their current roles. But in the new Web site text, you’ll find the term graphic designer. 😉

B&A: The joint forum with CHI at this year’s CHI is a great start in embracing the related disciplines. How has the CHI forum been received?

Terry & Clement: Anecdotally, the CHI2002 / AIGA Experience Design FORUM is being received quite well. People are happy to see more design at CHI, and we’re collaboratively happy to accommodate. We’ll know better when the rubber hits the road and we know the final attendance numbers!

B&A: What outcomes are you hoping for when it is all over? What events, conferences, seminars are next?

Terry & Clement: There will be further collaboration, which we expect to discuss at the FORUM.

B&A: Is there anything like this planned with the ASIST community? Was there an official AIGA presence at the ASIST IA Summit in March?

Terry & Clement: I (Terry) attended, but the timing was difficult for others simply because of the scheduling of AIGA’s national design conference the following weekend in DC. A challenge of logistics not interests. As far as collaboration, I’m looking forward to seeing what comes out of the planning group you asked about a few questions earlier.

B&A: Where do you see the AIGA ED community going in the next few years?

Terry & Clement: We plan to continue to execute on our mission “to build an interdisciplinary community of professionals who design for a world in which experiences are increasingly digital and connected” by continuing to address the most relevant issues of the community.

B&A: At last year’s summit, there were a lot of design educators there. Has AIGAED been working to develop a recommended curriculum for universities and art schools for this new community of practice?

Terry & Clement: Yes. AIGA is the institution that works with the National Association of Schools of Art and Design (NASAD) to develop accreditation criteria for four-year and graduate programs in design. In this capacity, we have developed with the ED community a set of criteria for an effective program (focusing on outcomes). The involvement of educators in the community and the publication of Loop, AIGA Journal of Interaction Design Education, are attempts to work with the education community to stimulate thinking about curricular issues.

B&A: How is it being accepted?

Terry & Clement: NASAD and the schools it accredits welcome the guidance. Acceptance in the educational community, however, is not as important as their engagement. In this regard, AIGA and the ED community are attempting to enable the community to become engaged around critical issues to the professional community (and its needs from the educational community). This takes time, but there do not appear to be other comparable efforts going on.

B&A: As a hiring manager myself, I have found the well-rounded skills needed for this role are often lacking in fresh graduates-or they have two degrees and have spent too many years in school. Are there any schools with something acceptable in place?

Terry & Clement: Schools are in dire need of overhauling their curriculum to reflect the realities of the marketplace. This is not a criticism of design schools but also of computer science programs, business schools and engineering schools as well.

B&A: As the AIGA ED gets off the ground, sponsoring conferences and seminars beyond the small Summits, what’s next for the two of you?

Terry & Clement: Clement is the president of AIGA and Terry is a national board member and chair of AIGA ED. We have our hands pretty full, not only planning this year, but also working with Ric and the rest of the board to determine where the organization is going. For more information than that, you’ll just have to get involved and contribute to what you’d like to see happen!

We’d also like to thank you for inviting us to participate in Boxes and Arrows!

For more information:

Erin Malone is currently a Product Design Director at AOL in the Web Properties division. She has been a practicing interaction, interface and information designer since 1993. She can be reached at .

The Big O: IA Lessons from Orienteering

by:   |  Posted on

Orienteering is a sport where competitors use a map pre-marked with a series of control markers to navigate through a terrain (usually a park). Competitive orienteers run between control markers, using a combination of map-reading techniques and navigation strategies to find the quickest route.

Backstory
Last June I found myself in Calgary, Alberta, on business. I had a few hours to spare in the morning, so I grabbed the map of Nose Hill Park I’d ordered from the local orienteering club, and went out to practice my orienteering. From the parking lot, I started to run up the large hill to the first control marker, carefully checking my map and route along the way.

“Designing effective catching features is similar to providing a strong information scent. Within ten minutes I was lost. The terrain I was running across didn’t resemble the terrain described on the map. What should have been open land was actually a small forest. A dozen unmarked paths crisscrossed through the trees. While searching for that first control, I had two thoughts. First, I was feeling the same kind of frustration I’d seen from people in user testing (“It should be here… why isn’t it here?”). Second, if orienteering isn’t that different from web navigation, then maybe it can inform the practice of information architecture.

John Rhodes used a real-world navigation metaphor to explain information architecture in his WebWord article “Information Architecture for the Rest of Us.” The article goes a step further by applying orienteering strategies and terms to IA and navigation design. Several orienteering strategies – including map simplification and contact, navigating by checkpoints, rough and precise map reading, and using attack points to find the goal – have useful IA parallels.

Simplification and rough map reading
An orienteering map has too much detail to absorb quickly, and most of it is extraneous to the orienteer’s goal of finding the shortest path from their location to the next control. A good orienteer maintains “map contact” by checking her map once every five to ten seconds. Simplification – the practice of ignoring unnecessary map details and focusing on important ones – is an important skill in orienteering.

This kind of rough map reading is analogous to scanning a web page for information (see Chapter 2, page 22 in Steve Krug’s book, Don’t Make Me Think). Both the orienteer and the user know their goal isn’t immediately in front of them, so they focus only on details that will bring them closer to their goal.

Checkpoints and catching features
Checkpoints and catching features are easily-recognized features of the terrain, such as a hill or a fork in a path. Just as the name suggests, orienteers use them as cues to “catch” themselves, or to stop, check the map and adjust their route. Catching features also allow the orienteer to focus on only one or two details on the map, and to create ad hoc, but effective, navigation rules that allow for speedy movement. For example, “Follow the edge of the forest for one kilometer until I reach the boulder.”

Designing checkpoints and catching features
Designing effective catching features is similar to providing a strong information scent. Effective labels and logical groupings of content can help users create those ad hoc navigation rules that let them move quickly to the area of the site they want. Images help reduce the ambiguity of labels. You want to make the features of the terrain as clear and unambiguous as possible, allowing your users to move rapidly to their goal.

Precision map reading and attack points
In usability testing, subjects often reach a point where they are confident they can complete a task – such as filling in a form, making a purchase or retrieving a particular piece of information. Many of them get to a point where they can say, “Okay, I know I can do that from here.” In orienteering terms, they have reached an attack point.

As experienced orienteers move toward a control marker, they shift from rough map reading to precision map reading. Precision map reading involves moving slowly, paying more attention to the map details, and scanning the terrain for the control. Typically, when approaching a control, the orienteer will pick a catching feature to use as an attack point. Arrival at the attack point is where the precision map reading begins.

Creating attack points
An attack point is where a user starts to work at reaching their goal, such as purchasing a product or reading an article. When the goal is simple, such as reading today’s headlines, the homepage often serves as the attack point. With a more complicated goal, like purchasing a PDA, several attack points may be offered based on users’ goals.

Attack points can be links, pictures or any other combination of page elements that facilitate the shift between rough and precise reading. Amazon, AOL and AT&T use the search box as an attack point by using keywords to take users directly to a page, or by presenting a filtered set of best-bet search results.

Figure 1
Figure 2

Amazon vs. Buy.com
To put the orienteering analogy to the test, let’s compare Amazon and Buy.com and look at how we might “attack” our goal of purchasing a PDA.

Figure 1 shows the main electronics page for Amazon and Buy.com. In addition to the left-hand menu, Amazon has prominent images and descriptions – these are checkpoints or catching features – for the main electronics categories. Buy.com merely has a menu on the left-hand side, and probably hasn’t included enough catching features for users who want PDAs However, the Buy.com list of featured products on this page is essentially a series of attack points.

Figure 2 compares the main PDA page from each site. Buy.com shows several products, attack points for people who want to purchase those products. Amazon’s page is a hybrid of checkpoints in the upper left, additional navigation for users seeking a particular brand of PDA or operating system, and attack points on the right. Offscreen, Amazon also offers two unconventional attack points – a buying guide and Consumer Reports product reviews. These might help “rough map readers” who are unsure about committing to a purchase or are lost in the section to switch into their precise map reading mode.

It’s also worth noting that in Figure 2 the design of each page changes. Those changes are consistent with what we’d expect from attack points: the product images are larger, there are more details on each product, and on Amazon the left-hand menu disappears.

Conclusion
Analogies between spatial and hypertext navigation tend to break down at some point, and this one is no exception. But up to that point, these analogies can still provide us with a helpful framework for analyzing site structures and designs. My hope is that by borrowing from orienteering’s well-developed navigation strategies, vocabulary and practice, IAs gain another way of thinking about, explaining and solving navigation problems.

(And you should really go out and try it, since it’s a helluva lot of fun, and easy too.)

For more information:

Gene Smith works for the government of Alberta, Canada. He leads the team responsible for the content, IA, design and usability of the main government web site (http://www.gov.ab.ca), and manages a government-wide web site standards process. He occasionally writes on his web site www.atomiq.org. Most Wednesday nights during the summer you can find him orienteering with his local orienteering club.

Alan Cooper Speaks! Impressions from BayCHI April 2002

by:   |  Posted on

On the second Tuesday of every month, BayCHI, the Bay Area chapter of the Association for Computing Machinery’s (ACM) special interest group on Computer-Human Interaction convenes at the research center formerly known as Xerox PARC. Phew! Now that we’ve got that mouthful out of the way, let’s get on with it…

This month we were treated to a one-two punch from Cooper’s man at the helm, Alan Cooper, and their Director of Design Research and Development, Robert Reimann.

“As an Interaction Designer, I’m saddened to hear that “Interaction Design” will be dropped from the name of one of the leaders of our discipline.”A true master of the genre, BayCHI’s own, Richard Anderson, conducted the interview with Alan. For those of you who don’t know Alan Cooper, besides being one of the founders of Cooper Interaction Design, he is also the author of two of the only interaction design books for which you should be ashamed of yourself for not having read, “About Face” and, “The Inmates are Running the Asylum.”

During the interview, Alan touched on three main points:

  1. The difference between Interface Design and Interaction Design.
  2. The establishment of Interaction Design as a discipline.
  3. What comes next for Cooper and Interaction Design in general?

Despite a likening to Attila the Hun (on the Cooper website), Alan seems a pretty likable guy. This was evident, not only from the many laughs he got during the evening, but also from the near-contagious head nodding by audience members.

Much like the axioms that fill his first book, Alan’s speaking style is axiomatic, in that much of what he has to say is just so right on.

The evening’s discussion began with the statement that “terminology is a trap”. It seems that Alan has been trapped by terminology just as many of us have been, which will help explain the surprising announcement about the company that I will later reveal.

That said, I don’t think any of you will be surprised to hear that he considers Interface Design a subset of Interaction Design and Interaction Design a subset of something bigger still. After all, we all agree that it is the behavior and not the design of the interface that ultimately has the greatest influence on the usability of an interactive system, right?

I, for one, was hoping to hear more about the “something bigger” of which interaction design was a subset. Could Alan have been thinking of Experience Design here? It’s hard to say. Clearly Cooper’s Director of Design Research and Development, Robert Reimann, has been very active in the emerging Experience Design community, on the AIGA Experience Design list and elsewhere, but Alan’s focus seems a bit more on the business side of Cooper the company. As it would turn out, his avoidance of naming the “something bigger” was probably at least partially on purpose.

At this point the discussion moved quickly into a review of the establishment of interaction design as a discipline.

An interesting point that Alan made was that after “Inmates” came out, programmers didn’t respond in protest. He said it was more of an “abdication,” which I thought was an interesting choice of words, especially coming from someone who clearly has a lot of respect for software engineers. Alan said that software engineers and their managers simply didn’t understand the affect they had on the people who use the results of their work. Of course, as designers, we see the evidence all around us. The fingerprints of software engineers are all over nearly every artifact in our world.

This point was particularly axiomatic for me because (although I’m a bit weary to admit) I was in Wal*Mart last weekend when I stumbled on a toaster with a button on the top labeled “Cancel.” If that isn’t a case of product design by engineers, I don’t’ know what is!

Alan also covered some of the reasons why builders can’t be designers because of the conflict of interest involved, which readers will remember was covered in, “The Inmates are Running the Asylum.”

This led into a statement that Alan made about the job of the Interaction Designer, which he said was to make sure the appropriate users are addressed appropriately. I liked this definition, but was a bit surprised to hear that he doesn’t think the Interaction Designer should ultimately be held responsible for the satisfaction of the users.

Upon further thought, this assertion seems quite logical. We are after all, as Alan said, merely practitioners. There are simply too many business issues, over which an interaction designer has no control, to be held responsible for something of that magnitude.

This obviously begs the question: then who is responsible? Alan’s contention is that the position should be held by someone at the “C” level (as in CEO or CFO). This was the only time during the evening that Alan mentioned that oh-so-problematic word “experience,” when he reluctantly suggested that the person responsible for the satisfaction of the users might be called the Chief Experience Officer (CXO).

Bringing us to what was, without question, the biggest announcement of the evening, which was that Cooper the company was dropping Interaction Design from their name. The reason “interaction design” is being dropped from the name, according to Alan, is to better reflect all of the work that they do, which, as it turns out, is more and more some sort of business consulting.

What sort of business consulting you ask? Unfortunately, this first half of the BayCHI event was already over time, so we didn’t get to hear, but based on what Alan was alluding to for much of the evening, it’s probably safe to say that a good part of that consulting work will include consulting for companies who are interested in making a place for the Chief Experience Officer in their organizations.

Indeed, Cooperista Jonathan Korman is working on a particularly relevant book – one that will discuss “how businesses can structure themselves to create great products.” In fact, if you haven’t read Jonathan’s article entitled, “Putting people together to make good products,” from the September 2001 Cooper newsletter, you should (after you finish all the other articles on Boxes & Arrows, of course).

While this is a very exciting proposition, it is not a new idea. Certainly many of you are aware that Don Norman has been encouraging members of the design and usability communities to move their way into the upper management of their companies for a number of years.

As an Interaction Designer, I’m saddened to hear that “Interaction Design” will be dropped from the name of one of the leaders of our discipline, but at the same time I’m excited about the opportunities that may arise for fellow Interaction Designers as the result of Cooper’s new mission.

And what else can we all be, except ecstatic, about the idea of Cooper’s consulting work resulting in a company where the issues surrounding users’ satisfaction will be addressed by “C” level managers and design is considered more strategically as a business advantage.

Fellow Interaction Designers, my advice to you is to bone up on your BS (no, not that BS, I’m talking about Business Skills) and prepare for the open highways that Cooper will hopefully pave for us!

For more information:

Brad Lauster works for Stanford University as an Interaction Designer, but is better known for his ruminations about Experience, Interaction and Product Design on his website brad lauster (dot com). You can usually find him traipsing around the Bay Area, attending talks on the subjects of his website.

Unraveling the Mysteries of metadata and taxonomies

by:   |  Posted on

Christina Wodtke of Boxes and Arrows interviews Samantha Bailey (former Argonaut and current lead IA for Wachovia Corporation’s Wachovia.com website) about Information Architecture, her dream process and the mysteries of metadata and taxonomies.

B&A: Let’s get meta – you come from the Argus LIS-flavored school of IA. What is your definition of Information Architecture?

SB: I’m going to pull this answer directly from an article I just wrote: “While it is unlikely that any two practicing information architects will give identical definitions of the term, there is consensus that information architecture has organization at its root. Basing my understanding on Morville and Rosenfeld’s approach, I define information architecture as: “the art and science of organizing information so that it is findable, manageable, and useful.” This definition is a “I think good IAs (like many good librarians) are often generalists at heart-people who have a love of learning and a tendency to be interested in practically anything that comes their way.”content-intensive interpretation, indicating my bias that information architecture skills are most critical in content rich environments. It also draws on the information retrieval roots of library science, emphasizing the importance of being able to find that which one seeks, whether known or unknown. Finally, information architecture is a user-centered discipline, understanding that usability is at the heart of a successful information based interaction.”

B&A What skills does one need to become a good IA?

SB: On an ongoing basis and in terms of basic personality traits, good IAs need to be inquisitive, problem/solution oriented, and dedicated to continual learning. The field is so new that there isn’t a set body of knowledge that you can learn in full and then have “mastered.” I think there is certainly a body of knowledge that an IA needs to pursue and absorb, which lays a foundation upon which to build.

In terms of the fields that I think most profoundly influence IA and are the best fodder for ongoing learning: Library and information science (my bias, obviously), HCI, cognitive psychology, ethnography and linguistics are among those I consider most critical.

Additionally, all of us need sales/marketing skills so that we can promote the field and continue inserting information architecture practices into processes that have been around long enough and are well established enough that it can take some work to make room for the IA piece.

B&A If someone wrote you having just gotten their BA-perhaps in English or philosophy-and wanted to become an IA, what would you tell them?

SB: I actually have a BA in philosophy, so it doesn’t appear to get in the way of pursuing IA too much. I guess I’d recommend reading as much as possible; there’s such a rich reading list now, and so many people with great insights. When I first became interested in IA, Lou [Rosenfeld] & Peter [Morville] hadn’t written their book yet, and IA was more nebulous. The ambiguity was appealing to me, as I was attracted to being part of something that was in the process of being formed. At times it also felt somewhat insubstantial; we were making it up, and sometimes there was a lurking sense that it lacked legitimacy for the very reason that it hadn’t been codified.

In addition to the reading, join the SIGIA listserv, find a discussion group, look for a mentor. And of course there is working on actual information architectures: your own site, volunteer projects, student projects. I wasn’t clear about what I wanted to do, career-wise, immediately after college, so I worked for several years. I’m really glad about that, as it made it easier to be confident and to be taken more seriously. After I got my master’s degree and my first “real” IA position, I had real world life and work experience. While it’s important to have rather specific skills in classification and user-centered design methodology, I think good IAs (like many good librarians) are often generalists at heart-people who have a love of learning and a tendency to be interested in practically anything that comes their way. I recommend throwing yourself in the way of whatever learning opportunities strike you as even remotely relevant.

B&A You recently joined a large financial institution. What are some of the differences you’ve seen between being a consultant and being an employee?

SB: There are both similarities and differences. Perhaps the biggest surprise has been in the area of sales/business development. As a consultant, I was never fond of the part of my job that involved business development (e.g., marketing the company, bringing in business via sales calls, structuring projects to enhance future business opportunities, etc). But I knew it was a critical part of my role as a consultant and, more particularly, as a consultant in a small start-up. So, when I joined a very specific department in a large company, I thought my bus dev days were behind me. And, indeed, I no longer have direct sales responsibilities. There aren’t calls to sit in on, RFPs to respond to, proposals to defend, etc., but my sales/marketing role remains a critical part of my new job. In this role, I’m selling something a bit different. Instead of selling a specific company/group of individuals, or a specific methodology or “secret recipe,” I’m now selling information architecture as a discipline that is critical to successful web design and that can be successfully fit into the company’s existing processes without too much pain. So, I’m changing my attitude about business development; from something that consultants or folks in small companies do to something that everyone has to do, in some way or another, all the time.

There is also, of course, the innie vs. outtie issue, that has been discussed on SIGIA. As a consultant, you see the pros and cons of being an outtie depending on the nature of the project- e.g., it can be a benefit to be removed because you’re not bogged down and swayed by existing politics, and yet it can also be a negative, as you may not fully understand the complexity of the environment and can put your foot in your mouth past the ankle before you even realize you’ve goofed. As an innie, there are pros and cons as well, and they’re often of an opposite nature-you have your finger on the pulse of the politics but you may not command the respect that a consultant’s “outsider” status conveys.

The biggest thing I miss about being a consultant is being able to “go home” both in the course of the project and at the end of the project. It was fascinating to be able to see, and sometimes even be part of, radically different organizations, as a consultant, knowing that in the end I was associated with my own, comparatively comfortable and particularly well-loved company. It could be bittersweet at the end of long, successful projects, but I’ve made great contacts and friends from those projects, and it was always fantastic to be able to finish up a project where the personalities hadn’t meshed as well and sink back into my own “family” of colleagues.

The thing that I’m most looking forward to, as an “innie,” is the issue of ownership and follow-through. As a consultant, I frequently left a project after the design phase and before implementation. That impacted the sense of pride and ownership of the final design, as well as the opportunity to influence the implementation process (in essence “eating our own dog food” when design elements that seemed strong on paper or in concept prove weak in action).

B&A What are some of the unique challenges financial sites offer?

SB: There are several. Security and issues of trust exist on virtually all sites, especially e-commerce sites, but with an online banking environment issues of security are paramount, and security needs that impinge upon the technological back-end supercede other drivers.

Another challenge I’m facing is the extremely complex nature of this site due to the fact that Wachovia is the nation’s 4th largest bank. We have both “retail” (the personal finance related banking you and I do) and “wholesale” (complex corporate and institutional banking) elements. In addition, Wachovia Securities is our brokerage arm, so from both wholesale and retail perspectives there are brokerage-related issues beyond traditional banking services. For example, our site is supporting both the features you’d find in an online bank and the features you’d find at a site like Schwab or Vanguard. This size and complexity issue leads to a number of impacts. The two most pressing are 1) it is quite hard to accurately define our users and narrow them into discrete personas and 2) it is very challenging to navigate the internal features of the bank (e.g. wanting to default to the bank’s organizational structure as the site’s organizational structure before gaining clarity as to what the bank’s organizational structure is and how it functions). B&A What’s the relationship between knowledge management and IA? (if any?)

SB: It depends. One thing it depends on is how you define knowledge management. I define knowledge management pretty loosely, first as the pursuit of maximizing your organization’s functionality by enhancing communication “Modern” methods of taxonomic classification are attributed to Linnaeus, who introduced his methodology in the 1700’s. Linneaus was a botanist, and taxonomy is generally associated with biology and systematics.”about and sharing of both tacit and implicit knowledge and second as the process of codifying this into a system/repository. The communication and capture piece may be the most critical aspect of KM, and I don’t know how much of a role IA can play in this aspect of KM. When it comes to codifying knowledge into a system, of course, IA will play a critical role in creating an information system that functions as well as it can.

B&A Can you tell me the difference between metadata and keywords?

SB: Metadata, at its broadest, is descriptive information about information. In the traditional library world, metadata is most commonly thought of as the big 3 from the traditional card (now online) catalog: Author, Title, Subject. But there are other fields as well-year published, publisher, shelf list number (administrative info for the library). In the online world, we use metadata for administrative purposes (to know when a document is “stale” and needs to be updated or deleted or to know the nature of a file so we know if we have the correct software to open it) and for retrieval purposes (the subject or keyword).
There are roughly 3 kinds of ways to think about, or classify, metadata:

  1. Intrinsic – information that can be extracted directly from an object (e.g., file name, size)
  2. Administrative/Management – information used to manage the document (e.g., author, date created, date to be reviewed)
  3. Descriptive – information that describes the object (e.g. title, subject, audience)

So, metadata can be quite varied-it may support retrieval (author, title, subject), it may support administration (call number, stale date), or both. As you can see, these categories are not mutually exclusive-administrative data could be used for retrieval purposes (if the system supported that usage) and we could debate as to whether “author” was administrative, descriptive or possibly even intrinsic, as with a piece of artwork.

That leaves us with keywords-what are they? Well, they’re a kind of descriptive metadata, generally describing the nature of the information. Keywords may be extracted directly from the text or they may be extrapolated-selected because they describe the text (subject, topic). The context in which keywords are selected and used is important for this reason. Keywords are by their nature fairly granular-a specific word applied to a specific item, often a narrow subset of a document (like a page or a paragraph), but even this granularity can vary in specificity (e.g., does the keyword describe the element in question specifically or generally?). Keywords are typically used for retrieval, as opposed to for administration.

When keywords are applied to html pages-which is generally done for descriptive and retrieval purposes-they are typically applied via a metatag. This may be what has led to some confusion around the difference between metadata and keywords. The metatag fields in HTML were meant to capture all sorts of metadata; and some are used to capture quite a wide array of information. Keyword seems to be the most commonly used/known of the meta field tags.

B&A How about the difference between taxonomies and hierarchies?

SB: Ah, taxonomies vs. hierarchies. Near and dear to my heart – I’ve just written an article on the uses (and misuses) of the term “taxonomy.” You probably know this, but just in case I’ll give a brief history lesson. Taxonomies have been around for a long time – they are hierarchical schemes for classifying things. Aristotle developed a system of classification in 300 BC. “Modern” methods of taxonomic classification are attributed to Linnaeus, who introduced his methodology in the 1700’s. Linneaus was a botanist, and taxonomy is generally associated with biology and systematics. Other disciplines have borrowed the term taxonomy from the hard sciences to describe their classification systems, so it wasn’t a completely novel act when folks working on the Internet stumbled upon it as a good term for describing what they were doing online. I first encountered the term in 1999 while doing some work with Ernst & Young.Management consulting seems to have been enamored of the term in this context early on- and was completely baffled, as I had only been familiar with the term from my biology courses and had never encountered it in my library science/information science work or reading. Doing more exploration, I concluded that when people were talking about taxonomy on the web they were often talking about the traditional LIS definitions for classification schemes, controlled vocabularies, or thesauri. (I went on a brief mission to convince the Argonauts that we should educate our clients about the LIS terms, but it was more or less a failure, so around 2000 I caved and began using the term taxonomy myself. Now, the terms has become so used, I think it has genuine validity of its own on the web.)

On the web, we tend to play fast and loose with terminology, and that’s true here as well. A strict interpretation of the definition of taxonomy would demand that the scheme be a pure hierarchy with one to one relationships. (Items can be in one place and one place only in the scheme-think of the animal kingdom or a family tree – but I’ve met people who are very comfortable with the concept of polyhierarchical taxonomy. Polyhierarchy being the concept that something can “live” in more than one place in a hierarchy. The most common example of this is “piano” in a scheme of musical instruments; it is both a stringed instrument and a percussion instrument.

Here are a couple definitions:

Traditional definition:

“Taxonomy, a sub-field of biology concerned with the classification of organisms according to their differences and similarities, still uses many of Linnaeus’ original categories. Today the major categories are kingdom, phylum, class, order, family, genus, and species.”
(http://www.ensc.sfu.ca/people/grad/brassard/personal/THESIS/node19.html)

Taxonomy on the web:

“A correlation of the different functional languages used by the enterprise to support a mechanism for navigating and gaining access to the intellectual capital of the enterprise.” (One of the more carefully justified definitions of taxonomy comes from research done by Alan Gilchrist and Peter Kibbey of TFPL, a leading taxonomy consulting firm. The definition can be found in the executive summary of the report “Taxonomies for Business: Access and Connectedness in a Wired World.”
(http://www.tfpl.com/consultancy/taxonomies/_report_/taxonomy_report.html)

B&A What about categories, where do they fit in?

SB: Categories are groupings of like elements (often by subject, but also by other criteria, like form). The groupings that make up taxonomies and classification schemes are categories.

B&A So where does the thesaurus come in? “Right now it’s a very thrilling time – we have a new medium and a new discipline, and a lot of work ahead of us teasing apart what it all means.”

SB: You won’t be surprised to find that I have a classic IA’s answer to this question: it depends. 🙂 A thesaurus is an information retrieval tool that excels at making connections between concepts. Information retrieval thesauri are almost the opposite of the way we think of the thesauruses we were introduced to in elementary school. Those thesauri took a word and exploded in outward, so that when we got absolutely sick of writing “brown” we learned that we could substitute the more exotic “sienna.” An information retrieval thesaurus at its most basic relationship brings concepts together, grouping and clumping like terms. Subsequently the document that mentions the brown crayon and the separate document that discusses the sienna Crayola are both pulled together in the information system that has a thesaurus applied to it.

There are 3 primary relationships that thesauri clarify: equivalent relationships (synonyms, variations; as with brown/sienna above), hierarchical relationships (broader and narrower-or more general and more specific), and associative relationships (related terms). In the classical sense, you only had a thesaurus if all 3 relationships were explicated, but on the Web people have been open to using the word thesaurus when they’re talking about just one or two of the relationships.

B&A Can you get all these things to work together in some way?

SB: Yes! There are a variety of different ways (some of this may be semantic, of course, depending on how strictly you want to interpret the terminology). Here’s an example: you might have a site that employed a high level taxonomy or classification scheme (think Yahoo!). If the taxonomy is polyhierarchical, thesaural relationships could be employed as part of the taxonomy (e.g. Movies: see Film). The thesaurus might also be used to show associated relationships for individual records (e.g., Final Fantasy, see also: Japanese anime). A thesaurus could also be used behind the scenes to enhance the search technology-for example, the taxonomy might only display movies and film but the search engine might use the thesaurus to tell the user who searches for “movie” that the results returned were based on documents indexed by the preferred term “film.” Conversely, the search engine might also use the thesaurus to create search zones-returning results for searches of “8mm” from the documents indexed as relating to film before the other documents.

B&A Does every site need all this stuff?

SB: No, definitely not all this stuff. These are concepts that can be leveraged as tools to support classification and retrieval. It’s basically the same as with search-not all sites need a search engine, for example. Barring the religious war between Jared & Jakob there is the reality that some sites seem to work quite well without search engines (e.g., Gap.com) while other sites are greatly enhanced by them (e.g., Amazon).

But every site needs some of this stuff, perhaps. It’s very difficult to have a functional site that doesn’t have some kind of approach to organization-usually in the form of a classification scheme-regardless of whether it’s a hierarchical taxonomy (a place for everything and everything in one place only), a polyhierarchical taxonomy (a Yahoo!-like scheme where items can be placed in more than one category), or a flat classification scheme (as with the simplest brochure sites), etc.

B&A What about software-can you think of software that could benefit from architecting their information?

SB: A topic worthy of a book, undoubtedly. When I’m looking at information architecture for content I tend to focus on classification, navigation, labeling and search, and there are certainly aspects of most all of these in software programs. Labeling is a huge issue in the functionality of software products, especially because we tend to be dealing with extremely narrow and deep structures with software. Good labels (even in the form of rollovers for icons) can make a significant difference in the users’ ability to understand and use the tools. (An interesting side note here is that generally novice or infrequent users have more success with broad and shallow schemes, something that doesn’t tend to work especially well with software interfaces.)

B&A What is your dream process for creating an architecture?

SB: Dream process, hmmm. Well first it begins with assembling a great team. I’d need to have a sense of the parameters to know what size team to go with, but at Argus we had great success with fairly small teams even for rather significantly sized projects. The best teams are a mix of skills, experience and personality. I tend to be drawn to the bottom-up elements of IA (e.g., content analysis, vocabulary control, indexing, etc.) so I tend to look for people with top-down skills (strategy, heuristics) to balance my approach.

After assembling the team, my dream project would have a dream context -clearly defined scope and goals with clients who value information architecture and are prepared to be advocates in their organization (this would be true whether I was an innie or an outtie; there’s generally some kind of client and stakeholder who can pave the way). But don’t go thinking the dream project would run perfectly smoothly-it would still have enough challenges to keep things interesting. I like projects that are daunting but not impossible.

So, let’s see: team, clients. Then I’d have the team sit down and hammer out a process that had a mixture of things we were comfortable with/had done before and had a high degree of confidence with and a few things we wanted to try out/experiment with. And once we had a rough road map we’d dive in and do the work.

B&A There is a lot of talk about semantic webs and self-organizing systems-automated IA, in other words. Meanwhile our community is talking about getting into Experience Design or getting MBA’s… can you see a future where there are no information architects, just machines and people who know what they do?

SB: I recently had a conversation with Matt Jones, IA for the BBC (his weblog is http://www.blackbeltjones.com/) about this very topic, in a more here and now way. Matt was arguing that he didn’t want information architects at the BBC, he wanted multidisciplinary staff members who were skilled in the discipline of information architecture. I took the position that in a world of ever increasing specialization, coupled with corporate environments that ask people to take on ever more responsibilities, with restricted schedules and budgets, we desperately need an individual in the IA role, both to look out for the IA particular issues and to evangelize. A sort of Lorax role-I am the Information Architect, I speak for the…labeling scheme and the organization structure and the search/browse system and so on and so forth. But that’s today, and you’re really asking about tomorrow.

In the library world there have long been whispers that automation will replace the need for librarians-it was even part of Autonomy’s ad campaign a few years ago. I think that there is a human tendency to both intrigue and scare ourselves with the idea that our creations will make us obsolete. And it is true that automation results in dramatic change. However, instead of making librarian’s obsolete, my experience has been that technology and automation often tends to replace the routine tasks, leaving the more subtle, often more interesting, challenges to be performed by people. So, in the big picture, I have no doubt that automation and technical developments will change the nature of our work as information architects over time. But people have been bending their minds to the nature and need for organizing information for a long, long time, whether as librarians or records managers or database administrators. Right now it’s a very thrilling time-we have a new medium and a new discipline, and a lot of work ahead of us teasing apart what it all means. So, yes, I think our work will evolve and change dramatically, but I don’t think the role is going to go away anytime soon.

B&A So what is the future of Information Architecture?

SB: The gazillion-dollar question that leaves me tongue-tied and tempted to blurt out “heck if I know!” But I think your question about semantic web and self-organizing systems hints at the answer-the immediate future requires stabilizing our role in the academic and business communities and identifying the key challenges and problems that we want to solve in the next 10 years. I think we’ll continue to see a weaving of old, new and newer-advancing technology with respected, well understood concepts and evolving thinking. Whatever the future of Information Architecture turns out to be, I’m excited about being part of the work as it unfolds.

Christina Wodtke is the founder of Boxes and Arrows. Her day job is Partner at Carbon IQ, a small user-experience agency in San Francisco, where she designs information architectures and conducts user research in the quest to create more usable, effective and profitable products.

Automating Diagrams with Visio

by:   |  Posted on

We have all heard the adage, “Good, Fast, Cheap: Pick any two (you can’t have all three).” The saying might generally be true of the work we produce as designers of information-use environments. Try to test the saying against one of the deliverables we might create—a high-fidelity interface prototype, for example—and see if you can disprove it. You can produce beautiful prototypes in Illustrator, but it will cost you time and money. You can do rough prototypes quickly and cheaply by hand, but the end result won’t look as polished as the Illustrator version.

Turnaround time can be relatively quick if you push your tools to perform for you. Site maps and user flow diagrams are good candidates for automation.

My approach to producing deliverables is to falsify the truism. I do the demanding intellectual work first and then force the tools to succumb to my need to produce seemingly speedy deliverables. The illusion of speed happens because you do the hard work up front—planning, analyzing and documenting your work in doing content inventories, designing user flow, etc. When it is time to realize that work in a document, the turnaround time can be relatively quick if you push your tools to perform for you. In this article I illustrate one method for producing diagrams quickly using software.

The process overview

We probably do most of our intellectual work in preparing deliverables before ever touching a drawing program. When the elements of the information architecture and user experience are defined, we are often expected to produce a polished document to visually represent the information. We can take a semi-automated approach to produce some of these documents using software. Site maps and user flow diagrams are good candidates.

The process I propose assumes that you’ve spent grueling hours doing the work of preparing your content inventory or sketching your user flow diagrams and now want to render your boxes and arrows for presentation. The next step in the process is to take the data produced in that intellectual work and prepare it for use in a diagramming application.

I will illustrate a process that relies on text files exported from Excel and uses Visio to transform those text files into diagrams. You can also use a database management system for this process, but details about using a DBMS are out of the scope of this article.

The steps to be covered in this process

  • Identify and document your nodes
    • For site maps, identify nodes in a content inventory, hierarchically arranged
    • For flowcharts, sketch and identify shapes and connectors
  • Document nodal connections
    • Indicate how parent nodes explicitly link to child nodes
  • Prepare text file for importing to a drawing program
    • Prepare a “shapes” file in Excel or with a text editor
    • Prepare a “links” file in Excel or with a text editor
      • If using Excel, export files to comma- or tab-separated file (saved as .csv or .txt)
    • Combine shapes and links files into one text file for importing into Visio
  • Open/Import and auto-diagram
    • Open the text file in Visio
  • Modify the diagram
    • Manipulate the diagram shapes for clarity and apply any cosmetic changes

Creating site maps or content architecture diagrams

We spend a good deal of time working with content to produce documents that help clarify the scope of data contained in websites. Key to the work of information architecture is the production of documents that list the site contents hierarchically (content audits or inventories) or diagrams that depict the site structure visually (site maps). The content inventory is the starting point in defining our information architecture. Graphic designers and technical people often use these documents in system and design specifications.

Step 1: Identify and document nodes in a content inventory

The process of specifying new data or auditing existing data to be included in a site helps to clarify the next steps in organizing that data for presentation. The inventory of data is often used to produce taxonomies or categories of access points. These access points usually inform the navigation and interface design.

Inventoried content is often categorized as a hierarchy of nodes (categories and subcategories, branches and leaves). A high-level extraction of the top-level nodes, perhaps even several levels deep, might give a good idea of the site structure.

To illustrate how to prepare your text files, consider this portion of a hierarchy for a hypothetical company website.

Content hierarchy for boxywidgets site

  • 1.0 Home
  • 2.0 Corporate information
    • 2.1 What we do
    • 2.2 Who we are
  • 3.0 Our process
    • 3.1 Discovery
    • 3.2 Concept
    • 3.3 Creation
    • 3.4 Implementation
    • 3.5 Rollout
    • 3.6 Testing
  • 4.0 Our clients
    • 4.1 Case studies
      • 4.1.1 Web
      • 4.1.2 CD-ROM and kiosks
      • 4.1.3 Print
    • 4.2 Client list
  • 5.0 Contact information
    • 5.1 Locations
    • 5.2 Online inquiry form
      • 5.2.1 Inquiry form submitted
      • 5.2.2 Inquiry form error

This example shows all the available nodes in a small site. All that Visio will need is a listing of the nodes that we want to diagram.
This list is comprised of:

  1. “Shape Name”—a unique numerical idea for each node and
  2. “Shape Text”—a label for the node. If this data is coming from a more complete content audit document, you should extract only the id and label for this exercise. This is fairly simple to do in Excel if you copy the data to a new sheet and remove the unwanted columns.

Visio accepts a number of other values in the file you import. They are as follows:

Shape,”Shape Name”,”Master Name”,”Shape Text”,”ShapeX”,”ShapeY”,”Width”,”Height”,”Property”

For our task, we are interested in the “Shape Name” and “Shape Text” values. We can simply skip all of the fields following “Shape Text”, but must include blank values using empty quotes (“”) for any fields that we are skipping before the last field. In this case, we use empty quotes for “Master Name” because we’re only using boxes in this diagram. The first value in each line is always the word “Shape” to indicate to Visio that this is the definition for a shape it will draw.

If you are authoring these files in Excel, you can create the first column for the “Shape” value and auto-fill all of your rows with the value “Shape”. The second column will hold your “Shape Name” values. The third column will be a placeholder for the empty “Master Name” field. The fourth column will hold your “Shape Text” labels.

Our sample Excel file would look like this:

Excel sheet with stripped down content inventory

Excel sheet with stripped down content inventory

We can export this sheet to a text file of comma-separated values (saved as .csv) and the resulting file for the content hierarchy will look like this:


; shapes.csv
; Shape file for Boxy Widgets site
Shape,"1.0","","Home"
Shape,"2.0","","Corporate information"
Shape,"2.1","","What we do"
Shape,"2.2","","Who we are"
Shape,"3.0","","Our process"
Shape,"3.1","","Discovery"
Shape,"3.2","","Concept"
Shape,"3.3","","Creative"
Shape,"3.4","","Implementation"
Shape,"3.5","","Rollout"
Shape,"3.6","","Testing"
Shape,"4.0","","Our clients"
Shape,"4.1","","Case studies"
Shape,"4.1.1","","Web"
Shape,"4.1.2","","CD-ROM and kiosks"
Shape,"4.1.3","","Print"
Shape,"4.2","","Client list"
Shape,"5.0","","Contact information"
Shape,"5.1","","Locations"
Shape,"5.2","","Online inquiry form"
Shape,"5.2.1","","Inquiry form submitted"
Shape,"5.2.2","","Inquiry form error"

Any line that is preceded by a semicolon (;) is ignored as a comment. I added comments in the first two lines to indicate what this file is used for. The next file we want to create is the file that shows relationships between nodes.

Step 2: Document nodal connections

The list we created above is a hierarchical listing of nodes, so the numbers and position in the list already indicate relationships. However, Visio requires that we explicitly reiterate the relationships by indicating child-parent connections following the format below.

Link,”Link Name”,”Master Name”,”Link Text”,”From Shape (or Connector) Name”,”To Shape (or Connector) Name”

We only need the “From Shape” and “To Shape” values for this file. The first value in each line is always the word “Link” to indicate to Visio that this is how the shape identified in the “From Shape” field will link to a shape in the “To Shape” field. Our link file for the example above would look like this.


; links.csv
; Link file for Boxy Widgets site
Link,"","","","1.0","2.0" ; Link the "Home" to "Corporate information"
Link,"","","","1.0","3.0"
Link,"","","","1.0","4.0"
Link,"","","","1.0","5.0"
Link,"","","","2.0","2.1" ; Link "Corporate information" to child "What we do"
Link,"","","","2.0","2.2"
Link,"","","","3.0","3.1"
Link,"","","","3.0","3.2"
Link,"","","","3.0","3.3"
Link,"","","","3.0","3.4"
Link,"","","","3.0","3.5"
Link,"","","","3.0","3.6"
Link,"","","","4.0","4.1"
Link,"","","","4.1","4.1.1"
Link,"","","","4.1","4.1.2"
Link,"","","","4.1","4.1.3"
Link,"","","","4.0","4.2"
Link,"","","","5.0","5.1"
Link,"","","","5.0","5.2"
Link,"","","","5.2","5.2.1"
Link,"","","","5.2","5.2.2"

Step 3: Diagram in Visio

We now take the two text files created above and merge them into one file that we are going to save as “ex1_visio_import.csv”. Now we are ready to open the file in Visio using the steps below.

  • File > Open (open dialog window appears)
    • Files of type: Text Files (*.txt,*.csv)
    • Select file “ex1_visio_import.csv”
    • Click Open (File Converter dialog window appears)
  • Visio File Converter dialog window
    • Field Separator: ,
    • Text delimiter: ""
    • Comment character: ;
    • Click OK

The end result is a diagram that needs a good deal of clean up. You can move the boxes around and play with colors to produce a more readable diagram.

Automatically generated site map (click to enlarge)

Cleaned up site map (click to enlarge)

 

Of course if you don’t want to see your diagram in the hideous colors that Visio gives you to work with, you can copy the diagram and paste into Illustrator where you can make it more presentable and pleasant to look at.

Creating user flow diagrams

While I think it’s rather nifty to create site maps using Visio, I have to admit that what I really prefer to create in Visio are flowcharts.

Flowcharts can be used to help the team understand how users might interact with your system. Interactions such as registration or e-commerce transactions may best be planned using flowcharts. They are also used in diagramming system logic for applications. These documents are often developed with technical people and serve to assist technical staff and graphic designers.

The process for doing flowcharts in Visio is the same as the process shown above for site maps, except we will also be introducing values to specify which shapes to use. We also have to tell Visio which stencils to get the shapes from by specifying a template. With flowcharts, there is less need to move your shapes around once you’ve imported them into Visio. I hardly ever touch the colors and fonts. I view flowcharts as utilitarian documents that are meant to illustrate system logic, so I prefer to show them in grayscale and prefer the linear top-to-bottom presentation, connecting pages with connector symbols when necessary.

To get you started I will illustrate how to use the process shown above to diagram a very simple flowchart. Since you are now familiar with the file preparation, I’m just going to define the fields that can be included for the node and link sections and then show you the files combined in one import file.

Step 1: Document nodes in flowchart

Flowcharting does not lend itself to listing shapes in a hierarchical list the way site maps do. The best approach is probably to first draw your flowchart on paper and number the shapes in the chart. You can then take each numbered shape and add it to your text file. All that Visio really needs to create your flowchart are a few required fields:

  1. The “Shape Name”—the unique numerical id you give it
  2. The “Shape Master”—the name of the shape you want to use from the Visio template (Terminator, Processing, Decision, etc.), and
  3. the “Shape Text”—the label for the shape.

Visio will also accept a number of other values in the file you import. The order of fields should appear as follows:

Shape,”Shape Name”,”Master Name”,”Shape Text”,”ShapeX”,”ShapeY”,”Width”,”Height”

The first value in each line is always the word “Shape” to indicate to Visio that this is the definition for a shape it will draw. We can simply leave off all the values following Shape Text, but we must include blank values using empty quotes (“”) for any values that we are skipping before the last value. If we don’t want to specify shape size and position, we can just skip the last four fields. I’m going to do that for this example.

Step 2: Document nodal connections

Since you have a sketch of your flowchart it should be fairly easy for you to create a list of the links between shapes.
Visio will expect at the very least that you include:

  1. “Master Name”, the name of the connector you will use
  2. “From Shape (or Connector) Name”, the numerical idea or “Shape Name” from the shape list, 2) “To Shape (or Connector) Name”.

The first value in each line is always the word “Link” to indicate to Visio that this is how the shape identified in the “From Shape” value will link to a shape in the “To Shape” value. There are some additional fields that you can use including “Link Text”, a field for a text value that can appear over the connector lines. For our example, we’re going to skip the extra fields and indicate them with empty quotes. The order of fields should appear as follows:

Link,”Link Name”,”Master Name”,”Link Text”,”From Shape (or Connector) Name”,”To Shape (or Connector) Name”

Step 3: Diagram in Visio

Now that we know what shapes to include and how to link them, let’s look at the combined import file we would create for this simple example. We need to indicate to Visio the stencil to reference when looking for shapes identified in our “Master Name” field. So begin the first line with the keyword “Template”, followed by a comma and the name of the Visio stencil file. Stencil templates are the Visio files followed by the extension .vst. You can get the names of stencil templates and stencil files by browsing in your Visio Solutions folder (usually located in “C:Program filesVisioSolutionsFlowchart”) In this example we’ll use the flowchart template “Audit Diagram.vst”, which includes the “Audit” and the “Connectors and Callouts” stencils.

Here is the import file for our example:


; ex2_visio_import.csv
Template, "Audit Diagram.vst"

Shape,"1","Terminator","Start",,,,,,,
Shape,"2","I/O","Some kind of input",,,,,,,
Shape,"3","Decision","Test the input",,,,,,,
Shape,"4","Display","Display true message",,,,,,,
Shape,"5","Display","Display false message",,,,,,,

Link,,"Next",,"1","2"
Link,,"Next",,"2","3"
Link,,"Result",,"3","4"
Link,,"No result",,"3","5"

We can save this file and open in Visio using the following steps:

  • File > Open (open dialog window appears)
    • Files of type: Text Files (*.txt,*.csv)
    • Select file “ex2_visio_import.csv”
    • Click Open (File Converter dialog window appears)
  • Visio File Converter dialog window
    • Field Separator: ,
    • Text delimiter: “”
    • Comment character: ;
    • Click OK
Automatically generated flowchartAutomatically generated flowchart

Summary

That’s all there is to it. You now have a simple process for generating diagrams in Visio from text files. It won’t make the intellectual work of preparing content inventories or user flow specifications much easier, but it may buy you some time when it comes to rendering that information in a drawing application.

If you work in an organization where you are expected to make modifications to your deliverables quickly, you might value this process. This process will help you make modifications a bit more quickly to those specifications you’ve spent hard hours on, so you can impress your colleagues and clients with how efficient you are.

For more information


Michael Angeles is an information specialist and site developer at Lucent Technologies, Bell Laboratories in the Information Solutions department. He maintains a weblog of information architecture news at http://www.iaslash.org.

SchwabLearning.org: A Case Study

by:   |  Posted on

One nonprofit + two web agencies + nine months = SchwabLearning.org. Yes, that was the formula to launch our web site, and I am one of the sole survivors to tell you about it. Before I begin telling the story of the project it is best to learn who and what Schwab Learning is.

Schwab Learning, a service of the Charles and Helen Schwab Foundation, is dedicated to helping kids with learning differences be successful in learning and life. The Foundation began in 1988 from the Schwabs’ personal struggle with learning differences (LD). After Mr. and Mrs. Schwab’s son struggled in school “Learning about our visitors’ experience first-hand has enabled us to create a web site that meets their needs in a more meaningful way.”they had him assessed for LD. During a meeting with a school psychologist, the Schwabs were asked: “Didn’t either of you have problems like this?” That is when Charles Schwab recognized his own dyslexia, and his lifelong struggle with reading and writing suddenly made sense.

In 1999, after eleven years of serving San Francisco Bay Area parents and educators through direct services and outreach, we realized that we could effect greater change if we expanded our web presence. We needed to find a Web agency that would conduct a study on our target group to understand their needs, develop a web strategy and implement the web site. This project was during the height of dot-com boom, and many agencies were not interested in us because they had many accounts that would bring in a lot more money than our budget allowed. After a few months of pitch meetings with agencies, we signed a contract with Sapient to conduct an ethnographic study and lead us from concept to implementation for a new web site.

Laying the foundation for our new site
When we began working with Sapient we had already established goals, objectives and a direction.

Goal: Help kids with learning differences be successful in learning and life. Support kids and moms through “the journey.”

Objectives:

  1. Create two web sites, one for parents/moms and one for kids, but begin with the parent site.
  2. Conduct a study with moms who have a child or children with LD to learn about their experiences. Also, test Schwab Learning’s hypothesis that moms are the “case managers” for their children when working with schools, doctors, etc., and that parents are on a journey to understand and cope with LD.
  3. Create a scalable business and Web strategy to reach moms.

We began working with Sapient in March 2000 focusing on the business strategy and study of moms’ experiences. There were approximately 10 to 12 Sapient team members and 10 to 12 Schwab Learning team members. As a small non-profit, it was awkward working with such a large team of consultants; they totaled one-third of our entire staff at the time. After two months of working together, a draft business strategy was ready for the Board, and the results of the study had been delivered by way of experience models.

Before explaining the experience models and their impact on the Web site it is important to understand the methodology of the study. These models are extremely rich, as it would be very difficult to describe a mom’s experience without them. There were three parts of the study: focus groups, in-home interviews and visual diaries.

Focus Groups: Conducted in San Francisco and Chicago to determine if there were state-to-state differences between moms. There were four focus groups in each state: Two with children identified with an LD and two with children who struggled in school. In each of these pairs one group of moms had children in kindergarten to third grade, and one group had children in fourth to eighth grade.

In-Home Interviews: Seven moms in San Francisco and seven moms in the Chicago area, each interviewed for two hours. These interviews asked moms how they found information about LD, which management strategies they used with their children and for details about their children’s daily routines. There was also a tour of the house to demonstrate how the mom and child interacted in the home. Moms wrote on index cards words, phrases and questions about how they managed their child’s LD and how they felt parenting a child with LD. They arranged these cards in groups to help us understand how the topics are related.

Visual Diaries: Sixteen visual diaries were given to moms in San Francisco and Chicago to chronicle their experiences in a four-day period. Moms were asked to answer some questions and to write free-form journals. Moms were also asked to take pictures of their home environment, their kids, etc.

The LD Landscape
Five domains make up the LD Landscape and demonstrate the areas of a mom’s life that are affected by her child having an LD. These domains exist before their child is identified with LD; however moms have to reorient their relationships in the domains once they begin managing their child.

The lifecycle: gaining awareness
There are usually three stages that parents go through before their child is identified with LD. First they begin to sense that something is different. Next they rule out the environment, sleep patterns or other factors that might cause their child to struggle in school. Finally, they have their child assessed for LD.

The lifecycle: management strategies
After a child is assessed it is now time for the mom to begin learning management strategies that will help her interact with her child in home and at school. Management strategies do not always work, and may have to be refined.

Mom’s evolution of knowledge
When a mom first finds out about her child’s learning difference she usually seeks all the information she can find. This information is critical in the beginning, but over time moms begin to gain confidence in their abilities to help their children and rely more on experience and knowledge.

The next phase
After the experience models were delivered and accepted by Schwab Learning, the next phase of the project began.

A study with moms identified six user types which illustrate the different roles a mom finds herself in along the journey.

Pre-Identified: Doesn’t know that an LD exists. Considers herself part of the “normal” community, yet might feel isolated.

Novice: Acknowledges her child has an LD, but might not know which one. Learns that an LD landscape exists and there are tools and strategies to learn.

Student: Begins to negotiate the landscape and recognizes the affected domains. Recognizes her need for information and assistance.

Case Manager: Reorients herself in the LD landscape. Improves her ability to handle crisis and management of her child.

Advocate: Proactively participates in larger community. Begins to extend her knowledge to others; beginning of leadership.

Sage: Becomes a community resource and begins to be sought out by others.

The articulation of these roles demonstrated to us that we needed to focus on a particular user type or role because we could not launch a site filling all of these needs. After several meetings working with Sapient we narrowed our target for launch to the Novice mom. Choosing this target group made the most sense as we had been serving this population in our local center for years, and we had ready-made content for the web site.

The day our direction changed
At the end of May 2000 the Foundation’s Board met to discuss various matters, primarily the new business strategy and direction of the Schwab Learning. After understanding the costs of the strategy: call centers, large-scale partnerships, and a deep and complex web site at launch, the Board was concerned. Mr. Schwab grew his business from the ground up, building on top of successes while taking calculated risks and learning from them. The decision was made to scale back the scope of the web site, find another web agency to build the web site from the study we had conducted, and launch by the end of 2000.

After finishing our commitment to Sapient in July, we wrote an RFP, interviewed agencies and hired Small Pond Studios (SPS) within a month. We did not want to stop the internal momentum and enthusiasm for building the web site, and we only had four and one-half months to launch the web site. SPS was an ideal agency to work with because not only did they have a stellar team, the four principles worked for Sapient prior to starting their own company. They understood all of the deliverables from Sapient and were able to translate them into a plan for the web site.

Creating a realistic web site
Once the documentation was internalized by SPS we began working on the design, branding and information architecture. There were four conceptual models to choose from: Information, Tools, Journey and Community. The “Journey” concept was the most compelling model because it gave site visitors an orientation about LD while balancing information, community and tools, which are important to managing the journey. Also, the Journey concept complemented our user study because parents need to understand the LD landscape before managing their child’s LD.

The Information concept did not provide Schwab Learning the space to be a guide to parents, and it de-emphasized community. The Tools concept would not provide parents enough desperately sought information. The Community concept would not put Schwab Learning in the expert role, and a community’s growth takes time, which we did not have.

Once the decision was made to move forward with the Journey concept, SPS created two different wire frames to test with moms. One wire frame was based on organizing the information architecture by the LD Landscape (domains): Work, Family, Institutions, Community and Self. The other wire frame was based on the Lifecycle: Is it LD?, Identifying and Managing a Learning Difference, and Sharing Information.

LD Landscape

LD Lifecycle

SPS conducted two rounds of user testing with six moms using wire frames. The first round was to determine which structure made more sense to moms, and the second was to refine the chosen model. During the first round of testing we discovered that moms did not know where to begin with the LD Landscape concept. All of the domains affected their life, and all were very interesting, so knowing where to click first was not intuitive. Moms had a better sense for were to start with the Lifecycle concept, and that confidence would be critical for first-time visitors to the web site.

For the second round of testing using the Lifecycle concept, the main “buckets” were reduced from four to three: Identifying a Learning Difference, Managing a Learning Difference and Sharing Knowledge. Also, because the concept made sense to moms, the domains became the secondary navigation architecture.. We probed on the wording of the “buckets” and placement of clicks, as well as interest in registering and reactions to a first version of the design.

Final information architecture wireframe

Initial design of homepage
We learned valuable information from this second round of testing. Moms liked the happy children and the warm, inviting color of the Web site. They also liked the “.org” front and center. To the moms it assured them that the site was not trying to sell them anything, and our information could be trusted. Moms did raise concern about the phrase “Sharing Your Knowledge” because some of them felt they did not have knowledge to share.

The next step was to continue to refine the design, then marry the technical and design for testing. We had decided early on to build the site in ASP with a MS SQL database. The live site at the time was built on the same platform so we were able to leverage our existing content management system and other functions for the new site.

In the span of two years, the site went from this design and information architecture in January 1999 …

To this site redesign in September 1999 …

And finally to this complete new site in December 2000.


So you launched, now what?
In 2001 we hired four staff members who grew the team to seven, and in 2002 we had a budget for two more. We added several pieces of functionality to the site: polls, quizzes, a web calendar and an html newsletter option; increased our content from eighty articles to two hundred articles and conducted a usability study with ten moms. In 2001 our web traffic steadily increased from month to month. The average visitors from the first quarter to the fourth quarter increased by 46 percent and page views increased by 49 percent.

When we conducted the usability test with moms we discovered that they were having a difficult time browsing once they clicked into “1, 2 or 3.” Moms were struggling to find information they needed in the domains because the lists of articles were becoming too long. Internally we were struggling with placing articles in our information structure, so we knew it needed to be changed. We have kept the 1, 2, 3 structure and added a 4 to house a visitor’s personal page and some of our functionality that previously did not have a home. We also consolidated the secondary information structure from Your Child, Your Family, Schools and Professionals, etc. to Kids & Learning, Home & Family, Schools & Other Resources and have now added a tertiary information structure. This provides us a more flexible structure that moms will hopefully relate better too. This new information and design structure launched in February 2002.

Lessons learned
It has been an amazing two years and yet we still have a long way to go. Looking back, we have achieved our original objectives and applied them to the building of SchwabLearning.org. We have learned many lessons along the way and here are a few:

First, don’t let your vision blind you. We were incredibly excited about helping moms and kids, and that enthusiasm led us to believe that our thirty-person organization could transform itself overnight. We needed to take a deep breath and say, “Wait a minute, how are we going to do this?” Today our vision remains as strong as ever to help kids with learning differences be successful in learning and life. Our process to achieve our vision changed from the big bang theory to starting small, building on the foundation we launched with and protecting our assets.

Second, conducting user studies was invaluable. Learning about our visitors’ experience first-hand has enabled us to create a web site that meets their needs in a more meaningful way. Our experience models have enabled us to communicate with partners and other friends of the Foundation as well as create a new language for us: domains, LD landscape, novice, case manager, etc.

Third, user research and usability testing will always put you on the right track. The testing we conducted pre- and post-launch has been extremely useful in guiding our development. The initial user research study gave us the opportunity to go into the homes of the people we were trying to help. This proved to be rich data because we could see first-hand the interactions with their children and how their homes were set up to accommodate their children (i.e. where they kept medications, chore lists, etc.). The focus groups revealed different information as these moms were in a group with different dynamics compared with one-on-one interviews in a home. The diaries gave us another data point that was intimate in a different way as we only knew these moms’ stories and never met them in person. As for the first usability testing, we were able to discover potential pitfalls before going live. Who would have known that moms would have concerns about the concept “Sharing Your Knowledge”, but “Connecting With Others” did not pose a problem. Also in our post-launch usability testing, we discovered that the secondary information structure based on the “Domains” made sense to us, but not to site visitors. This is a very important discovery because if users cannot browse the Web site easily they are apt to become frustrated and leave the site. Moms of kids with LD are most likely already frustrated when they arrive, and we want to provide them a place that takes away the stress and lets them know someone understands.

Although some of these lessons have been learned the hard way, it has been completely worth it. When we receive emails from moms that read, “I am so appreciative of you [SchwabLearning.org], just for being there. Wish I would have found you sooner,” we know we are doing our job.

Jeanene Landers Steinberg is the Web Director for SchwabLearning.org and had the role of project manager during the creation of the Web site. Jeanene manages a team of eight people consisting of technical, editorial and online community staff who are responsible for maintaining and growing SchwabLearning.org into a premiere Web site for LD information, guidance and support.

Speaking in Tongues

by:   |  Posted on

In last month’s welcome, I set out to describe Boxes and Arrows purpose and goals. On a line by itself I stated this is not a place for jargon. I felt that was important enough to call out. I certainly am being called to task for that.

Jargon is not using a fancy word appropriately, but it is jargon when the fancy word replaces a simpler correct word.

Perhaps I should have stated this will be a place free of jargon. Ridding our writing of jargon is a good goal, but a more complex task than one might think. That said, it’s important to define what jargon is and what jargon isn’t.

Jargon is words used as a gating mechanism. We use jargon when we wish to keep out those who are not like “us” whomever “us” may be. Jargon is when we replace perfectly good accessible English with slang, acronyms and other mangled phraseology. “Monetize” was a dot-com jargon term. It meant, “find a way to make a profit from” and was used partially out of laziness and partially to make people using the word feel like insiders (and perhaps not morons who forgot they had to make a dime on their crazy schemes) 80-20 was a rule for profits—20 percent of your users provide 80 percent of your profit—that became a noun. “Well Joe, the way I see it, it’s an 80-20.“

Jargon is not using a fancy word appropriately, but it is jargon when the fancy word replaces a simpler correct word. Paradigm has often given me fits because it is a perfectly good word… it’s just been abused. People often use it when “model” is probably a better choice. Utilize frequently replaces use when use is the right word. But there is an appropriate time to use utilize… when one means use for profit. We may even choose to utilize jargon if it will serve our sinister purposes in undermining the current design paradigm—but not if there is a better way—a clear, simple ordinary language way.

And jargon is not using a big word that you have to look up. Sometimes when we seek to be precise, we use big words. It happens. A dictionary is a good investment.

Acronyms happen. We have to stay alert for them. One man’s A List Apart is another woman’s American Library Association. ALA means different things depending on what crowd you run with.

New words are born when no word existed previously. It wasn’t that long ago that there was no such thing as an internet, or a CPU, or a handheld. To refuse to use these terms because they might be perceived as jargon would be foolishly handicapping ourselves in the service of communicating.

Finally our authors deserve to be allowed to be eloquent. Adam Greenfield’s style is not Jess McMullin’s, and neither writes like Nathan Shedroff. Nor would we want them to: Boxes and Arrows is composed of people, with a myriad of different voices and different word choices. We will edit to keep their writing accessible, but we will endeavor not to kill the poetry of their language. Writing is a scary and vulnerable activity. An author deserves to have his or her words respected, and editing should enhance and not squash.

So with all these challenges, why try? We try because Boxes and Arrows seeks to be inclusive, not exclusive. We want to cross lines to learn and communicate, and jargon is, as I said, a gating mechanism. So I’ll stick with my earlier statement, though I’ll modify it somewhat:

We will seek to keep this place free of jargon. We will enlist you, the reader to keep us honest. Every article has a discuss link, call us out on the carpet when we say LIS-IA, or directing eyeballs. Definitely bust us when we complain ED is not as good as UX because the CHI’ers are more user-centric in their dev-cycles because of the x-mod they do, while ED is all amusement parks and des9.

In return we’ll do our level best to talk straight.

Christina Wodtke
Publisher