Castle UI is an evolving design system project with the goal of aligning the overall user experience across Moody's Analytics KYC OU. The core system is maintained by the UX Team @ PassFort but contributions are welcome and encouraged from all.
Castle UI provides an extensive library to be used as the foundation for new product experiences and to build new components for any use case. The components we feature in Castle UI are built to be general-purpose.
Creating your own application style guide
In some cases, it will be necessary to create a component or pattern that is unique to the product you're working on. For these cases, we would recommend you set up a local application styleguide.
If you think a component or pattern within your product's application style guide could be promoted to Castle UI for more general use, take a look at the criteria below:
Adding new components
Designer guidelines
To contribute a new component to Castle UI the first thing to check is that the component or pattern will be useful and unique:
Is it useful?
Evidence that the component or pattern would be useful for many teams or products. Evidence could be screenshots or links to versions in different products, for example.
Is it unique?
Check that we do not already have something similar in Castle UI. If the component or pattern is to replace an existing item there should be an obvious improvement such as more supported use cases, improved accessibility or usability etc.
If the above criteria are met, check these things:
Is it usable?
The component or pattern should be tested in user research and shown that it works with a representative sample of users. If there's not enough research yet to show that it's usable, it can still be published as "beta". But it must be clearly based on relevant user research from other organizations or best practices.
Is it consistent?
It uses existing styles and components from the design system where relevant. The guidance and any content in examples follow the content style guide. If there is code, it follow the PassFort coding standards and is ready to merge into the design system.
Is it versatile?
The implementation should be versatile enough to be used in a range of different products. eg, a date input component could be set up to ask for: a year only, a month and year only, a precise date, any other combination. The component or pattern has been tested and works with the documented range of supported browsers, assistive technologies and devices.
Is it accessible?
The component should conform to Web Content Accessibility Guidelines (WCAG) 2 Level AA and support all human languages available in our products, including any RTL requirements.
As part of the submission, a Figma-designed version of the work should be included. Figma components should include full state management and be built into the Castle UI Figma workspace to allow other designers to use it.
Developer guidelines
Here are a few developer considerations to make when adding a new component:
Is the component already in our roadmap?
If so, you or your team may decide to work on it. Contact us [Insert contact method] to arrange a handover, as we will have additional context and requirements.
Does it have a docs page?
Check the developer getting started guide for a step-by-step on how to make a docs page for a component. This guide can be found in the README.md of the Castle UI repo.
Does it have tests?
Components that have complex built-in behaviours or states should be unit tested to document their functionality.
Does it define its theme with useMultiStyleConfig?
Please refer to the component style docs on how to create component styles using the style config API.
Does it have necessary accessibility props? (ARIA)
Read WAI-ARIA Authoring Practices 1.1 to find the relevant authoring practices needed for your component.
Feature requests
The core system is maintained by Alex White at Moody's KYC. If you have any general feature requests or would like to see what is coming up on the roadmap, visit our Canny.io