UXD - User eXperience Design

Use a Task Flow to Show “How do I ___?”

Although task flow diagrams (sometimes referred to as interaction flows, process flows or work flows) are a standard in most IA’s toolkits, it can be confusing for those unfamiliar with this particular tool to know when to start diagramming. When in the process is it started? How much information is needed before diagramming? How much detail should be added? When is it considered complete? 

The short answer is to start diagramming once the task is identified because it’ll help in flushing out the requirements. The diagram starts to identify what the user and the system need to do. It delineates a repeatable pattern of activity. It answers the question: “How do I _____________”.

After you have an identified task (I like to use Use Case Diagrams to call out the high-level tasks), the start point and end point need to be established. For example, let’s say your business requirements state that the web application is only accessible by authenticated users; therefore, a user needs to successfully login in order to see the home page. The initial diagram has the user starting on the login page, submitting their information and viewing the home page after the system logs them in.

But wait … I did say *successfully* login, didn’t I. O.k., so we add a decision point to the diagram to show that only successful logins allow a user to access the web application. Don’t worry just yet what the details are for the system to successfully authenticate a user. The purpose of the diagram is to identify the process, not to define it. For now, all that's needed is to show that the login information must be vetted before the system allows access.

Granted, the previous examples are simplistic, but simple is where task flow diagrams start. This basic statement “How do I ____________” turns into an initial task flow, delineating the steps needed to complete the task from start to finish based on the information known at that time. The first iteration is generally the ‘happy path’ and identifies the main flow of a task.  As more steps are uncovered through requirements, the flow is updated and modified to accommodate the new information and show the various decision points and/or alternative paths as they become known. The end result is a flow diagram that conveys both the overall structure of the main user tasks and the sequencing of activities to be programmed into a repeatable activity.

Use Case Diagrams

Projects start off at the 60,000 foot level -- the client wants a widget that allows their users to do X, Y & Z -- and need to be brought down to a level of detail where coding can begin. Something I use to start this process is a version of the UML Use Case Diagram.

For those of you not familiar with it, a Use Case Diagram describes the needed functionality in a system. Unlike flow diagrams, however, the use case diagram doesn’t represent the order or number of times the functionality needs to be executed and it doesn’t display any subroutines. Instead, it’s a high level diagram that identifies the primary tasks an actor/persona needs to be able to do.

The beauty of this diagram is that you’ve now captured the overall view of what the system needs to be able to do in order to allow the user to complete all their tasks. With the high level activities clearly identified, the diagram easily lets you communicate with your client and get their sign off that the needed functionality has been accurately captured. From here, the team can move onto further defining what’s needed to support this functionality: data modeling, user stories, task flows, etc.

The Curse of Knowledge

You can never know too much about something, right?  Wrong, at least according to a December 30th article in the New York Times.  As we become experts in a particular domain, our ability to innovate diminishes.
"Andrew S. Grove, the co-founder of Intel, put it well in 2005 when he told an interviewer from Fortune, “When everybody knows that something is so, it means that nobody knows nothin’.” In other words, it becomes nearly impossible to look beyond what you know and think outside the box you’ve built around yourself."

Reading the article, I couldn't help but think back to my own experiences with this same sort of issue.  I blogged recently about two related ideas: how interface designers are sometimes guilty of thinking as designers--when they should be thinking as users, and about the mixed bag that is competitive research, which can limit the designers creative thinking by boxing them into predefined solutions.   

Now I see that it's part of a larger problem of expertise and creativity.  The more expertise one exhibits in a particular field, the harder it is to think creatively--to so called think 'outside the box', and the harder it is to imagine not knowing what you do.  The problem affects whole companies, as a certain way of thinking becomes entrenched, and it gets harder for it to adapt to a changing landscape.  The article cites the example of Eveready, the flashlight maker, who's powers-that-be couldn't imagine that their product could be effectively marketed to anyone other than men shopping at hardware stores.

According to Cynthia Barton Rabe, author of “Innovation Killer: How What We Know Limits What We Can Imagine — and What Smart Companies Are Doing About It,” the solution for Eveready, as for any organization bogged down in its own expertise, is an infusion of outside thinking.  Bringing the so called novices--the non expert users--into the discussion at the early stages of design, weather it be product or strategy design, opens the door for new ways of thinking that experts have long been insulated from.


    
     

Powered by ScribeFire.

DUX2007 - Ubiquitous Computing

Adam Greenfield of NYU’s Interactive Telecommunications Program gave a great keynote presentation at DUX07 on ubiquitous computing -- embedded devices that are wirelessly networked, imperceptible, mobile and post-gui. Devices that are not perceived as computers by the people who use them, but rather as a facet of their lives. An example he cited is the Nike+ product for runners, which pairs with an iPod to give you feedback on how you’re running while you’re running and records info such as distance, time, etc. You can then sync your workout data to either iTunes or the Nike site, where you can then become part of the Nike+ community. It is a computer, but to most people it's just a piece of plastic you put on your shoe.

Ubiquitous computing. Existing or being everyware. Perceived as a facet of the user’s life. Eroding the distinction between product and service

Consider the automobile. When the first Model-Ts rolled off the assembly line, the car was a product. You drove it here and there and that was basically it. With the addition of On-Star, the car’s autonomy eroded as it was now networked with a diagnostic tool, roadside service, emergency contact, etc. The perception of a car as only a product began to erode as well; the car began to evolve to a platform. Fast forward a decade or so and we now have car as a service -- the Zip car. Glimpsing into MIT’s Smart Cities project, we begin to see the car as an interface to the city and not the engine.

As designers, then, our challenge is to design for these product/service ecologies.

Back to the Nike+:  although the device is basically a pedometer it only works for runners, not walkers. In addition, participation in the Nike+ community requires Flash because that's what the Nike site uses. This is a closed ecology and by their very nature, closed ecologies are brittle. Greenfield, therefore, advocates designing these products/services to use open frameworks because of their openness, their ability to be flexible and extensible. The downside of an open framework is a loss of control and for companies heavily vested in controlling their brand, this option may not even be considered. His argument, however, is that open frameworks aid in a product’s long-term viability.

Some final thoughts from Greenfield:

• As designers, we can no longer assume that the product we design will be a standalone product.
• Everything that can be networked, will be.

A final thought from me: it's an exciting time to be designing.

Technorati Tags: Design, User Experience, Usability, DUX07

Design Doesn't Just Mean Color

In discussing our SDLC process with some colleagues, I pushed for having a separate phase between Discovery and Development; a phase where we can take the knowledge gained from Discovery and begin sketching out high-level solutions in order to get a handle on the scope before going into iteration planning. In other words, a Design Phase.

I quickly discovered that some people hear the word ‘design’ and automatically associate it with the look and feel of the GUI, regardless of what else is being said. Until I understood that, their argument that there was no need to call out an entire phase for design made absolutely no sense. To me, using design in this context means to figure out how to do something at all levels, i.e., taking the requirements (Discovery Phase) into high-level schematics (Design Phase) to better understand their relationships, dependencies and impact in the end-to-end process. Obviously, I hadn’t explained that well.

Much conversation ensued, including the standard weeping and wailing and clutching of the pearls when passionate people get together. Amazing how we were all speaking English and yet totally missing what was being said. Until someone (the former English major, of course) effectively put us back on track by saying “Ok, but what do you mean by ....”

Ah-ha! Define the terms. With a BA, IA, and Tech Arch conversing, we found we were using the same terms to mean different things and different terms to mean the same thing. Well once we started speaking the same language, we agreed there is merit in having a separate phase specifically for design and revised the diagram accordingly. As a team, we were then able to define what that means to our process. 

I could say that as a team we designed our SDLC process, but I’m not even going to go there.

Technorati Tags: SDLC, Application Design, Design Phase

What is UxD?

A couple of weeks ago a sales presentation was being prepared in our New York office; it was primarily focussed on the problem at hand, but the presenter wanted to include a single slide as a cue to talk about  User Experience Design [UxD]. He emailed me and a couple of the principles asking for a description in a single frame.

I wrote something, designed two slides because I could not shoehorn it into one, various documents were thrown into the air, then we were all consumed by other work as the train moved on.

Now I am rethinking it. UxD is a fairly complex set of activities to describe, and there is no shortage of areas claimed by related disciplines. All of them are occurring in an area of rapid market development that happens to be highly valued by the societies we are in. Which is a recipe to attract passionate debate driven by financial rewards.

So is there a good way to describe it, or state it's value to a potential client in a single powerpoint slide? Assuming that no fly-ins, starbursts or windowshade rolls may be used in place of meaning, we will start with those old standbys - words:
________________________________________

Concise version:
User Experience Designers create structures for understanding and manipulating information, designing consistent contexts which encourage cumulative learning. In doing so they raise the bar from "being able to do something" to "being able to do something easily".

Their solutions go beyond code to model the most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________

Verbose version:
User Experience Designers are typically employed on applications or sites with large amounts of features, complexity or information.

They create structures for understanding and manipulating information or parameters, designing consistent contexts which encourage cumulative learning.

They raise the bar from "being able to do something" to "being able to do something easily". As a starting point they conduct research to find:
_Who are the users?
_What are their goals?
_In what context will they use the product?

Then they use any modeling technique available to propose solutions that go beyond code to model the most most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________

And this is just a starting point for discussion, and the slide itself is TBD. The concise version is hardly meant to be all encompassing, but it focuses on Pathfinders particular business goals. These are concentrated in application work, either in or out of a browser, and our communications tend to be directed toward fairly tech savvy folks. Interested in your comments.

Charles

Color for Developers, part 3

Through a glass badly

"This is not a pipe."  R. Magritte

You are reading this on screen. It is not what I expected.

One of the biggest problems for any on-screen designer is the weird backlit medium we fish swim in. This is true if you are creating interfaces for browsers or desktop applications.

By now you are asking why, why does he continue to torture us with these vague allusions and puzzling suppositions. Well it is just my sick idea of fun, really, but here is a simple test. Make a pdf of your favorite picture of a human. Put it on a flash drive and walk around to a few of your colleagues computers and compare the different displays. Extra points can be scored in two ways:

1] try a PC and any other platform, Mac, SGI, Treo

2] try laptop, lcd and CRT screens. If you can still find a CRT screen, they are fading into the dust of time or the junkyards of third world countries as we speak.

Of course you will find that the image of Britney Spears moments after the haircut discloses an array of skull colors limited only by the number of screens it is displayed on.

Individual hairs may or may not resolve, and the level of contrast will have a happy variety as well. This is where you work. Every one of your users sees this differently.

So great, isn't that a big mess, can we please just ignore it? Well no, that isn't really playing well with others. What we need is a basic strategy for accommodating this tragic reality.

There are commercial solutions to calibration available, or most Adobe programs ship with basic calibration tools. These will help... but only you. There is no way of knowing if your users ever did this, and we know that asking is not a scalable strategy.

Unless you are in a highly controlled situation, in an industry where there is a financial benefit directly tied to color fidelity, you can bet that no one really cares.

So what is the solution?

1] Design it a bit crude. Don't expect someone's screen to display a reliable difference between zero, 10 and 20 percent black, that is too subtle. Try 0, 15 and 30

2] Test it. Test it some more. Don't beat it to death, but it can definitely be too subtle.

There we go. In a few short blogs the secrets of your universe revealed. You have grasped the remote from my hand, grasshopper, do not watch Jerry Springer with the powerful tools you have been given.

Color for Developers, part 2

Color in context Many moons have swung by since our last talk, grasshopper, and by now you have had those tattoos revised and replaced more times than Angelina Jolie. I can only hope you have been as politically corrupt and personally shocking, really, she is a role model to so many.

Today we will talk about color and perception, then later we will do the sacrifice part... Right, let's start with Kasimir Malevich, who had strong opinions about color or the lack thereof and put his money, [or the people's money] where his brush was. Painted such fashion nuggets as "White on white" and "Black square". If you imagine what they look like in your mind, you will be darn close.

So what was on his mind? Why bother? There are a couple of reasons:

1] Cultural He was a Supremacist in Russia in the early part of the last century and thought that painting couches and side-tables was hopelessly bourgeois.

2] Psychological He wanted to defeat his own preconceptions and create something new; a kind of meta painting that was both free of objects and depicting pure emotion.

Well can color or it's absence do that? What strange and magical powers does it have? Vassily Kandinsky, one of Kasimirs drinking buddies, associated some very specific things with color - he claimed that certain colors elicited thoughts/memories/feelings of particular sounds and feelings and made them into a handy grid.

Most people make some basic and reliable associations with colors; black associates with night, death and designers clothing. Red means fire engines and radio flyer wagons. These are cultural associations, that effect how we perceive and interpret our world. A blue light on your dashboard is understood as a fairly passive status light. A yellow light, blinking rapidly, means the engine is probably about to seize.

When we use these colors in an interface, all of those associations are carried along with it. A complicating factor is the cultural context it is being read in. Many cultures have very different tolerances and preferences for color that western europeans; any short description of these differences will be reductive, but think of these references: Jamaican villages houses, Bollywood movies, Japanese packaging... Would those local tastes effect the design of an interface for those groups? I look forward to your comments. Leave a donation for the gods by the planter.

Que Multimedia, Part 3, Beyond Typography

As you might expect, I have a suggestion or two. Firstly, I would confirm my standing as a heretic by questioning the hegemony of typography. Put five designers in front of lattes and the one thing they will all agree on with mumbled nods is the importance of Typography. Of course I would too, but this reflexive assent masks a larger problem in how design is practiced and taught. The design profession has been so deeply fractured in the last 15 years typography has remained one of the few common links between this new multiplicity of practitioners. Well, for better or worse, the aesthetics of desktop and browser based applications use type in extremely limited ways that are an intersection between common system installed fonts and informative hierarchies. And common system fonts, consider Arial, Impact and Papyrus for a moment, leave much to be desired. However this is the palette of many desktop and browser based applications. Often the more complex issues in these engagements are how to assemble, change and order vast amounts of information. Designers bring a vastly different focus to these activities than most developers. The developer concentrates on a micro level of specific code interactions to construct a working system while a user experience designer connects the user to a much more general picture. Factors that might be involved include business problems, a users cognitive interest/abilities and the the capabilities of the developers systems. There are user research activity models, interface and task modeling considerations that have little to do with what anyone would describe as sophisticated print typography. Yet notions of hierarchy and the effect of symbols and composition are elemental to forming easily navigated tasks. So mere type skills will not be adequate; understanding interaction from a standpoint of task and capability is the core activity. This means that the designer must have a comprehension of the basics of digital design history as well as what is current, and this is equally as trend driven as any part of print culture, in development terms. I see this as the formation of the question, not an answer. What we do know is that the answer is a moving target, obfuscated by the claims of those who market digital culture. But the challenge to answer it is as real as any aspirations we have as providers of both sensible and innovative solutions.

Que Multimedia: Part 2, A Dilemma:

I share the responsibilities of hiring decisions for a small consultancy and being a design educator. Hiring new staff gives me one perspective on the state of education, and designing and delivering classes another. Our consultancy delivers user experience design for applications; the participation of any kind of designer in these tasks is a relatively new thing, and is too often seen with some suspicion by both developers and financial officers in the organizations we consult with. The ability to convey the passion that is required for the work is an asset, and one beyond any discussion of teaching methodologies. That said, I see it as vitally important work that is rooted in a strong understanding of typographic hierarchies, information design and the mechanisms of interactivity. Experience in the former role tells me that hiring a design graduate with less than 3 to 5 years experience is usually a mistake. Surprisingly, I have had better luck with geeky film or architecture grads. They tend to have stronger conceptual abilities. We can deduce that design programs are non-functional in developing graduates capable of exploring and understanding these tasks. This is a simple and troubling assumption, particularly as I am complicit in the activity of educating them. The organizers of the Schools of Thought conference have recognized a broader problem, inclusive of this issue, and have organized their spring conference around it. http://superstove.blogs.com/schoolsofthoughts3/portal/index.html My question is this. Is it presumptuous to expect Design Schools to graduate students with even a roadmap of the skills of information design, interactivity and typography? The problem lies less with graduate programs - where students should have some breadth of experience - but is pronounced in undergraduate education. I hear no end of lip service; these are core values all lay claim too; yet the results are a vision of the emperors new clothes.

The Art of the Thumbnail

I’ve been a designer for a number of years and during that time, I’ve encountered many people who refuse to sketch out an idea because, as they insist, they’re “not artists”. Instead, they rely on verbal skills and attempt to paint a picture of a concept that probably sounds really great in their head, but just isn’t sounding all that great in their description. And even though they realize their audience isn’t even remotely on board, they’d first resort to interpretive dance rather than sketching out an idea. Because, as they claim, they’re “not artists”. Well neither am I. In fact, finger painting back in kindergarden was probably the pinnacle of my artistic career.

However, I did learn about thumbnail sketches, which are very small, rough sketches that let you quickly outline the basic elements of an idea. They’re an easy way to visually let other people know what you’re thinking. By their very nature they’re not a pretty or perfect drawing--objects overlaying other objects, lines scratched out, arrows pointing to a different version, a big X to abandon the initial idea which is now evolving into a new thumbnail, etc., etc. They’re small drawings, done quickly to work through an idea.

Don’t Confuse the User

You’re the team lead for developing the next killer app, and word is passed along that the marketing campaign is being built around the user-centric design of your new app. Unfortunately, no budget has been allocated to hire someone with the desired skill set to achieve this lofty goal. Your developers are heads down into the code and have neither the time nor interest to become user experience gurus. What to do?

Establish a set of guidelines for your developers to follow. It won’t cover every scenario but it will encompass the basic rule of usable interfaces, to wit: don’t confuse the user. Such things as deciding on and applying a consistent terminology (e.g., section names matching up with navigation names), using expected widgets (checkboxes v. radio buttons), and applying consistent behavior (too numerous to mention) are the backbone to creating usable software. If there’s time, add in messaging for the user -- success messages and waiting messages (such as ‘retrieving data,  please hold’) are vital to assuring your user they didn’t make a mistake and a good way to prevent double clicks on submit buttons.

Listen, the reality is that most projects are not fortunate enough to have a separate user interface design team. Anything that can help your developers to at least start thinking about issues regarding user interaction is a good thing. Creating a set of user guidelines is a good way to begin.

Wait, how did I get here?

The importance of navigation is a given when designing a site. Design it poorly and it’ll have the same effect as having no navigation, i.e., leaving your users lost and confused and rendering your site useless. Taking the time to create a well-designed, well thought-out navigation is worthwhile because good navigation is a critical component in convincing a user to come back to your site. After all, if the user feels they’ve done nothing but encounter obstacles and roadblocks while attempting to attain their goal, where is their motivation to return?

Hey! you protest. I’ve already clearly defined the Global and Local navigation and the taxonomy is spot on. What’s next? O.k., here are two other ideas that can be brought into play to assist the user in getting around your site.

You Are Here. It used to be a standard navigational guide to unlink and visually highlight the navigational element for a section when the user was on the main page for that section.  The majority of large sites, however, now use one global navigation template for ease in maintaining their code. And more often than not, most teams can’t or won’t take the time to build in multiple if/then statements to change the look of the navigational element based on context. But it’s so worth it. Highlighting and unlinking a global navigation item when the user’s on that page comes with two benefits: it gives the user the visual recognition of their present place, and prevents them from clicking a link that sends them to the page they’re already on.

Differentiate Your Links. Not all links are created equal. Some go to other pages, some expand areas on a page, some download documents, etc., etc. So if these links all behave differently, shouldn’t they be displayed differently as well? Handle off-site links by letting the user know they’re leaving your site (see the external  links section on any wikipedia page for an example). Or consider changing the cursor from a hand to a pointer when a link is no longer active (sometimes you don’t want a link to be active in the hover state, e.g., when the link is used to display a dropdown menu on mouseover and not to link to another page). Combining CSS with your creativity, itemize the various types of links you have on your site and come up with ways to differentiate their visual display to clue the user in to to the link's behavior *before* they click on it.

Navigation, in all of its forms, is key to giving the user a good experience. If they’re lost and confused, chances are you’ve lost them as a site visitor. Keep them happy, and they just might visit again and again and again.

Web Accessibility is Good Business

Over the last few years, more and more basic services have been moving to the Web (banking, paying bills, canceling utilities, etc.) Whether the move is initiated as a cost-saving device or as a way to make the services more readily available, the fact is that moving every day "life administration" online means accessibility gains in importance.

Web accessibility is a broad topic but in essence it means your pages are accessible by people using a wide range of user-agent software and devices, in addition to the standard web browsers. The foundation for achieving accessibility is separating out the content and structure from the presentation and behavior of a page.

Use semantic markup to structure the document.

Semantic markup provides a framework for explicitly describing things. It is descriptive enough to allow machines to recognize it and make decisions about navigating a page. For example, the use of header tags <h1> allows users of screen readers to scan the headers on a page. Or a <strong> tag allows an oral user agent to apply a different voice for emphasis. An added benefit is that semantic markup still gives the content visual hierarchy even if the external style sheet fails to load.

Use CSS instead of presentational markup.

Style sheets define presentational characteristics. Presentational markup (e.g., <font>) does that as well, but it does not allow a user to adjust the presentation to suit their needs. When presentation is defined in a style sheet, it allows different users to override the author's styles with their own. This way, a visually impaired user can display a large text alternative by defining his or her own user style.

Ideally you want to use external style sheets so the presentation information for the site is held in one place and can be updated quickly.  In addition, external style sheets enable you to have consistency across pages and  implement global changes in just one file.

The Web Accessibility Initiative of the W3C, of course, has extensive guidelines and details on how to achieve web content accessibility. It's worth reviewing and implementing because after all, you want your site to reach the largest possible audience. Web accessibility increases the odds of doing just that

The Iphone, why.

Years ago I would go to conferences and people would hold up their Palm and lecture us on why it worked, the economy of means, the elegance. Time passed and the same people - usually people who had not actually participated in the design process of the particular device - would hold up an Ipod and preach the wonders of the clickwheel and how it had revolutionized design on the order of bread slicers or fishnet hose.

That they usually missed the point was irrelevant. The value of the Palm was that it was much smaller than a Newton, and much faster because Palm asked people what they actually used. And both of them had coherent software interfaces that easily synced the stuff on your desktop machine. That the Ipod made having many gigabytes of purloined music sort of marginally legitimate was not trivial, either.

So I wanted to get in on the ground floor of helping Apple hype the Ipod phone, because I am predicting that this will save me a significant amount in conference fees over the next two years.

Why does this phone elicit responses like Alice’s, a post or two back? Which I fully admit I shared as all the Mac addicts read the real time blogs from Macworld while jobs was unveiling it. Oh yeah, it is cool!

But what it makes such a big splash is a study in contrasts, and how the competition failed to develop and market something that people can feel affection for.

The current crop of cellphones are junk. There are so many difficult to use features that the cellphone companies market a special line of simple phones for the very young, very old or especially annoyed.

And the phone companies are completely oblivious to this resistance. Because of the way that cell phones are sold, really as a token of the extortionist contract with the service provider, there is a critical reduction that occurs to the feedback from the user. The design of the phones is passed on as a feature list and separated from everything else in the users existence. An elaborate, undoubtably extensively discussed system to create a broken wheel.

The worst thing about the current phones - and don’t get me wrong, Razors look cool and have great ads - is that if you lose it your numbers and all of the phone specific programming is gone. Unless you have a Trio or a Blackberry, you are just out of luck. But even Trio’s and Blackberries don’t have a good mp3/mp4 implementation. Much less the overwhelming cultural currency [read: cool] of the Ipod.

The Ipod advantage in both cases is it’s connection to the desktop.

For phone numbers, it leverages a much more powerful interface; your desktop through any Vcard compliant program. So you have all of your email addresses on the phone; and backed up. Think weeks of texting saved. Imagine what you will do with that time.

In terms of features, the new phone is configurable. Which means, to a luddite like me, that you can turn most of them off. Thankyouverymuch!

Not having to carry around my Ipod and my phone is probably the least of the advantages. Waiting until all the early adopters buy it and the price falls will be the hard part.

What's on my Bookshelf

Having recently been asked to review a book on CSS (which at first glance looks good but I'll go into details in a later post), it caused me to take a look at the crop of knowledge currently gracing my bookshelves. Hmmm, I thought. If I wanted to recommend two of those books, which two would I recommend? A nice little challenge. Deciding to keep the choices within the realm of the practical, rather than the theoretical, here's what I came up with.

First up is Designing Visual Interfaces, Communication Oriented Techniques by Kevin Mullet and Darrell Sano. The book begins with explaining the principles and elements of design and how they can be applied to user interface. There is no "one size fits all" solution but rather a discussion about techniques such as hierarchy, relationship, balance, etc., how they are used and why they're important in software design. The author also gets into module, programs and how structure, predictability and efficiency apply. Further chapters explain establishing modular units or using a grid layout. In other words, the book gives a great explanation of what design theory is and how it's the structure for well-designed user interfaces.

Next up, Designing from Both Sides of the Screen, How Designers and Engineers and Collaborate to Build Cooperative Technology, by Ellen Isaacs (interaction designer) and Alan Walendowski (software engineer). The book is divided into two parts: The Goal and The Process. The first part takes you through designing software with user centric design principles followed by the second section, which walks you through the process of building a software application illustrating what the authors did and, more importantly, why they did it. It's a good case study in creating technology that cooperates with people, shows how good designs help the user flow into their tasks instead of fighting them, and shows how design and engineering goals need not oppose each other. An good description of a theory and the application of same.

So there you have it, two recommendations off my bookshelf. The first promoting design principles and the second advocating user centric design. What's on your bookshelf?

Wheels on a boat

A couple of days ago someone sent me a link to a flash catalog piece...

I have seen these kinds of things before.

And I always wonder why the idea gets repeated. I suspect it is because catalog based retailers see the Book as some kind of golden calf which is due irrational worship. The downfall is in the data-density difference between print and screen is the culprit; print holds so much more that the on screen imitation is irrelevant. The magnifying glass shows a smaller width than a column of type; not being able to read a full line makes multiple lines an instantly rejected experience, fomenting shockingly derisive thoughts on the part of a user.

I have seen this done better, maybe it was a Lands End version... It popped up a new window which was larger and had better controls.

The next question is what would make it work? Is there value to this format that drives otherwise knowledgeable adults to keep trying this metaphor?

If you assumed a 1024 x 768 user base, you would have a larger  beginning state. A very large magnifying glass, or better yet- zoom capabilities, would allow you to move into the page. Which returns us to the question of value.

What is it that retailers are seeking here? I think it is the experience of browsing in a lateral fashion and focussing in on some desirable or intriguing item... A simple but durable pleasure. And the notion of lateral non-hierarchical browsing is certainly a mainstay of the web.

As well, they are looking to leverage the page layout techniques that they find successful in print. This is where things break down; cluttered web pages, whether imitating print or not don’t tend to function very well for impulse surfing. If the page design were less dense with more whitespace you might be able to leverage one medium against the other. However this becomes a series of decisions as to how your product offering combine with the semantic codes connoted by the design choices this would require.

Que Multimedia?

A local school recently asked me to teach a course in Multimedia. It is a first year grad course for people with little design context. Ordinarily I would have been interested in the school and it’s excellent program, yet I stumbled when I heard the term. Living in our Ajax enriched environment it struck me as an old school term, and wondered why it had faded from use.

After a bit of pondering, I came to the conclusion that it is a bit like carving trees out of wood. The metaphor is reversed. The soul in what we do is the interaction; multimedia is occaisionally part of the vessel.

Multimedia means Flash, cheesy little director games, tiny choppy video. Think of children’s CD-roms where low rent repitition is sort of a crash test stand-in for learning cognition. Multimedia means things that are difficult to sell and typically bring dissappointing responses when you do. And not usually worth producing except for massive media clients as they are expensive and cumbersome to update. These are not positive associations.

What is interesting is interaction design and the ability to synthesize actions and events into tighter groupings, both conceptually & physically - ideas like direct manipulation, contextual logic and coherent paths have utility; making it blink is just not that important.

I thought about for a bit, and realized that the suit didn’t fit. Back on the rack.

Web-o-lutions

We have seen many evolutions in website concepts and design over the years. I was talking to my colleague Matt Nolker and I noticed a book on his desk - it was the Internet Design Project book, edited by Liz Faber, published in 1998.

It showed a bunch of commercially marginal but visually impressive sites from the late nineties; back when people put a great deal of energy into brochure sites. And some of them were beautiful - let’s take Swoon as an example. Great graphics, idiosyncratic vernacular forms. Nice work, yet it just looks like a dead zone eight years later.

It made me realize that brochure sites are beyond dead. This is not an easy admission, as I have a couple languishing out in the electronic ether. The currency of websites now is their very currency. When does it get refreshed, what value can be packed up and taken away, or better yet consumed now? Immediacy is so important that aesthetics are largely irrelevant.

With the expectation of daily content, the visuals fall into two classes; an access point to an information nugget or a focussed experiment. For the everyday maintenance, static, highly mediated marketing images are pointless. Look at ten sites and email me if you find a photograph of a business person who isn’t a stockphoto. Look at 20 sites, and you will start to see the same photos recur.

What a site requires is a visual language that is extensible, and dare I say these words, fun to update.

Tabs should be clickable

New UXD Rule:  tabs and buttons should themselves be clickable, and not just the text that appears on top of them. 

Why:
Because if we are going to use real world metaphors, they should be complete.   If the entire surface area of a button is clickable in the real world, then it should be on screen as well.

Example:
The use of the tab metaphore on the Typepad interface is incomplete because only the text on the tabs are links...

Visualization in Project Planning

Visualization is a powerful tool when trying to take a large amount of data and communicate it in a form that is more immediately digestible. We’ve been experimenting with applying visualization to project planning.

Traditional project plans face two challenges. First, the typical list of tasks or Gant chart can be a confusing communication vehicle. Usually such artifacts are printed in microscopic fonts on a relatively small sheet of paper and it’s hard to see the forest among the trees. The second challenge of traditional project plans is they don’t really build a cognizance among team members of what the other team members are doing. In the end, the project has to succeed as a whole, so it’s crucial that team members work well together.

One method of visualizing the project plan is to create a visual timeline. The timeline shows thumbnail sketches of deliverables and environments used to create the deliverables. Example environments could include a location for user research or a meeting room for a brainstorming session. Participants can be represented by simple stick figures. Depicting a plan in this fashion can enable a lucid walk through and vetting with team members.

Another way of visualizing the project plan is to use a storyboard technique. Each panel shows an element of action, a deliverable or a progress measure. When panels are juxtaposed, the entire story of the project plan can be told clearly and effectively.

Visualization of project plans does not demand a lot of artistic skill, just a new approach. Give these techniques a try if you are looking for a way to make your projects plans more communicative and get your team working more closely.

Scenarios – Recording a Day in the Life

One of the simplest and most effective scenarios you can create for an application user (someone who uses an application as part of his or her daily work) is the Day in the Life scenario. It is effective at capturing both tasks and context for using the application.

A series of interview questions can be used to extract the Day in the Life. Some possible questions are:

1. When do you arrive at work?
2. What is the first thing you do?
3. What kind of interruptions do you have?
4. Do you multitask, or finish one thing at a time?
5. How frequently do you use the application during the day?
6. What tasks does the application help you perform?
7. How critical to your job are these tasks?
8. How does the application help you do your job?
9. What does the application not help you with?
10. How much time do you spend during the day using the application?
11. What work is left unfinished at the end of the day?
12. When do you leave?

You can add to this list and modify it as needed. Once you finish your interview, transform the responses into a narrative for an effective Day in the Life scenario.

The Buck Stops Here

Sometimes, it seems that the role of User Experience Architect is 90% management and 10% actual design.

And there's lots to manage:  user requirements, development schedules, business requirements, stakeholder expectations, schedules, timelines, and overall expectations. It's been frequently observed that the UXD is the liaison among all project participants. Truly, all roads to a given project lead through the focus of the user.

As a consequence, we mediators often become bargainers. I'm sure all of us have had to negotiate our design to conform with the myriad demands of the community of project stakeholders. We've given up the fight for a slick, appealing rich interaction for the sake of an overstressed timeline; have gone for the low-hanging, quick design hits in lieu of a more holistic and integrated design approach whose benefits may be more of an investment than an immediate showcase.

But some design recommendations are non-negotiable. Budget be spent, timelines be extended--we fail to justify our worth (and collaborate in our lack of ready acceptance) if we compromise on some critical practices.

Here are some of mine--I'm sure all of you can add to the list.

1. Coherent navigation:  An astronomical percentage rate of abandonment is associated with poor navigation on a website. This directly, and concretely, correlates to lost revenue on an e-commerce site, and only inversely impacts response rates on lead generation sites (i.e., improve the nav, improve the response rate). With applications, though, where users are often captive users, the erosion of usability is less direct, but nonetheless actual. It's almost a karma thing: what goes around (or fails to), comes around (or fails to).

2. Knee-jerk rebellion. As designers, we shouldn't adopt the personas of sulky fifteen-year-olds. Conventions endure for a reason. Especially on sites and apps. They cut through clutter and noise, and allow users to focus in on the heart of their tasks. Sure, we could all make our buttons into links, and links into drop-downs, and display diagonal navigation, but that's design that serves the designer--not the users. An electric light switch is dowdy and plain, but I can rely on what it will look like and what it will do, from sea to shining sea.

Of course, if I'm in Vienna or Tokyo or Rio, that switch is likely to look very different (although it serves the same function), which leads me to. . .

3. Xenophobia and the Ugly American Compulsion. Face it, we're good at thinking we set the standards for the world, and the statistics regarding internet usage bear out--at least for now--US influence and dominance. But that's changing--quickly. China will soon ascend as the country with the largest percentage of the population online. But it's not a simple case of "majority rules." Cultural differences are sometimes subtle, sometimes glaring, but always meaningful. In designing a website or application nowadays, it's best to assume global, rather than local, standards. This filters down to the smallest IA aspects, such as forms: most of the world doesn't conform to the US convention of <city>, <state>, <ZIP>.

A Short List for Contextual Inquiry

In its unscientific form, contextual inquiry is simply observing people do what they do. As professionals, however, we can be more effective by applying some science to the approach.

In a nutshell, the following items are recommended for a good contextual inquiry.

1. Understand your audience - do some research on what they do, what their tasks and goals are, and the unique characteristics of the environment in which you will observe them.

2. Make a list of what you want to observe - time with users is usually a precious commodity, so make a wish list of what you would like to get out of the session.

3. Plan a technique for getting rapport - Beyer and Holtzblatt (see reference below) identify several approaches such as the Master/Apprentice. In this approach, you are the apprentice observing the master at work.

4. Define all of your measuring and recording techniques in advance - you may wish to use audio, photography, video, etc., but even for simple note taking you may wish to prepare note sheets in advance to make the best records possible. For example, a "swim lanes" note sheet can be used to record the interactions between what the user is doing vs. what the system or tool is doing.

For more in depth information, you can look to two very good books. The first is Beyer and Holtzblatt's Contextual Design: Defining Customer-Centered Systems. The second is Mike Kuniavsky's Observing the User Experience.

Key Elements of Effective Personas

Alan Cooper is generally recognized for bringing personas to the UXD world in his 1998 classic book The Inmates Are Running the Asylum. Today, personas can be found stretching into the toolbox of marketing experts and business strategists. But what makes an effective persona? In our experience, several things are important.

First, give your personas a name and a photo. We can readily remember and relate to a series of names and photographs. It isn’t just soft fuzzy stuff, it will speed your discussions and make them more engaging. You will get to know these users as your project evolves.

Second, get a firm delineation of the user’s goals. What is this person trying to do? Then consider headlining the goals with a quote that characterizes the user’s attitude, desire or priority as it relates to the goals. For instance, in a mission critical healthcare setting, a quote might be something like “I need to be fast and accurate.”

Finally, provide a day in the life narrative about your user. What in his or her day relates to the product or system you are designing? What tasks or steps are key? You don’t need to be a great storyteller to write such a narrative. You can simply lay out a chronology of events from, say, arriving at work to leaving at the end of the day.

While there is a lot of science you can apply to personas, master the basics and you will be able to quickly craft a powerful vehicle for guiding design, strategy and ideation.

Color For Developers, V1

It is time to open the temple.
The secrets of the art ones can finally be spoken. Having gone to a school that was too expensive then and ridiculously so now, I am a fully qualified shaman of these mysteries. Line up to the left of the Hibachi and keep the coals smoldering.

The great truth is an anthem that has rung true from the beginnings of byzantine painting to the abstract impressionists:

Warm colors advance, cool colors recede.

That is the first axis. Hue, the amount of color & it’s context are primary definitions of what will be perceived in which order.

Sounds simple, doesn’t it? Like a little saying to remember a musical scale, it is easy to recall. It happens to be the basis of hundreds years of painting explorations, which influenced a couple of formal design philosophies - what some people call Swiss Modernism & the International Style.

The real connector here is a Mazdaznanian cultist employed by the Bauhaus - Johannes Ittens. In a nutshell, he liked to draw mandalas and label them. Now we call them color wheels. His codifications of color theory have been disseminated by Bauhaus students who became teachers, and their students, globally since 1919.

Historical theatrics aside - I am trying to pad this because it is really pretty straightforward - warmer colors dominate your attention. But wait, there’s more.

The other axis is a cognitive one that is more elemental than color - our perception of contrast.

The highest point of contrast becomes a focus point as well.

This is strictly about tone; the interplay of light and dark. Shape and scale work in a different way; context is more important here. A good example would be stars - not that bright or large, but you can’t help but notice them.

So imagine two sliders, one that goes from warm to cool colors, one from high to low contrast. High contrast and warm colors converge at one end of the slider, but cool high contrast areas can dominate perception if the context is controlled.

Additionally, the scale is relative. In a very pastel environment, we are still biologically compelled to compare & discern. We will look for the warmer tones & highest available contrast.

So there you have. Welcome to priesthood, those tattoos will heal in a just few weeks, and you’ll be ready for the piercing.

Breaking the First Commandment

The practice of user experience design frequently involves the invocation of rules, guidelines, tenets, and not a touch of folk wisdom. There are several plausible reasons for this.  UXD derives from the cultures of many previous disciplines: architecture, physical ergonomics, psychology, to name a few--and each discipline comes equipped with its own doctrines. More importantly, we strive to focus on the science as well as the art of UXD, and as practitioners, I think we often bend over backwards to position our findings as objective and standards-based, and not as a collection of personal opinions emanating from a range of individual perspectives (not that there's necessarily anything too much wrong with that--after all, user experience is our expertise. Do we ask for a heuristic review of the beef brisket from our butchers?)

If any commandment is central to the spirit and philosophy of UXD, arguably it's Arnie Lund's enduring admonition--heck, it's even framed Biblically: 

Know thy users, and thy users are not thyself

It's a good guideline, of course:  as user experience designers, we often know far too much about design, and far too little about actual user experience. But I've often found that sufficient user research is the ideal rather than the reality, for numerous and varied reasons. Sometimes, stakeholders see user research as the one point of resistance in an otherwise acceptable project plan--they simply can't see the value. Or, potential users are unavailable. I've encountered two common reasons for this--confidentiality of the project prevents the inclusion of users in research because of speed-to-market or the need to keep aspects of the site or application completely confidential. Or, the product is being designed for a foreign or distant market, and the logistics (and budget) simply can't support field studies or task analyses.

But we've discovered workarounds for obtaining information in the absence of "warm bodies." Proxy users--often project stakeholders--can be successfully separated from their personal points-of-view, and their domain knowledge can be leveraged. Friends-and-family research is also a rewarding path--as a group of designers, one of us usually knows someone (who knows someone?) who can fill in to help supply the user persona.

And the idea of personas and scenarios is key in reinterpreting Arnie Lund's directive:  after all, simple knowledge of the users is not sufficient--it's how you apply this information to the design strategy that's the important application.

To paraphrase Walt Kelly's Pogo, sometimes we've met the users and they are us.

User Testing: Shadow Casting Real Use

User Testing is always good. It always yields some worthwhile and occasionally unexpected results. After the ego’s involved recover, they realize it is always better & cheaper to know sooner.

But User Testing is not perfect. If it has a fault, it is this: user testing an existing site is like watching life in a rear view mirror. It’s a reflection of a snippet of experience; a kind of shadow casting of real use.

Often, people evaluate what they have access to and make profound determinations on the basis of what they can see. This can be a very limited view of reality, and tends to reinforce that which has already been invented; to paraphrase a tautology: That which is good exists, that which exists may or may not be good, but it can be tracked within a millimeter of it’s existence.

So it has to be taken with a grain of salt. There are famous business cases of researching an existing context and making regrettable decisions. The research that Ford did as to whether or not they should have a drivers side rear door on the Windstar strongly indicated that consumers did not care. Dodge ignored thier research and added one, taking the market from Ford. What is the lesson? Once consumers saw it, and used it, they realized that it was a valuable addition. Another chapter in Ford's seemingly endless downfall.

To suggest that the fault is the user testing is not quite the whole story. The user testing counted what was known to be countable; what it cannot do is invent, or count what it cannot quantify. However, a mix of interviews, done by objective mediators, can reveal trends that designers & developers may not have considered or may have de-emphasized in thier process.

Rapid PowerPoint Prototypes for Ajax and Rich Interactions

As applications take the web from static pages to dynamic screens, how can the designer effectively mock up and vet early-stage dynamic screen designs? PowerPoint provides one possible vehicle.

We have found PowerPoint to be effective because it has very easy to use animation, screen transition and click-through capabilities. While the prototypes we produced were not highly polished, they were highly effective in vetting the ideas for a new website IA with three key groups: stakeholders, developers and graphic designers.

One specific effect that was used was the screen transition called “Wipe”. The Wipe effect (available in up, down, left and right versions) enables easy simulation of things like sliding drawers. You simply make a slide with the closed state of the drawer followed by a slide with the open state of the drawer and apply the Wipe transition.

Though the technique is simple, it is quite effective at communicating the screen ideas to users and developers.

The Case for Case Studies

Currently, I've been tasked with writing up our team's recent projects, for the immediate purpose of publishing these stories on our website to support our marketing efforts. Using case studies for this purpose is a recognized, and arguably successful, way for designers to document their successes and describe the ways a good design has contributed to a good software product or website.

But I always wrestle with the narrative. What is the story we want to tell? How design, detached from the larger context, was appropriate, optimal, on-target and on-budget? Shades, perhaps, of "the operation was successful, but the patient died"?

Classically, a case study provides an opportunity for providing "an exemplary or cautionary model." A good case study should equally document the mistakes and the milestones, the lessons learned as well as the goals achieved.

Does this alter the tenor of the corporate case study? Hopefully.

User Experience in Sovereign vs. Transitory Applications

The characteristics of what makes a quality user experience can vary dramatically when talking about a sovereign application vs. a transitory one.  Sovereign applications, like Microsoft Word, draw in and maintain our attention for a length of time. Transitory applications, like Google, serve us for a short term need and then we move on.

Walk Up and Use
A transitory application should have a walk up and use quality. Even the slightest extra need for time to figure something out can dissuade users. In addition, these applications benefit from a comfort factor. If the software seems comfortable, I’m more likely to not mind spending a few moments with it. Finally, good error recovery is essential. The software should instruct the user as to how to recover and provide an easy way to do so, or start over.

Extend My Abilities
Sovereign applications should enable us to extend our abilities to get something done which may be complex or require some time. Making the correct design trade offs and arriving at a quality experience depends on characterizing how the tool extends the user’s abilities. Does the tool allow for faster performance of a repetitive task? Does the tool enable completion of a task not possible without the tool? Does the tool aggregate tasks into one place? The key to creating an effective design (and measure of success) is determining the ways in which the tool extends the users abilities and which are most important.

Types of Flow - A Quick Reference

How does the concept of flow manifest in an application? We usually look at three different aspects of flow during the design process.

The first is efficiency. Often we are seeking the use of an application to save us time in accomplishing what we have to do. In the user’s eyes, efficiency gains are often tied to satisfaction and are frequently where flow starts.

The second aspect of flow is hybrid navigation. Most applications of moderate or greater complexity will require a combination of linear and non-linear activities. It is important that the designer be able to empower each activity while keeping the overall scheme consistent and intuitive.

The third aspect of flow is comfort. When the interaction with a product is comfortable and natural, the product starts working at an emotional level. In technology-based products, accomplishing comfort in the design can be a significant differentiator in the marketplace.

Towards a concept of flow--UXD perspectives

"Flow" is an attribute we're talking about--and, hopefully, designing towards--here at Pathfinder. As application designers, we've been captive eyewitnesses to the proliferation of contradictory and unrelated features that consititues progress in IA and development.

Design theories of flow are derived, directly or indirectly, from the work of psychology professor Mihaly Csikszentmihalyi, who has dedicated over two decades to developing a theory of "optimal experience."

We've recently shared some of our thoughts on flow at the IA Summit and World Usability Day. Other perspectives include those of Kathy Sierra, the academically focused ACM, and designer/blogger Scott Berkun.

Plus, an interview with The Man Himself in Wired, titled (you guessed it) "Go with the Flow."

Maximizing Meetings:

or 6 blind men and an elephant, in a phone conference..

We had a meeting a few days ago with a senior rep at one of our clients. This client was a trainer for the product we are doing some substantial revisions on - we learned more about it’s capabilities and the histories of use in 20 minutes from him than we could have in months of studying the app.

So what do you do with that information once you have it? What is the best way to cut that iceberg of information into usable pieces ?  Iceberg is the right term, because most of it is still hidden.

We decided to separate & each write our own version of the truth. Then to reconvene and compare/contrast/collect the ideas we heard while brainstorming more. This way we each define our individual perceptions, without the dynamics of personality minimizing contributions. We have tried this numerous times & found it highly effective for maximizing creative ideation.

And it is worth noting that information gathering at this phase is anything but linear. There are snippets of narrative, hard parameters that must be recognized, ideas that immediately strike you as being part of a larger solution. Capturing these, sorting them and keeping them available to the team is an ongoing challenge to which there are both simple & complex solutions. These can range from the utility of having a well designed directory with ongoing and meta class folders to full CMS solutions that enable sophisticated search. The solution most useful is determined by utility, cost & scale.

Scenarios in Product and Project Management

One of the biggest challenges in product and project management is definition and control of scope. By its nature, a design process is a discovery process. As new things are discovered, scope can increase.

One way to manage scope is through scenarios. While a product can have many processes, interactions, screens or flows, at the human level there are likely to be a quantifiable and definable number of scenarios. After all, products and processes are created to enable someone to do something.

By using scenarios as the "buckets" of what a design needs to enable people to do, it's possible to manage scope from this perspective. Any new feature or requirement must fall into one of two categories: It either requires a new scenario, or it's an addition or refinement to an existing scenario. If the scenarios are prioritized, scope impact can be handled by answering the following questions:

- If the new feature requires a new scenario, how high a priority is that scenario?
- If the new feature ties to an existing scenario, does it change the priority of the scenario? Does it change the implementation time for the scenario?

Defining and prioritizing scenarios can be a great help in controlling scope of a project. Scenarios can provide a manageable way of grouping and prioritizing features, innovations and ideas to keep everyone on the same page and the project on-target.

The Design of Non-Everyday Things

Often as User Experience Architects, we are asked to bring the design process into new domains and complicated products that may have not been previously exposed to such a process. How can we, as professionals, achieve success in new and challenging environments? The answer is nothing new: Stick to the fundamentals. Don Norman listed them in his timeless classic, The Design of Everyday Things. As "Things" become more complex and more niche oriented, the principles still apply. Let's review a few of them.

First, keep the structure of tasks simple. A task may have many steps, and involve complicated data, but the structure can still be simple. Second, make things visible. If the user can't see it (or hear it or touch it), they probably can't use it. Third, design good error recovery mechanisms. The user should not be allowed to box themselves into a black hole they can't get out of. Finally, create and leverage standards. Think about the amazing complexities in road travel that are possible with a few simple standards of lights and signs.

Applying the fundamentals is the key to success in complex projects. Getting good with these timeless principles will make the complex manageable, and even fun.

The Experience behind User Experience Design

Back in the days of rigid gender stereotyping, Lily Tomlin observed that if we all grew up to be what we wanted to be, the world would be full of firemen and ballerinas.

I don’t recall aspiring to either of these vocations (too timid for the first, too tall for the other). More to the point, I never thought I’d eventually evolve into. . .ummm. . . whatever we’re being called today. Being WOTTI (Way Older Than The Internet), my education and professional expectations were defined in areas that seemed remote from technology, interface design, or usability. With degrees in English Literature and a late-blooming resistance to a life in academia, I began to accumulate the quixotic resume of the Liberal Arts graduate.

Eventually, I spent several years as an Instructional Designer (ID). As the internet boom gained increasing momentum, the small technology consulting company where I worked was acquired by a large technology consulting company, and our quirky New Media group was reinvented as the firm’s semi-quirky User Experience practice. Then, as now, we sought to crystallize our identity—and affirm our corporate value—by creating a clear, hopefully self-explanatory job title. I wince to remember that in the mid-90s we called ourselves (without irony) “Cognitive Engineers.” Now, “Information Architect” has gained currency, a title that retains the methodical and craft-like aspects of the role, while successfully distancing practitioners from the inevitably Devoesque connotations of spiky, mass-produced cogs and hand tools. To stay billable, “cognition” and “engineering” are two concepts that should not be paired on the same business card.

Actually, a background in ID is great preparation for a career in UXD. Both disciplines are solidly user-centric and require creativity as well as technique in planning and development. The two key goals of the Instructional Designer are to optimize content for organization and understanding and to determine learning goals and appropriate success metrics—both of which are important but often overlooked strategies in designing websites and applications.

The successful Instructional Designer has the ability to quickly understand and then effectively communicate information from complex knowledge domains. Although I’ve designed web-based training for neurosurgeons, you probably wouldn’t want me brandishing a scalpel in your OR. I may not be able to do—but I can teach. Our firm specializes in the design and development of complex applications, requiring a learning curve that approaches the perpendicular. This skill is valuable to me as a consultant as well as a designer.

I respect my colleagues who have had the benefit of formal training in HCI. I’ve had to create my own curriculum through reading, workshops, and work experience, and I wish I’d had the opportunity to study and experiment in a more cohesive and less project-driven way. But I admire—and have learned from—my peers who have come to UXD from more scenic routes. Certain disciplines have obvious synergies and commonalities—architecture, visual design, marketing, computer studies. But I know fantastic UXD practitioners from other backgrounds: quantum physics, music, healthcare. UXD is not an easy-entry profession, but it is one that welcomes the experienced traveler. I recently met an Information Architect with background and training in theatre, who feels that the persistent thread in her experience is the love of narrative—whether storytelling takes place on the stage or on the (computer) screen.

Maybe my friend and former colleague Jason lives in the best of all possible worlds: his undergraduate degree is in English, he has deep experience in development, and he’s recently completed his Master’s in HCI at DePaul. But who’s to say which of these experiences makes him an excellent User Experience Designer?

CHI2 Town Panel

On April 5 I was invited by Brian Maggi to speak with Mark FelcanSmith [Allstate] Frank Gruger [Motorola] & Jason Kunesh [Orbitz], at the Depaul Center at 1 East Jackson. Frank & Brian recorded the event for a podcast - I think elaborate mixing & sweetening is occurring as you read this.

Pre-talk dinner at the Exchequer loosened tongues & elicited shared histories with several of us having journeyed to the West Coast and/or back, and this became one of the first topics of the panel in terms of the opportunities available both here & there. My comments centered on the differences in the kinds of business endeavors which predicated a much more conservative environment here.

I find far less frivolous business ventures here - no pets.com or flash in the pan outfits like Friendster. What Chicago has is brick & mortar businesses who tend to be in a discovery phase with User Experience Design & HCI concerns; this means that there is vast opportunity. The logical corollary is a requirement for significant education; the panel agreed that IT departments were very much the gatekeepers here, and tended to be suspicious of anyone from outside their world-view. Luckily for us, there are many supportive currents in the media, both tech & general, that are helping open these doors.

Brian moderated, goaded & cajoled with great skill, keeping the conversation flowing. The structure of the event was simple Q & A, but as the panelists had many years of experience between them, stories & opinions were anything but lacking.

Adam Steele - in a moment of brilliant academic scheduling - brought his DePaul class. There were a couple of questions regarding what to show in an interview - I think the first one was whether you should show a book. YES, definitely was the resounding answer.

But what kind of book? The answer from the panel was unanimous - all of us wanted to see evidence of process. I recall it was Mark FelcanSmith who said show how you got there. I reinforced his comment by saying that I would rather see the process steps of three examples - problem statements, concept, iterations, solutions, results - than 15 unconnected finished pieces.

If you actually make it to an interview, then it gives both of you something worthwhile to talk about. How you developed an idea leas to methodology discussions of how you approach the stages of a process & how you deal with collaborative environments. UXD or HCI work is a team event - particularly as a junior, you are not likely to be handed a problem and told to come back with a solution in two days.

There will be Business Analysts, Developers, Senior designers & Clients working together to solve what is usually a complex series of problems. Work needs to be produced in a way that allows for comment, technical realities or epiphanies or creative market approaches. So the ability to work in stages is crucial.

Many other questions were asked & answered - I will link in the podcast when it appears. Thanks to Brian & the other panelists for an enjoyable evening & freely sharing their stories.