Design processes are often illustrated as continuous loops. Personally, I have not experienced quite a linear process. In fact, it’s pretty chaotic and messy and ugly. All areas of process overlap each other and, depending on the person you are, there’s a different process that works for you. Some start from the foundation, some start with the details, and others bounce back and forth between the two.
I have seen designers jump right into prototyping and use that for discussion. They design elements and requirements from some ambiguous idea with little direction. Then, they continue to iterate on the design by “jumping forward” in the conventional design process. They make sitemaps in their head just to define the hierarchy of the interface, without explicitly documenting. They use their initial attempt as a stage to fail and succeed, breaking apart their designs and gluing the best pieces back together.
I’ve also seen designers try to understand the big picture and where a product is going in the future. In order to tackle how they get there, they need to know where they are going. They start with sitemaps, concept models and very abstract representations — possibly off-the-wall metaphors. The farther along they get, the clearer the concept, and the shorter the feedback “loop.”
There’s a process that is also shaped by an environment. Not everyone is sold on conceptual models. Sitemaps might illustrate the architecture of a product better to one person than another. In this case, a designer might find themselves jumping back and forth between the official “levels of design” — see below. Why? Because the chemistry and mentality across their team isn’t the same. On the other hand, if your team thinks the same, you don’t have the greatest variety of perspectives to inform the best solution.
Process is not a line, loop, or piece of cake — pun intended. Why? Because users experience all parts of an interface as a whole— see below. Not every company is proactive enough to allow time to make requirements before jumping into defining and designing an interface, especially a start-up style company. Often, designs inform the requirements. It’s not a bad thing, it’s just how processes work sometimes — agile. Requirements exist, they are forgotten, left out, brought back, or added later. The process is often whisked away in the ungraceful, implosive act of iterations and never to be looked at again.
Process is more like a series of dead-ends in a consistent battle to reach a location further and further in the direction of success. Another way to look is that it’s a big net, and all the paths intertwine to form a strong foundation for a great product. Is process something you can look back on and see your entire journey for all the failures that you were tangled in, escaped from, and improved on? You decide!