What I mean when I say design process

There have been a few times when I’ve challenged my design colleagues with defining our design process only to have a couple people come back with concerns about being too prescriptive and that process might hinder their own style and methodology.

Even the word process can result in a reverberation of fear that someone will micromanage us and tell us exactly what to do – checking off a list of design tasks in a specific order. Also unnerving is the thought that you’ll be forced to use a specific design tool set and discouraged from trying out new programs or frameworks.

I can certainly understand this reaction particularly if you’ve endured micromanagement in the past and especially if you’re winning with your current design approach within your company dynam(polit)ics which usually takes some time and effort to have mastered.

Classic UCD cycle, intended for more than one iteration

Rest assured that when I say design process, I’m referring to a loose, but comprehensive framework that specifically takes into account time and space for strategy and research should you think these phases are essential to your design thinking and decision making down the line.

We’ve all seen these visual descriptions of the user centered design process, yet it boggles the mind when teams habitually ignore the full spectrum of design activities. Omitting them can potentially set you up for failure simply, because you won’t have all the necessary information needed to inform great design decisions. It’s hard to understand indifference to something that seems so important to the product’s success and sometimes you’re left to fight off the feeling that design is not integral, but incidental or somehow marginalized.

Call it what you will: process, phases or flows

Here’s another example of what I mean by a user centered design process in the event that the work scope requires UCD .

Design is a series of activities. – I forgot who said this