Ghosts: invisible specters often thought to be trapped between worlds, left to torment the living or act as a messenger from the beyond. They invoke fear because we can’t touch them, can’t see them, and we don’t fully understand their existence—much like the mysterious design decisions that often haunt your product.
Constraints drive and shape the design of any product. They are the foundation of a good decision-making framework, allowing multiple people to work in unison with a shared understanding. Constraints enable teams to rapidly iterate and create multiple scenarios or designs to solve the problems at hand. Eventually, constraints can give birth to a set of design patterns, components, interactions, and even shared vocabularies that become the building blocks of your design system.
Sometimes constraints are codified in some internal document on the company intranet (or maybe Google Docs). Sometimes they are printed out and hung on walls. More often than not, constraints are shared like most history: word of mouth. And while you can see them in various comps or wireframes, their reason for being is often not documented or clearly articulated. What you end up with instead is the classic “we’ve always done it like that” explanation.
This doesn’t seem like a terrible problem on the surface. However, as a project goes on and more people get involved, decisions continue to informed by constraints that existed at one point in the process but either no longer exist or have changed in such a way to be virtually unrecognizable.
Fortunately, there are a few things that can be done to avoid these ghosts from haunting the development of your product.
The first, is to hold regular design reviews that include a quick refresher of the design principles and constraints. This will get everyone on the same page and any confusion or misunderstanding can be addressed at this point. Throughout the review, the single best question we can ask is “Why?”
“Why are the labels verbs?” “Why are we using a :hover state for this information?” “Why is our grid laid out this way?” “Why are we using that color?” “Why is this flow six steps?” “Why don’t we display information about ______ here?”
Everyone of these and a thousand more are absolutely valid and important questions to continue to ask—even if you have answered them before. Asking “Why?” forces us to think through how we arrived at this current solution and why it continues to be the most appropriate solution. A designer may be using components that have been developed throughout the design process, but if they cannot articulate why they are using them and why the pattern exists, there is a good chance the design will eventually topple like a house of cards.
The second solution involves augmenting your existing design process with something I like to call “decision notes.” Decision notes are simply an annotation of why certain decisions were made and how they were implemented visually and interaction-wise. Many teams use some sort of wireframe/early-design process and do indeed annotate these with precise specs for layout, padding, behaviors, etc. Rarely do you see any documentation of why.
Admittedly, doing something like this in Photoshop or Fireworks seems very tedious. Not to mention that there is a huge barrier to entry and the updating process is rather laborious.
The great news is that more and more design and user experience teams are beginning to adopt a “prototype-first” approach and build wireframes with HTML and CSS. The practice of commenting your code is a fairly common and is an easy way to help others quickly understand how things work and relate to each other.
This seems like the perfect vehicle for Decision Notes. For example, you could annotate your HTML and CSS with something like this:
/* =Decision Note
What: navigation pattern
Who: John McDecisonguy, Thom Leadhoncho
When: Jan. 2, 2012
Why: we want one navigation pattern across all of our content sites in order for our users to have an instantly recognizable way to find what they are looking for.
*/
You can take Decision Notes as far as you want to. If you are using Git or SVN, you have an automatic history of any changes to the decision. If you are savvy with Javascript, you could whip up a little Decision Notes Viewer that could be toggled on/off for certain elements that have Decision Notes associated with them.
While this method requires a little more effort, it will actually save designers, engineers and others time and headache by eliminating the confusion around why a decision exists.
In order for us to earn our Ghostbusters badge and stop the haunting of decisions past, teams must take more responsibility to capture the “Why?” behind the design decisions that are made throughout the evolution of a product. In doing so, we eliminate finger-pointing and responsibility-shirking, create a deeper understanding across the team as to why things are being done a certain way and hopefully eliminate exceptions that lead to wasted hours for designers and engineers.
