Month: February 2007

This is totally from the the Paul Rand school of thought, as well as many other leading (and legendary) designers like Eames: Designers should leverage timeless principles (of form, content, quality) and embody a beauty (in all its multidimensional senses) in their work, outlasting momentary styles and fads. It’s admittedly an idealistic view that speaks to issues of craft and cultural value.

On the opposite end perhaps are those who seek to serve and influence the fashions of the day, whatever may be considered “cool” for the hip and savvy set. A former creative director of Nike and Quokka (now VP of Product Experience at Adobe) recently proclaimed that “we’re all fashion designers now”. Not too sure if I agree with that :-)

Couple quick examples of successful fashion-based adaptation:

* Madonna has done an extraordinary job morphing herself every couple years in terms of her style and music.
* Relatedly, MTV is a major commercial brand that must adapt to changing styles and fads to stay relevant to its savvy audiences, especially at a global scale!

You gotta mentally work through that idea towards implementation, carefully assessing the consequences for other members of the team (dev, design, QA, doc, PM, etc.) and overall impact on the product design direction. Consider the following questions:

What’s the impact on aesthetics? Does it deviate from pre-set styles (like CSS)? Does it introduce new (undesirable) modalities or unfamiliar behaviors inconsistent with the rest of the product? Does it interrupt the natural workflow? Is it something “cool” for the sake of hipness without real benefit to solving a user’s problem? Is it introducing scope creep given the current cycle/release? (ie, being a consultant it’s important to be mindful/respectful of the client’s situation, helps build cred and relationship)

Just to iterate again about the need to be smart and efficient about what deliverables to spend effort/time on…

1. Make sure it helps the team make decisions about the UI.
2. Make sure it moves everyone closer towards the prototype.

No, I’m not the “decider” (especially as a consultant, where I primarily “recommend” :-) But in the course of product development whereby the design of the UI colors the overall user experience (initially expressed as the prototype), decisions about “which widget goes where” are critical. Such decisions must be regarded seriously in terms of consequences upon the page layout, user interactions, system responses, technical abilities, etc. A few things to keep in mind about these vital decisions:

1. Make sure all the relevant parties (engineering, marketing, QA, doc) who can/will be affected by the UI decision are in the room together to hash it out in real-time.

2. Once a decision has been made (achieved via consensus or collaborative weighing of pros/cons), record it, commit to it and give it a deadline. A common problem is lack of follow-up or accountability for a design decision, or simply lost in a flurry of other decisions.

3. Designers love to make all kinds of artifacts/deliverables, but due to constrained time/resources/dependencies, the designer should ask herself “Does this artifact move us towards better design decisions?” or is it something simply to “help the client feel good” or for internal bureaucracy/political goals? (ie, furthering the machine of bureaucracy for the sake of Process)

Designers should create (and send onward) only those artifacts that are meaningful towards helping the client make a decision about the UI. For example, a designer may rapidly sketch out with his pen several possible solutions or a quick concept map of system objects to help him think through the problem, as a natural part of his process. But should he take the time to scan in those sketches and send them to the client? Should he spend the effort to rebuild them in Visio or Illustrator as a formal document? Only if the result will help the team make decisions about the problem and solution…and of course move everyone closer to the prototype!

Perhaps the first, and most pertinent driving principle of interaction design is that the prototype serves as the record of truth for the development team, as a vital stepping stone towards accurate implementation of the intended behaviors. The prototype also provides more visceral, accurate, assessable information for evaluating the design’s utility and enabling non-designers to buy-in, stakeholders to sign-off, and customers/users (preferably alpha users) to effectively judge. And the prototype, in demonstrating both visual as well as behavioral qualities, can provide a more “well-rounded” sense of what solution is supposed to be, helping implementation experts estimate for resources, timing, and methods needed to make the actual shippable product.

So, if the prototype is that critical for the design process, then you’re correct to assume that every step of the design process and every deliverable created along that path should be directed towards getting to the prototype quickly and efficiently. In other words, don’t waste time making a perfect flow diagram or set of wireframes …satisficing (from herb simon, the idea of sufficient yet valuable) is paramount to sustaining forward momentum.