Design as a Cognitive Process – Diagrams and Code

I recently read Robert Glass’s post on design as cognitive process. It got me thinking about how I do design in my head. I must clarify that by the term design I mean a small design and not the BDUF.

In his article, Robert mentions four basic steps that form the essence of design. I will try to relate those four steps as they relate to my process of design.

Step 1: Constructing a mental model of the proposed solution.

The design palette in my head is certainly not a whiteboard. However, I do use the physical whiteboard a lot( or a design card or simply a scrap paper) to sketch out initial ideas. This is most common when I do not know a prior solution to the problem at hand. There is not much “whiteboarding” going on inside the brain. Robert Glass refers to a “mental model” of the problem. For me, this is outside visible on a whiteboard or paper.

Step 2: Mental execution of the model

Now comes the meaty part. This is the stage I call thinking in code. The brain projects a text editor up onto its projection surface. I imagine pieces of code ( usually in some neutral C like syntax) written up in the text editor. Immediately the questions start flying inside my head. At this point, the diagram that I drew up, is mentally subjected to validation. The design could either prove viable or can crumble after this exercise.

In other words, my brain is not running an animation of a diagram with messages flowing back and forth between boxes. I am actually writing code in my head, imagining interfaces, thinking of exception scenarios, trying to come up with gotchas.

During this cognitive process, I am constantly aware that I could be missing or overlooking some important detail and the levies of the design are going to be broken by the tiny streaming details.

Step 3: Find the problem areas and enhance the mental model

At this stage, I go back to the whiteboard and try to repeat the step 1 and 2 in order to fix the problem areas. However, often I find myself going to step 4 soon after step 3.

Step 4: Evolve to a team model

In a team setting, this would be followed by a design discussion with the peers, where inevitably the team will manage to poke holes in the proposed solution. At this point, the design in hand could be kept aside to look for alternative ideas.

This entry was written by Amit, posted on October 21, 2005 at 11:48 am, filed under Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.