Continuing from the first part where we have covered how xOTB acts as a "single source of truth" to facilitate consistency in UX across products, four important pillars of xOTB and basics of "product centricity" in xOTB - in this part, I shall deep dive into a workflow centred around components.
The xOTB library workflow is a circular flow strengthened with solid feedback loops between xOTB designers, developers, and application developers.

Design
The first part of the workflow is the design. Here, the designer will start off by designing just one part of the user experience. They still keep in mind the context of their application as well as the components that are available in xOTB. This will often start with some hand-drawn images of a specific action of a specific experience, such as adding things to the cart. As the application design materializes, the designer breaks it down into composite parts which are nothing but components. From there, there can be an in-depth discussion of which components are application specific and which ones can go into the design system, like the controls (buttons, selections etc.).
Ideate
The UI developer and designer work together to isolate the core components for the UI, which allows the team to elaborate on the behaviors, structures, and appearances of these elements. Every component is to be seen as an independent entity that is isolated from the original design and fits every context and yet be very much connected to the design as a whole. This allows for a new component to be accounted for and coded.
xOTB designers and developers deliberate on plenty of aspects that need to be considered for each component to be qualified as a core component; such as how a component is styled, its interaction behavior, accessibility, and responsiveness, among others. This discipline is aimed at constraining scope, driving out unnecessary functionality for the core component, and making it extremely focused and generic.
Develop
Once the team has agreed on a specification, the xOTB developers will start building the core component as the Angular component. These need to be flexible enough to be integrated in multiple places, hence they ensure no business logic goes into them and they are as application-neutral as possible. These core components expose critical application programming interfaces (APIs) so that application developers can access and customize and hook them up with the application logic.
Leverage and Learn
These core components are then published to allow the application developers to use them in their application, creating more complex components and UI as a whole. The application developer’s focus shifts to composing the core components in different contexts, customized to deliver business value. Their feedback on core components is fed back into the design system so that the library always remains updated and error-free.
As new components are created by application developers, they are also put back into the design system to be used again if they qualify as core components.
xOTB Builder
The Builder is a low-code platform that provides a way for non-technical people to create UI using a convenient drag-and-drop builder and xOTB core components.
Select from as many core components as the xOTB library can offer, configure, and discover all the built-in choices available — and then export the code in Angular to use in your app! Core control encompasses form controls, grids, calendars, and input controls.
xOTB Resources
The tool acts like a wiki for xOTB owners and clients. It hosts additional documentation and tools to help one make the most of the xOTB design system. Ranging from documentation to Q&A, API references to samples, designers and developers can access everything they can work with, learn about, and contribute to, in xOTB.
Since every element in the xOTB design system is documented in ‘Resources’, it lessens the amount of rework considerably. You don’t need to reinvent the wheel, when you can see all of the wheels in your project at a glance.
xOTB is highly modular, scalable, and useful, giving designers and engineers the benefits of increased efficiencies, faster go to market, and better business value. A product team now doesn’t have to reinvent the wheel but can quickly customize the system to suit their needs and start leveraging it immediately. While xOTB offers the necessary infrastructure for designers and developers to build consistent experiences across the application(s) through a common language, there will be struggles in the process. For e.g., there are two sources that were used to create the application: original artifacts found in tools focused on design, like Sketch; and the Angular Library. These are two sources that are still very much in conflict at times during the overall application design/development process.
Like all life forms, a design system advances through an iterative handle and is like a living archive. Testing and feeding xOTB the inputs, both from the xOTB team and from its clients, makes a difference in its long-term relevance and significance. By providing solid governance and valuable feedback to xOTB, EDGE is committed to increasing the efficiency and speed at which ERS can construct delightful experiences for clients today and in the future.
References