Community of Practice

Sage exists to help ensure that designs and developers have a common language for ideating, prescribing, and building exciting features for our customers quickly and with great precision.

In order to facilitate conversations and collaboration between Designers and Developers, we hold a regular sync session where all folks interested can meet up to share work in progress, ask questions, and settle on new directions. Here are some examples of things we love to work on together:

• We need to tighten our consistency in handling a given pattern in Figma; how can our work in progress come together to best meet each use case?
• We have a new component in our designs that needs to be added to the code base but need to consider how it relates to existing components, and what impact its addition could have on the system.
• Our Design team identifies a need for substantive updates to a core feature: how do we best design the updates and implement them safely in the system and then work the changes into the production application?
• One of our UX Developers has an idea about a technique to use to improve some aspect of the codebase. Together we can evaluate the idea and discuss next steps to carrying it forward.

Our overall goal is to have an open platform for collaboration around a stable and relevant design system. Now for a little more background detail.

How it was built

So far, we've fleshed out as much of the core design aspects as needed as well as built an initial library of common components. These are built with precision and scalability.

How it is changed

Product designers are encouraged to think openly about the best use of the system and to both design within its constraints as well as to challenge those constraints for the delight of our customers. When changes are needed or new ideas emerge, the Community of Practice is where we get together to air out the ideas and determine next steps. Changes proposed must be carefully built by UX Developers in conformity with the other practices in the system so that they can be implemented reliably by application developers.

UX Developers are encouraged to contribute to Sage. Yet, this must be done with care and the collaboration of both other UX Developers and the Product Designers. No components should be added without the explicit request and/or buy in of the Product Design team, and PRs should ideally be reviewed by 2 or more UX Developers. The code review process to contribute to Sage is as thorough if not more thorough as it is to get code into Kajabi-products main repo. This is because components must fight to be included. By design the system should be streamlined to make the overall feel of the application consistent and easy to use.

How it is documented

Any additions or changes will only be useful if they are in some fashion exposed to those who will use the system through one or more of the documentation platforms. Therefore, any such work should always find a meaningful way to be acknowledged if not evidenced in one of the public-facing aspects of the system.

The power of the system is only as strong as our teams ability to consume it, so in-depth documentation is essential.