Some observations based on prior experience with pattern libraries (this is from 2011, in reference to a specific project, but is still widely applicable & current):

• Frameworks are related families of patterns. Some aspects of our framework: responsiveness, touch interface, limited multitasking.
• Patterns are generic solutions to problems.
• Components (nouns) & interactions (verbs) are specific applications of a pattern.
• We need not write all our own patterns. There are a lot already out there on the web.
• Consider anti-patterns (Bill Scott @ Netflix has a good presentation on anti-patterns).
• My hunch is that we will have more interactions than components.
• An embrace of agile methodology helps:
  • Avoid documenting a pattern/component/interaction before you need to (i.e., there are one or fewer instances in the product).
  • Even when it appears twice, think hard before making it a component.
  • DRY (Don’t Repeat Yourself): avoid having things in more than one place, where they can easily fall out of sync.
    • Document components and styles directly in the code with comments (?)
  • Don’t worry about organization, taxonomy, etc. until you need to.
• Visual style guide: start with a “specimen” page (in the source), with sample components, linked to the same stylesheets as the product.
• CSS won’t directly reference the components, but rather the smaller “Legos” they are made of.
• Consistency vs efficiency: Be efficient. If we’re inconsistent, everyone will know (and will tell us).

The first thing we should do is inventory the repeated components & interactions we have already (esp. the inconsistent ones!).