We kind of follow this structure ( I admit its an adaptation of the process of documenting reusable components in software design)

Pattern Name and Classification - A short, meaningful name for the pattern, The names are chosen with regards to the use and application of the pattern and the combination of predefined terms. For example,if the design pattern is an adaptation of a carousal, we might name it as a single left scroller carousal

Screenshots - Mostly high fidelity ones but also low fidelity ones depending on the level of definition of how we feel the pattern would be

Problem statement- A general description of the problem and constraints which the design pattern aims to solve. We normally do this by defining a use case scenario where such a need is there and how users can use the pattern to handle it. The problem statement should provide guidance to assist others in recognizing situations where the pattern can be applied.

Technical design specifications - This is the more technical aspect of it but here we normally highlight the details such as how it was implemented (e.g. Jquery,ASP.NET,web parts) and how it could be integrated into the system and what are the related dependencies (like is it pulling information from somewhere or does it need a certain Jquery file etc.)

Consequences- This is usually an discussion of the results and tradeoffs of applying the pattern. The alternate variations and options are also highlighted

Known Uses-Examples of the pattern in real systems and scenarios where it could be adapted.

If the design pattern is pretty large or has a number of "moving parts", we also create a table which highlights the functionality of each of those "moving parts". The table format is something like this :

A Google search brought up this layout which in my opinion is awesome :

• Name
• Screenshot(s)/working solution
• What Problem Does This Solve?
• When to Use This Pattern
• Why Use This Pattern?
• Special Cases
• Pattern library

Other examples of layouts :

1. Carousel UI Pattern

We kind of follow this structure ( I admit its an adaptation of the process of documenting reusable components in software design)

Pattern Name and Classification - A short, meaningful name for the pattern, The names are chosen with regards to the use and application of the pattern and the combination of predefined terms. For example,if the design pattern is an adaptation of a carousal, we might name it as a single left scroller carousal

Screenshots - Mostly high fidelity ones but also low fidelity ones depending on the level of definition of how we feel the pattern would be

Problem statement- A general description of the problem and constraints which the design pattern aims to solve. We normally do this by defining a use case scenario where such a need is there and how users can use the pattern to handle it. The problem statement should provide guidance to assist others in recognizing situations where the pattern can be applied.

Technical design specifications - This is the more technical aspect of it but here we normally highlight the details such as how it was implemented (e.g. Jquery,ASP.NET,web parts) and how it could be integrated into the system and what are the related dependencies (like is it pulling information from somewhere or does it need a certain Jquery file etc.)

Consequences- This is usually an discussion of the results and tradeoffs of applying the pattern. The alternate variations and options are also highlighted

Known Uses-Examples of the pattern in real systems and scenarios where it could be adapted.

If the design pattern is pretty large or has a number of "moving parts", we also create a table which highlights the functionality of each of those "moving parts". The table format is something like this :

A Google search brought up this layout which in my opinion is awesome :

• Name
• Screenshot(s)/working solution
• What Problem Does This Solve?
• When to Use This Pattern
• Why Use This Pattern?
• Special Cases
• Pattern library

Other examples of layouts : Carousel UI Pattern

We kind of follow this structure ( I admit its an adaptation of the process of documenting reusable components in software design)

Pattern Name and Classification - A short, meaningful name for the pattern, The names are chosen with regards to the use and application of the pattern and the combination of predefined terms. For example,if the design pattern is an adaptation of a carousal, we might name it as a single left scroller carousal

Screenshots - Mostly high fidelity ones but also low fidelity ones depending on the level of definition of how we feel the pattern would be

Problem statement- A general description of the problem and constraints which the design pattern aims to solve. We normally do this by defining a use case scenario where such a need is there is there and how users can use the pattern to handle it. The problem description should provide guidance to assist others in recognizing situations where the pattern can be applied.

Technical design specifications - This is the more technical aspect of it but here we normally highlight the details such as how it was implemented (e.g. Jquery,ASP.NET,web parts) and how it could be integrated into the system and what are the related dependencies (like is it pulling information from somewhere or does it need a certain Jquery file etc.)

Consequences- This is usually an discussion of the results and tradeoffs of applying the pattern. The alternate variations and options are also highlighted s

Known Uses-Examples of the pattern in real systems and scenarios where it could be adapted.

We kind of follow this structure ( I admit its an adaptation of the process of documenting reusable components in software design)

Pattern Name and Classification - A short, meaningful name for the pattern, The names are chosen with regards to the use and application of the pattern and the combination of predefined terms. For example,if the design pattern is an adaptation of a carousal, we might name it as a single left scroller carousal

Screenshots - Mostly high fidelity ones but also low fidelity ones depending on the level of definition of how we feel the pattern would be

Problem statement- A general description of the problem and constraints which the design pattern aims to solve. We normally do this by defining a use case scenario where such a need is there and how users can use the pattern to handle it. The problem statement should provide guidance to assist others in recognizing situations where the pattern can be applied.

Technical design specifications - This is the more technical aspect of it but here we normally highlight the details such as how it was implemented (e.g. Jquery,ASP.NET,web parts) and how it could be integrated into the system and what are the related dependencies (like is it pulling information from somewhere or does it need a certain Jquery file etc.)

Consequences- This is usually an discussion of the results and tradeoffs of applying the pattern. The alternate variations and options are also highlighted

Known Uses-Examples of the pattern in real systems and scenarios where it could be adapted.

If the design pattern is pretty large or has a number of "moving parts", we also create a table which highlights the functionality of each of those "moving parts". The table format is something like this :

A Google search brought up this layout which in my opinion is awesome :

• Name
• Screenshot(s)/working solution
• What Problem Does This Solve?
• When to Use This Pattern
• Why Use This Pattern?
• Special Cases
• Pattern library

Other examples of layouts :

1. Carousel UI Pattern