Project Design Logs
Every decision regarding a project affects it’s course. As projects progress, design and development decisions are made. Each decision is like a fork in the road, that led you here. As time progresses and vendors change, the decisions made are only known to those people involved at the time. What if we could capture things as they happened?
Why A Project Design Log
As work progresses on a project, we make decisions. They’re based on multiple constraints – skill sets, expertise of subject matter, capability of technology, technology availability, costs of technology, and project budget. As these factors change, opportunities present themselves to re-evaluate the state of things. Smart phones weren’t all that smart until the iPhone came along. The state of browser technology from the late 1990s, is neolithic by today’s standard. Responsive Design, Flexbox, and browser access to device APIs are all game changers. They provides new opportunities to change the way we create. The presence of new technology provides new challenges as well, particularly as we try to bridge the gap between the old and the new.
People are a significant factor. Each person has a contribution to make, bringing to bear their knowledge, experience, intuition, perspective, and style. As the mix of people changes, some doors close while others open. The pool of knowledge diminishes as people leave the project, while people joining are blank canvases. Knowledge needs to be retained – not just before people are about to leave, but while the decisions are being made.
What Does An Ideal Project Design Log Look Like?
An ideal project design log should answer a few different questions. As a new project member, what do you want or need to know? What decisions have been made? what were the criteria for the decisions? As an current member, what do you wish new people could know?
One related idea is a changelog. This is a file that is maintained by software projects, to tell the user what has been added, removed, or improved in the latest version. It retains the notes from previous versions, so you can see the progress of the project over time. However, a changelog only captures the result of the work. Where a project design log would differ is that it captures decision points in the design process.
Time
I do think there are a couple of pieces of content a log should have. Knowing when a decision was made can be important. Capturing at least the year and month can help determine the mindset of decision makers. A browser technology issue will be evaluated differently between now and 5 years from now.
Objective
A good project design log is written in an objective tone of voice. It’d provide information about decision factors without bias, as well as the result of the decision. There would be enough information to explain the thoughts behind the decision without being too verbose, or too time consuming.
Easy To Maintain
People get busy, and time is short. This needs to be kept in mind. If it’s too hard to update, people won’t do it. Part of this means reducing barriers. Having to create an account to yet another service can be a barrier. Things that require some technical skill can be a barrier. Git would be great for a team of developers, but project managers and the non-technical marketing person probably won’t even try to contribute to it. Dropbox or Basecamp would be good options. A key element is to keep it close to all your other project documentation.
Accessible
Accessible is meant in both senses of the word. The popular sense, which usually means available. In the universal design sense, it means anyone regardless of their ability can access, understand, and edit the document. Anyone in the project should be empowered to update the document. Assigning a single person to be the scribe creates a single point of failure.
The popular sense usually means it’s located on a server, probably a website or through a service like Basecamp. It should be readable and writable by everyone. Email is a bad option, because only the people on the thread can use it. It’s not easily discover-able by new members. It’s also difficult to have a single source of truth. As people edit the document, you don’t want to have to wonder if you’re updating the most current version. Everyone on the project should be able to read and update the project design log.
The universal design sense means the data format should be easily read and updated by anyone, regardless of their abilities. Plain text documents like Markdown and HTML make excellent formats. They can be read by screen readers, and manipulated by a large number of tools and applications.
Conclusion
This is just the tip of the iceberg – far from being complete. These are just some of the ideas I’ve been thinking about. I haven’t tried it yet, but I want to. There’s a lot of value in creating a project design log. If you create a project design log for your next project, I’d love to know how it worked out. Given that I’m only bringing up the idea now, it’s gonna be a while before some results are possible.