That said, I don’t keep a design pattern library of my own.
In fact, I rarely ever refer to my own document library, unless I’m referring to documentation for a project that’s currently in specification or build phase. I put all my old documents into Devonthink, so I can easily search for specific information, but I rarely use it.
If I’m working on a larger project, or a mature site that is built out of modules, then I maintain an active wireframe document of pre-made modules and widgets. But this kind of UX work is primarily production work and maintenance, and doesn’t really reflect the problem-solving nature of most UX design work.
It occurred to me that unless you’re maintaining a massive software project or training new designers, maintaining a pattern library and keeping track of copious UX design resources is often just busywork. That material is more useful when it’s in your subconscious and in your team’s shared understanding, not in your documents folder.
If you’ve ever had to rewrite an essay after losing your first draft, chances are that you wrote a lot faster and economically the second time round. The structure of the essay is in your head, but you’re not bound by the structure on the page. Some writers do this on purpose — after writing the first draft, they stick it in a drawer and start afresh.
The urge to copy and paste from old documentation is strong, particularly when you’ve worked similar solutions before and you’re under time pressure. But chances are that if you sit down with a blank piece of paper and a cup of coffee, you’ll come up with a better, more efficient solution.
I recently referred to my library for an earlier version of a relatively small project — an on-pack code-redemption mechanic for a giveaway promotion. Upon reading the earlier document, I realised that I could specify what I needed with three wireframes and a flow diagram. The earlier document had pages upon pages of use cases and data tables, none of which were necessary. By using conversational definition language, and ensuring that the developer understood the project, we were able to build the site quickly and effectively.
We often fall back on documentation to protect our jobs and to buck pass, when shared trust and responsibility is more efficient.