Boxes and Arrows

Experience Themes

Cindy Chastain — Tue, 06 Oct 2009 08:25:53 GMT

There’s an old adage among screenwriters that when a writer can sum up a story in a sentence or less, he has discovered what’s important about the story. He’ll know what the story is about and therefore have a strong sense of theme. And in knowing the theme, he’ll have a compass to use in the process of “designing” the damn thing (i.e. what to keep, what to lose, what actually happens at the end). The story will be all the better for it because it all hangs together with a central idea that will give it greater impact and meaning.

Now wouldn’t it be nice if we had something like that for user experience design?

This article is about a method drawn from storytelling that can help us build a better story about our product, unify teams, inspire design concepts and get us closer to evoking the pleasure, emotion and meaning of the experience we intend to deliver to users through the products and services we design.

So, What’s the Problem Anyway?

As designers, we spend a lot of time examining design solutions against an array of information–business goals, user needs, design principles, best practices, the results of usability tests–but less often (if at all) against a definition of the core experience we hope to deliver. If you’re not sure what I mean, think about this:

We had a big problem at our company. The problem was that the websites we were designing and building were coming together like potluck meals made by a loose confederation of team members and stakeholders who were all working out their dishes independently, and on their own terms.

You know the story: User experience brings the structural framework and behaviors of the interface; creative brings the visual design; client marketing brings the copy; business brings content; our engineering folks were sometimes bringing error messages. When each of these more tangible elements are cooked up in separate quarters without a shared vision or intent how can we possibly deliver an optimal experience, let alone agree on what that experience should be? It’s not that the meal is bad–it often makes a lot of people very happy–it just seemed that we were missing out on a chance to serve up something better, something that would distinguish itself as a dining experience people would remember in a marketplace of potluck dinners.

Coming from a filmmaking background where it’s a matter of course to see an army of people with specialized roles focus their efforts around bringing the story of the “project” to life, it often seemed as if our practice as UX designers neglected an important approach. On a film set, bringing a project to life involves having a very clear understanding of the experience the story is supposed to deliver to an audience. Everyone from the prop master to the camera person has a sense of this experience goal. If the story (or a particular scene) is supposed to make the audience fall over with laughter, the cameraperson, to be sure, will frame each shot in a way that maximizes that goal. Every scene, every moment, every tangible element of a film works together for a purpose: to make it easier for audiences to understand and engage with a story and to create an emotional response to walk away with.

In the case of user-centered design, we do well at coming up with the right technology and features that perform in a way that meets the needs or behaviors we observe in our users. But we often neglect to consider the story that’s told through the interactions people have with the things we make. For this story to be apparent to people, let alone meaningful, those involved with the design of a product should have a shared sense of the kind of experience they are trying to create. In the domain of digital products the story comes from asking the big questions: What’s the product or service about? What will it do for the customer? Where does it fit into their lives? In what ways might we create an emotional response the customer can walk away with?

How does a good story get built? With a theme, of course. Writers and filmmakers have been using themes to build stories for a very long time. They’re also not shy about designing explicitly for emotion and meaning. So why not designers? For us, a definition of the core value of experience can function as the theme that helps teams collectively build a more meaningful product. It’s the thing that can serve as a coordinating force behind the design. When the tangible elements of a product are all working together for the same purpose the product has a stronger story to tell. The theme is merely the thing that helps us deliver that story in the form of an experience.

From Theme to Story

For a writer, a theme is not the thing one starts with, but the thing one “finds” or discovers at some point after the writing has begun. It’s an idea that should emerge organically from the raw material of one’s research, note-taking, plotting, scene-making, and character sketches that are produced during the story planning and early writing process. Typically, a story theme is expressed as a value (greed), an opposition (freedom vs. security), a value plus a cause (justice is restored when the truth is revealed), or simply a very strong gut feeling of what the story is ultimately about. The form can vary widely, and often depends on the bent of the writer or the type of story.

An experience theme also emerges from the raw materials of our design process: the business goals, market considerations, user research and content analysis, among others. Yet while a story theme may express a topic or idea, an experience theme expresses the core value of the user experience. One such theme, for a project commissioned by Agnes Nixon, the renowned writer and creator of the soap _All My Children_, looked like this:

_Reliving All My Children_

Agnes Nixon and her family had asked us to create a site that would leverage their “tremendous library of content in a new, engaging interactive video-centric web property.” That was their only requirement. So where to start?

We started where one might expect. We immersed ourselves in the domain, read about soap operas, watched episodes, and spoke to fans until we got to the point where we felt like we finally understood what this rather obsessive world of fandom was all about.

But when it came time to define functional requirements, it simply wasn’t enough to take the business objectives and our user research and conclude that we should create a flexible video portable that would do x, y and z, include a really cool interactive timeline of Agnes Nixon’s life and a blog authored by Ms. Nixon herself. This wasn’t a concept or an experience. It might be easy to use. It might perform well and look great. But to go that route would do no more than deliver a library of branded video content.

What we needed to know was what this site was all ABOUT. What will it do for these fans? Where does it fit into their lives? In what ways might we create an emotional response the fans can walk away with?

So in an attempt to break away from our customary ways of approaching design we started hunting for themes. We looked at what we had learned about prospective users and soap fans in general and considered our business objectives. With this information we then spent a long time brainstorming ideas that would answer two questions: “What’s the site all about?” and “What kind of experience would be most compelling and meaningful to our users?”

_Reliving All My Children_ was just one of three possible themes. Our plan was to take these themes to the client to see if it would help them further articulate their vision.

Each of these themes sprang directly from what we knew to be true about soap fans, and each evoked a different kind of experience. For each theme there’s also an associated concept and story premise as well as an altogether different set of primary activities. If the site was to be “about” _Reliving All My Children_, then our design process would focus on creating an engagement that would tap into the memories of loyal soap fans who grew up watching the show. This theme evoked a product story about an immersive time machine where fans could engage with a “story timeline” of episodes, read blog posts about memorable moments, ask Agnes Nixon questions about what happened to certain characters.

The idea was that one of these themes would drive the site’s concept, functional requirements and our design strategy. The amazing thing: when the client saw these themes they were suddenly able to talk at great length about their vision for the fan’s experience of the site. We had, together, begun to form our product story.

Go team, go!

Once your team has an experience theme, they can begin to behave more like film crews. Everyone involved in the project will have a clear sense of what the site is about and their efforts can be focused around achieving that experience. When this happens all of the component parts of the product will begin to work together. If you’re a consultant or designer working alone, you can think of the theme as the thing that will coordinate your inner team.

But how does this happen? In our practice, the experience theme is packaged in a way that can be shared and internalized by all stakeholders. This usually takes the form of an _Experience Brief_ that outlines the purpose of the theme, the attributes upon which it was founded and the strategy it informs. And in a manner of speaking this document becomes another iteration of the product story.

For another project we created a theme that was to capture the value of the experience of an entertainment alerts program:

_Don’t Miss Out. Discover something new. Get it first._

With this long-term client, comprised of stakeholders from separate interactive, business and marketing departments, we introduced the concept of a theme with an experience brief that looked like this:

Our goal was to get this client to step away from discussions of pure functionality and to consider the value of using the product. As we were leading the research, we did the work of finding the theme that seemed to best reflect their business goals as well as their user’s expectations. We also appended a strategy, drawn from this theme that would connect it to more tangible, measurable goals.

With this brief on the table in front of them, the concept of user experience no longer seemed so abstract. By expressing the value of that experience, it gave them a way to look at their program from the point of view of their users. It gave us, as their vendor, a way into their ideas of what they envisioned as well as a chance to validate our thinking behind what kind of experience the program could deliver. It led to a discussion about how the efforts of marketing could match up with what we were doing in the design of the online piece.

The overall effect of this simple document was to synchronize our collective thinking about the project. In this way our product story was beginning to form. With this shared story, the copywriter from the marketing department and the interaction designer with our agency could now work toward the same experience goal.

Designing with Themes in Mind

What’s really interesting is how themes, once found, function in the creative process. In the words of Robert McKee, the author of “Story” and screenplay workshop guru, the theme (or, as he liked to call it, the “Controlling Idea”) is the thing that “_shapes the writer’s strategic choices. It’s yet another Creative Discipline to guide your aesthetic choices toward what is expressive of your Controlling Idea and may be kept versus what is irrelevant to it and must be cut._” A subplot, for example, may be constructed as a counterpoint to that controlling idea. A character might be designed to embody some aspect of theme. A scene might be cut because it’s simply not relevant to the theme.

The best way to understand how this applies to design is to think of the theme as the geography as well as the compass. When generating concepts, the theme acts as the region within which our ideas circulate: this conceptual lay of the land gives us an area of focus and a space to create. When analyzing and reviewing solutions, a theme functions more like a compass: if a creative solution doesn’t line up with North, it might mean that it doesn’t quite chime with the theme. In this way theme can inspire solutions as well as help us make decisions during the design process.

In another project, our team used the following theme to inspire solutions ranging from functional requirements to content strategy, site architecture and interaction design.

_Where the Fight Never Ends_

This project was for Showtime Sports, a site delivering content and event information for fans of Boxing and Mixed Martial Arts. We felt this theme encapsulated the idea that the site could provide an online experience that seamlessly extended the kinds of real-world engagement found among fans of the sport. Not only could the fight live on in the context of the site, but fans would be able to engage, follow and learn about the full fight story. It was supported by our research, and potent enough to carry around as an idea that could inspire and inform anyone working on the project and at all phases. It was expressive of what differentiated the site as well as what would be compelling to users. It was good for business as well as design.

Here are some examples of how the theme impacted our design:

Functional Requirements – We used the theme as a compass when looking at our standard spreadsheet of features for determining scope. In addition to frequency of use, importance and level of technical difficulty, we looked at these items against theme. For example, someone had an idea for a really “cool” dynamic ranking tree. Fabulous, but when it’s put up against the core story of the site it really had no place. The site wasn’t about seeing the sport in this way. It was about extending the experience of a fight. With the theme as an additional filter, it was easy to remove this from the list without prolonged discussion about its value. The idea simply wasn’t contributing to the core experience we were hoping to deliver.

Content Strategy – As a basis for content strategy, we analyzed the available content against the theme and created suggestions for new content ideas. Showtime had a wealth of footage related to each event and some promo clips shot before the fight, but nothing about what happened well-before or after a fight was over. When thinking about content that could support our theme, we suggested creating short, cheaply produced segments of the fighters’ private struggles in preparation for an event. We also suggested in-depth interviews with the fighters after the fight–something that would give them a chance to reflect on what they needed to do in preparation for the next fight. In this way, the theme functioned as a space in which to generate ideas that would support our collective vision about what was most important about this site experience.
Site Architecture – The theme inspired ideas for the structure and user pathways. For this, we began thinking about how the users flow through content would reflect our theme. We created a concept model as a way of seeing these paths and their relationship to key content areas. To further explore this idea, we created an animated version of the model which added a dimension of time, where certain content elements appeared during specific “phases” of the fight (illustrated by the colored bands around the content buckets). Our hope was that this evolving structure would also support the theme.

Interaction Design – When it came time to create solutions for the interface, our interaction designers sketched with the theme in mind as way to ideate concepts. This is the moment when the use of theme feels closest to “writing”. In this context theme is simultaneously our geography of play as well as our compass for analysis. We try not to be over-conscious of theme when generating ideas and sketching, but we do want to have it in the back of our minds.

To this end, we usually have our theme written somewhere on the whiteboard. Then, while iterating on sketches, we’ll pause and discuss the way we usually do, but we’ll also reflect on whether or not the sketches are doing anything to support our theme.

This process eventually led to the design of a flash component that stored all video content related to the fight in a carousel organized by time. The linear progression of videos would together create a “fight story”, from early pre-fight videos to post-fight interviews.

Whether users wanted to catch up on something they’ve missed, follow the fight online in absence of TV or revisit the fight at some future point the interaction design was supporting our experience goal of providing a place where the fight never ends.

The lesson? Experience themes can inspire solutions, help teams make decisions and (perhaps most important) help us remember the quality and value of the experience we intend to deliver.

Final thoughts

As Robert McKee writes: “The more beautifully you shape your work around one clear idea, the more meanings audiences will discover in your film as they take your idea and follow its implication into every aspect of their lives.” Themes, used in the context of experience design, can function in a similar way. By aiming to capture the value and focus of experience, themes have guided us in the design process and, by extension have strengthened the impact and meaning of that experience. Equally important, they’ve given us a path to holistic design.

As user experience professionals we should be looking at all aspects of the product or service design, as well as the aesthetic potential of every element that comprises the experience. Themes can help us do that. They can be a potent tool for harmonizing otherwise distinct, tangible elements of a product or service in a way that will effectively distinguish it from competitors and offer a more pleasurable and meaningful experience on the part of the user. A theme can be applied to all stages of the experience design process, and it helps everyone involved in creating the “whole” of the product or service, no matter what their role. From the critical perspective of leaders and stakeholders, a theme will help unify the efforts of those who play a role in anything from the strategy to the design, development and delivery of the service.

The ultimate beauty of a theme is that, in the product or service context, it can simultaneously inform the practical, tactical and aesthetic considerations of our work. It can be the coordinating force for an entire product, or a smaller component of a larger service. It is the organizing principle behind our product story. It can work for business as well as design. And in the end, it ultimately works for the benefit of customers.

Special thanks to Steve Baty, my editor, as well as Joe Lamantia, Jared Spool and Andrew Hinton for their immensely helpful support and feedback for this article.

Integrating Prototyping Into Your Design Process

Fred Beecher — Tue, 22 Sep 2009 22:50:01 GMT

“ Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. ”

Prototyping is a big deal right now. We get wrapped up in mailing list threads, new tools are released at an astonishing pace, books are being published, and articles show up on Boxes & Arrows. Clients are even asking for prototypes. But here’s the thing… prototyping is not a silver bullet.

There is no one right way to do it.

However, prototyping is a high silver content bullet. When aimed well, a prototype can answer design questions and communicate design ideas. In this article, I talk about the dimensions of prototype fidelity and how you can use them to choose the most effective prototyping method for the questions you need answered.

The dimensions of fidelity

A prototype’s fidelity has the most influence over its effectiveness. Fidelity simply refers to how realistic the prototype is. Most of the time when we talk about a “high-fidelity” prototype we are referring to a prototype that has some visual or industrial design applied to it. But that leaves out what’s most important to UX designers, what it’s like to actually work with the prototype!

Fidelity is multidimensional.

Not only can you have a prototype that looks like a realistic product, but you can also have a prototype that works like a realistic product. I call these dimensions of fidelity “visual fidelity” and “functional fidelity.” By varying your prototyping methodology along these two dimensions you can ensure that your prototyping effort is successful given your particular context. Let’s take a look at some examples.

A prototype can be as simple as a series of hand-sketched wireframes that flow together. This is a good example of a low visual fidelity prototype. These wireframes show layout and functionality but have no visual design. Take the same wireframes, integrate a visual design, and your prototype has a high visual fidelity. While you might think of them as being similar, these two prototypes are most effective in two different situations.

That same series of sketches is also a low functional fidelity prototype. Moving through screens drawn on paper is much different than working with the developed system. But if you render those sketches in HTML, JavaScript, & CSS, they have a high functional fidelity. Working with an interactive prototype is very similar to working with the developed system. Again, high- and low-fidelity prototypes are most effective in two completely different situations.

After spending all this time talking about fidelity, I want to share one of my favorite quotes on prototyping. Bill Buxton said this in his Interaction08 keynote:

There is no such thing as high or low fidelity, only appropriate fidelity.

Appropriate Fidelity

“Appropriate fidelity” refers to a level of prototype fidelity that allows you to achieve the goals you’ve set for doing a prototype in the first place. By varying the fidelity of your prototype along the dimensions of visual design and functionality, you make your prototype more effective at achieving some goals and less effective for others.

Low Visual and Low Functional Fidelity

Very low fidelity prototypes are extremely useful to UX designers. Why? They can be made swiftly, changed without repercussion, and still help visualize a concept. Low visual & functional fidelity prototypes are helpful at answering large structural questions. Here are some examples:

Does the system have all the features required to support the user’s goals?
Does the workflow make sense at a high level?
Which UX concept works best?
Coming to consensus on a UX concept with stakeholders, e.g.”Is this what you meant?”

Low Visual and High Functional Fidelity

In my own practice, this is the type of prototyping I do most often. What I make are interactive, HTML interactive wireframes. Everything is black, white, and gray, but the interactions are extremely close to what they’d be in the developed system. These types of prototypes are effective in many situations:

Evaluating the usability of proposed designs for new systems
Exploring isolated interactions as a proof-of-concept
Validating UX design direction with stakeholders
Validating the implementation of requirements with stakeholders
Supplementing printed documentation for development teams
Performing remote testing

Remote testing has become more and more important over the last several years. At Evantage, we do approximately 75% of our user testing remotely. It would be difficult for us to get good data about our designs for modern, highly interactive sites if we were limited to representing those designs using low-to-medium functional fidelity prototyping techniques such as clickable PDFs or interactive PowerPoint presentations.

“ By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an application around it…. If those ideas are actually pretty slick, I can release the design with confidence instead of with gritted teeth. ”

I also want to expand on proof-of-concept testing. This technique supports creativity and innovation. By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an entire application around it. This allows me to explore my crazy ideas and find out if they are, in fact, crazy. But if it turns out that those ideas are actually pretty slick, I’ll know that and can release the design with confidence instead of with gritted teeth.

High Visual and Low Functional Fidelity

At first thought, these prototypes may not make much sense. Why bother making something look nice if it doesn’t work? Well, because how something looks can have a huge impact on how easy it is to use. A high visual and low functional fidelity prototype allows you to test that with users. You can print out screen images and do a paper prototype test with them, or you can image map some JPGs and do what I’ve heard termed a “slap and map” test from within a browser.

High Visual and High Functional Fidelity

High visual and functional fidelity prototypes are the Rolls-Royce of prototypes. They take more time and effort to build than a lower fidelity prototype and are correspondingly more complicated to manage. Most of the time, this extra cost isn’t worth it. But there are a few situations where it is:

Evaluating the usability of proposed UX designs for an existing system
Performing usability tests with non-savvy user groups
Supplementing printed documentation for offshore development teams

Prototype testing is all about data, right? In the first two situations above, the prototype’s high visual fidelity reduces the confounding factors a wireframey prototype can introduce into test results, thus maintaining the quality of your data. In the third situation, the high visual fidelity helps minimize the design communication and interpretation problems inherent in offshore development.

Integrating Prototyping Into Your Design Process

What I’ve talked about so far has focused on the tactical, on how to prototype effectively to achieve specific goals. What I want to talk about now is more strategic. How can you integrate prototyping effectively into your design process?

First off, do what you’d do to begin any organizational change. Start small. Find a small project, express the value of prototyping and your interest in doing it, and do it. It would be best to start with something richly interactive though, as prototyping is more crucial the more interactive a system is. Of course, make sure you use a prototype of the right visual and functional fidelity for your purpose.

“ People like shiny things that move. The cool factor of prototyping will be difficult to resist. ”

As you near completion of the prototype, make sure you walk through the prototype with the project’s stakeholders. Ask them if something like this was what they had in mind. This will impress them on two levels. First, people like to feel important, and you’re soliciting their opinions. Second, people like shiny things that move. The cool factor of prototyping will be difficult to resist. When these stakeholders are involved in future projects, it’s very likely they will actually request a prototype as a result of their first experience with you.

Once you get buy-in, you can start integrating prototyping into your process. But just like different methods of prototyping are more effective for answering certain questions, different business contexts call for different ways to integrate prototyping.

Corporate, Agile, Mature UX Practice

This situation is fast-paced and iterative, but as an employee (as opposed to a contractor or consultant) you have the opportunity to own the UX of your company’s products. In this situation, there are three points in the design process that prototyping can be of benefit.

Low visual and functional fidelity prototypes can help select good UX concepts from several that you develop at the beginning of a project.
High functional fidelity proof-of-concept prototypes can help develop those concepts into usable designs.

You can work with a dedicated prototyper to build a separate prototype using code that can be reused in the production system to build efficiencies into an Agile process.

Corporate, Waterfall, New UX Practice

In this situation, the organization might not be comfortable enough with UX design to support the development of multiple UX concepts. You might just have to begin developing the wireframes and prototypes to meet the organization’s need for documentation and measurable signs of progress. This situation relies heavily on the prototype for communicating and validating direction with project stakeholders, with user testing often not yet being a real possibility. Here’s how prototyping can help:

High functional fidelity prototypes can help you communicate better with stakeholders and get their input on your direction
These prototypes should also be used for user testing, if at all possible.
Walk through the interactive prototype at the same time you walk through the printed documentation for the developers during handoff.

Consulting/Agency

When doing UX design for an external client, a lot of the magic is worked behind the scenes. The result is a process that is relatively unencumbered by internal politics. The challenge is to convey the importance of iterative prototyping to clients who sometimes feel like they’re paying for the same thing twice.

Sketch two or three of your design concepts into simple, low visual and functional fidelity prototypes and test them to decide which to go with. At this stage, testing can be very informal and done with anyone capable of putting themselves in the user’s shoes (e.g., other UX designers, customer service staff, or product managers who used to be users).
Build a small interactive prototype that shows the critical interactions, walk through it with stakeholders to validate your direction, then test with users.
Revise the prototype based on the test results, flesh it out to support more holistic tasks, and test again.
Revise the prototype and use it to supplement the paper documentation as you walk through both with the development team.

Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. If you follow the simple guidelines above and prototype to an appropriate level of fidelity for your context, you will achieve your goals and improve your design. No firearms required.

A Wiser Interaction

Chris Baum, Jeff Parks — Tue, 01 Sep 2009 06:05:47 GMT

iTunes Download Del.icio.us Boxes and Arrows theme music generously provided by Bumper Tunes

Chris Baum speaks with Bill DeRouchey, co-chair for the 2010 Interaction Design Conference, about the upcoming conference and how the third annual conference will start to model the essence of Interaction Design.

Looking Back
Bill talks about the first two years of the conference, the lessons learned from those experiences, and why Interaction ‘10 returns to Savannah.

A Brand New Program
For 2010, the program is quite different. Bill explains the new approaches, in particular “Discussions” and “Activities,” and why they are changing things up. He also covers the “Documentary” and “Art Exhibition,” two new Interactions-related events.

Submitting for Interaction 10
Interested in submitting session proposals for Interaction10? “Submissions are open”:http://interaction.ixda.org/submissions.php until September 15.

Documentary and Art submissions are open until November 1.

IxD S.W.A.T. Team
Along with Bill and Jennifer Bove, his co-chair, the conference team includes several well-known designers. Bill explains how each is bringing her/his talent to the conference preparations.

IxD in a Physical Environment
Flow of people in a hotel is relatively easy. In Savannah, however, Interaction spans several buildings. Bill describes how that will affect the design of the conference proper.

Sponsors
Interaction 10 will also introduce some new sponsorship programs. Bill explains what this means and how that helps both sponsors and conference attendees.

Test & Iterate
The conversation closes with more reflection on what the IxDA has learned from the first two years of the conference, and how 2010 will reflects what has come before.

For more information, visit “interaction.ixda.org”:http://interaction.ixda.org/.

IDEA 2009: An Interview with Thomas Malaby

Russ Unger — Sat, 22 Aug 2009 17:29:17 GMT

As IDEA 2009 draws closer, the IA Institute is conducting a series of interviews with the speakers for the conference. As Director of Events and Marketing for the IAI, I fill a variety of roles and lead the charge for the IDEA Conference this year, as well as get to Interview the IDEA Presenters (which I proudly share with Greg Corrin in this case).

For this interview, I was able to ask a few questions with Thomas Malaby. Malaby is an Associate Professor of Anthropology at the University of Wisconsin-Milwaukee and has a forthcoming book titled "Making Virtual Worlds: Linden Lab and Second Life" from Cornell University Press.

You recently finished a book about Second Life and online communities titled “Making Virtual Worlds” (Cornell University Press). Can you describe how your research process was structured for this writing effort? How does one conduct ethnographic research in online communities effectively?

The rise of digital technologies poses many challenges and opportunities for ethnographic research. Because this project centered on the makers of Second Life, Linden Lab in San Francisco, to a certain extent the familiar form of face-to-face ethnographic participant observation and interviewing was possible. But nonetheless even within the company an enormous amount of communication occurred through technologically mediated channels, including multiple email lists, wikis, an IRC channel, instant messaging, plus all of the tools for communication found within Second Life itself, wherein a great deal of Linden employees’ work was done.

What are some of your key research findings about Second Life? How is this community progressing from a sociological perspective?

My primary finding concerned the way in which the ostensibly “user-generated” world of Second Life was nonetheless shaped so deeply by the values and expectations that the makers at Linden Lab inscribed into it. What emerges is that while we may be tempted to think of the communities (and there are many) within Second Life as existing in a somewhat “natural” state, free to develop as they wish, in fact all users of Second Life are always already acting within an environment that makes assumptions about what kind of people they are. The inscription of property rights into the world is only the most obvious example of the ineradicable ideological assumptions that are part of SL.

Do you have any advice for professional or other organizations as to how they could use Second Life to help foster increased activity amongst their members?

Second Life’s advantage is the wide bandwidth for nuanced social action that it provides. That is, moving about as avatars within the environment broadens the scope for meaningful expression in ways that can form the foundation for powerful applications. From my point of view, the most promising of these are educational and therapeutic — uses that leverage the real human connections possible in an environment that allows people to express themselves so broadly.

Did you find in your research that Second Life is evolving in a unique way compared to other communities?

Certainly, but in a sense any given community changes historically in a unique fashion. We are always tempted to find some common sequence or pattern to how societies change, but overwhelmingly the evidence that anthropology and related fields have found about all communities is that they change historically, in contingent ways. There are some patterns we can observe that hold across some if not all cases, but no universal path. This is a facet of all change (even evolutionary change) that Charles Darwin deeply appreciated, but it is often forgotten in our desire to have universal answers.

Do you care to make a prediction on the future of online communities? Will Second Life shape any primarily online social world going forward, or are other systems innovating in other more interesting ways?

I think Second Life already has. Metaplace, the new virtual world by famous game designer Raph Koster, owes an enormous amount to Second Life in its conception of what users want (ideas that more deeply connect with longstanding assumptions about people, authority, and technology in postwar-U.S., especially the Bay Area).

Do you spend much time actively participating in communities online or are you always wearing a researching hat? If so, in which communities do you spend your leisure time?

I spend a great deal of time in virtual worlds, and almost all of it is in World of Warcraft, where I lead a guild of academics and their friends and family.

There are many different online and mobile applications that allow people to find new methods of connecting with very little overhead. How do you think SecondLife can compete—or work in conjunction—with these?

With any networked technology (really, any technology) we must always be mindful of the specific experience of using it and the affordances it brings. There are things that Second Life and similar worlds are good at that mobile apps could never hope to achieve, and it is the same in the other direction. We don’t need killer apps, we need killer uses—and those are far harder to anticipate and encourage through design.

—

About Thomas Malaby

Thomas Malaby is Associate Professor in the Department of Anthropology at the University of Wisconsin-Milwaukee. He has published numerous works on virtual worlds, games, practice theory, and indeterminacy. His principal research interest is in the relationships among institutions, unpredictability, and technology, particularly as they are realized through games and game-like processes.

You can learn more about Thomas on the Speakers Page and the Program Page of the IDEA Conference website.

About IDEA (Information Design Experience Access) 2009: Social Experience Design

IDEA2009 brings together the world’s foremost thinkers and practitioners: sharing the big ideas that inspire, along with practical solutions for the ways people’s lives and systems are converging to affect society.

These days, you can’t be socially engaging without considering the experience design. IDEA2009 brings together like-minded people who want to continue the exploration of Social Experience Design.

The Content Conundrum

Christopher Detzi — Mon, 03 Aug 2009 23:28:47 GMT

As web designers and information architects, we often dismiss deep consideration of content when we design interactive experiences. By content I’m not only referring to the various forms of text (e.g., headers, body copy, error messages) but also imagery, graphics, and videos or audio that make up the full interactive experience.

Sure, we have a sense of what content is available, and we’ve likely considered it to some extent when creating flows, wireframes, and prototypes. But the design artifacts that we create represent only part of the overall user experience that we’re designing. The content that sits inside of our design framework is often the final arbiter of success, yet we sometimes diminish its importance and separate ourselves from it. The more we separate our design activities from content development, the greater the risk of design failure.

Recognizing The Problem — The Content Gap

There’s often an unsettling discrepancy between the stakeholder approved wireframes and visual comps and the actual product in production. What you see in those environments is sometimes a far cry from those polished wireframes and those shiny, pixel-perfect visualizations that were filled with placeholder content (such as lorem ipsum text, dummy copy, and image blocks). What you’re seeing in production environments now holds the real content. The imagery doesn’t support the interactions, is meaningless, useless, or worse, contradictory to the design intent. The copy, headers, and labels are unclear, too long, too short, or simply irrelevant.

What happened?

More than likely, that content was discussed, created, and iterated outside or separate from the core design review process and ultimately plugged into a content management system (or pasted into the code by a developer) much later in the development process.

The example illustrated in Figure 1 shows two examples of web content. The image on the left represents a screen shot of the approved design that was delivered to the production team. The image on the right is a screen shot of that same page taken from a functional test environment after the real content was included. As you can see, the experience breaks down considerably with the amount, type, and format of the real content. The information is more difficult to scan, the primary call-to-action has been pushed well below the fold, and the choices that users need to make are less clear.

While this example highlights only a small portion of the overall web site, the problem manifested itself throughout the bulk of pages that made up this interactive experience. So what might be perceived as a small problem becomes a much bigger problem when considered across the entire interactive experience.

Exploring the Causes

These content gaps are both procedural and cultural within organizations. By procedural, I’m referring to the tangible processes used by an organization to design and develop a web product. Often times, these ‘processes’ are influenced by the organization’s values and overall culture. There are four common reasons why content gaps occur.

Flawed Processes

There’s undoubtedly a wide spectrum of web design and development ‘processes’ in use today. Most often, however, organizations use one that aligns more closely with either a traditional waterfall process or alternatively, an Agile one. In theory, both models have mechanisms built-in to eliminate and minimize surprises (including content gaps) but in reality, both tend to exacerbate the problem but do so in different ways. Rigid waterfall processes fail because they tend to segment activities and related roles. Designers often design totally separate from content ideation and development. Agile processes fail because they’re typically developer centric and move at speeds and iterations more akin to code production than to experience design and content development. The site is often being coded before the design or content are ever completed.

Content The Design(er) is King

“ We’re at a point now where usability is table stakes, and persuasion and message is necessary to differentiate products. ”

The value of most design projects is typically placed in the upfront design and strategy work. It’s here that the ‘big ideas’ are generated and explored. During this initial phase, are the right people involved in the design process alongside of us, exploring solutions? I’d argue that we rarely involve our content partners, even though we’re essentially creating a framework for communication and messaging. It’s here that content specialists thrive. We’d benefit from including those who specialize in communication, writing, persuasion, and instruction more directly. We might argue that as designers that we have those skills, but then we shouldn’t rely so heavily on placeholder content in our designs.

There’s a lot we can learn from traditional advertising here. In advertising, copywriters often drive the creative process. Their skills with communications and persuasive messaging are often unparalleled within an agency. We’re at a point now where usability is table stakes, and persuasion and message is necessary to differentiate products. In fact, some leading companies are beginning to recognize this change and develop tools and/or POVs on this topic (See Eric Schaffer’s article, “Beyond Usability; designing web sites for persuasion, emotion, and trust” and Forrester Research’s report, “Use Persuasive Content to Improve the Customer Experience”).

Design artifacts rarely include “real” content

I understand the need for lorem ipsum text and placeholder imagery. I am an information architect, after all. When working on an overarching framework for a web experience and creating a flexible design system, it makes sense to start with concepts and relationships, and to establish the right models and structures first. However, the more we start illustrating these concepts at the page level, the more we must concern ourselves with content and the overall message we want to create. By relying too heavily on placeholder text and graphics, we begin to communicate a level of reality that is problematic. It’s at this point in the process that the actual content should be considered and where our design deliverables should communicate these details.

Obviously, exploration of visual styles, hierarchy, and the overall visual language is crucial at this stage. That said, effective content to support those elements is absolutely essential for design success. The content works in conjunction with our visual language and style to help people move through and understand the information space they’re in. The more the design and content can be explored, iterated, and finalized together during this phase, the fewer problems we’ll encounter when the site goes live. Dr. Browyn Jones said it best in her 2007 article, titled Better Writing Through Design:

“Ideally, you should work with a writer from day one to design the voice of the copy in conjunction with the visual language of the site. And getting a writer involved early can help you solve lots of other problems—from content strategy issues to information architecture snags. Remember that writers are creatives too, and they are, in many cases, the keepers of the content your design ultimately serves.”

Lack of value assigned to content

When taken as a whole, the general perception is that content teams are production teams and therefore non-creative. Taken as a whole, content teams are typically highly focused on production and publishing issues. An unfortunate side effect is that these individuals are brought in much too late in the process, immediately playing catch-up, and trying to understand the bigger design decisions that were made. In many cases, the only information that they have to go on is a lot of ‘lorem ipsum’ or other placeholder content.

What Designers Can Do to Address these Problems

As a design community the first thing we can do is recognize the problem and want to fix it. I’d suggest that we look at it selfishly at first, realizing that if content fails, our designs fail. Period. There are a number of tactical things we can do with every project to mitigate the risks.

1. Rethink the need for specific content

Do you really need that introductory text? What about those thumbnail images? What will those elements really accomplish for your design? Are they necessary? Many of the content components we include don’t contribute to design goals or the users ability to perform a task. Simply remove those from the design entirely. The more concrete we are about what is and isn’t open for interpretation (or worse, misrepresentation) the fewer surprises we’ll see in those functional environments.

2. Explore Information Graphics & Visualizations

Take a step back from your designs and see what information can be communicated more effectively using visualizations and/or informational graphics. Let the user’s ‘scanning’ behavior work to your advantage. What can be communicated better with simple imagery than with text? How can that general concept be applied to your overall design paradigm? This critical extra step will improve and streamline the user experience. If you’re not the best person to create these assets, bounce your ideas off of the visual designers and production artists. Reviewing your own work this way will dramatically improve your design. As a bonus, the more perspectives you hear during this process, the better informed you’ll be to solve the design problem.

3. Write (some) content

If you can’t get a copywriter or content expert working with you from day one, spend some time writing draft content or sketching actual imagery and place it into your design artifacts. The goal isn’t to be perfect, but to communicate to stakeholders and partners the intent behind a particular content element or component. Bring the design to life and create actual content, headlines, text, instructions, headers, and imagery. Force feedback on those elements at the same time This will force you to think through the necessity of the content, the importance of the message, and force the same thought from your stakeholders. This means using lorem ipsum sparingly, particularly when designing critical web pages or elements that significantly impact the experience. Don’t rely on someone else to do it without first thinking hard about it yourself.

4. (Really) Collaborate with your content partners

“ The collaboration that we demand from developers should parallel those we have with our content partners: copywriters, strategists, production artists. ”

The collaboration that we demand from developers should parallel those we have with our content partners: copywriters, strategists, production artists. Often times, the content teams or copywriters are working with brand, marketing, or product teams on the creation of ‘final’ content. They understand what those teams need to accomplish and what they’re trying to communicate. Rather than have that process happen without your oversight, get involved early and often with these people and describe your vision, solicit their input, and ask for help clarifying your message and assumptions. This back and forth (like the one we expect to have with development) needs to happen with our content partners as well. Become friends with them. Remember, their skills at persuasion, messaging, branding, and simply overall writing prowess can only improve our designs.

5. Package real content with the visual mock-ups

Whether it’s visual comps, or a prototype, it’s important that whomever is responsible for creating and approving the content is actually involved with the visual designer and prototyper as they ‘package’ that deliverable. It’s impossible to fully evaluate the effectiveness of a web experience without having the content represented and under the same microscope as the design. Brand, product, and even training teams all have their own perspectives about what the content must communicate and are contributing to its development and we don’t want our design to fall apart once this ’collaborative’ writing process starts. Assign accountability to content upfront and place content professionals under the same creative deadlines you’re marching to.

There are a variety of tools and software emerging that can help you work with content. For example, Adobe InCopy hooks into Adobe InDesign. It’s just a matter of time before we start seeing integration points with Photoshop and other standard web design software and tools. But even without formal tools, the important step is that ‘real’ content is represented and tells a more complete story about the design you want to put out there.

Conclusion

It’s up to you to assess whether these content gaps are a problem in your design environment or not. Admittedly, this problem is more applicable to larger web sites and online businesses given variety of stakeholders (read: opinions). That doesn’t mean that these concepts don’t apply to the social web, or smaller marketing or micro web-sites. They do. It’s just that how critical this issue is depends on the size and scope of the website or application you’re designing.

This problem is common in many organizations (small and large). As a design community, we hold the power to 1.) change how we think about content, 2.) bring other roles into our processes, and 3.) change how we communicate with stakeholders and partners. Collaboration is what we strived for when developers shut us out, now it’s our turn to open up and let our content partners in and build even better experiences for our customers.

IDEA 2009: An Interview with Leisa Reichelt

Russ Unger — Mon, 03 Aug 2009 23:28:44 GMT

For this interview, I was able to ask a few questions with Leisa Reichelt. If her name is not familiar to you, it’s possible you’ve heard of the term "ambient intimacy" that she coined (and frankly, is quite too often NOT cited as the source for that). You can learn more about Leisa online at disambiguity where she blogs. You can also be on the lookout for Drupal 7; I hear she had a thing or to do with that…

Where do you go and what do you do to recharge, find inspiration, or renew your creativity?

I think the most guaranteed way to get myself into an inspired and creative state is to spend a few hours in an art museum – I particularly love being so close to the Tate Modern in London, but just remembering visits I’ve made to the Pompidou, the Guggenheim in NYC & Venice (I am a complete sucker for the Modernists) and I can almost feel my mind open up and think about what the future could be like and all the different ways to approach communicating what we’re thinking and feeling and believing.

At the completely other end of the scale, I also draw a huge amount of inspiration from my Twitter network and the tiny little nuggets of ideas, ourselves, and what we make of our world. I’ve also recently taken up crochet as a way to try to switch myself off for an hour or so in the evening – it is kind of like my equivalent to meditation, I guess.

And the other thing I find really valuable is to travel and spend time in different parts of the world. It is so easy to think that there is only one way of living, of seeing the world, and the best possible antidote to that is travel – I think that it is incredibly important as a designer to remind myself that ‘my way’ is just one of very many, and it is alarming how quickly we can forget this if we continue to surround ourselves with everything that is familiar.

As a parent, I often find myself “accidentally” teaching categorization and sorting to my kids. As a parent, do you ever find yourself trying to teach some tricks of the trade to your child?

Ha ha! No, not yet. I’m just trying to get him to put everything into one container at the moment (my boy is 18 months old and resisting the concept of ‘cleaning up’).

At this point it is all about him teaching me, actually. I have an iPhone that he has been using for a few months now, initially just as a music player for his nursery rhymes when we were in the car, but now he has several programs on the phone that are there specifically for him (Koi Pond, Bubbles and Peekaboo Barn for parents with iPhones – I recommend them!) I am constantly astounded at how skilled he is at interacting with my iPhone – not only for the applications that are designed for someone like him, but he can actually find the application on the phone, launch it, hit ‘Start’ (not settings) – I think it’s amazing and it makes me think a lot about what the world will be like for him, where these kinds of interactions will be a part of every moment of the life that he can remember. It’s exciting!

Drupal is many things; in addition to being a content management system it can be used for social networking and community organizing—how are you and the Drupal community working to make it better at supporting social interactions and experiences?

For the Drupal 7 release, the main thing that we’re trying to do is to make the Drupal platform and the wide range of tools that it makes available for social interaction and community building online more widely accessible to non-developers. At the moment, it can be a pretty daunting experience for someone who is new to Drupal or who doesn’t have a developer background and we’re trying to improve that experience by developing a system wide design that is more focussed on the ‘content creator’ role than it has been in the past. We’re not specifically aiming to make it better at supporting social interactions & experiences, but I do hope that is one of the outcomes of the work we do.

As a designer for a prominent open source community project, what have you found to be the keys to success in working with open source developers, specifically on the usability and experience fronts?

Ah, I’m not sure that we have yet found the keys to success – it is a big journey for everyone involved. Some things that have worked well though has been to clearly articulate some goals and/or principles for the project that can be easily repeated by the community throughout the project (for example, some of ours are to ‘focus on the content creator’, the ‘design for the 80% rule’, and the ‘use smart defaults’ rules) – defining these early on really helps people understand the direction you’re heading in, and then later on, helps you to explain why you’re suggesting approaches that may be unexpected.

Sharing the way that we work, I think, has also been very useful – we (Mark Boulton & I) really wanted to avoid any sense of design ‘mystique’ and to really show what designers do, how we work, the processes and methods we use. I think this does two good things – it helps people understand why designs are they way that they are, but it also makes design and designers more approachable and understandable, and perhaps even encourages some people to start integrating some of our practices into their own way of working. For example, I know that since we did the ‘crowdsourced usability testing’ and really made the process of doing a short usability test really transparent, there are some developers in the community who now actually do some observational research as a part of their practice now, which I think is beyond excellent.

We’ve also had to learn to shape the way that we work to suit the community a little – we need to be ready to explain, in detail and often, the rationale behind almost every pixel on a page. This is pretty heavy going at times, and not really a great way to get design implemented, but it really has made sure that we’ve really thought through why things are designed the way they are – it makes for a very thoughtful process.

I know many of my friends who are developers are excited—and possibly a bit nervous about the next version of Drupal being released. How do you think members of the UX community will receive it?

Oh gosh, I don’t know. I’m nervous too!

Anyone who has been following the process on D7UX.org should know what to expect because we’ve been posting screenshots of the work for months and the overall principles of the design of the next version have been out on the table since about April this year. I really believe that the user experience of Drupal 7 will be a significant step forward, and will make the experience of using Drupal for content creators and ‘clients’ of Drupal developers much, much better.

Having said that, there is a lot that we would have liked to have done to make Drupal 7 a truly game-changing release that we weren’t able to get over the bar. We had really hoped that with Drupal 7 non-developers would be able to build a site of reasonable sophistication that looked good within 30 mins of installing Drupal, and I don’t believe we’re going to achieve that goal this time around. I’m pretty proud of what we’ve achieved, though, considering the speed at which we’ve had to work and the complexities associated with the project – I hope it sets a good benchmark for what can be achieved when designing with a community.

You are currently in the UK, but have worked in Australia and on multi-national projects in the past. How important is local knowledge and understanding of cultural nuance in the design of social interactions online?

This is such a tough question and I go back and forth on it all the time. In some ways it is incredibly important and in other ways it is amazing how unimportant it is. I think it depends a lot on what you’re socialising around.

I think that if you are designing anything for cultures that you’re not native to – whether that be another country or an existing community – you really need to try to immerse yourself in that culture and to make sure that you’ve got a lot of great access to natives of that culture to help you make good decisions and avoid dumb oversights.

Having said that, I also think that we have much more in common, universally, and that there is a lot to be said for focussing on that.

Language is the real kicker though. I quite often have other English speakers (in the UK and US) look at me as though I’m speaking a foreign language and I realise that I’ve inadvertently slipped into speaking ‘Australia’ – I can’t even tell what is ‘Australian’ and what is not because I always thought I was just speaking ‘English’ – what a myth that is! (I’m also waiting to see if you’re going to change all my s’s into z’s when this is published!)

So many of the times that I’ve witnessed disagreements and hostility arise in an online community, the culprit has been language – mostly because so many of the important discussions are held in English only, and people are forced to engage using a non-native language – sometimes things come across entirely differently to how they are intended because the original intent gets lost in translation. Assuming best intent is such an old guideline but one of the most important and one that I’ve clung to over the past 12 months or so!

Do you think online communities culturally assimilated by virtue of the medium or still strongly affected by state and regional norms of culture and behavior?

This is a great question and I had to ask my Twitter network what we seemed to agree on.

1. see above re: language (see, I told you it’s the real kicker!) – language is the most likely reason for us to cluster online in a geographically influenced way which creates an environment where state and regional norms are likely to prevail, however; 2. it’s an ongoing negotiation and changes over time and is different from network to network (Anthony Gedden’s work on the Theory of Structuration is worth checking out if this is an area you’re interested in)

My experience has been that the more mature, geographically diverse and subject focussed the online community, the more likely they are to have a culture and behaviour that is unique to itself and to the more general ‘medium’ of ‘online community’ than it is to the norms of the individual participants ‘offline’ cultures. It is a constantly shifting environment though and endlessly subject to change both as the number and characteristics of its constituents varies, and also as particular behaviours are imposed onto the community (I’m thinking of how communications have to change in order to include participants who don’t read code, for example – one of the shifts that the Drupal community has been making in recent times).

—

About Leisa Reichelt

Leisa Reichelt is a freelance design researcher & user experience designer who has worked with global brands, innovative startups and open source communities to help them deliver great online experiences for their customers and community members.

You can learn more about Leisa on the Speakers Page and the Program Page of the IDEA Conference website.

About IDEA (Information Design Experience Access) 2009: Social Experience Design

These days, you can’t be socially engaging without considering the experience design. IDEA2009 brings together like-minded people who want to continue the exploration of Social Experience Design.

Using Wikis to Document UI Specifications

Peter Gremett — Mon, 29 Jun 2009 08:16:54 GMT

Introduction

The role of the interaction designer is to specify the interface’s behaviors and elements, so that engineers know what to build and how the product should operate. This documentation is commonly known as a UI specification or UI spec. There are several applications for authoring a UI spec, with wikis being a relatively new tool. However, designers should be aware of a wiki’s benefits and drawbacks for documentation, since UI specs uniquely reflect a project and its context. The documentation needs are often based on the size of the project, launch date, team dynamics, audience, technology, and the product development process. The development process usually plays a major role in how teams interact and how work is completed or delivered, thus, there is a direct relationship between the UI spec and the process the team is using.

Description of the Problem

There are many product development processes and one that has garnered much attention is agile. Agile refers to a group of software development methodologies that promote the project development lifecycle through iterations, open collaboration, and process adaptability. It moves away from traditional process-heavy methodologies and instead focuses on quick actions and an evolving plan as steps are taken.

The Agile Manifesto¹:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a strict plan

Many claim that agile methodologies help companies increase revenue, reduce costs, improve quality, ensure compliance, and drive innovation throughout the product lifecycle. As designers, we often find ourselves working with teams that are using agile processes. I propose that the UI spec is best documented through a wiki when working in such an environment. This method is both adaptive and sufficient for teams building and delivering products, and helps to foster the collaboration that agile development requires. Problems with traditional UI specs include the following:

Documentation is expensive to write and maintain
Encourage a waterfall methodology
Slow downloading time for documents filled with tables, images, and cross references
Difficult to facilitate collaboration within the document
Rely on one central author to write and maintain the document

Wiki Overview

Before you can write anything you must have wiki software² established on a private server. There are many articles available³ to help you choose the right wiki software⁴. Once you have the software installed it’s time to get going! The quickest way to make progress is to create a template that you can use for every project. A basic template frees you from having to repeatedly format a wiki page each time you begin a new project. You can modify your starter template and learn what format works best for you and your team. Template elements to consider include the following:

Table of Contents: A list of topics related to the project in order of appearance.
Tea List and/or RASCI Model: Owner, accountable person, or support role on the project; someone who provides input or expertise on its outcome.
Issues Section: Captures running problems or questions that need to be resolved.
Tables: How to layout information in a grid format.
Titles: Attributes such as bold, color, size, etc.
Subtitles: Attributes such as bold, color, size, etc.
References: Links to related information resources.
Figure References: How you refer to a figure or diagram within the document.
Images: Thumbnails and full images, as well as defining rules for opening a new window.

As you gather information and ideas, you can document them in the wiki. The nature of the wiki makes it fast and easy to record ideas, which helps to spawn additional ones and encourages participation. This process allows you to have a repository that can be easily reviewed by your team members. Undoubtedly, the wiki spec will start conversations among team members both online and in person. As you add more detailed material, your team members will be more likely to contribute. My experience has been that if someone needs clarification on a topic, they are vocal about it and team members will make sure the required information get added to the wiki. Before you know it the spec will be complete.

Benefits

Collaboration

Collaboration is the single best advantage of a wiki spec over a traditional one. The supposition of a wiki is that there are many authors and contributors to the document, and therefore, you have the right environment for collaboration. This is a huge advantage for product specifications. As the interaction designer you don’t have to sit in a cube by yourself and define everything on your own. It’s fine not knowing all the answers and you can rely on your team to help fill in the blanks.

Team members can add clarifications, details, or make edits to content. Oftentimes, the details and clarifications build upon one another to complete the document. For example, if the designer has specified the layout and behavior for a button, the tech writer can add in the rollover text without disturbing the designer or the flow of the project process. To follow the example further, the tech writer can then add the help content to the wiki, allowing the engineer to upload the information onto a server and post the URL. The transparency and collaboration are quite amazing. Team members are able to get the information they need to perform their jobs and help the project along.

Speed

Speed is a major benefit of wiki specs. This is also why it’s a good match for agile projects. Speed comes in two forms: writing and consumption. It’s easy to add content because of the WYSWIG interface. As you begin writing content, it can be instantly viewed by team members. I have found that the sooner you post sketches and thoughts the better. It gets the whole team collaborating and they can offer feedback immediately.

Flexibility

A wiki spec is extremely flexible. This characteristic allows you to morph its structure and organization as the project evolves, reflecting the nature of agile processes. The team is able to keep up with the changes that occur in an agile project because all edits can be instantly viewed. Additionally, if anyone wants to be informed of the most recent wiki changes, an email notification system can be set up by any team member.

Reversible

In the event that a change was accidental or a major disagreement arises, the wiki spec can be reverted to its previous version. This does not happen very often, but when it does, it’s a real life saver.

Figure 1: The image above shows the wiki revision history, including the date and time of the latest modifications.

Centralized Image Updates

As they say, “a pictures is worth a thousand words” and the old expression applies to UI specs as well. No spec would be complete without images to help the team see what it is building. Once an image has been uploaded it’s easy to update all instances of that image. All that’s required is uploading a new image with the same name. This step saves time for team members and interaction designers, since we’re usually creating screen mockups as we go.

Informal Approval Process

A team typically has an approval step or sign-off for a UI spec. This is often used to ensure that all issues have been resolved and everything has been documented to the team’s satisfaction. With wiki specs this step is unnecessary, since team members have been participating in writing the spec all along. This saves time and the formality of having a spec review. If the team does insist on a spec review, you can capture notes and issues in real time as the meeting is occurring and everyone can easily see the discussion progressing. As issues are resolved, the wiki can reflect the updates and decisions that were made after the meeting is adjourned. Team members can then modify entries and resolve any issues that remain outstanding.

Challenges and Solutions

Installing the Wiki

If you are lucky enough to have either the technical prowess to install the wiki software yourself, or have someone on your staff do the work, then you will have overcome the first hurdle in wiki specs. There are many free wiki software programs available online, so you might be able to skip this first step all together. However, if you are working on anything that is propriety or secure, I would not recommend hosting it on a third party site. You might be exposed to competition or legal issues, not to mention someone else will have your product specs.

Syntax

Another consideration is that wiki contributors must learn some syntax. This can be off-putting for non-technies, but the syntax is not difficult to learn and is similar to HTML. Many wiki software programs make it easy by providing a WYSWIG interface that allows for basic formatting while creating the syntax for you. This lets you focus on what you are writing rather than the syntax. Other ways around learning or creating complicated syntax is to pilfer code from another wiki template by simply copying and pasting it. If copy appears incorrectly, you can remove it or revert to a previous version. Wiki syntax also forces you to keep the document simple rather than spending time writing syntax for a spec.

Figure 2: This interface shows the code created by the WYSWIG editor.

Portability

Some people like the capability to read and write documentation wherever they are. With wikis you have to be online for either of these activities. Even though connectivity is increasing, most companies have firewalls or VPNs that can make access more difficult.

Simplicity

Some designers take pride in their documentation and deliverables. They spend a significant amount of time creating deliverables that are functional and beautiful. Wiki specs do not support this capability. They are essentially text editors that can be used to make documents more appealing by adding images, but they don’t really support the easy customization and flexibility that some designers would like to have. Images must be added one at a time and wikis don’t support many file formats. This may limit a person’s creativity in designing the document.

Printing

You may often see people printing traditional specs so that they can read them during their commute or at their desks. Wiki documents can be printed but they lack the basic characteristics that you would find in a traditional spec. Most of the issues involve pagination. Images get bumped to the next page unexpectedly or tables are displayed across multiple pages. This makes reading difficult, but it can be done. Although I do understand why some people like to print, I would argue that it’s not good for the environment and you should try to work on screen as much as possible. However, the functionality is there for those who prefer to print.

Trust

Trust is a major factor among team members. Some projects outright fail because of the lack of trust among individuals. Wiki specs can exacerbate a trust issue because team members have editing capabilities. If a lick of trust exists among your colleagues, you may see this manifested in the wiki via reverts and lots of edits or re-edits. This can be time-consuming and frustrating. If you have trust issues with your team or certain people need their roles clarified, you might want to consider an alternative method rather than a wiki spec.

Conclusion

Today’s economy and globalization are forcing companies to accelerate growth and increase revenue. In order to meet these demands companies are using new methodologies like agile, to bring products to market. As interaction designers we find ourselves working with these processes and playing an important role in the creation of new products. One of our major contributions is the UI spec, and the best way to document it for agile projects is through a wiki. It’s adaptive and allows for a collaborative experience.

References

¹“Agile Manifesto”:http://www.agilemanifesto.org

²“List of Wiki Software”:http://en.wikipedia.org/wiki/List_of_wiki_software

³“Wiki Engines”:http://www.iterating.com/productclasses/Wiki-Engines

⁴“Wiki Feature Comparison Table”:http://www.wikimatrix.org

UI Pattern Documentation Review

Patrick Stapleton — Mon, 29 Jun 2009 08:16:40 GMT

Introduction

User interface (UI) patterns have the potential to make software development more efficient. The prospect of such efficiency gains has led to interest in user interface (UI) patterns by individuals and organizations looking for ways to increase quality while at the same time reducing the costs associated with software development.

The very nature of UI patterns requires that they be familiar to end-users. An individual UI pattern is a discrete, repeatable unit of user experience. I refer to collection of patterns as a library.

In many cases, less proprietary patterns are more useful in solving a design problem as they can be implemented more uniformly across platforms. This characteristic and the efficiency gains make patterns an excellent opportunity for software companies to come together and promote UI patterns to the wider development community.

Producing a common pattern library, however, implies that the patterns presented are at the very least, consistently documented and most probably presented in the same single classification system. Currently though, patterns are classified and documented in various manners across publishers with no clear standard evident.

The problem

To date, the most common approach to propagating a single user experience standard is the development of UI guidelines and principles documentation within an organization. Development teams — usually incorporating a user experience specialist — then reference this documentation during implementation and upgrade processes.

However, as the numbers of systems grow within an organization, so does the effort needed to maintain the quality and consistency of the user experience. For many organizations, it is now impossible to assign much, if any, time of a user experience specialist to all implementation efforts, and experience has shown that the UI guidelines and principles approach to propagating a single user experience standard does not scale well.

There are two common issues, both major.

The first issue is ensuring developers are familiar with all the principles and guidelines.

Documentation to fully describe a UI standard is, by its nature, extremely detailed and complex. Getting developers to know all this information intimately is an ongoing and often un-winnable battle.

The second major issue is that the application of guidelines and principles can be open to wide interpretation.

Requiring developers to combine guidelines and apply principles together to create a complete UI can be inefficient. This synthesis process can result in widely-varying solutions to a single design problem across teams — especially when working with widely distributed and possibly culturally diverse groups. Removing these variances to create a more consistent user experience requires rework.

The solution

UI patterns to a great extent mitigate the problems of weight and interpretation experienced with the principles and guidelines documentation approach of the past. In essence, patterns can be seen as prepackaged solutions based on guidelines and principles.

Patterns and pattern libraries are more convenient for developers because they solve common higher-level design problems without the need for deep knowledge of often-complex guidelines and principles documentation. Also, they implement best practices, so developers don’t synthesize what are often “slightly original” solutions that would need to be reworked later.

Much of the value of a pattern to the developer is its less granular and more physical nature. Principles of good UI design dressed up as UI patterns add little value over traditional guidelines and principles documentation, as seen in many of the UI patterns as described in the Design of Sites; examples such as “Low Number of Files” — while an important design principle or guideline — do not deliver up a usable UI component.

Also important is creating the patterns to begin with. The guidelines and principles that form the foundation of patterns still need to be developed before any patterns themselves are developed.

Integrating UI patterns

Integrating UI patterns into the culture of software development is to a large extent still beginning. Next-generation development tools such as those proprietary ones being developed by enterprise software companies that implement patterns natively are now or will be soon in the hands of developers around the world.

Embedded drag and drop UI patterns hold the promise to empower developers to create better user interfaces, faster — unsupervised by user experience specialists. While this may strike fear in the hearts of many a user experience specialist, issues of scale dictate such a pragmatic approach. Be aware though, that they also can perpetuate problems if the UI patterns implemented are out of sync with end-user expectations.

Why standardize UI patterns?

Currently, there is no recognized standard for the classification or documentation of UI patterns, as seen by browsing through pattern libraries from:

Martin Welie’s UI patterns
Jennifer Tidwell’s UI Design Patterns
Sari Laakso User Interface Design Patterns
The Design of Sites: Patterns, Principles and Processes for Crafting a Customer-Centered Web Experience by van Duyne, Landay and Hong.
Yahoo Design Pattern Library

The variety isn’t surprising, since applying the pattern concept to user experience design is a relatively recent phenomenon. However, the successful introduction of a single classification and documentation standard could significantly increase the value of a UI pattern library to developers by…

Reducing confusion among pattern versions across collections. Not surprisingly, many of the same patterns exist across collections. A standard classification system (discussed below) can help developers make sense of both these patterns and their different versions in collections across the web and in paper publications.
Promoting development of net new UI patterns. A clear classification taxonomy is likely to make the “holes” in the current crop of pattern libraries more apparent, which in turn hopefully will increase the pace of development of new UI patterns.
Providing a standard UI pattern interface. As the number of patterns increases, pattern search tools will become more important. A standard classification and documentation approach will enable developers to quickly display their UI options.
Promoting UI pattern adoption. A clear classification taxonomy is likely to have the effect of making patterns easier to find and in turn increase their use.

Problems with the solution: UI pattern Classification Approaches

The following is a high-level analysis and discussion on classification approaches of the previously mentioned UI pattern collections. Each collection is mapped and discussed from a classification and documentation perspective.

Martin Welie’s patterns

Classification Analysis

Patterns in Interaction Design

Figure 1. Classification Map (click image to enlarge)

Welie divides the patterns into three delivery methods: Web design patterns, GUI design patterns, and mobile design patterns. Within the web design patterns channel (the focus of this document), the patterns are categorized into ten groups based on a mix of content and functional subjects.

Documentation Approach

Figure 2. Documentation Map (click image to enlarge)

Welie’s documentation approach is simple, with a focus on visual elements to explain the function of the pattern. It can be broken into three main parts:

Description: This area of the documentation provides the name and image to describe the pattern.
Rationale: This area provides a description of the problem that is solved by the pattern, how it works, and the scope of its use.
Associations: This area provides links to other patterns related to the current pattern.

Jennifer Tidwell’s patterns

The following is a map of Jennifer Tidwell’s UI Design Patterns. (Click image to enlarge.)

Unlike Welie, Tidwell does not take into account different delivery methods. The eight categories she does specify look to be based on functional subject areas only.

Sari Laakso’s patterns

The following is a map of Sari Laakso’s UI patterns. (Click image to enlarge.)

Like Tidwell, Laakso does not differentiate between delivery methods; he bases all seven of his categories on functional subject areas.

The Design of Sites’ patterns

The following is a map the patterns presented in “The Design of Sites.” (Click image to enlarge.)

The most extensive pattern collection of the four sampled, Design of Sites does not specify delivery methods, and, in some cases, the items presented could be regarded as design guidelines or principals rather than patterns. Twelve categories are presented with a mix of content and functional subjects.

Summarizing the classification types

From this analysis three main types of classification are present — content subject, functional subject, and delivery platform.

Content subject classifications normally specify an application genre (for example, ecommerce and supply chain management). Examples of content subject based classifications can be found in the Design of Sites collection under “Site Genres” and in Welie’s collection under “Site Types.”

Functional subject classifications are based on logical breakup of functionality (for example, shopping cart and two-panel selector). This is the most common prevalent classification type and is found in all the collections sampled.

Delivery method is used to describe the platform on which a pattern has been designed to operate. This classification type opens up the possibility for unique patterns to be developed for the same subject classifications across platforms. This classification type has the potential to provide more resolution for developers looking to offtake a pattern within a specific UI delivery platform such as mobile, desktop, or web.

Based on the publicly available pattern libraries available today, there is no clear indication as to whether “delivery method” is a valid classification type. An argument could be made that the process of binding a pattern to a specific technology is will reduce the life of the pattern as platforms develop. However, the timelessness of a pattern is of little consequence to developers whose primary goal is product delivery rather than pattern lifecycle.

Another Classification type – Level

This author would like to include an additional classification type: Level.

The level classification would further divide patterns into the following areas of concern:

Navigation architecture: Patterns relating to the navigation of content within an application
Screen architecture: Patterns which position functionality and content within a screen
Site furniture: Patterns for formatting functionality and content

In the case of the collections previously reviewed, the great majority of patterns would be classified as falling under the “site furniture” level type. However, it is this author’s view that considerable potential remains to develop patterns within the proposed navigation architecture and screen architecture level types.

A proposed classification system

The above diagram (click image to enlarge) describes a potential pattern library classification hierarchy. In this case, client classification nodes are presented at the top of the tree similar to that of the Welie collection; the proposed new level classification nodes are added above subject.

Content and functional subjects would be implemented as tags because these classifications would occur across levels.

Why have a classification hierarchy — aren’t filters or tags more useful?

In many cases, being able to filter by classification node as required is more flexible than drilling down through a preset hierarchy. However, a present classification tree is also useful to:

Automate the generation URLs to enable cross linkages within the UI pattern library.
Provide a simple drill experience for end users who have no specific problem to solve but rather just wish to browse to learn and or generate ideas.

UI pattern Documentation Proposal

The value of a standardized UI pattern documentation to developers is a single interface for search tools. Such tools hold the potential to streamline the off take of UI patterns by developers with specific problems to solve in a world with hundreds and potentially thousands of UI patterns to choose from.

UI patterns are by their nature visual. It must be noted that strong support for pictorial content would seem obvious and reduce the necessity for long verbal descriptions that add little value next to their visual equivalents.

UX Book Clubs

Steve Baty — Sat, 16 May 2009 09:00:22 GMT

In early Nov 2008, I started to talk to a few people about the idea of a book club in Sydney to discuss User Experience (UX) books. Russ Unger and Donna Spencer encouraged me to let other people hear about it, and when I did – through the Information Architecture Institute (IAI) Members discussion list, and then through the Interaciton Design Associaton (IxDA) – many people thought it was a good idea.

And then something surprising happened, people liked the idea so much that they started doing things to make it happen. Andrew Boyd registered the “uxbookclub.org”:http://uxbookclub.org/doku.php domain, set up the wiki, and starting the content rolling. Will Evans designed a logo, wrote a whole bunch of content, set up a decent structure, and let everyone use either, or both, if they wanted. Andrew’s been in on the wiki each day tidying and gardening, making sure it doesn’t get out of control.

First one volunteer, then another, and another put their hand up and offered to organize a UX Book Club in their local area. New York City joined Sydney, Canberra, and Washington D.C. By the end of that first week over 28 cities had a local UX Book Club under way, and nearly 400 people had signed up to take part.

The first meeting was held in Silicon Valley in mid-December, followed by meetings in New York and Los Angeles, Philadelphia, Chicago, Canberra, Sydney & Austin. Through the second half of February meetings were held in Atlanta, Minnesota, Melbourne, Tel Aviv, Brisbane, Toronto, London and Chicago.

The What and the Why

UX Book Club is a fairly simple idea: get a group of people together, choose a book, and agree on meeting details. Go away and read the book. On the date set, come together and discuss the book. Talk about how you might use what you’ve read in your work; how your experiences run counter to the book; an example of how the book is spot on. Have a bloody good argument about it, then go have a drink and talk about it some more.

At a UX Book Club you have an incentive to read some of those user experience books you’ve heard about but still lays on your bookshelf. You discuss the book with other UX practitioners, which will help you get more out of the book. And you meet fellow UXers working in the same town as you.

You also hear about a lot of books that other people have read, found interesting, but aren’t suitable for discussion by the group. That may be because they’re too long, or highly specialized, or too expensive for a large group of people. Hopefully, though, you’ll be exposed to a much broader range of books than you do on mailing lists or blog posts currently.

How It Works

The Sydney meeting – held on February 3rd – seems to have been fairly typical of the experiences across the board – with local variations in terms of weather, location, and numbers. But the stories seem to have a consistent theme: great discussion, lots of energy, and a good time had by all.

“It was fairly incredible how natural—how routine—it felt. I mean, here was a group of people, many of whom had never participated in any community event, and none of whom (to my knowledge) had ever engaged in an extrinsically focused book club. The book became the medium for discussion, though the topic remained entrenched in UX and design.”  - Jonathan S Knoll, UX Book Club NYC

UX Book Club Sydney held the February meeting at the offices of the “News Digital Media”:http://usit.com.au team in their “New York Lounge”. Their hospitality was greatly appreciated, and the space was perfect for the event.

The event was structured along the same lines as those used by New York City (thanks to Cindy Chastain) and applied successfully in Los Angeles. The meeting opened with a brief welcome and introduction, then a volunteer from the group gave a 5-minute overview of the book (in our case Bill Buxton’s Sketching User Experiences). We broke into two groups (10 and 13 people, respectively) and headed to opposite ends of the Lounge to discuss the book in detail. Cindy’s rationale for the smaller groups was that they give everyone a much better opportunity to contribute to the discussion – and this was borne out by the comments I received afterward.

After a good solid hour or so of group discussion we came back together, had a bit of a recap, thanked everyone for attending, and relocated to a nearby pub to carry on. The ‘official’ proceedings kicked off at 6pm and ended just after 8pm. The ‘after-hours’ discussions wound up around 10pm. Not bad for the first event.

The entire event was terribly uncomplicated, and I highly recommend the format. Better yet, the discussion highlighted areas of the book I hadn’t really considered important on first reading. This new information encourages me to go back and re-read those parts, armed with some real-world anecdotes to help make it more concrete.

“UX Book Club got me to finally pick up a book I had been meaning to read, and to have the chance to exercise my brain a bit. I found myself waxing philosophical with my fellow book clubbers about education and urban planning, as well as positive (and negative) user experiences we’ve had.”
- “Roz Duffy”:http://stellargirl.typepad.com/stellargirl/2009/02/my-current-muse-ux-book-club.html, UX Book Club Philadelphia

The events serve as both means and end. Reading the books being discussed is a good thing, in and of itself. You will get more out of the event having read the book, and the overall level discussion and engagement will be higher for everyone.

But reading the book isn’t required. The book acts as a starting point for a wider-ranging discussion around the topic. Each person brings not only their understanding of the book, but alsp the full breadth of their professional and educational experience to the discussion. So whilst reading the book provides everyone with a common frame of reference, the really interesting discussion arises from our differences.

“Most UX people I know are web interaction designers like me, but the book club drew developers, software UI designers, business strategists, visual designers, and various flavors of agency and in-house IAs and IxDs.”
- Sarah Mitchell, UX Book Club Los Angeles

In saying all that it’s also important to recognise that no two UX Book Clubs will be the same. The books will be different. Some groups will meet monthly; others every alternate month. Some will be small affairs with half a dozen folks and others will be big (30+); and some will be more book reviews than book discussion. And that’s OK. What’s important is that we learn something, meet some people, and enjoy ourselves in the process.

”...And that sort of set the tone for the rest of the event: high-energy, engaged conversation, a fertile middle ground between events where there is a single speaker with everyone else semi-passively engaged, and free-for-all cocktail hours, which are fun and great for networking, but lighter on substance.”
- “Anders Ramsay”:http://www.andersramsay.com/2009/01/17/taking-the-ux-book-club-to-the-edge/, UX Book Club NYC

Getting Involved In UX Book Club

There are two ways to get involved in UX Book Club. The first is to sign up to the group in your local area. A list of existing UX Book Clubs is available on the wiki at “uxbookclub.org”:http://uxbookclub.org. There are around 50 groups already listed – including some groups that are just forming. If you’re working in UX or would like to learn more about the field to help with whatever work you are doing, add your name so that you can be kept informed.

The second way to get involved is to start your own UX Book Club in your area. We’ve found that the best thing to do add your city or town to the wiki list, then post a message to the IxDA.org or IAI mailing lists (or both) letting other people know. We’ll send an announcement out via ”@uxbookclub”:http://twitter.com/uxbookclub on Twitter to help spread the word. If you have a local IAI, UPA, or IxDA chapter, tell them about it at your next meeting.

I’ll leave with you a quote from Whitney Hess (UX Book Club, NYC) that echoes the sentiments of so many UX Book Club attendees:

“These books really aren’t meant to be read alone — they’re references as well as jumping off points for exploration of the practice. It was great to hear what others thought of both the content and its context in the greater body of work, book-form and otherwise, that our community has produced.

I’m really looking forward to the next event.”

Control and Community: A Case Study of Enterprise Wiki Usage

Matthew C. Clarke — Mon, 04 May 2009 07:51:14 GMT

The Balance of Power

There are a wide variety of uses for Wikis and a level of interest in using them that’s matched by an extensive range of Wiki software. Wikis introduce to the Internet a collaborative model that not only allows, but explicitly encourages, broad and open participation. The idea that anyone can contribute reflects an assumption that both content quantity and quality will arise out of the ‘wisdom of the crowd.’

There are, however, negative effects of this extreme openness. One problem is the deliberate vandalism of Wiki pages. Another is that even those with no destructive intent may yet degrade the quality of a Wiki’s content through lack of knowledge or skill. Anyone can write nonsense as though it were fact. Anyone can accidentally delete useful information. Someone with half-baked knowledge of grammar may change all the “its” to “it’s.” Of course, someone more knowledgeable may notice the problem and fix it … but then again maybe they won’t.

Wikis can impose various forms of control to protect against these risks, including user registration, moderation, enforced stylistic rules, and imposing prescribed topic structures and page layouts. These types of control, however, are typically seen as contrary to the basic Wiki concept.

Consequently, one of the central tensions when managing a Wiki is between centralized control and anarchy. In the public arena, the balance of power tends towards anarchy, but in a corporate environment a more centralized approach is often required.

In this article I describe one application of the Wiki way to a common corporate process and extract some guidelines for the effective use of Wikis in that context. In particular, I am seeking insight from this case study into the “balance of power” tension.

The example on which these reflections are based is a project within the software company CorVu [1] to improve the technical knowledge base related to the products we sell. Like many companies, CorVu has extensive knowledge of its own products and a desire to make that knowledge available to customers. A major block to achieving that desire has been a lack of people with the time to either record the internal knowledge or to fashion the knowledge into a customer-ready format. We needed to spread the load so that a broad range of developers, tech writers, professional service consultants and others could all contribute what time and knowledge they had to a shared goal. Our hope was that a process built around several Wiki sites would facilitate this collaborative approach.

There’s no guarantee, of course, that lessons learned in that context will transfer to others. But without documented cases such as this one, any theorizing about the balance of power issue is just speculation.

Three contexts for a Wiki

To start with, it is important to clarify the key differences between three contexts in which Wikis are used: public, team and enterprise Wikis. [2].

Public Wikis

By a “public Wiki,” I mean one where any Internet user can read and contribute to the collaborative effort. It may be that editing content is restricted to a registered user group (as is the case with Wikipedia), but anyone can register. Consequently, the size of the contributing community is potentially huge, there is a high level of anonymity, and the contributors do not typically relate to each other outside the confines of the Wiki.

In this context, very little centralized control is evident. You typically find some explicit guidelines for contributors, either formulated by the founders/hosts, or as an evolving page edited by the contributors themselves. There is also an implicit understanding of etiquette and an implied social contract that comes with joining the “community.” But in the end, anyone can edit anything … and anyone else can un-edit it. This is the essence of anarchy: not that anything goes, but that what goes depends on peer acceptance. In an anarchy, it is not the case that there is no control; rather, the control is exerted by peers (around the edges) rather than by an authority (in the centre).

Requiring registration prior to participation does not alter the anarchistic nature of the process. Registration has numerous benefits, not least of which is that contributors can be recognized and gain respect for their contributions. Registration may also increase the sense of belonging because it reflects each contributor’s conscious choice to join the community. That sense of belonging is essential to any viable anarchy.[3]

Moderation, on the other hand, inevitably moves the balance of power towards the centre. Moderation invests some users with the power to limit the contributions of other users. While moderation is sometimes seen as necessary in order to combat vandalism and dissension, this imposition of authority denies the libertarian aspirations of most public Wikis.

Team Wikis

A “team Wiki” is one where the people who read and contribute all belong to the same team or work-group. Perhaps the R&D team uses the Wiki to record evolving product specifications; or the members of a local church collaboratively documents its history; or a class of students collates the results of a research project. Membership of the team predates and takes precedence over membership of the Wiki community. A person joins the team and as a by-product may be requested or required to use the Wiki. The number of people participating tends to be small and the contributors are likely to relate to each other outside the context of the Wiki.

In contrast to public Wikis, where self-selection guarantees that the vast majority of users are technically savvy and keen to be involved, the people contributing to a team Wiki may not be doing so voluntarily or with much enthusiasm. It may well be a required part of their work that they would prefer to avoid. The need to make the Wiki as easy as possible to use becomes even more important in this context. This includes clear navigation and an effective search function, but more than anything else it means a simple, familiar user interface for editing text. Many team Wikis fail simply because the potential contributors refuse to learn Wiki markup or to use a non-wysiwyg editor.

In this context, registration is essential, but moderation is not. The restrictions on who can contribute protect against vandalism and, because the collaborators have pre-existing relationships and a common commitment to a higher cause, the community operates with a trust model. In fact, apart from the restrictions on membership, a team Wiki is unlikely to impose much control at all over contributions. Standards, structures, and conflicts will be resolved using the organization’s normal processes outside the Wiki. The collaborators will discuss and vote, or demand and threaten, or just do what the boss says, without that process being explicitly controlled by mechanisms within the Wiki.

Enterprise Wikis [4]

When it comes to implementing Wikis across a large enterprise such as a global corporation, a new set of concerns affect the balance of power. Management wisdom is required to maximize participation while keeping business objectives clearly in sight.

In my experience, it is rare that a single Wiki site within an enterprise is open to contributions by any employee. Where this is the case, moderation is likely to be required because of the large numbers of contributors who have no direct accountability to each other. The concerns at the enterprise level relate to how numerous organizational Wikis within the enterprise can be integrated into the IT infrastructure and how the use of Wikis can most effectively support corporate goals.

Rather than allow the proliferation of diverse Wiki projects throughout the enterprise, IT management is more likely to select the Wiki software that everyone is to use and perhaps host all instances centrally. It may be that some IT managers are “control freaks,” but there are good reasons for standardizing on Wiki software:

Risk. If many work groups host their own Wiki using their own choice of software, there is a significant risk of knowledge loss. It is hard to guarantee that each work group will secure the Wiki adequately or ensure appropriate disaster recovery. What happens if the work group’s server dies? Will they have an adequate backup procedure? What happens if the work group’s IT expertise leaves the company? Will the knowledge of how to run the Wiki be passed on to the remaining team? What happens if the Wiki software no longer operates when the server’s operating system is upgraded? Centralized Wiki management can avoid such problems.
Support. Most Wiki software is easy to learn (at least to us!), but some are certainly easier to learn than others. In a context where many employees participate in multiple Wikis within the enterprise, training and user frustration can be reduced by using the same software for all the Wikis.
Cost. Centralized IT management can also reduce the total cost of ownership of Wiki projects. That may be counter-intuitive given that most Wiki software is free. But the costs of running a Wiki include the cost of the hardware that hosts the Wiki, the time it takes to manage the Wiki (installation, user admin and support, backup, etc.) and the time it takes to teach people how to use the system. Although these costs may be small for each work group, the total across the enterprise can be substantial, and can be reduced by standardization and centralization.

In this context, the balance of power swings inevitably towards centralized control. The challenge is how to do so without stifling the free and creative contributions that are essential to a Wiki’s success.

The CorVu case study

The company I work for, CorVu, started using Wikis within its R&D group back in 2000 using the original WikiWikiWeb software. The project described below was based on MoinMoin, but we have also used DoKuWiki and have since standardized on Confluence.

CorVu produces software that assists other enterprises to implement their strategy and to track their performance against that strategy over time. CorVu has a variety of channels for making its internal product knowledge available to its customers, but the product functionality grows at a faster rate than the Tech Writers can keep up with. Apart from the fundamental description of each feature, a complex assortment of configuration details need to be documented – performance optimization, best-practice implementation techniques, interactions with third-party software, etc. A lot of knowledge at that level resides with the Professional Services team rather than the Product Development team. Often, the people with the knowledge do not have the time nor the writing skills to record it, and the people with the responsibility to deliver documentation to the customers do not have the knowledge. There’s nothing uncommon about that problem!

Since the goal of capturing and disseminating quality technical documentation requires collaboration, I thought that a Wiki might help. So we set up two independent Wikis to capture knowledge from two different groups of employees, and a third so that customers could access a sanitized version of that knowledge.

I’m not putting my own case forward as the paradigm of success. In fact, although the project yielded a significant improvement in capturing internal knowledge, we have not yet achieved the final goal of effectively disseminating that knowledge to our customers.

Figure 1. Knowledge capture and dissemination using three Wikis

R&D Wiki

This Team Wiki is the home of internal coding standards, design documents, etc. Anyone on the product development team can contribute, while employees in other departments can only view.

Professional
Services Wiki

The Professional Services Wiki (actually called the ‘Internal Technical Knowledge Base’) is a Team Wiki for recording how the product is used in practice, for instance: internal discussion about bugs, compatibility with third-party software, implementation tips and techniques, performance optimization, etc.

Anyone in the organization can edit this Wiki, but the primary contributors are Professional Service staff (consultants and help desk). This Wiki has two intentions: to be the primary location for recording and accessing internal product knowledge, and to be the staging ground for knowledge that can later be released to customers.

We centrally imposed the top level of structure and navigation here, based on product modules. This makes it easier for contributors to know where new content should be added. Specific pages enable FAQs to be built over time. Where it is relevant, information from the R&D Wiki is incorporated into this Wiki.

We scrapped a commonly used set of email distribution lists in favor of a process whereby questions and answers are posted to this Wiki site. This means that problem solving previously lost in email trails is now captured and searchable.

Customer Wiki

The Customer Wiki has the same basic structure as the Professional Services Wiki. That is, nearly all of the pages in the Professional Services Wiki have a matching page in the Customer Wiki. The difference is that the content in the Customer Wiki is edited by professional technical writers.

Each page of the Professional Services Wiki includes a status block indicating who the primary author was, who has checked the accuracy of the technical content, and who has checked spelling, grammar and adherence to the corporate documentation style. Only when those steps have been completed can the page be copied over to the Customer Wiki. An important part of that process is to make judgments about what information should be kept internal and what the company wants to reveal to its customers.

The Documentation Department is the only group who can edit the Customer Wiki. Although customers can leave comments, they cannot modify the published content.

In this project, there was a clear business goal and a centrally-driven process to attain that goal. The Professional Services and Customer Wikis were seeded with pages that provided a structure for delivering accurate and accessible content to customers. While the ability to contribute was widespread, there were explicit “rules of engagement” around user registration, topic naming, page layout templates, content categorization, and navigation.

Although there was a degree of central control, we tried to balance that with encouragement for broad-based collaboration–otherwise, why use a Wiki? The distinction that guides this balance is between structure and content. Although the structure is imposed centrally, content is generated by a diverse range of people in a way that promotes openness, the recognition of contributors, editing of any content without fear of criticism, and shared responsibility for quality.

Since the quality of the documentation exposed to our customers is crucial, the process includes a QA step that is uncommon for Wikis. We did not want to constrain all contributors to adhere to strict grammar, spelling and style rules. Instead we left the knowledge capture stage free from those restrictions and used technical writers to edit the content before its dissemination to customers.

It may seem strange that we would use a Wiki to publish non-editable information, but this is a testament to the versatility of the software. Wikis provide a very fast means of building a web site, whether collaboration is the intention or not. In our case, we use one Wiki site to capture knowledge from one group of people and another Wiki site to disseminate the information to a different group of people. With regard to my categorization of Public, Team and Enterprise Wikis, the “Customer Wiki” is a hybrid: it is built by a specific team and hosted within an enterprise infrastructure in order to publish in the public arena. A more traditional approach to software documentation would have been to repackage the knowledge into some other HTML or PDF format for customer consumption. But the maintenance of that dichotomy would have been far more onerous than copying between two parallel Wikis.

Managing an Enterprise Wiki project

Embedding Wiki tools across an enterprise is an organizational change project and as such requires appropriate planning and project management, along both technical and cultural dimensions. I won’t go over those generic processes, nor repeat suggestions for Wiki adoption that are documented in places like WikiPatterns. But drawing from CorVu’s experience, I will highlight some advice for project managers in the enterprise Wiki context.

People

Seek patronage at the highest possible level. That is, find a person with as much power within the enterprise as possible who will sponsor the project. The sponsor may do no more than ‘give the nod’ to your work, but that invests you with the authority to draw on other people’s time. In CorVu’s case, the CEO himself was a key supporter.
Enthuse a champion. This needs to be a person who is well respected, who will lead by example, and in doing so enthuse others. The champion will need to be able to put a lot of time into the project and will often be the primary contributor to the Wiki, especially at the beginning. In our case, that turned out to be myself.
Identify the group of people who can be expected to generate the majority of the Wiki content. These are typically subject matter experts. Discuss with them the value of writing down what they know or Wiki-izing what they have already written.
Identify anyone whose participation is mandatory. Is there a key political player or subject matter expert who absence from the project will cause others to think, “Well, if she’s not involved, I’m certainly not going to waste my time?”
Since our goal was to create a knowledge base for external consumption, it was important that the content generated by subject matter experts was checked for both accuracy and readability in the same way as other customer documentation. Consequently, the people involved in the project needed to include professional technical writers.

Tools

There are many different Wiki software tools in the market (Wiki Matrix lists over 100) but most are not adequate for an enterprise rollout. CorVu’s experience suggests that an enterprise Wiki requires at least the following:

Administration tools to manage a large number of users, with integration to enterprise security mechanisms (e.g. LDAP and single sign-on).
Separately secured spaces for different knowledge areas.
Effective management of attachments that includes versioning and a built-in search function that indexes the attachments.
Integration with other enterprise software such as portals, business intelligence, and content management systems.
Many contributors in an enterprise context will be non-technical. This makes it essential that the Wiki has a familiar, WYSIWYG editing mode rather than forcing users to learn some Wiki markup language.
An assortment of non-functional requirements such as good reputation, reference sites, some assurance of product longevity, and the availability of support.

Generating participation

All Wikis stand or fall based on whether an active community is formed. You can’t achieve the ‘wisdom of the crowd’ unless you have an active crowd. The means of achieving that across an enterprise are somewhat different from public Wikis.

Build a critical mass of contributors. Since the contributors are employed by the enterprise, it is possible to make the Wiki part of people’s responsibilities. At CorVu we found this to be imperative. Unlike a public Wiki (where there are many people who contribute huge amounts of time as a hobby), in a work context (where everyone is probably too busy already), this isn’t going to happen. So write it into job descriptions. Get managers to send emails to their staff saying that one hour a week should be spent writing up their knowledge on the Wiki. Arrange a seminar on how to use the system. Use the company newsletter to promote the value of the project.
Build a critical mass of topics. To be used, the site must be useful. To generate traffic to the site, make the most frequently required information available on the Wiki first, and make the Wiki the only source for that information. In CorVu’s case, for example, one significant page stored the latest product release information. When any software version was moved from internal QA to Beta, or from Beta to General Release, this page was updated. Once people learn that the Wiki contains a lot of useful information they will look there for answers to start with rather than wasting someone else’s time by phoning or emailing questions.
Send links rather than information. Set an expectation that when anyone is asked for some detailed information, the response should be a link to a Wiki page. If the information has not yet been Wiki-ized, don’t type a lengthy answer in an email; instead, spend an extra minute typing it into a Wiki page.
Provide recognition and rewards. As with most Wikis, the best way to encourage participation in the long term is to ensure that the efforts of the contributors are valued. This is easier in team and enterprise Wikis than in public Wikis because the contributors are known. Wiki pages can indicate explicitly who the primary authors were. There can also be rewards within the enterprise beyond the boundaries of the Wiki. For instance, some employees may have components of their annual review linked to their involvement in Wikis.

The future of enterprise Wikis

Our experience with Wikis at CorVu has been very positive and gives encouraging signs about the future potential of this approach to shared document workspaces. There are multiple offerings that meet enterprise IT standards, and the tools currently available are robust, simple to administer, simple to use, and inexpensive. The CorVu case also shows that enterprise Wikis can be used not only for internal purposes, but also as a means of publishing information to external stakeholders.

By putting minimal central control in place an enterprise can gain significant benefit from this simple technology, including improved knowledge capture, reduced time to build complex knowledge-based web sites, and increased collaboration. Although enterprise Wiki use requires a greater degree of centralized control than public Wikis, this need not impinge on the freedom to contribute that is the hallmark of a Wiki approach. The balance of power is different in an enterprise context, but fear of anarchy should not prohibit Wiki adoption.

Nevertheless, I predict that Wikis will disappear over the next 5 to 10 years. This is not because they will fail but precisely because they will succeed. The best technologies disappear from view because they become so common-place that nobody notices them. Wiki-style functionality will become embedded within other software – within portals, web design tools, word processors, and content management systems. Our children may not learn the word “Wiki,” but they will be surprised when we tell them that there was a time when you couldn’t just edit a web page to build the content collaboratively.

[1] CorVu is now a subsidiary of Rocket Software, but this case study pre-dates that acquisition.

[2] There is another form of Wiki that I have ignored here – the personal Wiki – but in that case, questions about the balance of control do not arise.

[3] In an editorial comment, Christina Wodtke offered the insight that if identity is essentially disposable, then registration does very little. Perhaps it is only when the link between registration and identity is persistent that protecting one’s reputation becomes an important motivation towards good behavior.

[4] What I call an ‘Enterprise Wiki’ others have called a ‘Corporate Wiki’. I prefer the former because it is not restricted to corporations in the business world, but also applies to government agencies, churches, and large not-for-profit organizations.

Interaction 09 Follow-up

Whitney Hess — Mon, 04 May 2009 07:51:03 GMT

From February 5-8, 2009, IxDA hosted their second annual conference, Interaction 09, in Vancouver, BC. Last year’s inaugural conference in Savannah had a powerful and lasting impact on the community, filled with encouraging messages and the realization that for many of us that we had “found our tribe.” The challenge for 2009 was to see if that energy could be recaptured a year later—in a new place and during undeniably pressing times.

The Setting

The Four Seasons in Vancouver felt much less intimate than the refuge and privacy we shared in Savannah, and the impact of Simon Fraser University was invisible compared to that of Savannah College of Art and Design (SCAD). Still, one important aspect remained quite evident—this community of interaction designers truly adores one another.

Finding people with whom you share similar passions, challenges, and perspectives both comforts and uplifts the community. Even with the different feel this year, Interaction fulfilled a critical mission. Disenfranchised, overwrought interaction designers looking for a way forward found renewal that can last us the whole year. We encountered inspiration around every corner, ringing with the clear message that our time has come and our mandate as designers continues to grow.

Instead of practical advice on which interface elements to employ in particular situations or new techniques for prototyping, the overall emphasis at Interaction 09 was much more about the role that interaction designers need to play in their organizations and throughout the world. Even IxDA’s manifesto noted the aim to “improve the human condition”—a far loftier goal than simply making useful and engaging digital interfaces.

Day 1, February 6

After a day and a half of workshops, the Interaction 09 conference started on Friday afternoon with a lineup of impressive keynote speeches from John Thackara and Fiona Raby, along with a heated panel discussion moderated by Jared Spool.

Thackara, in his talk titled “Experiencing Sustainability” (description | video) demanded that interaction designers do our part to combat climate change, resource depletion, and economic crisis by shifting our focus and skills towards designing promising new solutions for repair and growth. As interaction designers, we have the ability to devise innovative systems to combat common, everyday problems, and Thackara urged us to consider our impact far beyond the computer screen.

Though A/V system problems mired her talk, Raby shared several projects from her design students at the Royal College of Art that challenge many constraints we artificially place on how people interact with technology, and more importantly how people interact with and relate to one another when facilitated (and controlled) by technology.

Spool kicked off his panel by noting that as of today, 10,000 new interaction designers are needed to support the growing challenges of even just the most major companies; he asked his panelists, both educators and managers of design teams, how they plan to meet the demand. Matthew Holloway of SAP, Josh Seiden of Liquidnet and outgoing president of IxDA, and Andrei Herasimchuk of Involution Studios discussed the perfect balance of skills, education, and experience that they seek from designers they bring into their teams. Liz Danzico, chair of the new MFA Interaction Design program at the School of Visual Arts, and Jon Kolko, who founded the interaction design minor at SCAD, discussed how to best prepare interaction designers to recognize and address everyday business obstacles, becoming all the more valuable to their organizations.

The panel was getting at some critical obstacles in growing the interaction design practice before it disappointingly devolved into a “define the damn thing” debate about the distinction between interaction design and user experience. Groans from the audience and fierce statements from the panelists revealed just how divisive and counterproductive this argument can be. Still, it was great to see the community alive with fervor, as many hallway and hotel room conversations on the topic followed.

Day 2, February 7

While everyone was still nursing their wounds, Saturday started off on a much more uplifting note. We had talked about the state of the world, laid out our differences, and recognized just how much we’re all desperately needed; now it was time to talk about how to get this stuff done.

In his keynote titled “Irrational Behavior” (description | video), Robert Fabricant showed us some concrete ways that his team at frog design is addressing pervasive public health issues in South Africa with Project Masiluleke. He shared inspiring examples of great interaction design and reminded us that “technology is not our medium; behavior is our medium.” Fabricant differentiated among the outputs, outcomes, and impacts of our designs, noting that just because people are buying a product doesn’t necessarily mean that their behavior is changing. Our goal, clearly, should be the latter.

Dan Saffer revved us up at the end of the day with an impassioned keynote (description | video). He called for an end to the “religious wars” and obsession with defining our practice and instead urged us to be flexible and determine what is best for each project. “There are no best practices,” he said. “Best practices should be a place to begin, not where it ends,” reminding us that our responsibility is to invent new systems. He echoed other speakers in focusing our attention on health care, education, government, energy, and other domains where our ability to recognize and solve ongoing problems is sorely needed. “Where are the interaction design rockstars?” Saffer asked, citing our need to be as visible as the Frank Gehrys and Philippe Starcks of the world.

Ultimately the message was that being poised to tackle these issues simply isn’t enough if we aren’t capable of selling ourselves. As revitalizing as it is for our community to come together and learn from one another, it’s more important that we get out of the echo chamber and make ourselves known to those outside of the practice who can put us in a position to create change.

Day 3, February 8

By day three, we were ready to step out of the shadows and no one better to show us the way than Marc Rettig, a very humble and discreet member of our community who exposed us to the ways in which he and his company are choosing to make a stand.

He reiterated many of the previous day’s themes in his keynote, “How to Change Complicated Stuff (e.g., the World),” declaring that the relationships we create through products are far more important than the products themselves. If our goal as interaction designers is to create positive change, then we can no longer just be satisfied with shipping the product or launching the site. “You must establish the change,” Rettig said, “and put in place the necessary conditions for it to be come the new Normal.” Ultimately, our success isn’t measured with metrics but instead by the personal stories that illustrate how lives have been improved by our design solutions.

Then in her closing keynote, Kim Goodwin noted that the sustainability and cultivation of our practice can be ensured by one very important activity: Mentorship. Goodwin noted that if everyone in the audience mentored just one or two people, our community would grow exponentially and we would all become better at our craft. Both the mentor and the mentee have much to learn from one another, and that passing of the torch symbolizes, and ensures, the longevity of our profession.

Indelible Marks

A single theme emerged throughout the three days of the conference: The time has come to expand the definition of what interaction design comprises. In an ever-changing, interconnected, and in many ways injured world, we need to apply our skill sets, techniques, methodologies, and critical problem-solving capabilities to much larger-scale systems far beyond the reaches of technology.

As Doug Lemoine of Cooper nicely stated in a blog post recap, “Like other disciplines, interaction design is wrestling with the ways in which we, as a profession and as individuals, can do more than simply design more disposable crap. How can we design stuff that lasts, stuff that helps, stuff that addresses real problems?”

Phillip Hunter was particularly intrigued by the greater number of touchpoints across which we can design. Reflecting on the conference two months later, he wrote, “It was really exciting to hear and see emerging design tools and interaction mediums. NUI & gestural interfaces, mobile, MS Surface, Axure, Catalyst (someday soon we hope), etc., along with continuing extensions of browser-type experiences with Silverlight and Flex.”

Our community is growing, and with new people come new approaches, perspectives, and methodologies. As Matthew Nish-Lapidus wrote on the nForm blog, “Our practice is still in relative infancy, but there is amazing momentum and a great sense of importance driving us forward.” The challenge now is to unify the practice and turn our attention to the profound problems that truly need our help.

Several other sessions deserve note for garnering much discussion. Leisa Reichelt’s “Design by Community—The Drupal.org redesign” examined how to use the community to grow the design, while Christina Wodtke’s “Designing the Viral App” examined how to use the design to grow the community.

Also of note were those talks providing insight into the full-body interactions required for touch screen interfaces—Nathan Moody’s “Designing Natural Interfaces” and Bjorn Hartman’s “Enlightened Trial and Error – Gaining Design Insight Through New Prototyping Tools.”

Looking Forward

One of the most interesting things about the IxDA conferences are the sheer number of sessions presented over the course of just a few days. While “Lightning Round” slots allow for a wider variety of topics, 25 minutes is much too short to get anything of value out of a session. By the time everyone arrived, got settled in their seats and pulled out their notebooks or laptops, almost half the session had passed. There were several sessions that left me wanting more, feeling as though I would have gotten greater depth out of reading a blog post or article on the topic. I hope in the future that the organizers schedule more in-depth 45-minute-to-one-hour sessions and reduce the number of these shorter sessions.

In the end, the best thing about Interaction 09 was the opportunity to spend three days with so many brilliant, passionate practitioners, educators, and thought-leaders from all around the world. It is an honor to be among them, and no matter where we are or how we gather, these events and the community’s support energize me to do more, try harder, think smarter, and reach farther. Here’s to next year back in Savannah!

Note: Videos have been indicated here where available. More videos will be posted by the IxDA on Vimeo. Feel free to check there for updates. -Ed.

IA Summit 09 - Day 3

Jeff Parks — Fri, 24 Apr 2009 08:10:40 GMT

IA Summit 2009 Podcasts

Main Conference Sessions, Day 3 – Sunday, March 22

These sessions were recorded on the first day of the conference. Download them individually here, or get them all with the Boxes and Arrows iTunes feed.

Links to the presentations and slidecasts will be updated continuously. See the Slideshare IA Summit 2009 page for up-to-the-minute lists of available presentations.

Thanks to the speakers for their hard work and for sharing their knowledge with the community.

Gaming the Design: Using Game Design Techniques in the Realm of Investing – Dominic La Cava and Kellie Rae Carter

Games have a central goal in their design: to keep people playing. Games use a variety of interactive and immersive techniques to create a play space, techniques that are useful to designers of more work-oriented or transaction-based interactions. These other interactive spaces, in fact, have the exact opposite goal: to reduce the time users spend on the task or interaction.

In this presentation, Dominic La Cava, Senior Information Architect at Vanguard, and Kellie Rae CarterUX researcher at Comcast Interactive Media, demonstrate how one design team incorporated game techniques into a redesign project.

Download

Leading with Insight – Matthew Milan

Insight is one of the most widely used and poorly understood concepts in the creative process. Insight is what drives the big idea, validates the crazy hunch, and frames both problem and solution in one fell swoop. Without the right perspective, knowledge, and grounding, generating insight can be unpredictable, wildly unreliable, and completely inconsistent in application.

Matthew Milan, Principal and Design Director with Normative, helps us understand how to generate, identify, frame and use insight effectively. This poorly understood practice is an increasingly a critical skill to have when working on solving complex problems. As an information architect, insight is one of the best tools you can use to unpack difficult challenges and turn them into effective solutions.

Download

Lessons from Slime Mold: How to Survive and Thrive in Ever-Changing Organizational Environments – Kate Rutter

How can we stay effective, be engaged and create great work in an environment that is ever changing and in constant flux?

Say hello to slime mold, an organism that has spent the last few million years evolving a powerful set of survival techniques that are wonderfully relevant for people grappling in shifting organizational environments.

Kate Rutter, Experience Designer at Adaptive Path, describes how this fascinating life form holds intriguing lessons for today’s knowledge worker—from sensing and responding to environments that become hostile to using the power of signals to create alignment and collective action. In this romp through the kingdom of myxomycetes, we learn a set of practical tips and tools for surviving, thriving and doing our best work in even the toughest of environments.

Download

The Art and Science of Seductive Interactions – Stephen Anderson

To be good information architects, we need to crack open some psych 101 textbooks, learn what motivates people, and then bake these ideas into our designs. We’ve spent the last decade perfecting how to create applications that serve our users needs. Now it’s time learn a bit about the art and science of seductive interactions.

Stephen P. Anderson has been gathering and analyzing specific examples of sites who’ve designed serendipity, arousal, rewards and other seductive elements into their applications.

By understanding basic psychological principles we can raise the bar on our projects!

Download

The Courage to Quit: Starting, Growing and Maintaining Your Own UX Business – Sarah Rice, Whitney Hess, Jenn Anderson, & Christopher Fahey

In this panel discussion, freelance IAs Sarah Rice, Whitney Hess, Jenn Anderson, and Christopher Fahey argue that Information Architects have an opportunity to structure and evolve their own work environment. There is potential to influence where they work, who they work with, the type of work they do, and for whom they do work.

This panel discusses what it is like to create ones own work environment – the motivation for taking this entrepreneurial path, what it has been like, what we’ve learned, and the ups and downs of such a work life.

Download

UX Health Check: A Measure A Day Keeps the Redesign Away – Livia Labate & Austin Govella

The UX Health Check allows IA/UX professionals and their collaborators to introduce metrics of success and benchmarks to their product and service design decision-making, from the most strategic to the most tactical aspects.

Measures of success that qualify and quantify user experience efforts are scarce and not widely adopted. Livia Labate, Principal of Information Architecture and User Experience for Comcast Interactive Media, and Austin Govella, author and Independent Consultant, demonstrate the UX Health Check. This approach introduces a common language for UX professionals to measure how investments in improving the user experience result in concrete outcomes.

Download

Professional IA/UX Organizations – How to Start and Run a Successful Local Group or Chapter – Kyle Soucy, Nasir Barday

The growth of the IA/UX industry has seen the birth of numerous organizations with local chapters and groups around the globe, but there is more work that needs to be done. Existing chapters and groups need support and guidance to ensure continued growth and there are still vast regions that are in need of their own chapters and groups.

During this session, Kyle Soucy, Founder of Usable Interface, and Nasir Barday, Senior User Experience Architect at FactSet Research Systems Inc, share how to keep the momentum of a group going strong, including:

* Good meeting ideas * How to find venues, sponsors, and speakers * How to promote your events * Pitfalls to avoid in running your group * How to deal with limited volunteer help

Download

An Internet Watered Down (or, How to Save the Mobile Web) – John Pettengill

Mobile sites are not an afterthought to be appended on the end of a development cycle. Smart phones have something that desktop computers do not. Context. We need to rebuild the mobile web from the ground up, capitalizing on the fact that we can know where our users are, and consequently we can know their intentions.

John Pettengill, Information Architect with Razorfish, believes mobile websites should address the needs of users who are “out and about”, and any site that doesn’t shouldn’t be considered part of the mobile web. The Starbucks iTunes Store is a great example of how we can change, and improve, the way we live. iPhone users are presented with a special application when they are at a Starbucks café, an app that displays songs played at the café and gives users a way to purchase them.

Download

Evangelizing Yourself: You can’t change the world if no one knows your name – Whitney Hess

We devote our careers to advocating for our users, but who’s advocating for us? No one is going to carry you through your career. If you want to make a major impact in this field, you’re going to have to work at getting recognized. Moreover, your name has to be synonymous with quality.

In this session, Whitney Hess, User Experience Design consultant, helps timid and unassertive practitioners come out of their shells and become leaders in the user experience community. Her advice is based on her own experience taking control of her career and developing an authentic and positive reputation.

Whitney talks about the value of starting a personal blog, actively using Twitter and LinkedIn to build and maintain a network, staying up-to-date with trends and standards, how to get the most out of conferences, and ultimately how to gain confidence in your skills and successes.

Download

Five Minute Madness – IA Summit Community

This open mic session traditionally closes the IA Summit. Any conference attendee can approach the microphone five minutes to make their mark on the IA Summit. As in years past, a variety of people take advantage of this open forum.

Download

These podcasts are sponsored by:

The “American Society of Information Science & Technology”:http://asist.org/: Since 1937, ASIS&T has been THE society for information professionals leading the search for new and better theories, techniques, and technologies to improve access to information.

The “IA Summit”:http://www.iasummit.org: the premier gathering place for information architects and other user experience professionals.

The theme of the event this year, Expanding Our Horizons, inspired peers and industry experts to come together to speak about a wide range of topics. This included information as wide ranging as practical techniques & tools to evolving practices to create better user experiences.

“Boxes & Arrows”:http://www.boxesandarrows.com: Since 2001, Boxes & Arrows has been a peer-written journal promoting contributors who want to provoke thinking, push limits, and teach a few things along the way.

Contribute as an editor or author, and get your ideas out there. “boxesandarrows.com/about/participate”:http://www.boxesandarrows.com/about/participate

IA Summit 09 - Day 2

Jeff Parks — Wed, 15 Apr 2009 07:10:19 GMT

IA Summit 2009 Podcasts

The IA Summit was held in Memphis, TN from March 20-22. Boxes and Arrows captured many of the main conference sessions (“see schedule”:http://iasummit.org/2009/program/schedule/).

| “Preview”:http://boxesandarrows.com/view/when-life-intervenes | “Keynote”:http://boxesandarrows.com/view/ia-summit-09-keynote | “Day 1”:http://www.boxesandarrows.com/view/ia-summit-09-day-1 | Day 2 | “Day 3”:http://www.boxesandarrows.com/view/ia-summit-09-day-3 | “Closing Plenary”:http://boxesandarrows.com/view/ia-summit-09-plenary |

iTunes Del.icio.us IA Summit theme music created and provided by BumperTunes™

Main Conference Sessions, Day 2 – Saturday, March 21

These sessions were recorded on the second day of the conference. Download them individually here, or get them all with the Boxes and Arrows “iTunes feed”:http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=275459507.

Links to the presentations and “slidecasts”:http://www.slideshare.net/faqs/slidecast will be updated continuously. See the Slideshare “IA Summit 2009”:http://www.slideshare.net/event/ia-summit-2009/slideshows page for up-to-the-minute lists of available presentations.

Thanks to the speakers for their hard work and for sharing their knowledge with the community.

Is Interaction Necessary? – Karl Fast

Do we have the conceptual tools necessary for designing with next-generation technologies? Multi-touch surfaces are going mainstream. New technologies for interacting with information are moving from the lab to our homes.

Karl Fast, professor in the Information Architecture & Knowledge Management program at Kent State University, argues that our conceptual tools for interaction design are more limited, and limiting, than we currently believe. The concept of “interaction” as currently understood is based on a host of assumptions, many of which run so deep that we no longer see them as assumptions.

Is interaction necessary? Of course it is. But for what?

Download

Personas and politics: The Discursive Construction of The “User” in IA – Adrienne Massanari

Adrienne Massanari, Instructor of New/Digital Media in the School of Communication at Loyola University – Chicago, assesses the problematic relationship between new media designers and “users” in texts written about user-centered design.

Adrienne examines current texts written about user-centered design, information architecture, and interaction design to understand the ways in which users are discursively “written into” the design process. She suggests that personas and their use is as much motivated by political realities within new media organizations as it is by the need to incorporate user needs within the design process.

Download

Discovering & Mining The Everyday – Richard Ziade & Tim Meaney

In our world today, machines are an indelible part of our everyday lives. We rely on powerful devices to help us find information, organize our lives and make decisions. What if all these machines that help us in our everyday lives actually “listened” to our actions? One of the most challenging aspects of the Semantic Web is introducing its concept and benefits to the everyday population. But do we really have to?

In this talk, Arc90 partners Richard Ziade and Timothy Meaney contrast the way we make discoveries today – by testing theories within controlled environments – to a world where correlations can be discovered by simply peering into and querying data gathered out of our everyday actions.

Download

Integrating Effective Prototyping into Your Design Process – Fred Beecher

Senior User Experience Consultant Fred Beecher shows his audience how to determine what, for your particular situation, is the most effective way to use prototyping to improve the user experience of your site or software.

He shares the factors that influence how effective various prototyping methodologies will be and how to choose wisely; what level of effort you will need to invest in prototyping in order to get useful feedback; and how to permanently integrate prototyping into your software development process in a way that is effective for your organization.

Download

UX Design & Deliverable Systems – Nathan Curtis

One thing is brutally clear: no teams – in fact, no two individuals – seem to produce deliverables like wireframes the same way. And that’s a shame. Too many designers seem guided by the flawed notion that not just design but documentation too must be ever unique. This leaves readers flustered, confused, and often dismissive. Even worse, not adopting a uniform approach may diminish a team’s influence and credibility, and, possibly, our discipline’s role in the industry.

This session, lead by Nathan Curtis of EightShapes, shares practical techniques that his organization has learned from, taught, and embedded in teams. Just as important, attendees learn to avoid failures Nathan and his team have experienced along the way.

Download

User Interface Issues with Metasearch – Dana Douglas

The user interfaces for search are evolving as new features and capabilities are developed.

One emerging capability that raises new design questions is that of federated search or “metasearch,” a search engine that applies the user’s keyword search terms across data bases or collections of content. Many government agencies, professional organizations, and private sector entities maintain multiple collections of related publications or bibliographic content.

Dana Douglas, User Experience Specialist at UserWorks, focuses on the current issues in metasearch interfaces and findings from usability tests, as well as related findings from past testing of other search interfaces.

Download

Usable, INFLUENTIAL Content: We Can Have It All – Colleen Jones

You wrote some web content. You followed the usability guidelines; it’s findable, scannable, relevant, and readable. But it’s dry. It’s cold. It doesn’t win your users over. They’re not buying, not converting, or not taking the action you’d like them to take. Turns out that what’s missing is a big something—influence. Usability qualifies us to be on the playing field. What gives us the winning edge is influence

Collen Jones from threebrick presents a practical guide to influencing through content. Her approach is neither marketing fluff nor manipulation. but critical to a company and its users achieving their respective goals. Colleen offers useful techniques and examples drawn from a decade of experience to help you turn usable content from blah to brilliant.

Download

Turning HiPPOs Into Allies: How to Connect with Powerful People in Your Organization – Samantha Starmer

Most of us have experienced the power of a HiPPO (Highest Paid Person’s Opinion) and how it can instantaneously derail a project, kill funding for user research and information architecture work, or approve some marketing feature that will cause a poor user experience.

Samantha Starmer, senior manager at REI.com, says that to find success in moving the practice of IA forward in both our individual companies and in the larger world of business, we must learn how to manage HiPPOs and turn them into allies. She offers her insights and several ideas about how to effectively connect with others including:

* Identifying the HiPPO * Listening more than you speak. Watching more than you present. * How to find the HiPPOs breeding ground (it usually isn’t in meetings) * Laying pipe, or the art of the pre-sell

Download

Selling IA – Heuristic Evaluation for the Pitch Process – Russ Unger

Russ Unger, Director of Experience Planning for Draftfcb, lectures on the basics of Heuristic Evaluation and how it can be utilized for your company’s pitch process.

An engaging facilitator, Russ uses the majority of his time in a hands-on group activity that has participants actively engaging in Heuristic Evaluation to create key slides for a sales pitch. Participants were provided with a document template that allowed them to generate leave-behind materials for potential clients.

This “guerilla-style” approach for Heuristic Evaluation will help IAs engage work partners from other disciplines within the organization and to work with them to rapidly in generating useful content for Sales and Account teams.

Download

Business-Centered Design – Christina Wodtke

We are all big fans of user-centered design, and all of us have tried our hand at CSS or database design. But somewhere along the way, the third leg of the tripod got lost: business.

It’s critical to know what your business model is. Without this information, you have no idea which actions of the user are valuable and which are not. And without knowing that, you are as likely to spend hours working on an aspect of the website that delivers no value as one that does. This is not usually a fatal mistake in a large corporation, but in a start-up it can literally kill the company.

In this talk, Christina Wodtke, founder of Boxes and Arrows and product developer at LinkedIn, walks through the most common business models, the desired user behavior that supports them, and how those business models affect the architecture of the website including features and functionality.

Download

Time to Spit on the Table: Being Functionally Appropriate Using Culturally Inappropriate Tactics – Dan Willis

A big man strides into the boardroom. The company’s CEO is introduced, but says nothing. After they all sit down, he loudly spits on the middle of the huge table. “You’ve just seen me do a disgusting thing,” he says. “And you’ll always remember what I just did.” It’s from a 1947 movie, “The Hucksters,” and it shows the power of being culturally inappropriate in order to be functionally appropriate.

Being inappropriate is a scary and powerful tool that user experience professionals should use more often, taking advantage of humor and non-traditional forms of communication. This session, presented Sapient consultant Dan Willis, explores ways of intentionally and skillfully exceeding historically respected boundaries, including:

* Creating culturally inappropriate presentations * Running culturally inappropriate meetings * Delivering culturally inappropriate documentation

Download

IA For the Rest of the World – Miles Rochford

One of the challenges facing designers today is how to engage with emerging markets and rapidly developing economies. Well over half of the global population lives and works in these countries, and technology is rapidly diffusing into their everyday lives.

Information architects have always played an essential role in providing access to information and services. Emerging markets have an enormous need for this access – but also a range of constraints that make it hard for designers to deliver effective IA.

Miles Rochford, Specialist in the Service and UI Design team with Nokia, helps information architects understand the opportunities presented by emerging markets and the role IA can play in development and growth. It will also discuss tools and techniques for creating globally relevant IA, alongside real-world examples of IA in emerging markets.

Download

These podcasts are sponsored by:

Contribute as an editor or author, and get your ideas out there. “boxesandarrows.com/about/participate”:http://www.boxesandarrows.com/about/participate

IA Summit 09 - Day 1

Jeff Parks — Thu, 09 Apr 2009 07:28:44 GMT

IA Summit 2009 Podcasts

The IA Summit was held in Memphis, TN from March 20-22. Boxes and Arrows captured many of the main conference sessions (“see schedule”:http://iasummit.org/2009/program/schedule/).

| “Preview”:http://boxesandarrows.com/view/when-life-intervenes | “Keynote”:http://boxesandarrows.com/view/ia-summit-09-keynote | Day 1 | “Day 2”:http://boxesandarrows.com/view/ia-summit-09-day-2 | “Day 3”:http://www.boxesandarrows.com/view/ia-summit-09-day-3 | “Closing Plenary”:http://boxesandarrows.com/view/ia-summit-09-plenary |

iTunes Del.icio.us IA Summit theme music created and provided by BumperTunes™

Main Conference Sessions, Day 1 – Friday, March 20

These sessions were recorded on the first day of the conference. Download them individually here, or get them all with the Boxes and Arrows “iTunes feed”:http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=275459507.

Thanks to the speakers for their hard work and for sharing their knowledge with the community.

You are (Mostly) Here: Digital Space and The Context Problem – Andrew Hinton

Lead Information Architect in Vanguard’s User Experience Group, Andrew Hinton provides engaging examples (including Mr. Spock, a speeding trolley, and a Dada urinal), illustrating how language powerfully affects context, and vice-versa.

Andrew connects this understanding with real-life IA design issues such as Twitter’s syntax or Facebook’s Beacon and challenges us to think more carefully about how we shape context in the digital dimension.

Download

Portable Research: Observing Users on the Go – Nate Bolt

As technology becomes increasingly portable, mobile, and ubiquitous, new challenges to traditional ethnographic user research arise. Bolt|Peters CEO Nate Bolt discusses these challenges and how to use new technologies pragmatically to document, broadcast, and involve stakeholders in mobile research process.

Additionally, Nate identifies the key considerations when designing a mobile ethnographic study, indicating how technological developments in the future might be used to improve upon current methods.

Download

Designing For, With, and Around Advertising – Karen McGrane

User experience designers often express a desire to play more of a strategic role in guiding business decisions. Yet UX designers don’t always seek to understand the advertising business model so they can maximize revenue. Instead, they often treat advertising as “clutter” — to be ignored at best and actively disliked at worst.

Senior partner at Bond Art & Science, and former VP and National Lead for User Experience at Avenue A/Razorfish, Karen McGrane teaches us ways to help advertising-supported sites be more successful. She presents case studies of several publishing sites from her body of work and explores the business decisions behind them.

Download

Creating Magic Kingdoms: User Experience Lessons from Disney’s Imagineers – Mike Atherton

Ever been in love? We can all recall user experiences we admire. But do we love them?

Emotional engagement is an enormously powerful driver in ensuring product success. One group of UX designers, Disney’s Imagineers, uses this approach to build experiences that people not only engage with, but truly love.

Mike Atherton aims to reconnect us to the passions that brought us to the IA Summit with his lighthearted and inspirational presentation. We love the work we do. Let’s make sure our users love it too.

Download

A Fundamental Disruption: Moving Information Architecture into the Hands of Individual Consumers – Peter Sweeney & Robert Barlow-Busch

A fundamental assumption in information architecture is that producers need to organize their content before consumers can access it effectively.

But what if content didn’t have to be organized in advance of its access, or even organized by producers at all? What if each consumer’s individual perspective could direct the organization of content, independent of the actions of other consumers?

Primal Fusion’s Peter Sweeney, Founder and CTO, and Robert Barlow-Busch, Director of Product Design, demonstrate existing technologies that are already moving the Web towards more consumer-directed forms of information architecture.

Download

ROI: Speaking the Language of Business – Eric Reiss

What is the business value of Information Architecture? Eric Reiss, co-founder of FatDUX, a user-experience design company headquartered in Copenhagen, reviews our current approaches, including limited use of the bean-counter acronyms, and explains why these arguments are usually not compelling for business executives.

With an uncertain economy and tight budgets, we need to convince them that what we do will help their business and why. Our responsibility, Eric argues, is to focus on giving our clients viable choices rather than “it depends.”

Download

The Semantic Web: What IAs Need to Know About Web 3.0 – Chiara Fox

Information architects have been singing the praises of metadata, thesauri, and controlled vocabularies for years. But there is a new game in town: the Semantic Web.

Chiara Fox, Senior Information Architect at Adaptive Path, answers the questions “What exactly is the Semantic Web?” and “Why should I care?” She provides greater context in how ontologies are similar and different from thesauri and taxonomies, provides examples of how this technology is being used in the marketplace, and looks at how these concepts can be incorporated into the information architecture work that we do today.

Download

Designing Rules: The Engine of User Experience – Dan Brown

Rules provide an underlying structure that governs the experience: what is displayed, when it’s displayed, and how it responds to user actions.

The depth of systems means that information architects no longer design structures with specific pieces of content in mind, but instead have to design structures around classifications, categories, and abstractions. Information architects must consider the rules that govern these objects and their appearance, display, and response to users.

Co-founder and principal at EightShapes, Dan Brown lays the groundwork for how we think and talk about this aspect of our work and provides a rationale for why thinking about rules is important. He distinguishes good rules from bad and offers a framework for designing and documenting them.

Download

A Real Nowhere Man: Managing Remote Teams Remotely – Joe Sokohl

Not only do we work with people across the hall, across town, and across the country, but we also work with people we never meet from countries we know about only through Wikipedia or the Travel Channel.

UX Lead for PracticeWorks, Joe Sokohl discusses principles to live by when managing teams remotely including: communication, flexibility, sensitivity, courage, and the best tool of all, empathy.

Download

Experience Themes: An Element of Story Applied to Design – Cindy Chastain

In the context of design, experience themes can be used as a conceptual framework that unifies the form, shape and quality of interactions. They expand our approach to user-centered design by reminding us to step back and consider the aesthetic and semantic experience of a product.

In this presentation, User Experience designer and screenwriter, Cindy Chastain looks at what makes experience themes unique and important, using examples from other crafts to illustrate her points. She also discusses how themes can be used in the design process and demonstrates her approach with a project she has recently completed.

Download

Design Games for IA – Donna Spencer

Would you like your design team to collaborate better? Are you looking to gather more valuable insights from your focus groups and interviews?

Freelance Information Architect and Interaction Designer, Donna Spencer, describes design games as a fun, technology-neutral way of gathering design insights for your projects. In this presentation she focuses on games and tips most applicable to IA projects, for all types of projects and people, including:

* Freelisting; * Design the Home page and Divide-the-Dollar; * Reverse-it and Idea cards

Download

Site Redesign: When Hell Freezes Over Use A Blowtorch – Melissa Matross

Head of the user experience discipline for Hotwire, an Expedia-owned discount travel website, Melissa Matross shares lessons from successes, failures, and pain at Hotwire to help guide those embarking on a large-scale UX project.

Based on her experience driving the first successful Site Redesign at Hotwire, Melissa discusses strategies and tactics to:

* Sell your large-scale UX project, gaining support and approval to augment UX and Engineering staff to resource the effort. * Make your project happen by distributing the work while showcasing UX leadership and maintaining momentum toward completion. * Demonstrate UX successes and build equity within the organization for future work.

Download

Motivating Teams: Inspiring People To Do Great Work – Dorelle Rabinowitz

How does a manager deal with an inherited team, rather than a team she hand-picked? Sometimes a manager has to motivate someone who applied for that manager’s job – and is extremely resentful. What about the differences between innies and outies?

Dorelle Rabinowitz, lead of the Design Systems Group at eBay, shares stories from both managers and individual contributors about how they either inspired their teams to do great things or how things fell apart.

Dorelle also talks about communication styles, team exercises like design sessions and reviews, sharing work, mentoring, and ways to foster a sense of community – all through real-life examples.

Download

IA Spy School – Joe Dyer

Fact: The greatest Information Architect in the world may never get his or her work implemented without the ability to influence decision makers.

Senior Information Architect at Travelocity, Joe Dyer runs the IA Spy School, outlining simple techniques and methods for working IAs to gather, share, and exploit data to gain influence over decision makers, including areas of:

* Intelligence Gathering * The Power of sharing intelligence and building a repository * Five methods used to gain influence with any decision maker * Ethical considerations when collecting and sharing intelligence.

Download

Evolve or Die: the Future of IA examined – Christina Wodtke, Gene Smith, Russ Unger, Joshua Porter

For Information Architecture to stay relevant in this world of highly dynamic social websites, it must adopt new bodies of learning and new strategies.

This panel, consisting of Christina Wodtke, Gene Smith, Russ Unger, and Joshua Porter use scenario planning to look at four futures of IA exploring ways IA can evolve, including one dystopia in which IA does not. Four senior practitioners will outline each scenario, then invite dialog from the audience.

Download

The Adoption of Web Standards into Web Design and Development: A Report on a Large Survey – David Robbins

David Robins, Assistant Professor in the Interdisciplinary Program in Information Architecture and Knowledge Management at Kent State University, shares preliminary results from a survey developed in partnership with colleague Sanda Katila to explore how web designers and developers are adopting web standards into their work processes.. The survey was administered to 128 people from 12 countries.

The preliminary results cover: # The level of commitment to web standards by designers, developers and organizations. # What forces drive the adoption of web standards. # The extent to which web standards have influenced work processes.

Download

Using Enterprise IA to Support Business Strategy: Driving Revenue and Brand Health with Better Information Management – – Samantha Starmer & Gary Carlson

Samantha Starmer, Senior manager at REI.com, and Gary Carlson, a senior consultant, share a case study where they identified a business case and ROI for an enterprise information architecture project that led to significant money and resource commitments.

Samantha and Gary explain how they were able to evangelize horizontally and vertically, present their case to executives, and bring a true business perspective to the project. In the end, these approaches enabled wide cross-divisional support.

Download

These podcasts are sponsored by:

Contribute as an editor or author, and get your ideas out there. “boxesandarrows.com/about/participate”:http://www.boxesandarrows.com/about/participate

IA Summit 09 - Keynote

Jeff Parks — Sun, 05 Apr 2009 23:07:48 GMT

iTunes Download Del.icio.us IA Summit theme music created and provided by BumperTunes™

IA Summit 2009 Podcasts

The IA Summit was held in Memphis, TN from March 20-22. Boxes and Arrows captured many of the main conference sessions (“see schedule”:http://iasummit.org/2009/program/schedule/).

| “Preview”:http://boxesandarrows.com/view/when-life-intervenes | Keynote | “Day 1”:http://boxesandarrows.com/view/ia-summit-09-day-1 | “Day 2”:http://boxesandarrows.com/view/ia-summit-09-day-2 | “Day 3”:http://www.boxesandarrows.com/view/ia-summit-09-day-3 | “Closing Plenary”:http://boxesandarrows.com/view/ia-summit-09-plenary |

The IA Summit Opening Keynote

Michael Wesch opened the IA Summit this year with an inspired keynote that provides a fresh and ambitious direction for all designers.

He points out that our “audiences” aren’t audiences at all, but rather creators, and our job is not to lecture but to enable. With this new approach comes not only design challenges but the joy of reconnecting people to each other, which he illustrated with a series of extraordinary video clips.

The following is an outline of some of his key points; please download the audio for the complete experience.

Contrast Reveals Mediation

Wesch tells several stories about his study of cultural anthropology and how those illustrate how Western culture, and in particular US culture, has become completely mediated.

Inspiration Trumps

He then illustrates the process of how his video “The Machine Is Us/ing Us”:http://www.youtube.com/watch?v=NLlGopyXT_g&eurl=http%3A%2F%2Fboxesandarrows.com%2Fview%2Fia-summit-09-keynote&feature=player_embedded becomes an internet phenomenon and how its rise represents an alternative to the mass media machine that has developed in the US over the last several decades.

Varieties of Media Bias

Content bias (e.g. liberal or conservative bent) is only one of many types of media bias, and that all of them add up to “metaphysical bias.” The effects of this have not changed much over time, that comments made about the printing press can help us reflect on what is happening in the current environment. Wesch wants us, as the creators of the tools, to think about what environment we want to create and work towards it.

Checking Out

Using his classroom as a crucible, Wesch delves into how US culture arrived in its current state, using the assembly line as the starting place, moving through MTV, and onto American Idol. As a part of this journey, he traces the history of “whatever” and comments on the current cultural impotence.

Burgeoning Transformation

Wesch then assembles a multi-faceted picture that there is hope for our culture through the interaction of digital artifacts. He spends a significant portion of the talk showing various example of these conversations. YouTube acts as a meme-spreader and remix environment, and Twitter allows you to see yourself clearly.

4chan, the disputably infamous “imageboard,” morphs into Anonymous and plays tricks on over 9000 celebrities and groups that take themselves too seriously. Wesch makes the point that we’re in the midst of a “context collapse,” examines what that means, and shows what people are trying to do with the tools that are currently available.

Architectures of Participation

In the end, “Architectures of Participation are becoming the architecture of our daily life.” Designers will be shaping the tools that shape the culture and hopes that our community of practice can help humanity “do whatever it takes by whatever means necessary.”

These podcasts are sponsored by:

Contribute as an editor or author, and get your ideas out there. “boxesandarrows.com/about/participate”:http://www.boxesandarrows.com/about/participate

Boxes and Arrows

Experience Themes

So, What’s the Problem Anyway?

From Theme to Story

Go team, go!

Designing with Themes in Mind

Final thoughts

Integrating Prototyping Into Your Design Process

The dimensions of fidelity

Appropriate Fidelity

Low Visual and Low Functional Fidelity

Low Visual and High Functional Fidelity

High Visual and Low Functional Fidelity

High Visual and High Functional Fidelity

Integrating Prototyping Into Your Design Process

Corporate, Agile, Mature UX Practice

Corporate, Waterfall, New UX Practice

Consulting/Agency

A Wiser Interaction

IDEA 2009: An Interview with Thomas Malaby

The Content Conundrum

Recognizing The Problem — The Content Gap

Exploring the Causes

Flawed Processes

Content The Design(er) is King

Design artifacts rarely include “real” content

Lack of value assigned to content

What Designers Can Do to Address these Problems

1. Rethink the need for specific content

2. Explore Information Graphics & Visualizations

3. Write (some) content

4. (Really) Collaborate with your content partners

5. Package real content with the visual mock-ups

Conclusion

IDEA 2009: An Interview with Leisa Reichelt

Using Wikis to Document UI Specifications

Introduction

Description of the Problem

Wiki Overview

Benefits

Collaboration

Speed

Flexibility

Reversible

Archives

Centralized Image Updates

Informal Approval Process

Challenges and Solutions

Installing the Wiki

Syntax

Portability

Simplicity

Printing

Trust

Conclusion

References

UI Pattern Documentation Review

Introduction

The problem

The solution

Integrating UI patterns

Why standardize UI patterns?

Problems with the solution: UI pattern Classification Approaches

Martin Welie’s patterns

Classification Analysis

Documentation Approach

Jennifer Tidwell’s patterns

Sari Laakso’s patterns

The Design of Sites’ patterns

Summarizing the classification types

Another Classification type – Level

A proposed classification system

Why have a classification hierarchy — aren’t filters or tags more useful?

UI pattern Documentation Proposal

UX Book Clubs

The What and the Why

How It Works

Getting Involved In UX Book Club

Control and Community: A Case Study of Enterprise Wiki Usage

The Balance of Power