10 Feb 2007 1336H

Feedforward, Affordances, Conventions, Design Elegance

Am looking for an AJAX UI widget that allows the user to scroll content horizontally like the widgets on the iTunes Music Store. Failing that, might code it myself. I’m reading through the contents of the Yahoo UI Library (YUI) and am pretty impressed by how well organized and very well documented it is; makes me think about the possibilities.

I’ve been thinking more about kinds of “feedforward” (as opposed to feedback). I think there’s something in that principle, if coupled with certain kinds of perceptual affordances, that could be used to defray some of the costs of teaching people how to interact with new or infrequently visited varieties of interfaces. It’s not the case that you need feedforward all the time. Ideally, if you design an application or system well-enough, either by error-proofing or other design method, there should not be a need for feedforward, though there are many conditions that should be met before that can be true.

Primarily my search comes from my frustration with all this handwaving about how important but difficult it is to design things for simplicity, viz, design elegance. As my design thinking tends to revolve around user actions, I think what might be needed is a framework for problem recognition, design strategy, and a language for action, which I think these design patterns help situate. But if we have all the tools we need already for designing for simplicity, is it just getting our heads around the problems we need to solve that is unclear? But doesn’t this all goes back to Asking Why Five Times, since we’re trying to get at the heart of a problem?

Oftentimes, we are simply reacting without thinking to someone’s request to change something, when we should be asking them why they want it to be done a particular way, and not so readily cede our design responsibilities to them, since they are not professional designers. Perhaps we do so because the other person is difficult to work with, perhaps it is because they have political power over us. These considerations don’t get at the heart of a problem.

In talking with a client designer about my philosophical and disciplinary biases, I’ve been telling them that I generally lean conservatively with interface design, because users know now, through years of training, how some things on the net work, so its important to leverage conventions, because users have expectations about how things behave, and rather than re-inventing the wheel, and having to train users all over again, I’d rather go with the Devils We Know, or Things We’ve Seen Before.

When I observe designers strategizing how to solve a visual communications problem, I notice that if they have not worked much with online media in cross-disciplinary teams, more often than not, they tend to veer off in a novel and less-than-optimal direction. But convention and structure should not be deprecated, but be used as a base upon which you build innovative solutions. Someone wrote recently that it’s because there isn’t much award or acclaim in creating things we’ve seen before. That’s all well and good, but since we’re both trying to solve a problem for a user or a client who wants to accomplish something on the site, let’s do this together cause we don’t want to create A) an ugly user experience, and B) something that looks pretty but is unpredictable and frustrating to use, causing metrics to fall. Of course this is just one part of the design lifecycle, since as always, user testing helps us make better decisions by informing our design about user expectations.

So we use perceived affordances, conventions, feedforward, poka yoke, all the flora and fauna in the IxD ecosystem to tell users how to use something. This is why people can’t design something simply and easily, since what one user perceives as simple is not the same as another. If you’ve never flown a plane before, the user has no context for the environment and so few affordances can be perceived. If a user hasn’t ever come to a site, or ever performed a construction or design workflow, then you should not be surprised when the user can’t accomplish certain tasks. And of course, if one is not exposed regularly to the conventions of online design, we should also not be surprised if they cannot design to those conventions.

This is where feedforward might be helpful. In a novel environment, the feedforward points out what the actionable items are, what action might be performed on them, and even how to perform the action. But you don’t need feedforward all the time, and depending on how you design, you might not need it at all. You might need it the first time you come to a new application, you should be able to turn it off at will, and for all other times, maybe have function-attached, on-demand contextual help. My friend J, a usability manager in Hong Kong, told me a few months ago that he got a Creative Zen music player but despite the name, its “as-is-ness” was not so self-evident, since it failed to demonstrate to his friends and colleagues how to just turn the thing on. In this case, designing the error out of the system would be the first step, but one wonders if and how feedforward would have helped or hindered the subsequent user interactions.

Permanent link to Feedforward, Affordances, Conventions, Design Elegance

Filed under Design, User Experience, Web

Respond »

Be the first to respond to "Feedforward, Affordances, Conventions, Design Elegance"

RSS feed for comments on this post. TrackBack URL

No responses yet.

And now it's your turn.

Fire your weapon, soldier. Just be careful of friendly fire. NAME & EMAIL required.

Your response