Process, procedure & methodology

This entry is also posted at the Little Springs company blog. If you feel compelled to comment, I'd do it over there as its quite a bit better read. Interactive design is exactly like making a pizza No, its not. At all. Its also not at all like building a house. Or changing the tires on a car at 60 mph. Or any other favorite analogy your leadership has used to describe the situation. Sometimes, this analogy work goes quite a bit too far. Inappropriate analogy – or blindly inherited process – encourages inappropriate process and methodology. Houses need blueprints, then foundations. Do websites? I think that considering design and code to be “construction” leads to incremental approaches and a misunderstanding or misapplication of iterative design, for one example. Its time that interaction design (and software development) comes into its own, and can be understood without arbitrary analogies. To that end, what is a design process and how can it be applied to design work? Process – Making the business work Process is about business practices. How to get business, how to account for time spent, how to assign people and so on. Some of these will be performed by the design team. You are likely to have internal staffing processes, for example. However, since they are about internal functions, not design, they are business-oriented, and are process. Processes are also enterprise- or product-wide. Everyone has to abide by the same process or it won't work. If a strict set of rules can be applied, but the result will change over time, or as internal conditions change, it's a process. Think of scheduling new work; any designer (ideally) should be able to do the job as well as any other. Which one is assigned is dependent entirely on workload, scheduling, and generally internal and transient conditions. The conditions of the designed produce have little or nothing to do with it. Procedure – Working with others Collaboration requires everyone be on the same page. The quickest way to this is to make sure everyone does their job, and communicates, in the same way. The difference between process and procedure is that “doing stuff the same way” part. Procedure is needed for any workgroup large enough to warrant a process. Not only does the process need procedures like paperwork and meeting times, but each functional team will have them. The process for design teams will include artifact creation styles, storage, sharing and other collaboration-related functions, within the team, with clients and with consumers of your design work. Other departments will have their own procedures, by the way. Work within yours, and be aware of others' but try not to confuse them with process. Methodology – How you design The manner in which you work is a method. When this is repeated and codified and applied uniformly it's a methodology. Since we're talking about design, methodology is about activities and artifacts directly related to the design work. Good methodology is about designing well. Since this is our field, I can go on for weeks about design methodology , so I won't do that. Yet. Your next steps Internal process, procedure and methodology are easy. Everyone in the design organization should believe the same things. The hard work will be with the other groups, the clients and the developers. Build your relationships and sell them on the right process. Keep in mind:

1. There are good processes and bad ones. Push for recognition of which process is being used, and for using the right one.
2. Get the terms right. Know what you mean, know that everyone understands you, and make sure they know it well enough to explain it later. Likewise, if there's any question about others' terminology, ask for clarification.
3. See what happens. Once a product has launched, did the right thing come out the other end? Either way, why? Find root causes and implement fixes. Don't let everyone skip this step because they don't want to be confrontational or just want to move on. Otherwise, nothing will get better.