We practice a well-structured and principle-based way of working
Copy link to headline:Agility
We adapt quickly to changes and divide our tasks into smaller parts in order to work on them in short sprints. This allows us to maintain an overview and adapt our plans accordingly - depending on the current situation.
Copy link to headline:The community
We value our community and love to get in touch with you all. That's why we use GitHub(opens in a new tab) as a platform that allows us to exchange ideas with you and gather feedback. Your input shapes our work and improves the product.
Copy link to headline:Flexibility
We design and create our components according to the latest web standards. This means they can be used in all kinds of projects and are super versatile.
Copy link to headline:Quality
From planning to the final stages of implementation, we put our knowledge and skills into our design system at the highest level. We want it to work smoothly for all our end users alike.
Copy link to headline:Collaboration
The skills and expertise of everyone are involved in our decisions by working closely together. We take everyone's skills and input into account and rely on each other.
Copy link to headline:Definition of Ready (DoR)
The described definitions on this page show the focus on guidelines for working with tickets in the onyx team.
A component ticket must fulfil the following aspects to be considered ready:
| Description | UX/UI | DEV | PO |
|---|---|---|---|
| The design is linked | 🧑🎨 | - | 🧑💼 |
| The acceptance criteria are defined ****r => AC has specific steps/interactions defined | - | - | 🧑💼 |
| Dependencies are defined and completed | - | - | 🧑💼 |
| Implementation details are noted | - | 🧑💻 | - |
| Comparable implementations are linked | - | 🧑💻 | - |
| Matching ARIA patterns are linked, if applicable | 🧑🎨 | 🧑💻 | 🧑💼 |
| No open questions and ToDos | 🧑🎨 | 🧑💻 | 🧑💼 |
| Ticket was estimated | 🧑🎨 | 🧑💻 | 🧑💼 |
Copy link to headline:Definition of Done (DoD)
The described definitions on this page show the focus on guidelines for working with tickets in the onyx team.
A component ticket must fulfil the following aspects to be considered done:
| Description | UX/UI | DEV | PO |
|---|---|---|---|
| The acceptance criteria are fulfilled | 🧑🎨 | 🧑💻 | - |
| The features are covered by component tests ****r => Screenshot tests are updated | - | 🧑💻 | - |
| Known open points are either fixed or a ticket was created | - | 🧑💻 | 🧑💼 |
| The onyx version was updated and the documentation is deployed ****r => Docs approved by DEV | - | 🧑💻 | - |
| StoryBook can show the feature ****r => approved by UX/UI | 🧑🎨 | 🧑💻 | - |
| Our guidelines were followed | 🧑🎨 | 🧑💻 | - |
Copy link to headline:Ticket naming convention
We use a naming convention to make it easier to understand the scope / responsible party on our tickets(opens in a new tab).
Copy link to headline:UX Tickets
- "Concept..." for UX
- "Adjust..." or "Redesign…" for UX bugs
- "Research..." for UX Research
Copy link to headline:Dev Tickets
- "Implement..." for Devs
- "Fix..." for Dev bugs
- "Define..." for Dev POCs
Copy link to headline:Generic Tickets
- "Onboard..." for UX/Dev Sharing info / POC
Copy link to headline:Component quality stages
This page describes which perspective must be taken into consideration when creating components in onyx.
Copy link to headline:Essentials: Concept handover
| Description | UX/UI | DEV |
|---|---|---|
| Defined responsive behavior for all breakpoints | 🧑🎨 | - |
| Defined architectural structure of component | 🧑🎨 | - |
| Neutral color theme is used | 🧑🎨 | - |
| Defined density behavior: compact, default, cozy | 🧑🎨 | - |
| Defined slots and functions | 🧑🎨 | 🧑💻 |
| Defined states: hover / disabled / active /... | 🧑🎨 | 🧑💻 |
| Component design fits our principles | 🧑🎨 | 🧑💻 |
| Design variables are used | 🧑🎨 | 🧑💻 |
| Considers darkmode / lightmode | - | 🧑💻 |
| Defined basic layout in figma design | - | 🧑💻 |
| Market research / internal experience exchange was performed | - | 🧑💻 |
| Component API fits our technical guidelines | - | 🧑💻 |
Copy link to headline:Essentials: MVP component release
| Description | UX/UI | DEV |
|---|---|---|
| Defined keyboard interactivity | 🧑🎨 | - |
| Other light + dark color themes are applied | 🧑🎨 | - |
| Provided textual documentation + property description (in Storybook) | 🧑🎨 | - |
| Classification into component groups | 🧑🎨 | - |
| Functional figma component is created in library | 🧑🎨 | - |
| UX approval of coded component | 🧑🎨 | - |
| A11y level A / barrier free | 🧑🎨 | 🧑💻 |
| DEV + UX aligned the naming | 🧑🎨 | 🧑💻 |
| Verify keyboard interactivity | - | 🧑💻 |
| Prime behavior covered by playwright | - | 🧑💻 |
| Screenshot tests (dark + light) were created | - | 🧑💻 |
| Component is fully documented (props, slots, ...) in Storybook | - | 🧑💻 |
| Used clean SCSS naming (BEM) | - | 🧑💻 |
| Verified HTML standards (tag names, prop names, behavior, ...) | - | 🧑💻 |
| Used clean code | - | 🧑💻 |
Copy link to headline:Final expansion stage of a component
| Description | UX/UI | DEV |
|---|---|---|
| Figma library clean-up + sorting | 🧑🎨 | - |
| Provided images and visualization inside documentation | 🧑🎨 | - |
| Created tags for components | 🧑🎨 | - |
| Special packages for special use-cases (e.g. gloves optimized) | 🧑🎨 | - |
| Documentation of patterns (cooperation between multiple components) | 🧑🎨 | - |
| All variants of a component are defined | 🧑🎨 | - |
| Component fulfills least a11y level AA | 🧑🎨 | 🧑💻 |
| Provide touchscreen support (tested in dev-tools) | - | 🧑💻 |
| Mobile breakpoint optimized | - | 🧑💻 |
| Verified behavior for the WAWI | - | 🧑💻 |
| Implemented all density specialties :br(e.g. cozy for glove usage or compact for very small screens) | - | 🧑💻 |