It worked in my head

It started with a tweet from Dan North:

So I’m writing a doc to help think about the shape of a new app. So far 3 moving parts with responsibilities. This needs a word… design?

— Dan North (@tastapod) July 26, 2012

@karianna Using a whiteboard too. It’s a README, so I’m writing to a user describing how to use the app. It’s causing me to simplify it!

— Dan North (@tastapod) July 26, 2012

This triggered a discussion on the nature of architecture versus design, to which Ruth Malan contributed, linking to one of her journal entries (which has inspired another post I have queued up to follow this one). My first takeaway from the discussion, however, was a tangential one: beyond their value in communicating decisions, design artifacts serve to assist in making those decisions in the first place. Rather than being just an output of the design process, they can serve as an input as well.

Dan North’s observation that writing the document describing how to use the application was causing him to simplify it should not surprise. I’ve often found that writing up a problem allows me to get out of my head and see it more clearly (I can’t count how many unsent emails/unposted forum comments have resulted from this). My first sequence diagrams were put together for my own use, to ensure that I understood the interactions involved in code I was working on. Writing and/or diagramming forces you to organize your thoughts and makes it more difficult to gloss over issues in your design.

Terry Bunio’s latest post discusses using visualization to design a data warehouse. These visualizations provide a powerful tool to both define and refine the design as well as communicate it to customers and development team.

The use of visualization in this manner isn’t restricted to design. One of the tenets of Kanban is being able to visualize the process. This visualization forces issues into focus, rather than allowing them to hide in the background noise.

Most of those reading this should be familiar with “but it worked on my machine”, indicating that the developer likely failed to do the due diligence required to make sure his/her code deployed correctly. Using design artifacts to organize and visualize your design makes it easier to evaluate. After all, you don’t want to be in the position of saying “but it worked in my head”.