The fact is that these tools and methods often address one side of the dilemma – either design or development. As a result, design and development fall apart creating a huge gap in between them. And in the center resides a one-way hand-off that needs consideration for both sides.
Introducing xOTB, or “xperience Out of the Box”— comprehensive EDGE design system inspired from atomic design. It imbibes the best from both worlds— style guides from design and thinking from modern UI development to enable both the paradigms through a component-oriented approach with a seamless hand-off mechanism. xOTB acts as a “single source of truth” that brings consistency between designers, developers, BAs, and product owners, and promotes cultivation of a platform to share assets, examples, and best practices with EDGE developers and designers globally. If you plan to craft a modern web experience, you can quickly customize an xOTB system to suit your needs and start benefiting from the out-of-the-box features.
Principles of xOTB
View design as working components
In simple terms, a component is an identifiable part of a larger construction to provide a particular function. Component architecture in web applications is not a developer-only concept anymore. UI designers already understand the importance of the component architecture when crafting designs for large-scale applications. The designer connects the dots between well-known frameworks like atomic design and the philosophy behind React.
xOTB brings the best of component-driven models by encouraging the breakdown of a UI into hierarchies (isolated functionality) and designing for consistency.
Designers and engineers have their own unique languages for their tasks. The designer looks more at the design of things (that the menu animates when clicked) while the engineer thinks about the logistics of doing that using their coding (that <select> needs to be used and then, CSS needs to be applied). But wait, how should the menu animate? As an ease-in or a roll-down?
While they both are correct in their own context and are trying to accomplish similar things, their language is not one; this can lead to the wrong interpretation and result in mistakes. Delivering cohesive user experiences across industries, products, and workflows is a challenge for the enterprise, especially when designers and developers don’t employ a shared language.
xOTB implements a language that’s mutual across design and development, based on component architecture. Designers won’t need to refer to a static object in Sketch anymore, they can refer to a real living component in the xOTB’s library. This implies less mistaken assumptions and a much superior execution of designs.
For e.g., in the context mentioned above, a designer can state, “Use xOTB’s horizontal menu component” and the developer then imports it from the xOTB JS library with ease. Both of them know that the horizontal menu will roll down.
With the xOTB design system, communication is free from ambiguity and is effective so that designers and developers can focus on their business rather than on semantics.
There are four magic tools that define xOTB:
- xOTB Guide
- xOTB Library
- xOTB Builder
- xOTB Resources
The Guide is your hotspot for design best practices and standards when utilizing text styles, hues, and components to amass a page structure.
Some of the important aspects that the Guide directs designers on are:
Good design ensures good experiences for everyone, regardless of one’s abilities or impairments. In terms of accessibility, xOTB is dedicated to pursuing and adhering to best practices. All xOTB components observe the Web Content Accessibility Guidelines Checklist and Section 508.
The xOTB Guide acts like a handbook that covers several categories of disabilities including those related to colors, keyboards, and screen readers. The guide details how differently-abled users experience an interface, what designers and developers should think about when they build interfaces for them, and how the guidelines apply to everyone.
The Guide acts as a baseline for accessibility guidelines so that designers can extend and amend on the basis of their target users and the product that they design for.
Icons are visual symbols that are used to depict thoughts, items, or behavior. They transmit messages at a glance, facilitate interaction, and bring important data to the user’s attention.
EDGE’s xOTB design system provides an inventory of ordinary icons which might be employed in client applications. This listing is a result of a detailed study on EDGE’s iconography and consolidating that with standardized icons (for example, a disc to represent a "save" function). The icons within the list ought to be acquainted to users.
You can now use the xOTB icons stock list as is and per your requirements or you may extend them using the standard SVG format.
Using a consistent and pleasing color palette will create a cohesive look and feel within products.
The Guide offers visual designers a range of color options – brand colors, status indicators, and a color palette, among others, so that a visual designer can quickly tweak the shades and rebrand for new systems.
Sketch Library (work in progress)
The Sketch Library includes a collection of low- and mid-fidelity UI components (a replica of the Angular Library in Sketch) to design and prototype layouts quickly including fonts, colors, and icons.
Designers can quickly assemble the UI components, describe their context and interaction, and build interactive prototypes.
The Sketch Library aims to make the design and development process more effective and concentrated, creating a common vocabulary between designer and developer, and offering clear, discoverable advice on best practices in both design and development.
The xOTB Angular Library is a host of Angular modules based on the xOTB Design System specifications, with over 40 core UI components and two visual themes. Core components refer to the main expression for the design language of a particular system. These are very exact and targeted in their scope and define the overall experience as well. Each component in xOTB has been designed and developed to address a very particular UI problem, such as presenting a list of options, enabling choices for users, and so on. Every individual component in the xOTB library is crafted to work harmoniously together as building blocks of a greater whole.
With the xOTB library, you can focus on business logic rather than fussing over UI details.
When designers and developers in xOTB implement these core components, this will give enough room to application developers. Those who use the xOTB design system to develop client applications, focus on UX and business specifics. They might as well build components but they are rather application-specific and are typically larger in scope, often consisting of one or more core components.
With this distinction of components, how is the team supposed to decide on which parts of their design are needed to be in the library? Would this create a total dependency on the xOTB team to keep putting out these core components? In what ways will these applications use the core components? Each of these questions show discrete challenges to teams, resulting in a mindfully constructed workflow that ensures consistency when composing the core components.
Workflow Centered around Components
The primary guiding principle for xOTB is for designers to use actual working components as the way to share designs with the UX developers. This was a unique approach used in lieu of using traditional design artifacts like prototypes, mockups, and style guides. The library hosts an array of components that designers can refer to, application developers can leverage to build UI, and then the unique and qualified application components are fed back into the design system wherever necessary.
In the next part, I will talk about xOTB library workflow and how it strengthens the hand-off between different stakeholders when working on a digital product experience.