Creating patterns is an interesting process in itself. If a team is building a unique and individualized experience for a single app or product, it makes sense to determine a direction, solution and voice for that particular product. However, if a team is building a suite of apps or a system of products that will work in concert with one another, it is smart to put as much effort that can be afforded into a pattern library.
A pattern library can be defined as:
a resource of various layouts, components and elements that use the same visual language and follow a set of common principles.
This resource provides definitions as to what a particular layout, component or element is and guidelines for where and when these components should be used, as well as, how they can be implemented. In the best scenario the catalogue presents a holistic understanding of all the elements from a very high level, but also provides low level details for the specific elements, if that is what is needed.
Patterns can be discovered through a "Top-Down" or "Bottom-Up" approach. These methods could also be called, Manufactured or Organic.
The "Top-Down" or Manufactured method
A team will look at many real use cases and scenarios and determine some common guiding principles, interactions and visual treatments that as many possible use cases can share. This can mean that a team will expend some upfront effort discovering, defining and documenting the patterns that are found. Typically this method will be most appropriate for a system redesign process or new product design process where there are multiple products being designed at the same time.
The "Bottom-Up" or Organic method
An organic approach requires less of an upfront effort to discover reusable patterns. Using a much less documented set of standards to inform the design of one product or small feature enhancement to an existing product. The team attempts to bring clarity and uniformity to the various individual projects that are going on. Where over time, products are starting to look and behave in the same manner. They are starting to speak the same language. It is an ongoing and much more fluid process. I would argue that this method, although nimble can present some difficulties. It can appear that not very much is changing because the changes are occurring in smaller instances. If a team is poor in documenting the concepts or visual language being used to design their enhancements and projects it can feel like extra effort is being spent on modifying the one project so as to harmonize it with the endeavors of other teams. There is an innate lack of perspective with this method by design. This is what makes it somewhat faster when it comes to the individual projects and efforts but slower when it comes to producing multiple products that appear and interact the same way.
Obviously a team can potentially use both of these methods together. The ultimate goal of creating a pattern library is to develop a common set of principles and guidelines that will enable faster design and development while working more efficiently by not having to start from scratch with every new project or enhancement.
One by-product of using these methods could be a GUI Kit that can be used by designers or product managers to create consistent mockups for developers. Another potential and possibly more valuable by-product is a code repository of the html semantic, styles and scripts required to implement the patterns that have been designed. By having a GUI Kit that matches the code that will be implemented both conceptually and practically many barriers are removed and the less time it will take to get from concept to code, making it possible to act nimble and respond much quicker in an economy that requires relevance and progressive values.
Specs & Docs
Specs and Docs are exactly that, specifications and documentation. Usually these words are associated with more of a waterfall interaction between the business stakeholders, designers and development, where needs, concepts and solutions are thoroughly documented by each member of the team and passed to the next team and the next team and so on. This method usually means the solutions implemented address the needs of the past. I don't need to express the value of agility in product design and development. Of course it is valuable to capture decisions that are made throughout the process and provide some form of specifications to assist the collaborative process. If a pattern library is used, a team won't need to stick annotations all over the mockups to present developers with the font sizes, contai