# Getting Started \*Welcome to the Nord Design System. If you're just getting started with designing or developing something for our therapyveterinary products, you're in the right place. \[For veterinary, please switch brand]\(/start/?theme=vet)\[For therapy, please switch brand]\(/start/?theme=nord).\* Nord Design System is a collection of reusable components and tools, guided by clear standards, that can be assembled together to build digital products and experiences for [Nordhealth](https://nordhealth.com){rel=""nofollow""}. The goal of Nord Design System is to improve UI consistency and quality, while making our software design and development processes more efficient. The system also helps to establish a common vocabulary between everyone in our organization and ease collaboration between different teams and disciplines. \> \[!NOTE] \> Nord Design System ships with two distinctive brands, \[therapy]\(/?theme=nord) and \[veterinary]\(/?theme=vet). You can switch the currently active brand from the top left corner of this documentation website. --- ## Design guidelines Check out these practical guides to help you understand how to design for Nordhealth's platforms using Nord Design System. \*\*\[Nord Design Principles]\(/principles/)\*\* - nordhealth.design/principles/ \*\*\[Figma Toolkit]\(/figma/)\*\* - nordhealth.design/figma/ \*\*\[Color guidelines]\(/colors/)\*\* - nordhealth.design/colors/ \*\*\[Iconography guidelines]\(/iconography/)\*\* - nordhealth.design/iconography/ \*\*\[Grid guidelines]\(/grid/)\*\* - nordhealth.design/grid/ \*\*\[Typography guidelines]\(/typography/)\*\* - nordhealth.design/typography/ \*\*\[Theming guidelines]\(/themes/)\*\* - nordhealth.design/themes/ \*\*\[Design Tokens]\(/tokens/)\*\* - nordhealth.design/tokens/ \*\*\[Components]\(/components/)\*\* - nordhealth.design/components/ \*\*\[Templates]\(/templates/)\*\* - nordhealth.design/templates/ \*\*\[Nordicons]\(/nordicons/)\*\* - nordhealth.design/nordicons/ \*\*\[Downloads]\(/downloads/)\*\* - nordhealth.design/downloads/ ::div --- :: ## Development packages Nord is a collection of reusable components and tools that are divided into nine packages. They can be used together or separately depending on your team's needs. \*\*\[Web Components]\(/web-components/)\*\* - nordhealth.design/web-components/ \*\*\[React Wrappers (deprecated)]\(/web-components/#react)\*\* - nordhealth.design/web-components/#react \*\*\[Vue Types (deprecated)]\(/web-components/#types-and-editor-integration-with-vue)\*\* - nordhealth.design/web-components/#types-and-editor-integration-with-vue \*\*\[CSS Framework]\(/css/)\*\* - nordhealth.design/css/ \*\*\[Themes]\(/themes/)\*\* - nordhealth.design/themes/ \*\*\[Nordicons]\(/nordicons/)\*\* - nordhealth.design/nordicons/ \*\*\[Design Tokens]\(/tokens/)\*\* - nordhealth.design/tokens/ \*\*\[Webfonts]\(/webfonts/)\*\* - nordhealth.design/webfonts/ \*\*\[Color Utilities]\(/color-utilities/)\*\* - nordhealth.design/color-utilities/ \*\*\[AG Grid Theme]\(/components/table/#recommendation-for-component-based-libraries)\*\* - /components/table/ Each package can be installed using [Node Package Manager](https://www.npmjs.com/org/nordhealth){rel=""nofollow""}. To do so, run the following command(s) in your terminal: ```bash # Design Tokens, CSS Framework, Themes, Nordicons, Webfonts: # (For usage with any framework) npm install @nordhealth/tokens npm install @nordhealth/css npm install @nordhealth/themes npm install @nordhealth/icons npm install @nordhealth/fonts npm install @nordhealth/color npm install @nordhealth/ag-theme-nord ``` ```bash # Web Components for HTML, Vue.js and Vanilla JS: npm install @nordhealth/components ``` ```bash # React Wrappers (deprected): npm install @nordhealth/react ``` ```bash # Vue Types (deprected): npm install @nordhealth/vue ``` \> \[!WARNING] \> For further installation and integration guidelines for each Nord Design System package, please see documentation \[linked above]\(#frontend-packages). ::div --- :: ## What's new This section is updated regularly with new content to help you stay up to date with the latest [releases](https://nordhealth.design/changelogs/web-components) and [updates](https://nordhealth.design/updates/) from the Nord team. We also have [an RSS feed](https://nordhealth.design/feed.xml) you can subscribe to. \*\*\[Changelog]\(/changelogs/web-components)\*\* - nordhealth.design/changelogs/web-components \*\*\[Latest Updates]\(/updates/)\*\* - nordhealth.design/updates/ \*\*\[Migration Guides]\(/migrations/)\*\* - nordhealth.design/migrations/ ::div --- :: ## Browser support Nord Design System is tested in the latest two versions of the following browsers. Our team addresses critical [bug fixes](https://nordhealth.design/help/) in earlier versions based on their severity and impact. If you need to support IE11 or pre-Chromium Edge, this library isn't for you. \*See browser icons\* ::div --- :: ## Can I use Nord in my own project? Nord Design System is solely meant for building digital products and experiences for [Nordhealth](https://nordhealth.com){rel=""nofollow""}. Please see the [terms of use](https://nordhealth.design/terms/) for full license details. ::div --- :: ## Getting support If you experience any issues while getting started with any of Nord's tools, please head over to the [Support page](https://nordhealth.design/help/) for more guidelines and help. # About Nord \*Nord Design System is a collection of reusable components and tools, guided by clear standards, that can be assembled together to build digital products and experiences.\* The goal of Nord Design System is to improve UI consistency and quality, while making our software design and development processes more efficient. Nord also helps to establish a common vocabulary between everyone in our organization and ease collabo­ration between different teams and disciplines. Nord Design System has a core team of designers and developers inside Nordhealth who are dedicated to building and supporting the system. The core team includes [Elwin van Eede](https://elwinvaneede.com){rel=""nofollow""}. Our documentation is public as it makes sharing and collaboration between different teams and third party vendors much easier as it increases the system’s visibility and accountability. This also makes us push towards higher quality and enables us to be more transparent. Finally, it also serves as an amazing tool that we can leverage in recruiting. You can reach out to the team by heading over to [our support page](https://nordhealth.design/help/). ![Nord Design System architecture overview](https://nordhealth.design/img/updates/architecture/1.jpg){.n:border.n:rounded} Nord Design System package architecture, [read more from our blog](https://nordhealth.design/updates/february-2022-design-system-architecture/). --- ## Relevant reading - **[Launching Nord Design System article](https://arielsalminen.com/2022/launching-nord-design-system/){rel=""nofollow""}** - **[How Nord team uses Custom Properties in Web Components](https://web.dev/custom-properties-web-components/){rel=""nofollow""}** - **[Nord Statistics for the first year](https://nordhealth.design/updates/march-2022-statistics-for-the-first-year/)** - **[How Nord team uses Figma](https://nordhealth.design/updates/january-2022/)** - **[Nord Design System documentation](https://nordhealth.design){rel=""nofollow""}** --- ## How we started Looking back in time, we started our design system journey at the end of 2020 with initial user research. We did this because we wanted to first better understand the challenges we're trying to solve at [Nordhealth](https://nordhealth.com){rel=""nofollow""} and how the design system might help. Back then, we interviewed around 60 different persons from different teams, with different backgrounds, and with different levels of experience. The result of this research was an organizational challenges heatmap that highlighted organization level problems. Once we had this data, we continued the research with a [series of workshops](https://arielsalminen.com/2018/vue-design-system/#figuring-out-challenges){rel=""nofollow""}. These workshops were meant to reveal a lack of alignment and personal biases across teams. The final output from these workshops was a set of prioritized actions that directly informed the backlog of the design system. Once we knew what the challenges were, it was a matter of creating fundamental [principles](https://nordhealth.design/principles/) and [goals for the system](https://nordhealth.design/about/#our-goals) that we should follow to start solving these issues. We came up with these four goals for Nord: ![Nord goals](https://nordhealth.design/img/updates/goals.jpg){.n:border.n:rounded loading="lazy"} At the same time, we also created design principles for the design systems work that would form the foundations for Nord and guide our team when working on the different parts of the system and help us do better and more informed decisions. These are the six design principles we created for Nord: ### 1. Put user needs first We care for the people who use our products. We're here to make their day-to-day and long-term work better and more pleasant through great user experience. ### 2. Strive for consistency, not uniformity We should use the same language and design patterns wherever possible. This helps people get familiar with our services. Same holds true for the system and its developer experience. ### 3. Default to openness We should share what we're doing whenever we can. Building our services transparently increases their visibility and accountability and makes us push towards higher quality. ### 4. Make it accessible Our services are for everyone. We make sure people with different needs can use our products and that they meet the accessibility standards outlined in WCAG 2.1. ### 5. Provide a good developer experience Providing a good developer experience is very important to us. Developers should be able to start using our tools in minutes, not hours, days or weeks. ### 6. Automate everything you can We value the time of our colleagues, users, and our future selves over our own. We are always proactively looking for ways to automate repetitive tasks and testing. ![Nord has tech-agnostic components](https://nordhealth.design/img/updates/agnostic.jpg){.n:border.n:rounded loading="lazy"} --- ## Technical architecture Whenever we talk about Nord Design System, one of the first things that we like to mention is that Nord is **tech agnostic, not tech specific.** Meaning that you can take any component from Nord and use it with any framework. That could be Angular, React, Preact, Vue.js, plain HTML, your old PHP application, or any future framework. We achieve this by building on top of existing web standards ([Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components){rel=""nofollow""} to be exact), instead of choosing a specific framework to go with. This is really important for us for a few reasons; ### Tech-Agnostic Instead Of Tech-Specific In order to create modular interfaces, a design system needs to be technology-agnostic instead of technology-specific. Web Components offer this benefit and make it easier to reduce our design system's complexity and improve its reusability. ### Future Proofing With Web Standards [Web Standards](https://en.wikipedia.org/wiki/Web_standards){rel=""nofollow""} are more future proof than any given JavaScript framework. I've seen different frameworks come and go during my almost two decade long career on the web, but Web Standards keep thriving and evolving. ### Any Framework Or No Framework Web Components can be used with [any JavaScript framework](https://custom-elements-everywhere.com/){rel=""nofollow""} or no framework at all. This means we're able to support all our product teams from a single codebase. This makes it possible for our small design system team to be very efficient. ### Full Encapsulation [Shadow DOM](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM){rel=""nofollow""} allows components to have their own DOM tree that can't be accidentally accessed from the main document. For us this means that "everything just works" when the components are implemented onto different environments and platforms. Most styles cannot penetrate a component from the outside, and styles inside a component won't bleed out. ![Nord has tech-agnostic styles as well](https://nordhealth.design/img/updates/agnostic-2.jpg){.n:border.n:rounded loading="lazy"} Nord's tech-agnostic thinking isn't limited to only components either, all our styles are agnostic as well. We use [design tokens](https://nordhealth.design/tokens/) instead of hard coded values to ensure a better UI consistency across different platforms. Be that a web application, a native application, a mobile application, a VR solution, or something new that doesn't even exist today. The way [Nord](https://nordhealth.design) itself is structured, looks somewhat like shown in the picture below. The most important thing about the architecture is that we aren't really talking about one gigantic design system, but multiple small modular systems that can be used either standalone or together depending on specific team's needs. On the first level, we have packages called [Webfonts](https://nordhealth.design/webfonts/), [Design Tokens](https://nordhealth.design/tokens/), and [Nordicons](https://nordhealth.design/nordicons/). These packages are like atoms of the systems as they don't have external or internal dependencies into any other packages in the system. On the second level, we have [CSS Framework](https://nordhealth.design/css/), [Web Components](https://nordhealth.design/components/), and [Themes](https://nordhealth.design/themes/). These packages internally depend on the first level packages, but we wanted to hide these dependencies for the end user, Frontend Developer in this case, meaning that you'd more or less always install one or more of the second level packages only into your app to consume parts of the system. ![Nord Design System architecture overview](https://nordhealth.design/img/updates/architecture/1.jpg){.n:border.n:rounded loading="lazy"} As an example, if you would like to use our **CSS Framework,** you would only install that specific NPM package and that's really it. You don't have to care, as a user, that internally this package also uses our **Webfonts** and **Design Token** packages: ![Dependencies for utilizing CSS Framework](https://nordhealth.design/img/updates/architecture/2.jpg){.n:border.n:rounded loading="lazy"} Another example could be that if you'd want to skin your application with one of our themes, you'd also add the **Themes** package and choose a theme to use from it. Again, internally, we still use both **Webfonts** and **Design Token** packages, but as a user, you don't have to care about those: ![Dependencies for utilizing Nord Themes](https://nordhealth.design/img/updates/architecture/3.jpg){.n:border.n:rounded loading="lazy"} Finally, in the below example, we show all three first level packages being used internally (Webfonts, Design Tokens and Nordicons), but for the end user, only **CSS Framework** and **Web Components** will be relevant in this case: ![Dependencies for utilizing Web Components](https://nordhealth.design/img/updates/architecture/4.jpg){.n:border.n:rounded loading="lazy"} You could also directly utilize one of the first level packages, like the **Design Tokens** if you're working on a native iOS application and want to pull in the base colors and similar styles in XML format: ![Dependencies for utilizing Design Tokens on iOS](https://nordhealth.design/img/updates/architecture/5.jpg){.n:border.n:rounded loading="lazy"} While the above is still possible, we wanted to avoid the user having to install a lot of different dependencies to be able to use a utility class from the CSS Framework, or a component from the Web Components package. So while we strive towards having modularity to reduce the complexity and improve our system's reusability by breaking it into small, easier to consume parts, we also want to make sure this modularity doesn't become too burdensome for our users. **To learn more about the Nord Design System, how it works, and our release in 2022, please also read [Launching Nord Design System](https://arielsalminen.com/2022/launching-nord-design-system/){rel=""nofollow""} article.** --- ## Important information - **Name of the project:** Nord Design System - **Companies involved in design:** [Nordhealth](https://nordhealth.com){rel=""nofollow""}, [Ariel S. Design](https://arielsalminen.com){rel=""nofollow""}, [Iijii (icons)](https://ilkkaj.com){rel=""nofollow""} - **Companies involved in implementation:** [Nordhealth](https://nordhealth.com){rel=""nofollow""}, [Ariel S. Design](https://arielsalminen.com){rel=""nofollow""} - **Client:** Nordhealth - **Category:** Best design system - **Link to the project:** {rel=""nofollow""} --- ## Further material - **[Launching Nord Design System article](https://arielsalminen.com/2022/launching-nord-design-system/){rel=""nofollow""}** - **[How Nord team uses Custom Properties in Web Components](https://web.dev/custom-properties-web-components/){rel=""nofollow""}** - **[Nord Statistics for the first year](https://nordhealth.design/updates/march-2022-statistics-for-the-first-year/)** - **[How Nord team uses Figma](https://nordhealth.design/updates/january-2022/)** - **[Nord Design System documentation](https://nordhealth.design){rel=""nofollow""}** --- ## How we work The following set of fundamental rules allows us to get to the highest level of productivity while benefiting both the company and our team members. - We avoid meetings as much as possible. Instead of having them, we communicate asynchronous to each other via Linear, GitHub, Notion, Figma, and (occasionally) Slack, expecting responses within 24 hours. - We don’t do team wide standups or sync meetings, except one meeting at the start of every cycle. Here we walk through the tasks and also discuss about how the team feels, what motivates them right now, and what would they want to change. - Most collaboration and discussion happens in feedback loops, using the above mentioned tools, which requires clear and thoughtful communication from everyone. - We don’t have strict deadlines. We ship incrementally as we move through the backlog and launch new things as they become ready. - Our team members should be able to work on what they think is fun, or rely on their intuition when picking tasks from the backlog. Our [roadmap on Linear](https://linear.app/nordhealth/team/NDS/all){rel=""nofollow""} holds us accountable. - We focus on persistent iteration over flashy launches. --- ## Our goals ![Nord goals](https://nordhealth.design/img/updates/goals.jpg){.n:border.n:rounded loading="lazy"} ### Efficiency Improved work efficiency for designers and developers. ### Consistency Improved user interface consistency and quality. ### Openness Improved communication between teams and people. ### Standards Shared guidelines and standards through documentation. # What's New \*This section is updated regularly with new content to help you stay up to date with the latest \[releases]\(/changelogs/web-components) and \[updates]\(/updates/) from the Nord team.\* \*\*\[Changelog]\(/changelogs/web-components)\*\* - nordhealth.design/changelogs/web-components \*\*\[Latest Updates]\(/updates)\*\* - nordhealth.design/updates/ \*\*\[Migration Guides]\(/migrations)\*\* - nordhealth.design/migrations/ # Web Components \*See component grid\* # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Use the circle avatar to represent a single user or an animal. \- Use the square avatar for organizations or group of animals. \- Always add the name of the user, animal, organization, or group of animals using the \`name\` property. \- For the best results, use square images or images cropped into a square. \> \*\*Don't:\*\* - Don’t use the circle avatar to represent organizations or group of animals. \- Don’t use the square avatar to represent a single user or an animal. \- Don’t use an avatar when an icon is more suitable, for example when denoting groups or "things". \- Try to avoid using landscape or portrait images as avatars. Let users crop their images before or after uploading if possible. # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Use established variants and color patterns so that users can clearly identify the importance level. \- Use to show a status update on a piece of information or action. \- Use to mark something as a “draft” or “new”. \- Use when you want to highlight something that has been added recently. \- Always position badge so that it’s easy to understand what object it’s related to. \> \*\*Don't:\*\* - Don’t make badges clickable. Instead use button component’s small variant. \- Don’t use alternatives to existing badge variants. \- Don't use badges for labeling, categorizing, or organizing objects. Use the \[tag component]\(/components/tag/) instead. --- ## Content guidelines Badge labels should use a single word to describe the status of an object. Only use two words if you need to describe a complex state: \> \*\*Do:\*\* Complete \> \*\*Don't:\*\* Action completed When writing badge labels, always write them in sentence case, not title case. The first word should be capitalized and the rest lowercase (unless a proper noun): \> \*\*Do:\*\* Partially refunded \> \*\*Don't:\*\* Partially Refunded Avoid unnecessary words and articles in badge labels, such as “is”, “the”, “an” or “a”: \> \*\*Do:\*\* Pending \> \*\*Don't:\*\* Item is pending Always describe the status in the past tense: \> \*\*Do:\*\* Refunded \> \*\*Don't:\*\* Refund --- ## Variants This section describes the different component variants, their purpose, and when to use each variant. | Name | Purpose | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------- | | `neutral` | The default style variant. | | `info` | Used to convey general information that isn’t critical. | | `success` | Used to convey success states. For example, you might want to show a badge that tells the user a payment was successful. | | `highlight` | Used to highlight specific items in the interface, like notifications. | | `danger` | Used to communicate problems that have to be resolved so that user can continue forward. Should always be used for highlighting errors. | | `warning` | Used to display information that needs a user’s attention attention and may require further steps. | | `progress` | Used to convey something that’s in progress. | # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Use this component if you need to communicate in a prominent way. \- Place banner at the top of the section it applies to. \- Use for highlighting errors and success statuses. \- Put banner close to the context it’s referring to. \- Move focus to the banner if it’s relevant to the current workflow. \> \*\*Don't:\*\* - Move focus to banner if it appears on page load. \- Use for highlighting general content or as a banner. \- Use to replace an error page. --- ## Content guidelines Banner content should be clear, accurate and easy to understand: \> \*\*Do:\*\* We’re experiencing an incident. Please see our status page for more details. \> \*\*Don't:\*\* There was an error. When writing banner content, always write it in sentence case, not title case. The first word should be capitalized and the rest lowercase (unless a proper noun): \> \*\*Do:\*\* We’re experiencing an incident. \> \*\*Don't:\*\* We’re Experiencing An Incident. Always end in punctuation: \> \*\*Do:\*\* We’re experiencing an incident. \> \*\*Don't:\*\* We’re experiencing an incident # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Use to group together buttons, or dropdowns, of a similar nature or purpose. \- Use the appropriate \`role\` attribute on the button group to provide additional semantics. \- Use an \`aria-labelledby\` attribute referencing another element to best explain the contents of the button group. \> \*\*Don't:\*\* - Don’t add components other than buttons, dropdowns and in some instances visually hidden components to the button group. \- Don’t skip the addition of an appropriate label if the added \`role\` attribute value calls for it. \- Don’t use for building grid based layouts. --- ## Content guidelines Button labels should be clear, accurate and predictable. It should be possible for the user to understand what will happen when they click a button: \> \*\*Do:\*\* View user settings \> \*\*Don't:\*\* Click here When writing button labels, always write them in sentence case, not title case. The first word should be capitalized and the rest lowercase (unless a proper noun): \> \*\*Do:\*\* My tasks \> \*\*Don't:\*\* My Tasks Avoid unnecessary words and articles in button labels, such as “the”, “an” or “a”: \> \*\*Do:\*\* Add item \> \*\*Don't:\*\* Add an item --- ## Variants This section describes the different component variants, their purpose, and when to use each variant. | Name | Purpose | | --------- | -------------------------------------------------------------------------------------------------------- | | `default` | The default variant renders a group of segmented buttons to emphasize that they’re thematically-related. | | `spaced` | The spaced variant renders a gap between the buttons to space them out evenly. | # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Only use one primary button per section, as a main call-to-action. \- Use clear and accurate labels. \- Use established button colors appropriately. For example, only use a danger button style for an action that’s difficult or impossible to undo. \- Prioritize the most important actions. Too many buttons will cause confusion. \- Be consistent with positioning of buttons in the user interface. \- Use strong, actionable verbs in labels such as “Add”, “Close”, “Cancel”, or “Save”. \> \*\*Don't:\*\* - Don't use a primary button in every row of a table. \- Don’t use buttons to link to other pages. Use regular link or a plain style instead where necessary. \- Don’t use buttons for navigation where the link appears within or following a sentence. \- Don’t use labels such as “Read more”, “Click here” or “More”. --- ## Content guidelines Button labels should be clear, accurate and predictable. It should be possible for the user to understand what will happen when they click a button: \> \*\*Do:\*\* View user settings \> \*\*Don't:\*\* Click here When writing button labels, always write them in sentence case, not title case. The first word should be capitalized and the rest lowercase (unless a proper noun): \> \*\*Do:\*\* My tasks \> \*\*Don't:\*\* My Tasks Avoid unnecessary words and articles in button labels, such as “the”, “an” or “a”: \> \*\*Do:\*\* Add item \> \*\*Don't:\*\* Add an item --- ## Variants This section describes the different component variants, their purpose, and when to use each variant. | Name | Purpose | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `default` | Default style is the most common button variant. Only switch to another variant if you need to adjust the visual weight of the element. | | `primary` | Primary style is reserved for main call-to-actions. Should be used only once per content area or panel, e.g. for a “Save” action. | | `dashed` | Dashed style should be used for actions that trigger filtering. | | `danger` | Danger style should be used for actions that delete data or otherwise make it hard to undo the action. | | `plain` | Used for less important or less common actions. Can be also used for linking to other pages. | | `disabled` | Used for actions that aren’t currently available or not available anymore. Also prevents users from being able to interact with the component, and conveys its inactive state to assistive technologies. | --- ## Icon usage in button Illustrative icons should be always positioned in the `start` slot: ![Button with icon in start slot](https://nordhealth.design/img/components/button/start-slot.png){.n-border.n-border-radius.n-brand-therapy height="475" loading="lazy" style="max-inline-size:700px;" width="800"}![Button with icon in start slot](https://nordhealth.design/img/components/button/start-slot-vet.png){.n-border.n-border-radius.n-brand-veterinary height="475" loading="lazy" style="max-inline-size:700px;" width="800"} When a button is used as a dropdown toggle, the `interface-dropdown-small` icon from [Nordicons](https://nordhealth.design/nordicons/) is automatically placed in the `end` slot (you can use the `hideDropdownIcon` property to hide it): ![Dropdown button](https://nordhealth.design/img/components/button/dropdown.png){.n-border.n-border-radius height="475" loading="lazy" style="max-inline-size:700px;" width="800"} Each button size has a recommended icon size. The medium button uses the `s` icon size, the [small button](https://nordhealth.design/components/button/?example=small+buttons) uses the `xs` icon size, and the [large button](https://nordhealth.design/components/button/?example=large+buttons) uses the `m` icon size. The icon will adjust size automatically based on the button size, so you will get the correct behavior by default. However, this can be overridden by explicitly setting a size on the icon. ![Button icon sizes](https://nordhealth.design/img/components/button/icon-sizes.png){.n-border.n-border-radius.n-brand-therapy height="475" loading="lazy" style="max-inline-size:700px;" width="800"}![Button icon sizes](https://nordhealth.design/img/components/button/icon-sizes-vet.png){.n-border.n-border-radius.n-brand-veterinary height="475" loading="lazy" style="max-inline-size:700px;" width="800"} Use `interface-add-small` icon in the `start` slot for create/add type primary actions in the [header](https://nordhealth.design/components/header/): ![Create/add type primary action with icon](https://nordhealth.design/img/components/button/create.png){.n-border.n-border-radius.n-brand-therapy height="475" loading="lazy" style="max-inline-size:700px;" width="800"}![Create/add type primary action with icon](https://nordhealth.design/img/components/button/create-vet.png){.n-border.n-border-radius.n-brand-veterinary height="475" loading="lazy" style="max-inline-size:700px;" width="800"} --- ## Additional considerations - Users of assistive technology expect a button to submit data or do an action. If you need the button to navigate into another view, use the `href` property which will output `` tag instead of a `