Robert | 12.23.2005 @ 10:57 AM
Permalink | 0 Comments  

In the real world, Alan Cooper's methods don't always work. This is true not because Cooper is wrong, but because too many companies skip the interaction design process completely, leaving it up to programmers to "design" software themselves, making spur of the moment decisions that greatly, and most often adversely, affect the experience of using the application. When design is left up to programmers, software becomes complicated, extremely difficult to use, and bloated with edge-case features that, while giving marketers a hefty list of bells and whistles to cite in marketing collateral, actually inhibit the ability for most users to use the software effectively to accomplish their goals.

As long as this remains true, "Just in Time Design" must be allowed into the process. Just in Time (JIT) design is the act of doing intentional design work right when it's needed the most, which is the moment right after someone has decided to add a new feature and right before the programmer starts producing code. (This is especially true and necessary when the software company adheres to eXtreme Programming methodologies, which creates a constant state of in-flux prioritization.) Excluding quality interaction design work prior to software development is a bad idea, but when it happens (and it happens on a daily basis in the corporate world), JIT design must occur so that at least some intelligent design can make its way into the final product.

I hesitate to call this eXtreme Design, by the way, because doing so grants permission to stakeholders to ignore the interaction design process and latch onto the catchy "eXtreme Design", a phrase which sounds cool and cutting-edge, but cannot ever be as effective as interaction design.

JIT design, in my world anyway, generally entails holding a quick meeting before the coding starts to brainstorm and decide how a new piece of the software will behave, how it will be accessed or invoked, and how it will look. This meeting can take five minutes or three hours, but it must be done. And the meeting should always include someone with user-interaction know-how. If you don't have any experts around, grab the person with the most earnest level of interest in the subject and give him or her ownership of the role (people tend to step up to even extreme responsibility when given ownership).

During this metting, at least one programmer, one designer, and one user should be present. While this sounds like the ever-ineffective "seat at the table" approach, it generally offers exactly what is needed for the purpose: a representative user (usually an interal employee) to talk about what he or she needs and wants, a designer to interpet those needs and make suggestions about possible solutions, and a programmer to map out the feasibility of the suggestions and quietly begin devising a coding plan.

The result of such a meeting may or may not involve assigning the task of creating wireframes for the new interaction. Wireframes are preferable, but when there's no time to wireframe, at least the programmers will have a good idea of what to build and how it should behave prior to making impulsive decisions that lead to more bad software. Believe me, folks, this is the bare minimum of what should be done, but is significantly better than doing no design work at all. This way, at least more than one person has been involved in the decision process, and at least one of them is a real-live user.

Whenever possible, a resident expert on interaction design should be present (whoever might be the best person you can get), so he or she can make educated suggestions about how to make the particular piece of software more usable, more flowing and intuitive, and more likely to help users achieve their goals. In a worst-case scenario, where no interaction gurus are available, you should at least have a graphic designer in the conversation, so that an improved look stands a chance of improving the interaction. Again, this is in a worst-case scenario. Your company should always have in its employ someone who has done extensive research on how people actually use computers so he or she can make educated suggestions about how to improve the experience.

JIT design should not have to exist, as Interaction Design should always occur prior to building anything an end-user will touch, but since interaction design is currently ignored in entirely too many situations, JIT design is the best one can hope for, and the best attempt at a remedy before things get too out of hand and you end up with software loaded with features that make users feel stupid by neglecting their needs and wants.

A user who has his goals ignored is a user who will never be a true fan of your software, and true fans are the best thing a company can possibly acquire. If you cannot include quality interaction design as part of your process, you must, at the very minimum, allow JIT design to run interference between stakeholders and programmers. With modern computing quickly becoming as ubiquitous as sliced bread, it's a moral imperative.