diff --git a/roadmaps/design-system/content/accessibility-testing@yhP8EhyCWWRBLkYPyOFeg.md b/roadmaps/design-system/content/accessibility-testing@yhP8EhyCWWRBLkYPyOFeg.md index a59e55b73..f7270733e 100644 --- a/roadmaps/design-system/content/accessibility-testing@yhP8EhyCWWRBLkYPyOFeg.md +++ b/roadmaps/design-system/content/accessibility-testing@yhP8EhyCWWRBLkYPyOFeg.md @@ -1,3 +1,3 @@ # Accessibility Testing - + Accessibility testing checks that components meet standards like WCAG, covering things like sufficient color contrast, proper keyboard navigation, and correct screen reader labeling. It combines automated tools, like axe or Lighthouse, with manual testing using assistive technology to catch issues automated tools miss. Testing accessibility at the component level ensures every product built from the design system inherits accessible behavior by default. \ No newline at end of file diff --git a/roadmaps/design-system/content/accessibility@aLtOGjNFxaRzg0PI-ed99.md b/roadmaps/design-system/content/accessibility@aLtOGjNFxaRzg0PI-ed99.md index da87d3dcb..40229f189 100644 --- a/roadmaps/design-system/content/accessibility@aLtOGjNFxaRzg0PI-ed99.md +++ b/roadmaps/design-system/content/accessibility@aLtOGjNFxaRzg0PI-ed99.md @@ -7,6 +7,4 @@ Visit the following resources to learn more: - [@article@Introduction to Web Accessibility](https://www.w3.org/WAI/fundamentals/accessibility-intro/) - [@article@What is Accessibility? by Mozilla](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility) - [@article@Accessibility Principles](https://www.w3.org/WAI/fundamentals/accessibility-principles/) -- [@article@WebAIMs Website (Web Accessibility In Mind)](https://webaim.org/) -- [@article@WAVE Web Accessibility Evaluation Tool](https://wave.webaim.org/) -- [@feed@Explore top posts about Accessibility](https://app.daily.dev/tags/accessibility?ref=roadmapsh) \ No newline at end of file +- [@article@WebAIMs Website (Web Accessibility In Mind)](https://webaim.org/) \ No newline at end of file diff --git a/roadmaps/design-system/content/code-style@zEqFAuH9zmKTLwwgx54pW.md b/roadmaps/design-system/content/code-style@zEqFAuH9zmKTLwwgx54pW.md index e586f01e2..dcbefb6fa 100644 --- a/roadmaps/design-system/content/code-style@zEqFAuH9zmKTLwwgx54pW.md +++ b/roadmaps/design-system/content/code-style@zEqFAuH9zmKTLwwgx54pW.md @@ -1,3 +1,3 @@ # Code Style - + Code style refers to the formatting and structural conventions followed when writing a design system's component code, such as naming conventions, file structure, and formatting rules enforced by tools like ESLint or Prettier. Consistent code style makes the codebase easier to read and maintain as multiple contributors add or update components. It's usually enforced automatically through linting tools rather than left to manual review. \ No newline at end of file diff --git a/roadmaps/design-system/content/commit-guidelines@IVYe8oh1IWbUbxMZRxVQA.md b/roadmaps/design-system/content/commit-guidelines@IVYe8oh1IWbUbxMZRxVQA.md index 4baed9bdc..c3770e7c9 100644 --- a/roadmaps/design-system/content/commit-guidelines@IVYe8oh1IWbUbxMZRxVQA.md +++ b/roadmaps/design-system/content/commit-guidelines@IVYe8oh1IWbUbxMZRxVQA.md @@ -1,3 +1,3 @@ # Commit Guidelines - + Commit guidelines define a consistent format for writing commit messages when contributing code to a design system, such as the Conventional Commits format that prefixes messages with types like "feat" or "fix." Consistent commit messages make it easier to generate changelogs automatically and to understand a project's history at a glance. They're often enforced through automated checks that reject commits not following the required format. \ No newline at end of file diff --git a/roadmaps/design-system/content/communication-channel@LWrrKrhwXfMDKgbFW5DuO.md b/roadmaps/design-system/content/communication-channel@LWrrKrhwXfMDKgbFW5DuO.md index 773aec123..d4446e0a6 100644 --- a/roadmaps/design-system/content/communication-channel@LWrrKrhwXfMDKgbFW5DuO.md +++ b/roadmaps/design-system/content/communication-channel@LWrrKrhwXfMDKgbFW5DuO.md @@ -1,3 +1,3 @@ # Communication Channel - + A communication channel is the primary medium a design system team uses for day-to-day questions and announcements, such as a dedicated Slack channel or Microsoft Teams space. It gives consuming teams a fast way to ask questions or report issues without going through formal ticketing for every small query. Having a clearly designated channel prevents design system discussions from getting scattered across multiple informal threads. \ No newline at end of file diff --git a/roadmaps/design-system/content/community-meetings@eG8ranXuINtcqWfeMH5GW.md b/roadmaps/design-system/content/community-meetings@eG8ranXuINtcqWfeMH5GW.md index dc95b4a15..49617814d 100644 --- a/roadmaps/design-system/content/community-meetings@eG8ranXuINtcqWfeMH5GW.md +++ b/roadmaps/design-system/content/community-meetings@eG8ranXuINtcqWfeMH5GW.md @@ -1,3 +1,3 @@ # Community Meetings - + Community meetings are regularly scheduled sessions where design system maintainers and the teams that consume the system come together to discuss updates, gather feedback, and address concerns. They give consuming teams a direct channel to raise issues or request new components rather than relying solely on written tickets. These meetings also help build a sense of shared ownership over the design system across the organization. \ No newline at end of file diff --git a/roadmaps/design-system/content/component-catalog@VeLiPzbGr22_Mh_8T2Gnf.md b/roadmaps/design-system/content/component-catalog@VeLiPzbGr22_Mh_8T2Gnf.md index b2c964888..8c125e8b1 100644 --- a/roadmaps/design-system/content/component-catalog@VeLiPzbGr22_Mh_8T2Gnf.md +++ b/roadmaps/design-system/content/component-catalog@VeLiPzbGr22_Mh_8T2Gnf.md @@ -1,3 +1,3 @@ # Component Catalog - + A component catalog is a searchable, browsable reference of every component in a design system's code library, usually generated automatically from the component code itself. Tools like Storybook are commonly used to build a catalog that shows each component's variants, props, and usage examples in an interactive interface. It gives developers a live reference to check component behavior without reading the underlying source code. \ No newline at end of file diff --git a/roadmaps/design-system/content/contribution-guidelines@TiCNCRpMPgZUhn7JdaIZA.md b/roadmaps/design-system/content/contribution-guidelines@TiCNCRpMPgZUhn7JdaIZA.md index 8b118d120..2ad34a1f6 100644 --- a/roadmaps/design-system/content/contribution-guidelines@TiCNCRpMPgZUhn7JdaIZA.md +++ b/roadmaps/design-system/content/contribution-guidelines@TiCNCRpMPgZUhn7JdaIZA.md @@ -1,3 +1,3 @@ # Contribution Guidelines - + Contribution guidelines document the process for proposing, reviewing, and approving changes to a design system, whether on the design side or the development side. They typically cover how to submit a new component, who reviews proposed changes, and what criteria a contribution needs to meet before acceptance. Clear contribution guidelines make it possible for people outside the core design system team to safely add or update components. \ No newline at end of file diff --git a/roadmaps/design-system/content/design-system-examples@hauTvrBOAHgrUnO_m_kDM.md b/roadmaps/design-system/content/design-system-examples@hauTvrBOAHgrUnO_m_kDM.md index ad1933e6b..09bcea5eb 100644 --- a/roadmaps/design-system/content/design-system-examples@hauTvrBOAHgrUnO_m_kDM.md +++ b/roadmaps/design-system/content/design-system-examples@hauTvrBOAHgrUnO_m_kDM.md @@ -7,6 +7,4 @@ Visit the following resources to learn more: - [@opensource@Collection of Open Source Design Systems](https://github.com/alexpate/awesome-design-systems) - [@article@Material Design (Google)](https://material.io/) - [@article@Carbon Design System (IBM)](https://carbondesignsystem.com/) -- [@article@Atlassian Design System](https://atlassian.design/) -- [@article@Polaris Design System (Shopify)](https://polaris.shopify.com/) -- [@article@Gov.uk Design System](https://design-system.service.gov.uk/) \ No newline at end of file +- [@article@Atlassian Design System](https://atlassian.design/) \ No newline at end of file diff --git a/roadmaps/design-system/content/design-system-vs-component-library@J5mU0v491qrm-mr1W3Msd.md b/roadmaps/design-system/content/design-system-vs-component-library@J5mU0v491qrm-mr1W3Msd.md index 3fb5cfa68..25198c5fc 100644 --- a/roadmaps/design-system/content/design-system-vs-component-library@J5mU0v491qrm-mr1W3Msd.md +++ b/roadmaps/design-system/content/design-system-vs-component-library@J5mU0v491qrm-mr1W3Msd.md @@ -4,6 +4,5 @@ A component library is just a collection of visuals i.e. colours, button styling Visit the following resources to learn more: -- [@article@A Design System: So Much More Than A Component Library](https://www.architech.ca/a-design-system-so-much-more-than-a-component-library) - [@article@Design System vs UI Component Library vs Brand Style Guide](https://prototype.net/blog/design-system-component-library-style-guide) - [@article@Design Systems vs Pattern Libraries vs Style Guides vs Component Libraries](https://www.uxpin.com/studio/blog/design-systems-vs-pattern-libraries-vs-style-guides-whats-difference/) \ No newline at end of file diff --git a/roadmaps/design-system/content/faqs@cpAeotBxN8BCsU9RqTEue.md b/roadmaps/design-system/content/faqs@cpAeotBxN8BCsU9RqTEue.md index 9a6fec71e..9326b6977 100644 --- a/roadmaps/design-system/content/faqs@cpAeotBxN8BCsU9RqTEue.md +++ b/roadmaps/design-system/content/faqs@cpAeotBxN8BCsU9RqTEue.md @@ -1,3 +1,3 @@ # FAQs - + FAQs are a curated list of frequently asked questions and their answers, covering the most common issues or points of confusion that consuming teams run into when using the design system. Maintaining an FAQ reduces repetitive support requests by pointing people to existing answers before they need to ask directly. It's usually kept alongside the main documentation and updated as new common questions emerge. \ No newline at end of file diff --git a/roadmaps/design-system/content/input-checkbox@F5_sxUnnGEdgF6BkA5T5x.md b/roadmaps/design-system/content/input-checkbox@F5_sxUnnGEdgF6BkA5T5x.md index 9c08afdc4..30990a58b 100644 --- a/roadmaps/design-system/content/input-checkbox@F5_sxUnnGEdgF6BkA5T5x.md +++ b/roadmaps/design-system/content/input-checkbox@F5_sxUnnGEdgF6BkA5T5x.md @@ -1,3 +1,3 @@ # Input Checkbox - + An input checkbox component lets users select one or more options from a set of choices, toggling between a checked and unchecked state. It usually supports an indeterminate state as well, used when a checkbox represents a partially selected group of sub-options. Checkboxes are built with clear focus and disabled states to remain accessible via keyboard navigation. \ No newline at end of file diff --git a/roadmaps/design-system/content/input-radio@rN-_plAA5FkcQl03wsL18.md b/roadmaps/design-system/content/input-radio@rN-_plAA5FkcQl03wsL18.md index 15fb312a2..b2c1b6060 100644 --- a/roadmaps/design-system/content/input-radio@rN-_plAA5FkcQl03wsL18.md +++ b/roadmaps/design-system/content/input-radio@rN-_plAA5FkcQl03wsL18.md @@ -1,3 +1,3 @@ # Input Radio - + An input radio component lets users select exactly one option from a group of mutually exclusive choices. Radio buttons in a group share a common name so that selecting one automatically deselects the others. They are used instead of a dropdown when all options should be visible at once for easier comparison. \ No newline at end of file diff --git a/roadmaps/design-system/content/input-switch@NISeaJUlDtQ0kSuyxmrOT.md b/roadmaps/design-system/content/input-switch@NISeaJUlDtQ0kSuyxmrOT.md index c04c290d8..670daaeb4 100644 --- a/roadmaps/design-system/content/input-switch@NISeaJUlDtQ0kSuyxmrOT.md +++ b/roadmaps/design-system/content/input-switch@NISeaJUlDtQ0kSuyxmrOT.md @@ -1,3 +1,3 @@ # Input Switch - + An input switch, also called a toggle, lets users turn a single setting on or off, typically represented as a sliding control rather than a checkbox. It's commonly used for binary settings, like enabling notifications, where the on and off states have a clear, immediate effect. Switches usually include a visual and sometimes textual indicator of the current state. \ No newline at end of file diff --git a/roadmaps/design-system/content/list@2T7tiM3Ew3H1U5iJR2TDb.md b/roadmaps/design-system/content/list@2T7tiM3Ew3H1U5iJR2TDb.md index af5f4375f..77caf2498 100644 --- a/roadmaps/design-system/content/list@2T7tiM3Ew3H1U5iJR2TDb.md +++ b/roadmaps/design-system/content/list@2T7tiM3Ew3H1U5iJR2TDb.md @@ -1,3 +1,3 @@ # List - + A list component displays a vertical sequence of items, each following the same layout, such as a list of contacts or notifications. It often supports variants like showing an icon, avatar, or action button alongside each item's text. Lists are commonly built to handle large datasets efficiently through virtualization when the number of items is high. \ No newline at end of file diff --git a/roadmaps/design-system/content/loading-indicator@JhnHOMIlU6mQcwvIpErUY.md b/roadmaps/design-system/content/loading-indicator@JhnHOMIlU6mQcwvIpErUY.md index 34c57ebfc..db1124f95 100644 --- a/roadmaps/design-system/content/loading-indicator@JhnHOMIlU6mQcwvIpErUY.md +++ b/roadmaps/design-system/content/loading-indicator@JhnHOMIlU6mQcwvIpErUY.md @@ -1,3 +1,3 @@ # Loading Indicator - + A loading indicator communicates to the user that content is being fetched or processed, typically shown as a spinner, progress bar, or skeleton screen. It prevents the interface from appearing frozen or broken during delays caused by network requests or heavy computation. Design systems usually offer a few variants, such as a small inline spinner and a full-page loading state. \ No newline at end of file diff --git a/roadmaps/design-system/content/logging@xYqDmDpjwkShtL86nt-vY.md b/roadmaps/design-system/content/logging@xYqDmDpjwkShtL86nt-vY.md index c3257957b..c1670632e 100644 --- a/roadmaps/design-system/content/logging@xYqDmDpjwkShtL86nt-vY.md +++ b/roadmaps/design-system/content/logging@xYqDmDpjwkShtL86nt-vY.md @@ -1,3 +1,3 @@ # Logging - + Logging, in the context of a design system, means recording events and errors that occur when components are used in production, such as a component failing to render or receiving invalid props. Reviewing these logs helps the design system team catch bugs that only surface in real-world usage across different consuming products. It complements testing done before release by revealing issues that appear once components run at scale. \ No newline at end of file diff --git a/roadmaps/design-system/content/making-a-design-system@dUaoMARPabiD4DRqdkaer.md b/roadmaps/design-system/content/making-a-design-system@dUaoMARPabiD4DRqdkaer.md index 5e7594648..1107bc9a1 100644 --- a/roadmaps/design-system/content/making-a-design-system@dUaoMARPabiD4DRqdkaer.md +++ b/roadmaps/design-system/content/making-a-design-system@dUaoMARPabiD4DRqdkaer.md @@ -7,5 +7,4 @@ Visit the following resources to learn more: - [@article@Design Systems: Step-by-Step Guide to Creating Your Own](https://www.uxpin.com/create-design-system-guide/) - [@article@Does My Organization Need a Design System?](https://www.method.com/insights/does-my-organization-need-a-design-system/) - [@video@Introducing Design Systems Into Chaos - Diana Mounter, GitHub](https://www.youtube.com/watch?v=FZSi1bK-BRM) -- [@video@Design Systems, when and how much?](https://www.youtube.com/watch?v=Hx02SaL_IH0) -- [@video@Create a Design System with Figma - Full Course](https://www.youtube.com/watch?v=RYDiDpW2VkM) \ No newline at end of file +- [@video@Design Systems, when and how much?](https://www.youtube.com/watch?v=Hx02SaL_IH0) \ No newline at end of file diff --git a/roadmaps/design-system/content/milestones@ruPXxVwmD9vSlS7rBZmA-.md b/roadmaps/design-system/content/milestones@ruPXxVwmD9vSlS7rBZmA-.md index e8b47b938..70314c48a 100644 --- a/roadmaps/design-system/content/milestones@ruPXxVwmD9vSlS7rBZmA-.md +++ b/roadmaps/design-system/content/milestones@ruPXxVwmD9vSlS7rBZmA-.md @@ -1,3 +1,3 @@ # Milestones - + Milestones are specific checkpoints within a design system's roadmap that mark the completion of a significant piece of work, such as shipping a new component library version or completing an accessibility audit. They break a larger roadmap into measurable stages, making it easier to track progress over time. Milestones are often tied to specific dates or releases to create accountability. \ No newline at end of file diff --git a/roadmaps/design-system/content/modal@IjNitkG25vNo30rB4ckNV.md b/roadmaps/design-system/content/modal@IjNitkG25vNo30rB4ckNV.md index 332cc2949..af5486fca 100644 --- a/roadmaps/design-system/content/modal@IjNitkG25vNo30rB4ckNV.md +++ b/roadmaps/design-system/content/modal@IjNitkG25vNo30rB4ckNV.md @@ -1,3 +1,3 @@ # Modal - + A modal component displays content in a layer above the main page, requiring user interaction before returning to the underlying content, commonly used for confirmations or focused tasks. It typically includes a backdrop that dims the rest of the page and traps keyboard focus within the modal while it's open. Modals need careful accessibility handling to ensure focus returns to the triggering element once closed. \ No newline at end of file diff --git a/roadmaps/design-system/content/open-hours@YWoPoO9IW3vLZyxLL2fnT.md b/roadmaps/design-system/content/open-hours@YWoPoO9IW3vLZyxLL2fnT.md index 78eb5c543..f5e26446c 100644 --- a/roadmaps/design-system/content/open-hours@YWoPoO9IW3vLZyxLL2fnT.md +++ b/roadmaps/design-system/content/open-hours@YWoPoO9IW3vLZyxLL2fnT.md @@ -1,3 +1,3 @@ # Open Hours - + Open hours are scheduled time blocks during which the design system team is available for live questions, pairing sessions, or troubleshooting help from consuming teams. They give teams a predictable way to get direct support without waiting for a response in a ticket or chat channel. Open hours work especially well for onboarding teams that are new to using the design system. \ No newline at end of file diff --git a/roadmaps/design-system/content/pilot@4dzoZmkNHPedgLqLy93t8.md b/roadmaps/design-system/content/pilot@4dzoZmkNHPedgLqLy93t8.md index 658280eb4..5ead5017f 100644 --- a/roadmaps/design-system/content/pilot@4dzoZmkNHPedgLqLy93t8.md +++ b/roadmaps/design-system/content/pilot@4dzoZmkNHPedgLqLy93t8.md @@ -4,5 +4,4 @@ Pilots are one of the best ways to put your design system through its paces, esp Visit the following resources to learn more: -- [@official@Design Systems: Pilots & Scorecards](https://danmall.com/posts/design-systems-pilots-scorecards/) - [@article@How to run a design system pilot](https://university.obvious.in/product-design/design-system/how-to-run-a-design-system-pilot) \ No newline at end of file diff --git a/roadmaps/design-system/content/plugins@uO-2O0Jwh_DxrMAB9wxp1.md b/roadmaps/design-system/content/plugins@uO-2O0Jwh_DxrMAB9wxp1.md index c77aca9d9..3c8635ce4 100644 --- a/roadmaps/design-system/content/plugins@uO-2O0Jwh_DxrMAB9wxp1.md +++ b/roadmaps/design-system/content/plugins@uO-2O0Jwh_DxrMAB9wxp1.md @@ -1,3 +1,3 @@ # Plugins - + Plugins are add-on tools that extend a design editor's functionality, such as automating token synchronization, checking accessibility contrast, or generating code snippets from design components. They reduce manual work by connecting the design tool directly to other parts of the design system workflow, like a token repository or a documentation site. Teams often build custom plugins tailored to their specific design system setup. \ No newline at end of file diff --git a/roadmaps/design-system/content/pr-templates@wd9ZHZmqV7wbLN-9V4EQy.md b/roadmaps/design-system/content/pr-templates@wd9ZHZmqV7wbLN-9V4EQy.md index 8905deab8..8e24871f3 100644 --- a/roadmaps/design-system/content/pr-templates@wd9ZHZmqV7wbLN-9V4EQy.md +++ b/roadmaps/design-system/content/pr-templates@wd9ZHZmqV7wbLN-9V4EQy.md @@ -1,3 +1,3 @@ # PR Templates - + A PR template is a predefined structure that appears when someone opens a pull request, prompting contributors to fill in information like a description of the change, screenshots, and a checklist of required steps. It ensures every contribution includes the context a reviewer needs, rather than relying on contributors to remember what to include. Design systems use PR templates to keep the review process consistent as the number of contributors grows. \ No newline at end of file diff --git a/roadmaps/design-system/content/release-strategy@CfWCQNaCJGL-egRhFhc4B.md b/roadmaps/design-system/content/release-strategy@CfWCQNaCJGL-egRhFhc4B.md index e1ec8c0ac..235b13700 100644 --- a/roadmaps/design-system/content/release-strategy@CfWCQNaCJGL-egRhFhc4B.md +++ b/roadmaps/design-system/content/release-strategy@CfWCQNaCJGL-egRhFhc4B.md @@ -1,3 +1,3 @@ # Release Strategy - + A release strategy defines how and how often new versions of a design system get published, including whether releases happen on a fixed schedule or whenever changes are ready. It also covers how breaking changes get communicated and how long older versions remain supported. A clear release strategy helps consuming teams plan when to upgrade without being caught off guard by unexpected changes. \ No newline at end of file diff --git a/roadmaps/design-system/content/roadmap@gMrX5600JqFDplriq-eU3.md b/roadmaps/design-system/content/roadmap@gMrX5600JqFDplriq-eU3.md index 65ca13745..789523df4 100644 --- a/roadmaps/design-system/content/roadmap@gMrX5600JqFDplriq-eU3.md +++ b/roadmaps/design-system/content/roadmap@gMrX5600JqFDplriq-eU3.md @@ -1,3 +1,3 @@ # Roadmap - + A roadmap, in project management terms, is a high-level plan that outlines what a design system team intends to build or improve over a given period, such as new components or major token changes. It helps set expectations with consuming teams about what's coming and in what order. Roadmaps are typically reviewed and adjusted regularly as priorities shift based on feedback and adoption needs. \ No newline at end of file diff --git a/roadmaps/design-system/content/semantic-versioning@ZLt1yJqinC8OSpqucC2dV.md b/roadmaps/design-system/content/semantic-versioning@ZLt1yJqinC8OSpqucC2dV.md index 1d7b68d3e..ab47f5063 100644 --- a/roadmaps/design-system/content/semantic-versioning@ZLt1yJqinC8OSpqucC2dV.md +++ b/roadmaps/design-system/content/semantic-versioning@ZLt1yJqinC8OSpqucC2dV.md @@ -1,3 +1,3 @@ # Semantic Versioning - + Semantic versioning is a version numbering convention, formatted as major.minor.patch, used to communicate the type of change made in each release of a design system's code. A major version bump signals a breaking change, a minor version adds new functionality without breaking existing usage, and a patch fixes bugs. Following this convention lets teams consuming the design system understand the risk of upgrading to a new version at a glance. \ No newline at end of file diff --git a/roadmaps/design-system/content/service-and-health-metrics@5znnOkpf9G9tdiMWB6Rut.md b/roadmaps/design-system/content/service-and-health-metrics@5znnOkpf9G9tdiMWB6Rut.md index 675ce32b6..ca13c0bd7 100644 --- a/roadmaps/design-system/content/service-and-health-metrics@5znnOkpf9G9tdiMWB6Rut.md +++ b/roadmaps/design-system/content/service-and-health-metrics@5znnOkpf9G9tdiMWB6Rut.md @@ -1,3 +1,3 @@ # Service and Health Metrics - + Service and health metrics track the overall reliability and performance of a design system as a product in its own right, such as build times, uptime of documentation or component hosting, and how quickly reported bugs get resolved. These metrics give the team an objective view of how well the design system is being maintained, beyond just component-level usage. They're often reported to stakeholders as evidence of the system's ongoing value. \ No newline at end of file diff --git a/roadmaps/design-system/content/tabs@1vYR1EMyZhJA-znxnFBBb.md b/roadmaps/design-system/content/tabs@1vYR1EMyZhJA-znxnFBBb.md index 1f65ed26c..3bf3f723f 100644 --- a/roadmaps/design-system/content/tabs@1vYR1EMyZhJA-znxnFBBb.md +++ b/roadmaps/design-system/content/tabs@1vYR1EMyZhJA-znxnFBBb.md @@ -1,3 +1,3 @@ # Tabs - + A tabs component lets users switch between different views or sections of content within the same page area, without navigating to a new page. Each tab typically shows a label and, when selected, displays its associated content while hiding the others. Tabs need keyboard support so users can navigate between them using arrow keys. \ No newline at end of file diff --git a/roadmaps/design-system/content/ticketing@i39J0fk4DaPeNFIMbH0ap.md b/roadmaps/design-system/content/ticketing@i39J0fk4DaPeNFIMbH0ap.md index b2d4c2a61..0bd36077e 100644 --- a/roadmaps/design-system/content/ticketing@i39J0fk4DaPeNFIMbH0ap.md +++ b/roadmaps/design-system/content/ticketing@i39J0fk4DaPeNFIMbH0ap.md @@ -1,3 +1,3 @@ # Ticketing - + Ticketing refers to the system used to track individual tasks, bugs, and feature requests related to a design system, typically using tools like Jira or Linear. Each ticket captures a specific piece of work, such as adding a new component variant or fixing an accessibility issue, along with its status and assignee. A well-maintained ticketing system gives the team and stakeholders visibility into what's currently being worked on. \ No newline at end of file diff --git a/roadmaps/design-system/content/toast@-T7uL6a3lJ5-IIcDaG6IN.md b/roadmaps/design-system/content/toast@-T7uL6a3lJ5-IIcDaG6IN.md index a2d3f644e..37efb6a0c 100644 --- a/roadmaps/design-system/content/toast@-T7uL6a3lJ5-IIcDaG6IN.md +++ b/roadmaps/design-system/content/toast@-T7uL6a3lJ5-IIcDaG6IN.md @@ -1,3 +1,3 @@ # Toast - + A toast component displays a brief, temporary message that appears and disappears automatically, typically used for confirmations like "Changes saved" or lightweight error notices. Unlike a banner, a toast floats above the page content and doesn't require the user to dismiss it manually. Toasts are commonly positioned in a corner of the screen and stack when multiple messages appear at once. \ No newline at end of file diff --git a/roadmaps/design-system/content/tooling-analytics@qiJGYYWL4naJX-MgZA9Ms.md b/roadmaps/design-system/content/tooling-analytics@qiJGYYWL4naJX-MgZA9Ms.md index 0f6be545f..230ba6eaf 100644 --- a/roadmaps/design-system/content/tooling-analytics@qiJGYYWL4naJX-MgZA9Ms.md +++ b/roadmaps/design-system/content/tooling-analytics@qiJGYYWL4naJX-MgZA9Ms.md @@ -1,3 +1,3 @@ # Tooling Analytics - + Tooling analytics measure how the design system's own supporting tools get used, such as how often a Figma plugin runs, how frequently the documentation site is visited, or how often the component catalog is searched. This data helps the team understand which tools deliver value and which ones go unused. It informs decisions about where to invest further tooling effort. \ No newline at end of file diff --git a/roadmaps/design-system/content/tooltip@2oCAzsk_y2Y2oHUi467dp.md b/roadmaps/design-system/content/tooltip@2oCAzsk_y2Y2oHUi467dp.md index 0ad517369..739dcec6d 100644 --- a/roadmaps/design-system/content/tooltip@2oCAzsk_y2Y2oHUi467dp.md +++ b/roadmaps/design-system/content/tooltip@2oCAzsk_y2Y2oHUi467dp.md @@ -1,3 +1,3 @@ # Tooltip - + A tooltip component displays a small piece of contextual information when a user hovers over or focuses on an element, typically used to explain an icon-only button or provide extra detail. It appears near the triggering element and disappears once the user moves away or shifts focus elsewhere. Tooltips need to be accessible via keyboard focus, not just mouse hover, to work for all users. \ No newline at end of file diff --git a/roadmaps/design-system/content/ui-kit@lUObv2N7eH3Jdnwwd5vmI.md b/roadmaps/design-system/content/ui-kit@lUObv2N7eH3Jdnwwd5vmI.md index 295f88020..13d6de100 100644 --- a/roadmaps/design-system/content/ui-kit@lUObv2N7eH3Jdnwwd5vmI.md +++ b/roadmaps/design-system/content/ui-kit@lUObv2N7eH3Jdnwwd5vmI.md @@ -4,5 +4,4 @@ As it relates to a design system, a UI Kit is a representation of coded componen Visit the following resources to learn more: -- [@article@Design System vs UI Kit](https://uigstudio.com/insights/design-system-vs-ui-kit) - [@article@Your sketch library is not a design system](http://bradfrost.com/blog/post/your-sketch-library-is-not-a-design-system/) \ No newline at end of file diff --git a/roadmaps/design-system/content/unit-testing@y8No8I0MltA91j4Q2toT0.md b/roadmaps/design-system/content/unit-testing@y8No8I0MltA91j4Q2toT0.md index 738c7a8d6..9f2cbcdff 100644 --- a/roadmaps/design-system/content/unit-testing@y8No8I0MltA91j4Q2toT0.md +++ b/roadmaps/design-system/content/unit-testing@y8No8I0MltA91j4Q2toT0.md @@ -1,3 +1,3 @@ # Unit Testing - + Unit testing means writing automated tests that verify individual components behave correctly in isolation, such as checking that a button calls its click handler or that a checkbox toggles its state correctly. These tests catch regressions early when a component's code changes, before the change reaches production. Design systems rely heavily on unit tests since a bug in a shared component can affect every product that uses it. \ No newline at end of file diff --git a/roadmaps/design-system/content/usage-guidance@RmSFwKqL9yXXxGKZusKWX.md b/roadmaps/design-system/content/usage-guidance@RmSFwKqL9yXXxGKZusKWX.md index 447910abe..95c85799b 100644 --- a/roadmaps/design-system/content/usage-guidance@RmSFwKqL9yXXxGKZusKWX.md +++ b/roadmaps/design-system/content/usage-guidance@RmSFwKqL9yXXxGKZusKWX.md @@ -5,7 +5,5 @@ Logo usage guidance provides rules for proper implementation to maintain brand c Visit the following resources to learn more: - [@article@Logo Usage Best Practices](https://99designs.com/blog/tips/logo-usage-guidelines/) -- [@article@Brand Guidelines Development](https://designsystem.digital.gov/design-tokens/logo/) - [@article@Trademark and Logo Legal Guidelines](https://www.uspto.gov/trademarks-getting-started/trademark-basics) -- [@article@Brand Identity Protection](https://www.brandfolder.com/blog/brand-guidelines) -- [@feed@Explore top posts about Brand Management](https://app.daily.dev/tags/branding?ref=roadmapsh) \ No newline at end of file +- [@article@Brand Identity Protection](https://www.brandfolder.com/blog/brand-guidelines) \ No newline at end of file diff --git a/roadmaps/design-system/content/version-control@CYY6nbQiC2pu5ATWmO6wA.md b/roadmaps/design-system/content/version-control@CYY6nbQiC2pu5ATWmO6wA.md index 9901b5b81..2e4721751 100644 --- a/roadmaps/design-system/content/version-control@CYY6nbQiC2pu5ATWmO6wA.md +++ b/roadmaps/design-system/content/version-control@CYY6nbQiC2pu5ATWmO6wA.md @@ -1,3 +1,3 @@ # Version Control - + Version control, in the context of design tooling, means tracking changes to design files over time, similar to how developers track code changes, so past states can be reviewed or restored. Some design editors have built-in version history, while others rely on external plugins or file naming conventions to track changes. This becomes especially important as multiple designers contribute to the same design system files. \ No newline at end of file diff --git a/roadmaps/design-system/content/vision@cMfsRtvzvDZZJ0TqeUOxm.md b/roadmaps/design-system/content/vision@cMfsRtvzvDZZJ0TqeUOxm.md index 3766720ef..482a50f21 100644 --- a/roadmaps/design-system/content/vision@cMfsRtvzvDZZJ0TqeUOxm.md +++ b/roadmaps/design-system/content/vision@cMfsRtvzvDZZJ0TqeUOxm.md @@ -6,6 +6,4 @@ Visit the following resources to learn more: - [@article@Creating Brand Vision](https://www.interaction-design.org/literature/article/branding-in-ux) - [@article@Vision-Driven Design Systems](https://bradfrost.com/blog/post/the-design-system-ecosystem/) -- [@article@Brand Strategy for Design](https://alistapart.com/article/creating-a-brand-identity/) -- [@article@Purpose-Driven Design](https://designsystem.digital.gov/design-tokens/brand/) -- [@feed@Explore top posts about Brand Strategy](https://app.daily.dev/tags/branding?ref=roadmapsh) \ No newline at end of file +- [@article@Brand Strategy for Design](https://alistapart.com/article/creating-a-brand-identity/) \ No newline at end of file diff --git a/roadmaps/design-system/content/what-is-atomic-design@6r9XbwlBtHmJrhviG2cTD.md b/roadmaps/design-system/content/what-is-atomic-design@6r9XbwlBtHmJrhviG2cTD.md index 4d62646f0..3493dcb32 100644 --- a/roadmaps/design-system/content/what-is-atomic-design@6r9XbwlBtHmJrhviG2cTD.md +++ b/roadmaps/design-system/content/what-is-atomic-design@6r9XbwlBtHmJrhviG2cTD.md @@ -5,5 +5,4 @@ Atomic design (by Brad Frost) is a mental model to help you think of user interf Visit the following resources to learn more: - [@article@Atomic Design Principles & Methodology 101](https://xd.adobe.com/ideas/process/ui-design/atomic-design-principles-methodology-101/) -- [@article@Atomic Design Methodology](https://atomicdesign.bradfrost.com/chapter-2/) -- [@article@Atomic Design and UI Components: Theory to Practice](https://blog.bitsrc.io/atomic-design-and-ui-components-theory-to-practice-f200db337c24) \ No newline at end of file +- [@article@Atomic Design Methodology](https://atomicdesign.bradfrost.com/chapter-2/) \ No newline at end of file