Negative amount display placement
Always place the negative symbol before the currency and amount in either format. Correct examples: -$4.20, -12,50 €. Incorrect examples: $-4.20, 12,50 €-
Shopify Polaris · all subjects
content-fundamentals
92 notes in this subject, read out of this brain and free to use. This is page 2 of 2.
Customer-facing currency formatting defaults
Default to explicit format whenever prices are customer-facing. Use short format for unit prices, itemized prices, and installment prices. When using short format, always use explicit format for cart total, checkout total, and notification totals.
Currency formatting decision guide questions
Use these questions when deciding on currency formatting: Does the merchant know which currency they're looking at? Does the currency format support the merchant's main task (scanning, comparing, analyzing, or taking an action)? Are there enough details to make an informed decision? Can the UI be simplified without creating confusion?
Currencies with shared symbols for testing
USD, CAD, AUD, HKD, and SGD are currencies that share the same symbol "$". These should be used to test for clarity when multiple currencies with the same symbol may appear.
Japanese Yen for testing space constraints
Japanese Yen (JPY) should be used to test currency length and space constraints. Approximately 1 USD equals 100 JPY. If there is enough space for the JPY amount, it should work for most other major currencies.
Major currencies in local formats table
Currency formatting reference table with locale, short format, and explicit format: | Currency | Locale | Short format | Explicit format | | US Dollar ($, USD) | en-US | $12.50 | $12.50 USD | | Canadian Dollar ($, CAD) | en-CA | $12.50 | $12.50 CAD | | Canadian Dollar ($, CAD) | fr-CA | 12,50 $ | 12,50 $ CAD | | Australian Dollar ($, AUD) | en-AU | $12.50 | $12.50 AUD | | Euro (€, EUR) | de-DE, fr-FR | 12,50 € | 12,50 € EUR | | Euro (€, EUR) | en-IE | €12.50 | €12.50 EUR | | Euro (€, EUR) | nl-NL | €12,50 | €12,50 EUR | | British Pounds (£, GBP) | en-GB | £12.50 | £12.50 GBP | | Japanese Yen (¥, JPY) | ja-JP | ¥1250 | ¥1250 JPY | | New Zealand Dollar ($, NZD) | en-NZ | $12.50 | $12.50 NZD | | Hong Kong Dollar ($, HKD) | zh-HK | $12.50 | $12.50 HKD | | Singapore Dollar ($, SGD) | zh-SG | $12.50 | $12.50 SGD | | Danish Krone (Kr, DKK) | da-DK | 12,50 kr. | 12,50 kr. DKK |
Navigation schemes in Shopify admin
The Shopify admin uses three types of navigation schemes: structural (main navigation, local navigation, breadcrumbs), associative (contextual links to other features or help documentation), and utility (linked avatars to access account, search).
Information architecture definition
Information architecture is the practice of organizing, structuring, and labeling content in an effective and sustainable way. It applies to apps, admin interfaces, new features, and editorial pages.
IA purpose: simplify complexity
Information should be structured and managed in the simplest way possible.
IA purpose: create familiarity
Regardless of how merchants access Shopify, it should feel like the same product. Creating a common experience goes beyond design and extends to how content is structured.
Wayfinding principle: show audience where they are
Successful wayfinding happens when an audience can make navigation decisions that fulfill their goal. Navigation enables wayfinding by allowing merchants to explore a topic in depth, switch tasks easily, and filter information. This requires establishing multiple navigation schemes, using task-based navigation, and integrating secondary navigational support like breadcrumbs.
IA principle: give content one home and many doors
All content should have a single authoritative location, but should be accessible from multiple entry points across the product. Merchants access content through various paths including side navigation, search, breadcrumbs, and contextual links. This accommodates different information-seeking behaviors and allows merchants to begin tasks on one device and finish on another.
IA principle: avoid information overload
Use progressive disclosure to gradually reveal information as requested, provide multiple access points to information, and eliminate redundant content. This helps merchants reach decisions faster and avoids frustration and disorientation from front-loading too much detail.
IA principle: plan for growth and change
Information architecture decisions need to leave room for growth while promoting consistency across the experience. To make IA decisions scalable: communicate early and often within and outside the team; think about the future and how work intersects with other projects; create content groups flexible enough to accommodate growth while being meaningful to users; and consider how IA will adapt to multiple environments and their existing patterns (iOS, Android, desktop browsers, chatbots, retail products like Point of Sale).
IA purpose: support scalability
Good IA practices will help avoid overhauling previous work whenever the product grows or changes.
Foundational design guidance resources
Polaris provides foundational design guidance through experience values, design guidelines, and content fundamentals documentation for creating good merchant experiences.
New badge lifespan and removal rules
New badges should have a short lifespan. The badge should disappear when the user has clicked on the interactive element it's attached to, or 5 days after they first saw it, or after 3 sessions such as landing on a page 3 times.
New badge purpose and use cases
The New badge informs merchants about the release of a feature that creates new value. It should be used sparingly and for a short time frame. It should be used on features that have all three of these characteristics: we want to drive adoption of this feature, it's creating new value for merchants (not just an improved way of doing something they are already doing), and it's worth distracting merchants from their current workflow to inform them about a whole new part of Shopify. An example use case is to signify an entirely new page in the Settings nav.
New badge overuse creates unnecessary distraction
Overusing the New badge creates unnecessary distraction and lessens its impact. Consider how the admin would look if it was cluttered with New badges or features of varying importance.
New badge approval requirement for Settings nav
Using the New badge in the Settings nav to draw attention to a new feature must be reviewed and approved by UX management on a case by case basis.
New badge should not be used in primary navigation
The New badge should never be used in the primary navigation menu of the Shopify admin.
Pip usage distinction from New badge
A pip can be used to highlight a status or new element in a list, such as next to a new notification in a list of notifications. A pip should not be used for representing new features.
Comments and notes visibility in help text
Do not use placeholder text for comments and notes. Comments and notes help merchants keep track of unstructured information they may need about an order or a buyer. Some comments and notes are not visible to customers, but some are. In the help text, describe clearly who will be able to view the note.
Placeholder text in minimalist design
In some cases where help text clutters a page, such as the minimalist design of pages like the admin login page, placeholder text can be used. The placeholder should float above the text entry once the field has been selected. Use this method sparingly as it is not easy for everyone to read the small print of the floating text.
Titles, names, and descriptions avoid placeholder text
Do not use placeholder text for free input titles, names, and descriptions. Use help text instead.
Codes and tracking numbers help text approach
Do not use placeholder text for codes or tracking numbers; use help text instead. If the code follows a standardized format, include an example using the same format as help text for modeled content. If not, omit the example since the field contents can vary. Choose clear names for the field label and do not repeat it in the help text if possible. Instead, offer context that will help the user understand and complete the task quickly.
Multiline text inputs help text approach
For multiline fields, do not usually provide example text as you do not typically know what will go in them. Instead, include help text that explains how the text will be used and who can view it.
Field label best practices
Field labels act as a title for the text field and should typically be short and in noun form, such as 'Name'. When a text field is not part of a form and is placed individually on a page like a comment field, you can write the field label as a call to action, such as 'Leave a comment', because there is no surrounding context and using just 'Comment' alone could be confusing.
Help text purpose and best practices
Help text provides extra guidance or instructions to people filling out a form field and can also be used to clarify how the information will be used. Use help text when the text field label does not clearly explain the purpose of the text input, to provide guidance or instructions on the type of information needed, or to show examples of the required format for modeled text inputs. Avoid repeating the field label in help text. If the field label provides sufficient context for completing the action, then help text is likely not needed. If there is not enough room to include both instructions and an example, include only the example.
Modeled text inputs help text guidelines
For modeled text inputs, use help text to include an instructional call to action and an example that shows the required text format. If there is not enough room to include both an instructional call to action and an example, include only the example. Use the word 'Example' followed by a colon to introduce the example instead of using 'e.g.'
Free text inputs should not have examples
Do not provide an example for free text inputs. The text does not follow a specific format, and you should not assume what belongs in the field. If more context is needed, use help text instead.
Search, filter, and email fields placeholder text exception
For search fields, filter fields, and email entry fields, regular or floating placeholder text can be used. Placeholder text is a common, recognizable pattern for these field types. For other standard text fields, avoid placeholder text.