We’ve recently rolled out the second version of our internal design process wiki which documents our process and deliverables. So we thought it was appropriate to give it some time in the spotlight, and talk a little more about why we redesigned it, how we use it to work more efficiently, and some of the unexpected benefits.
Why Redesign?
Answering that question would become one of the most important throughout many parts of the process. Before we set out to update the existing design process wiki to better reflect our process, our documents, and our history using them, a bit of research was needed to figure out where the current wiki could be updated. It also served as a primer to get me up to speed on all things design pattern related.
First up was Michael Mahemoff and Lorraine Johnston’s paper, Principles for a Usability-Oriented Pattern Language. Their paper points out one of the overarching principles of any design pattern; context is key. Without it, a pattern library would just be a collection of designs without any sense of how or why to use them. Context is kind of like the sport pepper, tomato, and neon relish. Without it you still have a hotdog that I guess you could eat, but with it – it’s crystal clear why you should eat the delicious Chicago style dog in front of you. Context makes it complete.
Second up in the reading queue was A Pattern Language: Towns, Building, and Construction. One of my personal favorites in the bunch, each pattern presented isn’t isolated, it’s connected to the others as a whole, as a language almost a “build-your-own” model for design, which lends itself extremely well to documenting a design process since so many parts are interconnected. .
While reading through The Design of Sites, the themes inherent to any good pattern library started to become clear. The book takes a slightly more visual approach which is very helpful. It’s filled with a mix of both real-world examples and solutions, and simple wireframes to keep it useful and straightforward.
After taking a look through the paper, design patterns, the books, and some other design pattern libraries, the take home messages for how to modify our wiki started to become clear.
- Context is key | Without context, the whole is not the sum of its parts. It’s just parts. Context is the driving force behind any pattern. If “Why?” is the question, context is the answer. When everyone says that “content is king”, you can tell them it’s actually context.
- Identify relationships | Highlighting where connections exist as well as how the pieces all fit together helps inform context. Identifying where activities and deliverables fit in the overall Fuzzy Math process goes after “When?”, in the pattern library layout.
- Pictures please! | Adding a bit of visual interest again aids context, and at the end of the day is a bit easier to digest when you can see an example or two of what the document might look like.
- Instruction manual | Providing details on “How” to use a pattern is critical. A roadmap of how to execute a deliverable ensure you can do just that, not just know when and why to use it.
Patterns a la Fuzzy Math
So how did we update our design process wiki you might ask? The time has come, here we go! One of the main goals of the wiki from the outset was to better document our processes and the documents that come out of them. Whether to get a new employee up speed on the Fuzzy Math process, getting a refresher on a particular process or deliverable, or starting a new project, documenting the context of our process and deliverables helps to identify the Fuzzy Math “way” for each one, and any overlap that exists. Understanding why we do what we do ultimately creates a better experience for the user, by letting them be the focus, not document set up.
Using that overlap, we started to build out a set of templates for documents that we are creating regularly, in order to spend more time in process and designing, and less time sifting through past projects looking for similar deliverables to hijack. Combining the power of “why” from the wiki for all of our documents and processes, with templates for regular players (the “what”), the result ends up being more time spent on creating solutions for clients and their users needs and less time on all the fiddly bits of document setup. Our next goal is to focus on using the wiki to document what processes have worked well and where there room for tweaking, based on feedback from clients and first-hand experience.
While it wasn’t necessarily a goal from the outset of the wiki, the taxonomy we came up for the wiki navigation trickled down to our project folder structure, with both eventually becoming part of the same project. The modular approach it created for project setup again, saved time. Even recently the same taxonomy, which continues to ebb and flow with new approaches to certain deliverables and technologies, is working it’s way further into our project management setup as tasks in Basecamp.
At times it’s been a true labor of love, documenting the Fuzzy Math process and deliverables on the rails of a pattern library has ultimately left us more time to focus on solving users’ needs. We use our wiki to understand how and why to use our process, and what documents we should produce. All in support of creating great user experiences, recording our experience with the process, and spending a bit less time searching for a file. On top of that it’s streamlined our project file set up, and will soon be used to better track workflow on projects. Better yet, comments from the Fuzzy Math team will help teach the rest of the team and continue to make sure our process is spot on. Who knew a wiki could be so powerful?