Beautiful Things "Work" Better, Except Maybe When We're Talking About UX Deliverables

Seems to me there”s some sort of meta-critique that can be made (or perhaps has already been made) regarding what Norman observes about attractive things being functionally superior to ugly things, and the conflicting idea in some UX circles that intentionally ugly deliverables might “work better” than high-fidelity comps and prototypes for representing and conveying foundational and structural design intention to our clients.

There”s a prima facie problem with the notion that abstract, simplified,  aesthetically-neutral deliverables might be better at conveying design intent and getting durable client approval on specific, complex structural and navigational ideas.  Especially if your understanding of Don Norman”s work is that he”s saying attractive things always work better than ugly things.  This oversimplified reading of Norman would seem to necessarily stand as an indictment of the traditional approach to IA design, as much of the simplification and abstraction in IA design deliverables is attained by subtraction of visual design elements that correlate with attractive-ness.  But hold-up:

[the] pleasure derivable from the appearance or functioning of the tool increases positive affect, broadening the creativity and increasing the tolerance for minor difficulties and blockages. Minor problems in the design are overlooked. The changes in processing style released by positive affect aids in creative problem solving that is apt to overcome both difficulties encountered in the activity as well as those created by the interface design. In other words, when we feel good, we overlook design faults. Use a pleasing design, one that looks good and feels, well, sexy, and the behavior seems to go along more smoothly, more easily, and better. Attractive things work better

In my IA class at UM SI, I talk about how the abstract deliverables we create as information architects can be more effective with client decisionmaking on issues like organization scheme and navigation and labeling because they subtract the highly emotional stuff (photography, color, typography) that “skews” client understanding of the info architecture.  Counterintuitively (for some at least), the passage from Norman quoted above strengthens the argument some UX folks have been making with regards to simpler, even ugly deliverables*.  The more attractive the deliverables are, the more likely the client will “overlook design faults”.

Right?

*NOTE: link to anonymous IA Wiki node with discussion of pretty vs. ugly deliverables is currently offline. I quote this node on a slide in my class, which is viewable here.

13. January 2009 by dan
Categories: Book In Progress, Information Architecture Design, Steal From Here for NTISI, User Experience Design | Tags: , , , , , , , | 3 comments

Comments (3)

  1. I second. While a wireframe, for example, can be quite elegant, I find that wireframes and paper prototypes in particular help clients take a step back and think about the site structure. If you explain the purpose of the document and see if they even want such a thing, and explain again when you hand them a grayscale image full of boxes and Helvetica, people seem to get that it is a skeleton, and not the site, particularly if the client knows that their site is a mess and has specifically asked you to clean it up. There are a lot of “ifs” in that last sentence, but since what I mostly do is clean up other people’s messes, low-fi IA/UX deliverables tend to work for me.

  2. I suspect there’s something very important when we’re using abstractions like computer-generated wireframes to make sure we and our clients have to make a leap with those abstractions from their inception-format (computer mockup) into some other format (hand-drawn huge cartoony prototype) in the course of developing and approving them.

    If we lock our design development renderings into a relentlessly screen-based procession from bullet list in word to crude visio sketches to elaborate visio wireframes to initial photoshop comping to final photoshop layouts to web browser … aren’t we necessarily sabotaging our ability to get clients to engage with the IA work in terms of “these are abstractions” and “this is not the website”?

    Intentionally interrupting that rush from one desktop app to another with forays into meatspace isn’t new in the world of information architecture. Many of us come at this work from a background in librarianship, and we love to get the post-its and notecards out and do organizin’ stuff that’s decidely and deliberately happening in meatspace (you know, meatspace: where the books are). But what I’m curious about and what I think might be novel in UX-land is a mindfulness and insistence about working moments of transfer in between analog and digital worlds into the UX development process for the purpose of ensuring that nobody, especially the client, mis-comprehends what’s being developed and ultimately decided-on in a deliverable. Regular-old-architects always move from paper to screen to balsa wood back to paper back to screen … lots of transference among formats is inherent to regular-old architecture. It is not inherent to information architecture.

  3. Do you think some of it has to do with client expectations as well? I think a lot of clients still have this notion that computers are magic and that it’s really easy to instantly make complex changes to mockups and other deliverables, as well as the final product (the “My nephew can do that in two hours and for free!” problem). Old Architecture has a built-in ancient history and is inherently venerable.

Leave a Reply

Required fields are marked *