Design frameworks define the fundamental patterns, workflows, architectures and and layouts that comprise a product. Frameworks provide system coherence and allow for efficiencies in the building of products (consistency in design patters, makes it easier for developers to leverage code from one part of the product for another). Frameworks can be be the product of intentional, rigorous effort, or the outcome of organic growth and development.

Well designed intentional frameworks have tremendous strength and flexibility. Often they allow for a huge number of variations in workflow and make it easy to extend a system with features and functionality not conceived in the original design.Organic frameworks tend to develop significant drift over time. Pattern application is inconsistent and expression of features varies because each is a custom design solution.

Understand your design framework; If you can’t start with an intentional framework, iterate toward one

Organic frameworks with significant drift should be considered technical debt. They prevent extensibility and often require significant retooling of code, paying down technical debt in order to build  new features. Early versions of products can be released without too much concern for the framework, so long as you’re willing to adjust code as the organic framework reveals weaknesses.

Intentional frameworks take time to design and refine. Seemingly simple decisions should be explored for their downstream impact. Exploring the way the system may need to grow in the future helps you make necessary refinements to your initial design. The results of this work are frameworks that support extension and set product trajectories with long arcs. The well designed intentional framework ages elegantly.

Strive to define and maintain solid intentional frameworks, but recognize that many times you’ll start new products organically and must iteratively, over time, bring coherence to a framework. Other times you’ll need to compromise a framework; either by making quick, ad-hoc decisions without time for forecasting their impact, or because business or technology constraints constrain the ability to meet your design. In these cases document the compromise in a design backlog. Form a hypothesis about the effects of making the compromise and test it. Seek to understand if the deviation is a positive evolution o of the framework, or compromises its integrity. Rigid adherence to a framework isn’t the goal, you always want to be testing, exploring and seeking to evolve the framework. But you don’t want to negatively disrupt the technology or business in this process.