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 of most users to use the software effectively to accomplish their goals.
As long as this rule 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 when it’s needed the most, which is the moment right after someone has decided to add a new feature and just before the programmer starts producing code. This is especially necessary when the software company adheres to extreme programming methodologies, which create 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 is essential so that at least some intelligent design can make its way into the final product.
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 meeting, at least one programmer, one designer, and one user should be present. While this practice sounds like the ever-ineffective "seat at the table" approach, it generally offers exactly what’s 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 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 only 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 (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 involve 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 may be the best we can hope for. It also may be the best attempt at a remedy before things get too out of hand, and you end up with software loaded with features that neglect users’ needs and wants, making them feel stupid.
A user whose goals are 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 can’t 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.