Product
UI Components
What we share here is the theory. Which strategy we used and how we applied it within our work process.We plan to share a public, light version of our UI Kit on Figma Community. Stay tuned!
The Buzzvil UI kit follows an Atomic structure. Our libraries are diverging based on the products, but keep the core atom components as a shared and unique source of truth for all files and products.
Ground rules
UI mockups will be our final Design-handoff materials for developers to start integrating. We want these mockups to be as lean and clean as possible.
Auto-Layouts
This includes only using Auto-layouts. It gives precious informations to the developers while integrating UIs, particularly for Web projects.
Variants
We also build Variant components and include all the hidden bits such as states and transitions inside prototypes.
Prototype-ready
Supporting the above, we pre-build every single component to be prototype-ready. This means that inside a component set of variants for instance, we already connect the different states to each others so that it will behave as expected if used into a prototype.
The Core UI kit
The core UI kit contains all our generic atoms. These simple components are consumed across our various teams and files.
These teams working on different products are using these atoms to build more complex elements scaling from molecules to complex organisms.
The Core UI kit is 'brandless'. It doesn't contain any theme. Instead, we want it to be looking like a wireframe UI set. Our products are so different in their usage, the device they are mode for that having a base theme would be already impossible without duplicating most atoms. Plus, starting to design with a clean, wireframe like set of component is actually a great practice to solely focus on functionality before aesthetic.
The platform designer is in charge of maintaining and sharing this core UI kit to every other designers or stakeholders.
Product-based UI kits
As I mentioned, our products are very different. Some will be desktop-first, targeting our customers and having a professional outlook where complexity can actually bring simplicity and efficiency in the user experience. Some other products will be oriented toward our customers' end-users, on mobile and with a completely different user experience, joyful and as simple as possible.
So we need different UI kits to support these various needs. Each mission team in charge of each products are in charge of maintaining this second layer of UI components. These UI kits must consume Core UI kit components first. If a component isn't available, a discussion with the platform designer in charge of the Core UI kit is required to decide whether this should remain on the product-specific level or if this should be adopted inside the Core UI kit.
These kits are developing more complex components, up to complete organisms and views.
The Buzzvil UI kit follows an Atomic structure. Our libraries are diverging based on the products, but keep the core atom components as a shared and unique source of truth for all files and products.
Ground rules
UI mockups will be our final Design-handoff materials for developers to start integrating. We want these mockups to be as lean and clean as possible.
Auto-Layouts
This includes only using Auto-layouts. It gives precious informations to the developers while integrating UIs, particularly for Web projects.
Variants
We also build Variant components and include all the hidden bits such as states and transitions inside prototypes.
Prototype-ready
Supporting the above, we pre-build every single component to be prototype-ready. This means that inside a component set of variants for instance, we already connect the different states to each others so that it will behave as expected if used into a prototype.
The Core UI kit
The core UI kit contains all our generic atoms. These simple components are consumed across our various teams and files.
These teams working on different products are using these atoms to build more complex elements scaling from molecules to complex organisms.
The Core UI kit is 'brandless'. It doesn't contain any theme. Instead, we want it to be looking like a wireframe UI set. Our products are so different in their usage, the device they are mode for that having a base theme would be already impossible without duplicating most atoms. Plus, starting to design with a clean, wireframe like set of component is actually a great practice to solely focus on functionality before aesthetic.
The platform designer is in charge of maintaining and sharing this core UI kit to every other designers or stakeholders.
Product-based UI kits
As I mentioned, our products are very different. Some will be desktop-first, targeting our customers and having a professional outlook where complexity can actually bring simplicity and efficiency in the user experience. Some other products will be oriented toward our customers' end-users, on mobile and with a completely different user experience, joyful and as simple as possible.
So we need different UI kits to support these various needs. Each mission team in charge of each products are in charge of maintaining this second layer of UI components. These UI kits must consume Core UI kit components first. If a component isn't available, a discussion with the platform designer in charge of the Core UI kit is required to decide whether this should remain on the product-specific level or if this should be adopted inside the Core UI kit.
These kits are developing more complex components, up to complete organisms and views.
The Buzzvil UI kit follows an Atomic structure. Our libraries are diverging based on the products, but keep the core atom components as a shared and unique source of truth for all files and products.
Ground rules
UI mockups will be our final Design-handoff materials for developers to start integrating. We want these mockups to be as lean and clean as possible.
Auto-Layouts
This includes only using Auto-layouts. It gives precious informations to the developers while integrating UIs, particularly for Web projects.
Variants
We also build Variant components and include all the hidden bits such as states and transitions inside prototypes.
Prototype-ready
Supporting the above, we pre-build every single component to be prototype-ready. This means that inside a component set of variants for instance, we already connect the different states to each others so that it will behave as expected if used into a prototype.
The Core UI kit
The core UI kit contains all our generic atoms. These simple components are consumed across our various teams and files.
These teams working on different products are using these atoms to build more complex elements scaling from molecules to complex organisms.
The Core UI kit is 'brandless'. It doesn't contain any theme. Instead, we want it to be looking like a wireframe UI set. Our products are so different in their usage, the device they are mode for that having a base theme would be already impossible without duplicating most atoms. Plus, starting to design with a clean, wireframe like set of component is actually a great practice to solely focus on functionality before aesthetic.
The platform designer is in charge of maintaining and sharing this core UI kit to every other designers or stakeholders.
Product-based UI kits
As I mentioned, our products are very different. Some will be desktop-first, targeting our customers and having a professional outlook where complexity can actually bring simplicity and efficiency in the user experience. Some other products will be oriented toward our customers' end-users, on mobile and with a completely different user experience, joyful and as simple as possible.
So we need different UI kits to support these various needs. Each mission team in charge of each products are in charge of maintaining this second layer of UI components. These UI kits must consume Core UI kit components first. If a component isn't available, a discussion with the platform designer in charge of the Core UI kit is required to decide whether this should remain on the product-specific level or if this should be adopted inside the Core UI kit.
These kits are developing more complex components, up to complete organisms and views.