Sadly, many companies skip the design process completely, leaving it up to programmers to "design" software themselves, making spur-of-the-moment decisions that greatly, and often adversely, affect the experience of using the application. When design is left up to programmers, applications often become complicated, extremely difficult to use, and bloated with features that, while giving marketers a hefty list of bells and whistles to cite in marketing collateral, actually inhibit the ability of most users to use the software effectively to accomplish their goals.
As long as this remains true, Just-In-Time Design and Just-In-Time Review are viable and necessary alternatives.
Just-In-Time (JIT) is the process of acquiring and delivering materials right when they're needed, as opposed to maintaining a surplus. In Web terms, this translates to Just-In-Time Design, which involves doing design work right at the spur of the momentthe moment right after someone has decided to add something to the interface and right before the programmer starts producing code.
JIT Review, on the other hand, is used as a final opportunity to reduce and refine a solution once it's been built.
JIT is especially appropriate when a development team practices Extreme Programming, which creates a constant state of in-flux prioritization, but it can be used in any company to improve the state of an application before the latest version is released to users.
JIT Design generally entails holding a quick meeting before the coding starts for a new feature (or some other change to an application) 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 and flow. This meeting can take five minutes or three hours, but it must be done, and it 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 (people tend to step up to even Extreme responsibility when given ownership of the result).
During a JIT Design meeting, one programmer, one designer, one user, and one whiteboard should be present. Other people can come too, but the fewer the better. More voices only make more debate. The meeting requires exactly what is needed for the purpose: a representative user (usually an internal employee) to talk about what he or she needs and wants, a designer to interpret those needs and make suggestions about possible solutions, a programmer to determine the feasibility of the suggestions and begin devising a coding plan, and a whiteboard on which to sketch interface ideas and list requirements.
A digital camera is handy, also, so you can photograph the whiteboard sketches to keep a record of the meeting and either keep the interface ideas fresh in the developer's mind or give the designer a reference point from which to create a wireframe.
To begin the meeting, simply present the problem that must be solved. Everyone should then try to justify the change to the softwareit needs to be determined whether the problem is really a problem by trying to talk yourselves out of it (e.g., is there already a way for the user to do this? Is it the right solution? Does this change help 80 percent of our users?). If the change is not justifiable, the meeting is over. One of the best ways to reduce an application's complexity is to avoid adding anything new to it in the first place.
If the problem really is a problem and must be solved, attendees should brainstorm possible solutions based on the representative user's needs and desires. Everyone can contribute ideas, but the resident user-experience expert should be the one who leads the conversation. JIT Design requires fast thinking, so be sure the person leading this conversation is able to produce design ideas quickly and consistently.
The meeting should not end until everyone has a clear idea about what to build and why.
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, 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 a weak design.
The other time JIT comes into playthe time most relevant to this chapteris when the coding has been completed, as a bookend to the Design meeting that took place prior to coding. JIT Review, as the name implies, is about reviewing what was built to make sure it adheres to what was previously agreed upon and to see how it can be improved prior to release.
In the fast-paced Web world, there is usually very little time to review, let alone refi ne, an interface before it goes out the door, especially if you don't write the code yourself. Performing a JIT Review, however, is infinitely better than doing nothing at all, so try as hard as you can to incorporate JIT Review at the end of every iteration cycle prior to release.
In most cases, a meeting is not necessary for JIT Review (though you can certainly review the solution as a group and decide collectively how to refine it). Once the proposed solution is built and is available for testing by those who developed the solution in the first place, each person involved can simply review the implementation from his or her own desk. This is true anytime even if ample time was allowed for design work earlier in the process.
Each person should try to interact with the solution with the same goals in mind that users will have when using the final product. Go through the interaction once and make mental notes about anything that isn't completely obvious, and then go through it again with the goal of discovering ways to improve it. Make notes about how to refine the solutionhow to make it better adhere to a user's mental model, take less time, and become less complicated and more error-proof.
Stick all the notes into an email or, more preferably, a bug report, and send it off to the group. When everyone has made their notes, a quick conversation is usually enough to decide how to proceed. Make the changes, test the new version, and release it to the world.
One of the best things about the Web is that it's conducive to constant change. An application doesn't have to be perfect the first time. You should certainly aim to present a good solution the first time out, but don't be afraid of imperfect solutions. The second you're done with one version, you can start iterating through the next one. Eventually, each and every part of the application will have gone through several iterations and the application will develop, almost by its own momentum, into a solid application that keeps users feeling confident and productive.
JIT as a solution
With complicated applications, JIT is the bare minimum of what can or should be done.
In simpler applications, however, JIT may be all that's really needed. An application team of only two or three people working in a room together can hold whiteboard sessions freely and often, so design decisions can be made and changed on a dime. (In fact, this can be quite fun and effective, as it creates a fast-paced environment of designing and coding that can produce amazing results in a very short time.)
Whenever possible, a resident expert on interaction or interface design (preferably a good, authoritative designer who's willing to own the interface) should be present, 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 a high aesthetic standard, guided by someone with a design background, can help improve the interactions. Whenever possible, though, your company should have someone on-site with a deep knowledge of how people actually use computers, so he or she can make educated suggestions about how to improve the experience, preferably before and after the coding process.
A user whose goals are ignored is a user who will never be a true fan of your software, and a true fan is the best thing a company can possibly acquire. If you cannot allow time for quality design work, you should, at the very minimum, allow JIT Design and Review to run interference between programmers and users. It may be the best chance you have to design, reduce, and refine an application before your company banks its future on something that doesn't meet the needs of its customer base.