@adobe/spectrum-design-data 3.2.2 → 3.3.0-beta.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/guidelines/ai-resource-guide.json +50 -0
- package/guidelines/app-frame-overview.json +44 -50
- package/guidelines/applying-the-type-system.json +63 -0
- package/guidelines/attention-hierarchy.json +12 -21
- package/guidelines/background-layers.json +44 -10
- package/guidelines/bi-directionality.json +57 -0
- package/guidelines/border-width.json +42 -0
- package/guidelines/brand.json +30 -10
- package/guidelines/cognitive.json +197 -0
- package/guidelines/colors.json +35 -17
- package/guidelines/component-spacing.json +49 -0
- package/guidelines/contact-us.json +67 -0
- package/guidelines/content-area-browsing-context.json +65 -0
- package/guidelines/creating-bluelines-browsing-context.json +91 -0
- package/guidelines/design-tokens.json +122 -0
- package/guidelines/developer-overview.json +25 -9
- package/guidelines/drop-shadow.json +56 -0
- package/guidelines/faqs.json +96 -9
- package/guidelines/fonts.json +29 -14
- package/guidelines/grammar-and-mechanics.json +252 -0
- package/guidelines/grays.json +17 -44
- package/guidelines/header-browsing-context.json +37 -0
- package/guidelines/icon-fundamentals.json +7 -18
- package/guidelines/illustration.json +109 -0
- package/guidelines/in-product-word-list.json +29 -0
- package/guidelines/inclusive-design.json +93 -0
- package/guidelines/inclusive-ux-writing.json +30 -0
- package/guidelines/internationalization.json +87 -0
- package/guidelines/layout-and-structure-containers.json +47 -0
- package/guidelines/layout-spacing.json +39 -0
- package/guidelines/manifest.json +278 -14
- package/guidelines/motion.json +17 -16
- package/guidelines/object-styles-overview.json +17 -0
- package/guidelines/resources.json +21 -15
- package/guidelines/rounding.json +61 -0
- package/guidelines/side-navigation-browsing-context.json +71 -0
- package/guidelines/spacing-overview.json +45 -0
- package/guidelines/states.json +15 -10
- package/guidelines/typography-overview.json +39 -0
- package/guidelines/typography-system.json +168 -0
- package/guidelines/using-icons.json +33 -44
- package/guidelines/visual-language-containers.json +36 -0
- package/guidelines/voice-and-tone.json +47 -0
- package/guidelines/writing-about-people.json +103 -0
- package/guidelines/writing-for-errors.json +120 -0
- package/guidelines/writing-for-onboarding.json +119 -0
- package/guidelines/writing-for-readability.json +54 -0
- package/guidelines/writing-with-visuals.json +70 -0
- package/package.json +2 -2
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
|
|
3
|
+
"$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/illustration.json",
|
|
4
|
+
"name": "illustration",
|
|
5
|
+
"title": "Illustration",
|
|
6
|
+
"category": "designing",
|
|
7
|
+
"documentBlocks": [
|
|
8
|
+
{ "type": "purpose", "content": "Illustration" },
|
|
9
|
+
{
|
|
10
|
+
"type": "guideline",
|
|
11
|
+
"content": "Comparing Spectrum 1 and Spectrum 2.\n\nHere’s a summary of the main updates that you’ll notice with Spectrum 2 illustrations, compared to the style of Spectrum 1: Similar to icons and text, all linear illustrations now use Spectrum gray 800 instead of gray 500. This meets accessibility standards by ensuring visibility regardless of the background color. These illustrations have a much closer connection to the icon metaphors and forms, for a consistent and cohesive visual language. Linear illustrations feature rounder and friendlier forms, making them feel more approachable. The compositions are also less cluttered and more clear, to promote focus and scaleability. The S2 illustrations come in three sizes: S (48×48 px), M (96×96 px), and L (160×160 px). These sizes are in line with the spacing tokens, and provide more flexibility for layouts. With the introduction of gradient illustrations, there's now an option for illustrations with more color. Color creates more expressiveness and brand integration, as well as supports multiple levels of attention hierarchy."
|
|
12
|
+
},
|
|
13
|
+
{
|
|
14
|
+
"type": "guideline",
|
|
15
|
+
"content": "Spectrum 2 illustrations have two styles: linear (monochromatic) and gradient (color). Both have specific use cases. If you’re not sure about which style is appropriate for your use case, please reach out to the Spectrum Brand team for support. Do not create your own illustrations, or use 3rd-party assets. Illustrations are very visible parts of our design system that drive the consistent look and feel to our products, so they need to be used strategically and thoughtfully."
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"type": "guideline",
|
|
19
|
+
"content": "The Spectrum 2 linear illustrations are an evolution of the Spectrum 1 outline style. The Spectrum 2 icons serve as the blueprint; they follow the same metaphors and are drawn in a similar way. Linear illustrations are monochromatic. They use the same color token as the icons (S2 / gray 800), and switch colors according to dark and light UI."
|
|
20
|
+
},
|
|
21
|
+
{
|
|
22
|
+
"type": "guideline",
|
|
23
|
+
"content": "Sizes.\n\nLinear illustrations come in three sizes: small (48×48 px), medium (96×96 px), and large (160×160 px). Small and medium are the most commonly used sizes; large is not used as often. For most use cases, the medium size works well across mobile, tablet, and desktop."
|
|
24
|
+
},
|
|
25
|
+
{
|
|
26
|
+
"type": "guideline",
|
|
27
|
+
"content": "Color.\n\nThe linear illustrations use Spectrum gray 800, and switch between light and dark UI. For production, the SVGs in the A4U libraries use embedded tokens, similar to the structure of the icons. This ensures that they can programmatically switch depending on UI brightness or color theme. The components in the Figma library use the S2 / Variables tokens."
|
|
28
|
+
},
|
|
29
|
+
{
|
|
30
|
+
"type": "guideline",
|
|
31
|
+
"content": "Naming convention.\n\nLinear illustrations use the following naming convention: Prefix identifies it as part of a larger group of assets: in this case, S2 (Spectrum 2). Type is the type of the asset: lin for linear illustration. Illustration name is in camel case, and there are no empty spaces or individual characters allowed. Illustration size is stated in pixels at @1x. Filetype suffix indicates the asset format, like SVG or PNG."
|
|
32
|
+
},
|
|
33
|
+
{
|
|
34
|
+
"type": "guideline",
|
|
35
|
+
"content": "Use cases.\n\nLinear illustrations are straightforward and clear UI illustrations for a variety of use cases, such as empty states or error messages. They support calls to action — like a drop zone illustration, or an empty state illustration — that explain the next steps for how to use the interface in order to get started or move forward. A good example of a use case for a linear illustration is with the illustrated message component."
|
|
36
|
+
},
|
|
37
|
+
{
|
|
38
|
+
"type": "guideline",
|
|
39
|
+
"content": "Sizes.\n\nGradient illustrations come in the same sizes as the linear illustrations: small (48×48 px), medium (96×96 px), and large (160×160 px). For most use cases, the medium size works well across mobile, tablet, and desktop."
|
|
40
|
+
},
|
|
41
|
+
{
|
|
42
|
+
"type": "guideline",
|
|
43
|
+
"content": "Colors.\n\nThe colors of the gradient illustrations use Spectrum’s 6.0.0 color system. They're tied to the different Adobe product categories and individual products. There are two gradients that can be used for surfaces that show different products, or that are not product-specific. The other gradients are tied to specific products or clouds. For example, blue is tied to the photography and digital imaging category (such as Photoshop, Lightroom, and Fresco), while green represents the 3D category (such as Substance 3D Stager and Substance 3D Designer). It’s essential to use the appropriate illustration colors according to the product categories. If the application is for multiple products, use one of the gradient swatches that incorporate the Adobe brand red. Do not use the category gradient sets as semantic colors to communicate meanings like errors (red), warnings (yellow), or successes (green)."
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"type": "guideline",
|
|
47
|
+
"content": "Naming convention.\n\nGradient illustrations use the following naming convention: Prefix identifies it as part of a larger group of assets: in this case S2 (Spectrum 2). Type is the type of the asset: fill for gradient illustration. Illustration name is in camel case, and there are no empty spaces or individual characters allowed. Category differentiates the different gradient fill colors. The categories include: allproduct1, allproduct2, 3D, DC, drawing, DVA, express, EC, photo, and print. Illustration size is stated in pixels at @1x. Filetype suffix indicates the asset format, like SVG or PNG."
|
|
48
|
+
},
|
|
49
|
+
{
|
|
50
|
+
"type": "guideline",
|
|
51
|
+
"content": "Illustrations and attention hierarchy.\n\nThe different styles of illustrations are connected to the Spectrum 2 concept of attention hierarchy. Linear illustrations are elements that communicate lower attention, as they blend in well with the rest of the UI. They can be used multiple times in a layout without drawing too much attention. Gradient illustrations are high attention elements that should be used sparingly and selectively. Only one illustration, element, or group of elements should have high attention on a page. Learn more about this with the Spectrum 2 attention hierarchy guidelines."
|
|
52
|
+
},
|
|
53
|
+
{
|
|
54
|
+
"type": "guideline",
|
|
55
|
+
"content": "Use linear illustrations for errors or critical messages.\n\nErrors or critical messages should only use linear illustrations. Gradient illustrations use colors that can be misunderstood as semantic colors (e.g., green for positive, red for negative). They also have an upbeat and inspirational tone, which isn’t appropriate in situations where a user may be frustrated by something that’s an inconvenience or is disruptive to them in accomplishing their work."
|
|
56
|
+
},
|
|
57
|
+
{
|
|
58
|
+
"type": "guideline",
|
|
59
|
+
"content": "Use linear style when showing several illustrations together.\n\nThe linear illustration style works well for layouts that feature a number of illustrations together (such as a collection of cards). Linear illustrations draw a lower level of attention and blend in well with the UI, so it’s appropriate to use them in a collection of elements. Gradient illustrations draw a lot of attention in multiples, so they need to be used sparingly and sparsely."
|
|
60
|
+
},
|
|
61
|
+
{
|
|
62
|
+
"type": "guideline",
|
|
63
|
+
"content": "Don’t resize illustrations.\n\nDon’t scale or resize linear illustrations. The stroke weight and the corner radii are already set to work best in the given canvas sizes."
|
|
64
|
+
},
|
|
65
|
+
{
|
|
66
|
+
"type": "guideline",
|
|
67
|
+
"content": "Don’t create your own linear illustrations.\n\nIt’s essential to have consistency in tone and metaphors across all Adobe products. Don’t create your own linear illustrations or alter existing ones. If you need a new linear illustration, make a request using Workfront."
|
|
68
|
+
},
|
|
69
|
+
{
|
|
70
|
+
"type": "guideline",
|
|
71
|
+
"content": "Don’t recolor illustrations.\n\nAlways use gray 800 for the illustration color. Using semantic colors (red, orange, green, blue) can help reinforce meaning, but should be considered on a case-by-case basis."
|
|
72
|
+
},
|
|
73
|
+
{
|
|
74
|
+
"type": "guideline",
|
|
75
|
+
"content": "Use gradient illustrations thoughtfully.\n\nGradient illustrations are high attention elements in the layout. Use them strategically and thoughtfully to draw the user’s attention and to provoke a delightful moment."
|
|
76
|
+
},
|
|
77
|
+
{
|
|
78
|
+
"type": "guideline",
|
|
79
|
+
"content": "Don’t show more than one gradient illustration at a time.\n\nGradient illustrations draw more attention because they’re very colorful. Using more then one in a given view will make the UI too busy and too loud. Use gradient illustrations sparingly to guide a user’s attention to engaging, high-value actions such as uploads, starting projects, or commenting."
|
|
80
|
+
},
|
|
81
|
+
{
|
|
82
|
+
"type": "guideline",
|
|
83
|
+
"content": "Don’t use gradient illustrations for error or critical messages.\n\nGradient illustrations incorporate product category colors, and also include colors that have semantic meanings in Spectrum: red, orange, or green. It creates inconsistency and confusion to have an error message or a critical alert in green (a color has a positive semantic meaning). Use gradient illustrations when you want to emphasize positive actions. Gradient illustrations have an upbeat and inspirational tone, which isn’t appropriate in situations where a user may be frustrated by something that’s an inconvenience or is disruptive to them in accomplishing their work."
|
|
84
|
+
},
|
|
85
|
+
{
|
|
86
|
+
"type": "guideline",
|
|
87
|
+
"content": "Don’t create your own gradient illustrations.\n\nIt’s essential to have consistency in tone and metaphors across all Adobe products. Don’t create your own gradient illustrations or alter existing ones. If you need a new gradient illustration, make a request using Workfront."
|
|
88
|
+
},
|
|
89
|
+
{
|
|
90
|
+
"type": "guideline",
|
|
91
|
+
"content": "Use the correct colors for your product.\n\nThe colors in gradient illustrations are connected to the product categories. For example, an illustration for a Substance 3D product should use the Substance 3D green colors. Do not use different colors than those of your product category. Reach out to the Spectrum Brand team for guidance about the appropriate colors for your use case."
|
|
92
|
+
},
|
|
93
|
+
{
|
|
94
|
+
"type": "guideline",
|
|
95
|
+
"content": "Test if gradient illustrations work well in your layout.\n\nIt’s highly recommended to test gradient illustrations as you’re designing your layout. They’re very expressive and colorful, so it’s important to determine how they complement (or don’t) different communication points (e.g., user-generated content, onboarding, feature banners, upsells, and more). If gradient illustrations are making the layout too noisy, use linear illustrations instead."
|
|
96
|
+
},
|
|
97
|
+
{
|
|
98
|
+
"type": "guideline",
|
|
99
|
+
"content": "Thematic banners are descriptive and represent a specific topic or feature. Similar to the gradient illustrations, they’re either connected to the product brand categories by color, or they use the generic gradient swatches. These banners use the same shapes, metaphors, and elements as the linear illustrations, but they have a distinct style that is combined with the gradients and colors of the gradient illustrations. With their size, usage of color, and high editorial quality, thematic banners are high on the attention hierarchy scale. In layout, they work best when used to promote positive and high-impact moments, such as announcing new features. Because of this, they should be used sparingly. Thematic banners are created on a case-by-case basis by the Spectrum Brand team. You can request thematic banners through this Workfront request form. There is no asset library for thematic banners because they have unique needs for each product use case."
|
|
100
|
+
},
|
|
101
|
+
{
|
|
102
|
+
"type": "guideline",
|
|
103
|
+
"content": "Before you work with these illustrations, please familiarize yourself with the usage guidelines here. You’ll especially need to understand the differences in how to use the linear and gradient illustrations. For new or existing illustrations, please submit a request through this Workfront form. You can also reach out to the Spectrum Brand team with any questions on Slack in #product-branding or by email. To view existing S2 Illustrations, visit the S2 / Illustrations library in Figma. The assests from this library are also available in A4U for production and engineering assets (VPN access required)."
|
|
104
|
+
}
|
|
105
|
+
],
|
|
106
|
+
"sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/visual-language/illustration",
|
|
107
|
+
"lastUpdated": "2026-08-19",
|
|
108
|
+
"status": "published"
|
|
109
|
+
}
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
|
|
3
|
+
"$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/in-product-word-list.json",
|
|
4
|
+
"name": "in-product-word-list",
|
|
5
|
+
"title": "In-product word list",
|
|
6
|
+
"category": "designing",
|
|
7
|
+
"documentBlocks": [
|
|
8
|
+
{ "type": "purpose", "content": "In-product word list" },
|
|
9
|
+
{
|
|
10
|
+
"type": "guideline",
|
|
11
|
+
"content": "Consistent language builds user trust and strengthens their knowledge that a product is meeting their needs. Using inconsistent vocabulary across Adobe’s apps and products can be confusing to users, and it makes it harder for those creating education and documentation. Below is a list of words that we either recommend using, or suggest avoiding. Some words are noted as internal-only jargon at Adobe. We’ve still included these in this list because, while we may use them internally when we work on or talk about our products, they occasionally appear in user-facing content in ways that aren’t clear, intuitive, or appropriate. For capitalization guidance, view the Grammar and mechanics page for the UX writing style guide. Keep in mind that some terms are branded and follow Adobe Brand Guidelines for styling and usage. This list is regularly updated and is by no means complete. If you have words you’d like to submit for consideration, please fill out this suggestion form. The Adobe Design Content Strategy team reviews suggestions once a quarter, and will get in touch if they need more information."
|
|
12
|
+
},
|
|
13
|
+
{
|
|
14
|
+
"type": "guideline",
|
|
15
|
+
"content": "Consistent language builds user trust and strengthens their knowledge that a product is meeting their needs. Using inconsistent vocabulary across Adobe’s apps and products can be confusing to users, and it makes it harder for those creating education and documentation. Below is a list of words that we either recommend using, or suggest avoiding. For capitalization guidance, view the Grammar and mechanics page for the UX writing style guide. Keep in mind that some terms are branded and follow Adobe Brand Guidelines for styling and usage. This list is regularly updated and is by no means complete. If you have any questions or seek clarity on any words on this list, you can email us. Word or Phrase Status Usage Notes addUse with caution In Creative Cloud products, to add is to bring already existing assets into a certain browser or view. In Experience Cloud products, this word is reserved for images. For example: Add PNG Add images, fonts, styles, and more to a library to keep what you need nearby. Avoid using the word add for the action of inviting people to a document or other shareable resource. affordanceAvoidInternal jargon used as a word to describe a feature or a control. Do not use the word affordance in UI copy, and refer to the action that a component is used for instead.appPreferred App is preferred over application for the sake of brevity, simplicity, and because app is so widely used now to describe both desktop and mobile software applications.applicationUse with caution App is preferred over application for the sake of brevity, simplicity, and because app is so widely used now to describe both desktop and mobile software applications.assetUse with caution Jargon for any file, element, or content that a user needs to complete their goal, as well as the output of completing that goal. At Adobe, this includes things such as desktop-synced files, mobile creations, Creative Cloud libraries, images, fonts, colors, gradients, or CSS information. Asset is a generic word and has multiple meanings which can be conflicting or ambiguous. For example, there are assets that are part of a creative agency workflow, and there are assets to describe a generic grouping of disparate items. Try to avoid using this word if possible. Instead, be more specific and describe what something is, such as a video or an illustration. If you can’t, proceed with asset. auto / auto-Use with caution For feature names and UI labels, use the adjective form (e.g., Auto tag, Auto crop, Auto analyze, Auto save ). New names and labels that use auto require the Brand team’s approval. In general references, use the combining form (e.g., auto-tag, auto-crop, auto-analyze, auto-save ). When describing how UI elements with auto labels work, generally spell out automatic or automatically. available / not availablePreferred Use not available to describe an app, service, or control that temporarily can’t be accessed or used (e.g., an app is taken down for maintenance). View also supported / not supported. beginPreferredPreferred for descriptive text. For a call-to-action, use start.blacklistAvoid This word has roots in racism and oppression. Replace it with this format to provide contextual clarity: (Action)(object) For example: Blocked users Prohibited IP addresses buttonPreferred When referring to a specific button in an interface, try to refer to the action (e.g, undo, edit ) rather than naming the button. If you need to refer to the interface element directly, capitalize and bold the name of the button but not the word button itself (e.g., Undo button, Edit button ). clickAvoid Avoid instructing a user to click or tap. Instead, use a call-to-action and the right design component to imply the interaction. View select. When you need to refer to the result of clicking on something, use the same words as the call-to-action. closePreferred Use close as a catchall term for a dismissal action. It can also reference OS-specific patterns. Whenever possible, use workflow-specific verbs (e.g., publish, export, delete ) to reinforce the action being taken, instead of the more generic close, finish, or OK. cloud docsAvoid Internal-only jargon. View cloud documents. Amended guidance to come on the rare exception to this rule. Abbreviate as cloud docs in English on mobile when called for due to space constraints. cloud documentsPreferred Use across Creative Cloud products, experiences, and messaging as a functional name, and not as a branded feature of Creative Cloud. Do not capitalize cloud documents on its own. For product UI, align to the interface style specific to the design component (e.g., if all caps, use all caps; if title case, use title case). Only attribute this to relevant apps such as XD or Photoshop, and never to Creative Cloud. (e.g., XD cloud document, not: Adobe Creative Cloud cloud document ). Do not shorten to cloud docs or documents in product UI, marketing, or messaging. Translate this where other functional names are also translated. Amended guidance to come on the rare exception to this rule. Abbreviate as cloud docs in English on mobile when called for due to space constraints. continue / cancelPreferredUse continue and cancel as dual actions in workflows where there is only one way to move forward and it’s not possible to skip or go back steps.courseUse with cautionUse sparingly to describe a sequential arrangement of multiple tutorials that form a cohesive learning experience. Use words like tutorial, tutorials, or tutorial series instead.createUse with caution Create should only be used descriptively (e.g., Use everyday language to create extraordinary results with generative AI ). Do not use create as a UI action in the context of generative AI technology, where content is generated rather than created. creditsUse with cautionView generative credits current version / previous versionAvoidWhen referring to apps, latest version / older version is preferred.custom modelsRequired A model that has been trained on a unique style (e.g., Firefly custom models). Do not use title case. This is not a branded term. dismissAvoid Avoid using dismiss as an action to signify acknowledgement or completion. Use OK instead. This word can be acceptable in rare cases of when the action being taken is a “hard dismiss,” or the equivalent of a user communicating that they do not want to be shown something ever again. If possible, show an icon-only close affordance (typically, a cross icon) if appropriate to the component, to indicate dismissal. documentPreferred Documents is commonly used in Document Cloud to refer to files in general, of any file format. In Creative Cloud, use the word file for a local document, to better distinguish from cloud documents. While all cloud documents are files, not all files are cloud documents. Similarly, all documents are files, but not all documents are cloud documents. doneUse with caution Close and finish are preferred over done for a dismissal call to action. In general, stick to verbs (like close ) over adjectives (like done ) to label actions — verbs more clearly reflect whatever action the user is taking. Use done as an acknowledgment or call to action for a standalone button in a modal, dialog, or overlay when it wouldn’t make sense for the context to use finish, close, or OK. Done conveys finality, allowing users to signal that they no longer want to interact with a given element. downloadPreferred When writing instructional copy, word choice should mirror that of the OS. Otherwise, use download only when referring to the transfer of assets or files from a server onto a device. When guiding users through an installation or update flow, be explicit about the different steps they will take. View also install. drag and dropUse with cautionInstructions for interactions should use the same words that the OS does.edit inAvoidSee open in.embedPreferred Placing an embedded file means that it is no longer connected to the original source file. This saves a static copy of the file’s content into the destination file. For example: Embed a PDF as an image layer in Fresco Place an image as an embedded object to save a copy right here in your Photoshop file. Place as embedded enable / disableAvoidThese terms are needlessly technical to convey the more straightforward on / off. Use turn on / turn off to refer to the actions of activating and deactivating a capability or mode.entitlementUse with cautionInternal-only jargon, along with entitlement-aware, to describe access to a particular app or program.exportPreferredUse export when a file will be saved in a different format than it was created in. If the file will be opened as-is in a different app than it was created in, use open in.fail, failureUse with caution Fail and failure are vague technical terms with a strong negative connotation. Avoid using these words in error messaging when you can be specific about what the problem was. View also success, successful, successfully. featureUse with cautionA single, outcome-oriented functionality of a product or service. Determining if something is a feature happens through a partnership between product, marketing, and branding. This word should not be used to mean “everything in a product.”file namePreferredTwo words. Use instead of one word, filename, in user-facing content. A filename is the technical name that a file system creates (and includes the file type extension). The file name is the name for the file that a user creates.file typePreferred Two words. Use instead of one word, filetype, to refer to file formats such as PNG, JPEG, PDF, PSD, AI, PSDC, etc. Do not abbreviate file types unless there is a character constraint. View JPEG. finishPreferred Use finish in headlines, body copy, or metadata to describe the completion of a user-invoked process or flow. Finish can be used for the last step of interactive learning experiences. Use it strategically in user-driven experiences, not for things that launch automatically. freeUse with caution When using free to describe to an Adobe offering, the offering and all of its features must: cost nothing not require a credit card or subscription for download or use Use free trial to refer to both trials that require payment information and trials that do not. View also freemium. free trialPreferred Free trial is the legally required term for trials with payment, which require a credit card to start the free trial and then automatically convert to a paid subscription after the trial period is over. It is also the preferred way of referring to trials without payment. In the initial call to action for trials with payment, it is required to use one of the following: Start free trial Free trial Start free trial to subscribe Agree and start free trial freemiumAvoid Do not use the word freemium in UI copy. A freemium app is internal jargon for an app that is free to use but requires a credit card payment if the user wants to access its premium features. In the initial call to action for a freemium app, use one of the following: Start for free Download for free Start now Download Get started For actions within a freemium app that do not require a credit card payment or subscription, use “free to try” or “free to edit.” gen techAvoidDo not use gen tech to describe generative AI or other kinds of AI.generateRequired Use generate as a UI action in the context of generative AI technology across the Adobe product ecosystem, where content is generated rather than created. Generate is the initial action as well as the action any time an existing prompt is modified or changed in some way. It is also used where variations are replaced/destructive (formerly refresh ). generate againRequired Not common. Use generate again instead of generate where a single variation is replaced (whether destructive or not) and the use of generate isn't clear enough (e.g., the generative extend feature in Premiere Pro). Use generate more for sets of multiple variations. generate moreRequiredUse generate more instead of load more where variations are stacked (formerly load more ).generate similarRequiredUse generate similar instead of show similar.generationsUse with caution Use generation or generations as a noun to refer to the act of producing output in the context of a Creative Cloud plan or feature. For example: This feature uses 100 credits per generation. Each generation outputs 4 images. Your complimentary generations have been used. generative AIRequiredDo not use GenerativeAI, GenAI, Gen AI, or other shorthand for generative AI.generative creditsPreferredUse to describe Creative Cloud generative credits. OK to shorten to credits on second mention only, if the generative credits context is clear.got itAvoid Got it is overly colloquial. Use OK instead.importUse with caution In most Creative Cloud products, this word means to convert a file to a different format to open it in an application. For Adobe’s video products, import has a broader definition, encompassing add and place. This is because people using these products collect files of different formats into a single view, and then those are converted or “ingested” as links to improve machine performance. For example: Learn more about the supported file formats you can import in Premiere Pro. Go to File > Import to open a Sketch file in XD. In Experience Cloud products, import can refer to adding data sources to a view. View add. in the cloudPreferred Use in the cloud (not on the cloud ) to describe a process that is part of the cloud or deployed using cloud software, like cloud storage and cloud rendering. Do not use with the cloud except in phrasing like “software with cloud services.” View also to / from the cloud. installPreferred When writing instructional copy, word choice should mirror that of the OS. Otherwise, use install (verb) or installation (noun) to describe the process of adding and making software usable on a device. When guiding users through an installation or update flow, be explicit about the different steps involved. For example, don’t use an Install call to action if the user will be redirected to a store or website. View also download. intelligentAvoidDo not use intelligent in naming any UI element.JPEGPreferredUse the full form JPEG, not JPG.latest version / older versionPreferredPreferred over current version / previous version when referring to apps.launchAvoidWhen referring to apps or services or an aspect thereof (e.g., a new window), open is the preferred action.lessonAvoidThe Learn team does not use this term at all. Avoid in UI content.linkPreferred Placing a linked file turns it into a reference to the original source file. Changes made to the placed content in the destination file or to the original source file will be reflected and updated automatically in both locations. For example: Go to File > Place > Linked object to make changes to the Photoshop file from here. Place a linked PDF if you want it to be updated automatically when you edit the PDF. loadUse with caution Preferred for messages like Loading…, Loading {appName}…, Can’t load page, or similar. Use open as an action in reference to an app or service or an aspect thereof (e.g., Open {appName}, Open a new window ). load moreUse with cautionView generate more lock / unlockPreferred To lock something is to freeze it at the current moment in time and prevent changes to its contents. When something is locked, objects associated with it can’t be selected or altered. To unlock something allows a user to select and edit it. These actions are usually represented in the interface via an open or closed padlock icon. long pressUse with cautionInstructions for interactions should use the same words that the OS does.magicAvoidDo not use magic in naming any UI element.masterAvoid Master is an established software term that has roots in bigotry and oppression. Do not use master descriptors to mean primary, main, or source (e.g., main track or source graphic ). Do not use master to describe hierarchy, (e.g., master and slave servers). Instead, describe hierarchical relationships as primary, secondary, tertiary, etc. More menuPreferred In interface language, try not to directly refer to the ellipsis (“…”) contextual menu that provides more options. If you need to refer to it directly, call it the More menu. Bold the word More and capitalize it; menu is lowercase, not bolded. namePreferredAnother word for file. Do not use title to mean name.next / backPreferredUse next and back in workflows (e.g., tours, tasks) where someone would be going back and forth in the flow.next / previousPreferredUse next and previous for pagination (e.g., pages of search results).OKPreferred Use OK as a primary action for acknowledgement if taking that action will not impact a user in a negative way. Style in all-caps no matter the interface element, not as Ok, ok, Okay, or okay. Avoid using dismiss as an action. Be mindful of using OK as an action in flows that involve a user agreeing to options that require payment, or for giving consent. Instead, use more specific verbs and explicitly communicate what someone is acknowledging or agreeing to. on the cloudAvoidView in the cloud and to / from the cloud.one-of-a-kind XAvoidDo not describe generative AI content as one-of-a-kind. We cannot guarantee that all generated content will be 100% one-of-a-kind unique.openPreferredUse open as an action in reference to file, app, service, or an aspect thereof (e.g., Open a new window ).open inPreferred Open in is preferred over edit in, view in, comment in or similar because it is secondary action-agnostic and doesn’t guess at what the user might want to do (e.g., edit, view, review, comment). Secondary actions can be referenced in supporting copy if necessary for a particular flow or context (e.g., “This file is view only on web. To make edits or leave comments, open it in the desktop app”). If the app context is clear (e.g., the user is in Photoshop web and wants to open something on Photoshop desktop), it’s preferred to say, Open in {surface} app (e.g., “Open in desktop app”) for the call to action. If the app context will change (e.g., the user is in Photoshop web and wants to open something on Illustrator desktop), it’s preferred to say, Open in {appName} {surface} and drop app (e.g., “Open in Illustrator desktop”) for the call to action. OSPreferredAbbreviation of operating system. It's also acceptable to spell out the full term, if needed for extra clarity.panelUse with caution Avoid referring to the names of interface elements in UI content unless absolutely necessary; describe the action, rather than the interaction. You can describe something as a panel if it’s a centralized collection of multiple tools, options, or other controls that has a fixed placement and could be collapsible as a navigational element (as opposed to being a temporary view). pinchUse with cautionInstructions for interactions should use the same words that the OS does.placePreferred Placing brings content (e.g., images, other files) from an original source into a destination file. For example: You can place an Illustrator file into your XD layout. One way to bring an image into your Photoshop file is to go to File > Place. Things can be placed as linked or embedded files. platformUse with caution A platform is a technology or group of technologies that are used as a base upon which other applications, processes, technologies, or even other platforms are developed. This word is used to communicate the concept of a centralized, foundational infrastructure (as opposed to a system, which is a grouping of things that work together in the same place). Usage of this word is extremely dependent on context. It can describe where something appears, where something is stored, or a product itself: A tech framework (e.g., UXP) Hardware and devices (e.g., mobile, tablet, desktop) Operating systems (e.g., Android, iOS) Adobe products (e.g., Adobe Experience Platform) playlistUse with cautionUse series to refer to a list of tutorials in a sequence (e.g., “Select the second tutorial in the series”).pleasePreferredUse in an instructional way, and in error messages when asking a user to do an action that requires significant effort or time (e.g., Please provide feedback, Please reload the page ).pluginPreferredOne word, with no hyphen (not: plug-in ).preferencesUse with caution For both web and mobile apps, treat preferences as a subset of settings and in menu names, call out the type of settings (e.g., Preferences may be found under App settings or Account settings ). A user can customize, choose, or select preferences for various things within a settings menu rather than setting their preferences. pressUse with cautionInstructions for interactions should use the same words that the OS does.productUse with caution Internal-only jargon. Use sparingly to describe a self-contained experience that provides a user with a specific benefit (e.g., Creative Cloud is a collection of products ). To those outside of Adobe, a product is often thought of as a name-branded thing that is a countable unit of sale that may be downloaded to a device (e.g., one Adobe Photoshop subscription ). Use the word app to describe this concept. programAvoidUse app instead.promptUse with cautionOK to use prompt consistently in your product if approved by Content Strategy, Brand, and Legal. Eventually we may all move to something like input.quitAvoid Avoid this word especially as a call-to-action because it is platform-specific. While you can quit on MacOS, you can exit or close on Windows. Quit can be used generally as a reference to this action on MacOS. railAvoid Internal-only jargon used to describe the UI element that spans the top or the bottom of a screen. To make accessible products, this word should not be used in UI content. Instead, be more directive. If you need to refer to this design element in your product, try to write around describing its appearance and instead talk about its function. For example, talk about the actions or the feature names inside the rail, rather than the rail itself. recalledAvoid Whenever possible, use generic language such as not supported or not available to describe an app or service that can’t be used. Words like revoked, recalled, or rescinded have negative connotations, often making users feel like they’re being scolded or fearful of losing work. Instead of getting into the reason for an error, guide users to a resolution. View also the Spectrum Writing for errors page. recommend, recommendationPreferred Use recommend (verb) and recommendation (noun) for when a human is doing the action (e.g., “We recommend backing up your work before sharing”). To suggest or make a suggestion is the preferred way to describe when AI or other technology is doing the action. redlineAvoid Redline is a common design term that has roots in racism and oppression. To refer to the details, parameters, or attributes of a design that are communicated to engineers for implementation, use specifications or specs instead.reference XRequiredWhen using a reference to generate content (e.g., an image), use reference X to label or refer to this element (e.g., reference image ).refreshPreferredUse refresh as the action to view page or screen updates, or to fix issues (e.g., “Refresh this page and contact support if the issue persists”).regenerateAvoidDo not use regenerate. View Generate, Generate again, Generate more, Generate similar.relaunchAvoid Restart is the preferred action for any hardware, process, app, or service, regardless of desktop, mobile, or web surface context.reloadUse with cautionThere may be a technical reason why we’d want to use reload, but for most use cases we can say things like Refresh this page, Restart the app, and so on.rescindedAvoid Whenever possible, use generic language such as not supported or not available to describe an app or service that can’t be used. Words like revoked, recalled, or rescinded have negative connotations, often making users feel like they’re being scolded or fearful of losing work. Instead of getting into the reason for an error, guide users to a resolution. View also the Spectrum Writing for errors page. restartPreferredUse restart as an action in reference to an app, service, device, process, or workflow.resultsUse with caution Avoid results as a label or description of generated content in generative AI creative modules, features, or tools. View variations. OK to use in things like tooltips to describe an effect (e.g., move an object for a desired result ). revokedAvoid Whenever possible, use generic language such as not supported or not available to describe an app or service that can’t be used. Words like revoked, recalled, or rescinded have negative connotations, often making users feel like they’re being scolded or fearful of losing work. Instead of getting into the reason for an error, guide users to a resolution. View also the Spectrum Writing for errors page. runUse with cautionUse run to describe scenarios where a machine or system is the actor rather than the user (e.g., run a report, run a script, or run a simulation ).scrollUse with cautionInstructions for interactions should use the same words that the OS does.seeAvoidIn order to be more inclusive, avoid using the word see. Use the word view instead. For example, instead of See all results, say View all results.selectPreferred Select is the preferred gestural word over click or tap for several reasons: It’s device-agnostic, meaning that it’s not necessary to write a new string for different devices. It’s more inclusive because many people using assistive technology aren’t clicking or tapping to take an action. It guards against future design changes and surface migrations. For example, if a UI element stops being clickable and instead uses a slider, the word select would still work for both cases. send toAvoidUse open a copy or open a copy in instead. View also open in.seriesPreferred Series refers to a list of tutorial videos. Use sparingly, such as a tutorial series or series of tutorials. Preferred over playlist.servicePreferred Describes content, components, data, and/or dynamic features. At Adobe, this word is used contextually across many things (e.g., plugins, cloud storage, search, help) to describe “something that Adobe offers.” A service may be something that is contained to a single product or experience, or something that is available across multiple offerings. It’s often designed for a use case that relies on the functionality of a platform. settingsPreferredIn menu names, describe the type of settings (e.g., App settings, Account settings ). See also preferences.show similarUse with cautionView generate similar skipPreferredOK to use as a call-to-action in stepped flows, such as a coach mark series.smartAvoidDo not use smart in naming any UI element.softwareUse with cautionPrograms and other services that are used by a device. Only use software when the words app, service, or product are not sufficient for the use case.solutionUse with caution Jargon. Solution is often used interchangeably with app or product, and can describe something that integrates into a larger whole. It’s often used to talk about something descriptively in terms of its use case (instead of its product or feature name) as a way to achieve a goal or complete an intent. However, people may feel excluded by this word; if something is described as a solution and it doesn’t work for someone, they could feel that they themselves are the “problem.” Instead of using the noun solution, frame the message using active verb phrases such as solve, help solve, try to solve, or helps (someone) do (something). sorryUse with cautionOnly use the word sorry in error messaging scenarios where the error causes a major interruption and inconvenience for a user (e.g., needing to restart their device, if work they had saved was lost).spacePreferred The amount of room available. Space refers to this concept on a local machine or device (e.g., “You don’t have enough space on your computer to save this file”). Storage is the word for this in the cloud (e.g., “Your Creative Cloud storage is full”). startPreferredPreferred over begin for calls-to-action. Variations on this call-to-action using the word start are also acceptable (e.g., Start tour ).startPreferredUse start as an action in reference to a device, process, or workflow.storagePreferred The amount of room available. Storage refers to this concept in the cloud (e.g., Your Creative Cloud storage is full ). Space is the word for this on a local machine or device. (e.g., You don’t have enough space on your computer to save this file ). stuffAvoidThis word is a U.S.-centric colloquialism used to describe things without specificity, and is difficult to accurately localize. Do not use the word stuff in UI copy, and refer to items directly instead (e.g., files, not your stuff ).submitPreferred Submit is the preferred word for the action of sending data in a form. When asking users to share feedback, use Submit as the call-to-action, not Share. success, successful, successfullyAvoidAdding success, successful, or successfully to a message is usually redundant and unnecessary. For example, say “Your password was reset” instead of “Your password has been reset successfully.”suggest, suggestionPreferred Use suggest (verb) or suggestion (noun) for when AI or other technology — not a human — is doing the action. To recommend or make a recommendation is the preferred way to describe when a human is doing the action. supported / not supportedPreferred Use not supported or no longer supported as a catch-all descriptor for an app or service that permanently can’t be accessed or used (e.g., an outdated or unauthorized app version). View also available / unavailable. surfaceAvoidInternal-only term for a consumer-facing framework that delivers content or services to a user. A product may have multiple surfaces (e.g., Adobe.com, Creative Cloud desktop, mobile, and web).swipeAvoidInstructions for interactions should use the same words that the OS does. Reserving swipe actions for intuitive actions in-line with the mobile OS should make it unnecessary to use this word in UI copy.switch on / switch offUse with caution Turn on / turn off is preferred over switch on / switch off because it's a more general and accessible way of referring to the actions of activating and deactivating a capability or mode. Only use switch on / switch off when there is a need to refer to a switch UI component directly in interface copy. In these rare cases, the action/verb should closely match the component/noun. The phrase “switch between modes” is OK to use. tabPreferredWhen referring to a specific tab in an interface, respect the capitalization of the name of the tab as it appears in the UI but don’t capitalize the word “tab.” Bold the name of the tab but not the word tab (e.g., Learn tab, Your Work tab, Apps tab ).tapUse with caution If at all possible, avoid instructing a user to tap or click. Instead, use a call-to-action and the right design component to imply the interaction. View select. When referring to the result of tapping on something, use the same word(s) as the call-to-action. There are some instances where using the word tap can't be avoided because of device mechanics, such as selecting points on a tablet. templatePreferredA template is a document that has been pre-formatted or contains pre-formatted elements so that a user doesn’t have to start from scratch. Use template rather than starter file or other jargon for templates.titleAvoidFor field labels, name is the preferred word for a file name or for the name of another kind of entity. Do not use title to mean name.to / from the cloudPreferred Files are uploaded (or backed up) to the cloud and downloaded from the cloud. View also in the cloud. toggleAvoid Jargon used as a verb to describe the action of switching between two modes, or used as a noun to describe the button or switch for going between two modes. To make accessible products, do not reference UI elements. If you need to refer to this design element or what it does in your product, write around describing its appearance and instead talk about its function. View turn on / turn off. toolPreferredWhen referring to a specific tool in an interface, respect the capitalization of the name of the tool as it appears in the UI but do not capitalize the word tool. Bold the name of the tool but not the word “tool” (e.g., Zoom tool, Pen tool, Undo tool ).touch and holdAvoidInstructions for interactions should use the same words that the OS does.trialAvoidSee free trial.turn on / turn offPreferredUse turn on / turn off to refer to the actions of activating and deactivating a capability or mode.tutorialPreferredCan be used to describe a single tutorial, or a series of two or more tutorials.unique XAvoidDo not describe generative AI content as unique (e.g., unique images ). We cannot guarantee that all generated content will be 100% one-of-a-kind unique.updatePreferredUnlike an upgrade, an update does not usually require payment (e.g., Update your browser, Update your app ).updatePreferred Use update (verb) to refer to the act of replacing software with a new version of itself that brings the system up to date or includes improvements. Use update (noun) to refer to the replacement software version. When guiding users through an update flow, be explicit about the different steps involved. For example, don’t use an Update call to action if the user will be redirected to a store or website. update laterUse with cautionUse Update later as a call to action when presenting the user with the option to defer updating an app or to have an app update automatically when certain installation criteria ( e.g., quitting or restarting) are met. View Update now.update nowUse with cautionUse Update now as a call to action only when the user can choose between updating later and taking the necessary steps to begin updating immediately. View update later.upgradePreferredUnlike an update, an upgrade usually requires payment (e.g., Upgrade your plan, Upgrade to the full version of Photoshop ).User GuidelinesRequired When referring to the Adobe Generative AI User Guidelines, it is always title case User Guidelines on both first and second mention. Do not use other terms or shorthand in place of User Guidelines (e.g., GenAI User Guidelines, GenAI Terms, terms ). variationsRequiredUse variations to label or describe generated content in generative AI creative modules, features, or tools (e.g., Your prompt will generate four variations, AI Assistant generated four image variations in its response ). Avoid results.videoUse with caution Use this word sparingly as a lightweight alternative to describe a standalone tutorial, tutorial series, or course (e.g., “Learn Illustrator step by step in our series of short videos”). Video is a preferred word to use when talking generically about the type of media (e.g., video and audio, video files, video assets ). viewPreferredTo be more inclusive, view is preferred over the word see. For example, say View all results instead of See all results.watermark, watermarkingPreferredUse watermark (noun) to refer to a logo, text, or signature that is superimposed onto an asset. Watermarking (verb) is used for identifying the artist behind the asset, copyright protection, preventing unlicensed usage, or marketing.whitelistAvoid This word has roots in racism and oppression. Replace it with this format to provide contextual clarity: (Action)(object) For example: Shared domains Approved users Targeted sites wifiPreferredAll lowercase, no hyphen or space."
|
|
16
|
+
}
|
|
17
|
+
],
|
|
18
|
+
"sourceUrl": "https://main--spectrum-hub--adobe.aem.live/content/in-product-word-list",
|
|
19
|
+
"lastUpdated": "2026-09-04",
|
|
20
|
+
"status": "published",
|
|
21
|
+
"tags": [
|
|
22
|
+
"UX writing",
|
|
23
|
+
"in-product language",
|
|
24
|
+
"Adobe Brand Guidelines",
|
|
25
|
+
"internal jargon",
|
|
26
|
+
"app vs application",
|
|
27
|
+
"asset terminology"
|
|
28
|
+
]
|
|
29
|
+
}
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
|
|
3
|
+
"$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/inclusive-design.json",
|
|
4
|
+
"name": "inclusive-design",
|
|
5
|
+
"title": "Inclusive design",
|
|
6
|
+
"category": "designing",
|
|
7
|
+
"documentBlocks": [
|
|
8
|
+
{ "type": "purpose", "content": "Inclusive design" },
|
|
9
|
+
{
|
|
10
|
+
"type": "guideline",
|
|
11
|
+
"content": "Inclusive design is part of Adobe’s mission. Designers, engineers, and product builders are invested in learning how to think more broadly, seeking out more voices, and working together to make better experiences. Spectrum also builds for the widest audience possible. Our system is designed to be clearly readable, intuitive to use, and mindful of those who use assistive technology. From how components function to language and internationalization, we consider inclusion to be a top priority."
|
|
12
|
+
},
|
|
13
|
+
{
|
|
14
|
+
"type": "guideline",
|
|
15
|
+
"content": "Assume nothing is perfect.\n\nProvide context-sensitive help to ensure that people can be supported throughout many kinds of interactions. Prevent error conditions wherever possible, and highlight error conditions when they exist. When an error occurs, provide clear guidance about what someone can do to resolve the error by using clear and helpful messaging."
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"type": "guideline",
|
|
19
|
+
"content": "Make room to adapt.\n\nProvide targets large enough to see and interact with. Label and describe all objects. Ensure that designs can be interacted with by mouse, keyboard, pen, fingertips, voice, accessibility API, or other methods. When designing for the web, embrace responsiveness. Accommodate web page size down to 320 px."
|
|
20
|
+
},
|
|
21
|
+
{
|
|
22
|
+
"type": "guideline",
|
|
23
|
+
"content": "Give people a choice.\n\nAllow for someone to customize their experiences within a product, and respect system-wide user preferences such as captions, large fonts, and high contrast. Ensure that every task can be completed in a logical order using only a keyboard."
|
|
24
|
+
},
|
|
25
|
+
{
|
|
26
|
+
"type": "guideline",
|
|
27
|
+
"content": "Avoid distractions.\n\nDon’t place animations near paragraphs of text. Allow users to turn off unnecessary animation."
|
|
28
|
+
},
|
|
29
|
+
{
|
|
30
|
+
"type": "guideline",
|
|
31
|
+
"content": "Be consistent.\n\nUse common components for well-defined tasks and interaction patterns, instead of new or custom-built ones. Use common shortcuts across experiences, and especially within products that accomplish similar tasks."
|
|
32
|
+
},
|
|
33
|
+
{
|
|
34
|
+
"type": "guideline",
|
|
35
|
+
"content": "Involve marginalized users.\n\nInclude people with diverse ranges of ability in user testing, and co-design whenever possible. Seek feedback from historically underinvested communities."
|
|
36
|
+
},
|
|
37
|
+
{
|
|
38
|
+
"type": "guideline",
|
|
39
|
+
"content": "Make documentation a priority.\n\nDocument all accessibility features and workflows (keyboard shortcuts, support for operating system features, etc.), and make it easy to find the information in your product’s help content."
|
|
40
|
+
},
|
|
41
|
+
{
|
|
42
|
+
"type": "guideline",
|
|
43
|
+
"content": "Structure.\n\nEnsure that complex components — such as lists, forms, and panels — have a logical reading order. Check that the keyboard tab order has been defined in a logical progression."
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"type": "guideline",
|
|
47
|
+
"content": "Color.\n\nAvoid referring to objects by color (or by location) alone. Instead, refer to these by their names or by the grouping in which they belong."
|
|
48
|
+
},
|
|
49
|
+
{
|
|
50
|
+
"type": "guideline",
|
|
51
|
+
"content": "High contrast mode in Windows.\n\nWindows high contrast mode is a setting that replaces all colors in the operating system to a simplified high contrast color palette. It includes preset color theme options and allows users to create their own color themes. This is an important feature for users with low vision, contrast sensitivity, and other needs, and should be supported by all Adobe web-based and Windows applications. Spectrum component documentation will include visual references for what the component should look like in Windows high contrast mode. These examples will all be shown in the default Windows high contrast black theme."
|
|
52
|
+
},
|
|
53
|
+
{
|
|
54
|
+
"type": "guideline",
|
|
55
|
+
"content": "Animation.\n\nAvoid making parts of a screen flash more then 3 times per second, to help prevent photo-epileptic seizures. Also, don’t create content that moves or blinks for more than a couple of seconds, to help prevent people from getting distracted."
|
|
56
|
+
},
|
|
57
|
+
{
|
|
58
|
+
"type": "guideline",
|
|
59
|
+
"content": "Interactions.\n\nAvoid “clear”/”reset” actions on forms, since someone could select these by accident and erase a lot of painstaking work. Let people save forms so that they can leave and come back. Provide keywords before or inside of links."
|
|
60
|
+
},
|
|
61
|
+
{
|
|
62
|
+
"type": "guideline",
|
|
63
|
+
"content": "Text alternatives.\n\nInclude a textual label for all elements. There may be a few exceptions, when the context is sufficient (e.g., document zoom level “100%”). Use the label element in HTML where possible. If not, use ARIA to set the label (depending on the context, “aria-label” or “aria-labelledby”). Make sure labels are concise and have a clear association with objects. For objects in a table or a list, make sure that they can be identified by the structure around them (e.g., using a table header). Label all images when possible, and in all cases, include a short, meaningful text alternative. Exceptions are for decorative images as outlined in Guideline 1.1 Text Alternatives in the WCAG 2.1 standards. Provide a long description for any object that requires more information for understanding or operating it (e.g., tooltips and coach marks ), so that those using assistive technology can read it in context. Learn more about creating text alternatives in Spectrum’s Inclusive UX writing guide."
|
|
64
|
+
},
|
|
65
|
+
{
|
|
66
|
+
"type": "guideline",
|
|
67
|
+
"content": "Fonts and text.\n\nUse Spectrum typography and colors to ensure proper type scale, line height, weight, and contrast for blocks of text. Use one column per page, with a width no longer than 80 characters (or 40 CJK characters) wide. Have line lengths at a maximum of 50-75 characters. Organize writing for comprehension. In layouts, left-align running text (this will be mirrored along with the UI for right-to-left languages). Fully-justified text creates text rivers, or irregular alignment of spaces that creates running gaps throughout the text; this makes it more difficult for readers with dyslexia. Avoid switching alignments in a single view. Whenever possible, provide options for people to adjust font size, color themes, and contrast, either manually, in-app, or through operating system preferences."
|
|
68
|
+
},
|
|
69
|
+
{
|
|
70
|
+
"type": "guideline",
|
|
71
|
+
"content": "Error prevention and correction.\n\nAvoid the need for error messages by designing workflows that prevent an error state from even happening in the first place. When there is an error, associate it with the field or element that needs to be corrected or addressed. Make errors visually and semantically different from other messages (e.g., including icons, colors, placement), and write error messaging in a helpful and guiding way. Use appropriate click/touch zones to leave enough space between elements. Doing this minimizes click/touch target errors. Anticipate spelling mistakes in search queries, and accommodate multiple spellings of words in search results."
|
|
72
|
+
},
|
|
73
|
+
{
|
|
74
|
+
"type": "guideline",
|
|
75
|
+
"content": "Keyboard equivalents.\n\nUse the built-in keyboard focus states that are defined in Spectrum components. Ensure that people can complete any action using a keyboard and keyboard equivalents, including on mobile (e.g., iPad Smart Keyboard). Set a tab order so that people can move back and forth within a view by using the Tab key."
|
|
76
|
+
}
|
|
77
|
+
],
|
|
78
|
+
"sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/inclusivity/inclusive-design",
|
|
79
|
+
"lastUpdated": "2026-09-03",
|
|
80
|
+
"status": "published",
|
|
81
|
+
"tags": [
|
|
82
|
+
"inclusive design",
|
|
83
|
+
"accessibility",
|
|
84
|
+
"assistive technology",
|
|
85
|
+
"high contrast",
|
|
86
|
+
"keyboard accessibility",
|
|
87
|
+
"internationalization",
|
|
88
|
+
"responsive design",
|
|
89
|
+
"color naming",
|
|
90
|
+
"co-design",
|
|
91
|
+
"user testing"
|
|
92
|
+
]
|
|
93
|
+
}
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
|
|
3
|
+
"$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/inclusive-ux-writing.json",
|
|
4
|
+
"name": "inclusive-ux-writing",
|
|
5
|
+
"title": "Inclusive UX writing",
|
|
6
|
+
"category": "designing",
|
|
7
|
+
"documentBlocks": [
|
|
8
|
+
{ "type": "purpose", "content": "Inclusive UX writing" },
|
|
9
|
+
{
|
|
10
|
+
"type": "guideline",
|
|
11
|
+
"content": "Business.\n\nCompanies connect with fewer people Non-inclusive products directly reflect on the company that makes them, generating negative sentiment both inside the company and in the broader industry"
|
|
12
|
+
},
|
|
13
|
+
{
|
|
14
|
+
"type": "guideline",
|
|
15
|
+
"content": "Brand value.\n\nCompanies recruit fewer candidates from historically underinvested communities Companies and their products perpetuate stereotypes of and prejudice against historically underinvested communities"
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"type": "guideline",
|
|
19
|
+
"content": "Accessibility as a discipline falls under the umbrella of inclusivity. Inclusive UX writing must address how people with disabilities access information, but not in a vacuum; it’s necessary to also think about how designers and developers build products to function with assistive technology. Inclusive UX writing is accessible, but the reverse isn’t always true. UX content includes: Visible text, including labels for UI elements, text on buttons, links, and forms Non-visible descriptions that don’t appear on screen (e.g., alt text for buttons with icons), images, workflows, tutorial formats Anything else that a person can read inside a product No matter what kind of UX content it is, it should be descriptive and meaningful. Here are some examples of why certain words and phrases are preferred, and why some should be avoided: PreferredAvoidWhyPeopleCustomersBe inclusive of current and potential users of products — not just the paying ones. If the context is dependent on a payment or subscription, “customers” is acceptable.You (when speaking to your audience about themselves)Users (when speaking to your audience about themselves)Be inclusive of the person who’s reading. If the context is dependent on a role (e.g., an admin managing permissions), “user” is acceptable.Adobe Dimension helps you create in 3D.Adobe Dimension is for graphic designers looking to get a 3D edge.Be inclusive of more reasons to use a given product.View, Show, Go to allSee allBe descriptive. Not everyone is “seeing,” and the “do” options (“View,” “Show,” “Go to all”) have more nuance in meaning.Play videoWatch videoBe descriptive. Not everyone is “watching” the video.Last updated: 2 days agoUpdated • 2d agoBe meaningful. Symbols and abbreviations, when read aloud by a screen reader, can obscure the message if you don’t take additional steps to ensure they read correctly.Update your information (step 1 of 3)Confirm your informationBe meaningful. Guide people in a stepped flow and tell them specifically what to do. Set accurate expectations for how long a task will take."
|
|
20
|
+
},
|
|
21
|
+
{
|
|
22
|
+
"type": "guideline",
|
|
23
|
+
"content": "There are a number of additional pages about language and inclusivity that make up this guide: Writing about people Writing for readability Writing with visuals This is a list of topic areas to think about when creating inclusive content. It’s just a start, and will evolve as often as necessary."
|
|
24
|
+
}
|
|
25
|
+
],
|
|
26
|
+
"sourceUrl": "https://main--spectrum-hub--adobe.aem.live/content/language-and-inclusivity/inclusive-ux-writing",
|
|
27
|
+
"lastUpdated": "2026-09-04",
|
|
28
|
+
"status": "published",
|
|
29
|
+
"tags": ["inclusive UX writing", "inclusive language", "assistive technology"]
|
|
30
|
+
}
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
|
|
3
|
+
"$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/internationalization.json",
|
|
4
|
+
"name": "internationalization",
|
|
5
|
+
"title": "Internationalization",
|
|
6
|
+
"category": "designing",
|
|
7
|
+
"documentBlocks": [
|
|
8
|
+
{ "type": "purpose", "content": "Internationalization" },
|
|
9
|
+
{
|
|
10
|
+
"type": "guideline",
|
|
11
|
+
"content": "There are roughly 200 countries and 6500 spoken languages in the world. Culture is deeply rooted in our thinking patterns, and it affects how users interact with and benefit from digital experiences. International design is a complex challenge that goes beyond translation. Acknowledging cultural characteristics and differences is the first step to create richer, world-ready digital experiences. Here, you'll find recommendations and guardrails for how to start creating user experiences that are scalable globally, and concepts to better understand how varied our user landscape is. Designing for a global audience is not an exact science, but by acknowledging the following issues, we take an important first step to develop more empathy towards our international users and build globally relevant user interfaces. For questions, feel free to reach out to the International Design team to collaborate and make our products equally effective in all regions. International Design Wiki"
|
|
12
|
+
},
|
|
13
|
+
{
|
|
14
|
+
"type": "guideline",
|
|
15
|
+
"content": "There are roughly 200 countries and 6500 spoken languages in the world. Culture is deeply rooted in our thinking patterns, and it affects how users interact with and benefit from digital experiences. International design is a complex challenge that goes beyond translation. Acknowledging cultural characteristics and differences is the first step to create richer, world-ready digital experiences. Here, you'll find recommendations and guardrails for how to start creating user experiences that are scalable globally, and concepts to better understand how varied our user landscape is. Designing for a global audience is not an exact science, but by acknowledging the following issues, we take an important first step to develop more empathy towards our international users and build globally relevant user interfaces."
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"type": "guideline",
|
|
19
|
+
"content": "Localization-ready design.\n\nLocalized content and text expansion have a substantial impact on how user interfaces look and perform across different countries. It’s vital to create layouts that can efficiently flow with the textual content of different length and nature."
|
|
20
|
+
},
|
|
21
|
+
{
|
|
22
|
+
"type": "guideline",
|
|
23
|
+
"content": "Correct or incorrect.\n\nCheckmarks and “X” glyphs are commonly used in Western cultures to represent affirmation. However, in some countries such as Japan, these symbols are mostly used to indicate that something is not correct. At the same time, in Japan the “O” mark is the common way to express positive feedback to an action instead."
|
|
24
|
+
},
|
|
25
|
+
{
|
|
26
|
+
"type": "guideline",
|
|
27
|
+
"content": "Artifacts.\n\nWe often use icons to represent real life objects that are familiar to the human eye and use everyday. However, some of these objects take different shapes in different countries. A common example is the mailbox icon; familiar to North American users, it doesn’t translate well for users in other countries."
|
|
28
|
+
},
|
|
29
|
+
{
|
|
30
|
+
"type": "guideline",
|
|
31
|
+
"content": "Hands and animals.\n\nHands gestures are, generally speaking, tricky to use. Even gestures that we frequently use such as thumbs up and thumbs down can be perceived in an offensive way in certain countries. Animals can lead to misunderstandings as well. An example is the owl, which is a symbol of wisdom in the United States, carries the opposite meaning in some Asian countries."
|
|
32
|
+
},
|
|
33
|
+
{
|
|
34
|
+
"type": "guideline",
|
|
35
|
+
"content": "Embedded text.\n\nAs a rule of thumb, embedding text within icons, illustrations, and images can potentially lead to headaches when the content needs to be localized, as the content is not easy to translate and as the icons are not meant to adapt to text expansion. As a workaround, it’s reasonable to use lines instead of real text."
|
|
36
|
+
},
|
|
37
|
+
{
|
|
38
|
+
"type": "guideline",
|
|
39
|
+
"content": "People and portraits.\n\nIt’s important to pick models who are dressed appropriately for the region. Editing of portraits also differs with facial manipulation and skin smoothing being popular in many Asian countries such as China and Korea. The amount of skin shown can also be considered too suggestive in some cultures. Similarly, political, inspirational figures that are celebrated and extremely popular in the United States are likely to be unknown in some regions."
|
|
40
|
+
},
|
|
41
|
+
{
|
|
42
|
+
"type": "guideline",
|
|
43
|
+
"content": "Religion and politics.\n\nIn general, it’s best practice to avoid religious symbolism, hand gestures, and political imagery, as regions may perceive them differently. Photos of Tibetan monks are perceived in Western cultures as deeply spiritual. In China, on the other hand, Tibetan Buddhist monasteries are a symbol of a long religious and political dispute."
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"type": "guideline",
|
|
47
|
+
"content": "Seasonal content is greatly different country by country, and photography should reflect it accordingly. For example, there is a variety of celebrations, such as Thanksgiving, that are not meaningful in Asian countries, or interpreted in different ways. Valentine’s day in Japan is quite unique from a western standpoint. The common roles are reversed and it’s the women who present gifts to significant others, usually chocolate or sweets."
|
|
48
|
+
},
|
|
49
|
+
{
|
|
50
|
+
"type": "guideline",
|
|
51
|
+
"content": "Traditions and manners.\n\nIt’s often said that the best way to experience a country is to learn and respect its customs. Similarly, when choosing imagery across different cultures, we need to be respectful and aware of different traditions and manners across different regions, and act accordingly. Pictures like this one would likely represent “relaxation” in the United States, but are inappropriate in countries like Thailand, where you are not supposed to show the soles of your feet."
|
|
52
|
+
},
|
|
53
|
+
{
|
|
54
|
+
"type": "guideline",
|
|
55
|
+
"content": "The meaning of color is rooted in culture.\n\nLet’s consider an example: the design for a finance application. To display how certain stock options are performing, designers from the United States or Europe would likely use the color green to depict good performance and red to display stocks performing poorly. On the other hand, surprisingly, designers in China or Japan would likely take an opposite approach, and reverse the usage of these two colors. While in the United States and most western countries the color red is often associated with the idea of error or danger. However, in eastern countries the color is tied to the concept of good luck and happiness. White is a color tied to the concept of purity in western countries, but can be seen as a mourning color in countries like China. In Japan, purple is a color that expresses luxury and financial success, while in Italian popular culture is seen as a color that attracts bad luck. The list goes on."
|
|
56
|
+
},
|
|
57
|
+
{
|
|
58
|
+
"type": "guideline",
|
|
59
|
+
"content": "Best practices.\n\nIn general, no color can be assumed to have a consistent meaning across cultures. When approaching the design of user interfaces for a global audience, colors should not be the only indicator of a specific status or use case. It's always better to integrate with textual or other visual clues. When designing promotional content, capturing the right tone and emotions from the local audience is key, and colors can have a big impact. It’s important to research specific markets from a cultural standpoint to choose the right creative decision."
|
|
60
|
+
},
|
|
61
|
+
{
|
|
62
|
+
"type": "guideline",
|
|
63
|
+
"content": "Readability across languages.\n\nLanguages like Chinese, Japanese, and Thai use characters that are visually complex compared to the Latin ones. The peculiar nature of these writing systems has an impact on the character size, which is usually slightly bigger than western typography. To ensure good readability, it’s important to adjust the line-height value of paragraphs to create some extra breathing room between lines, and when necessary, increase interline spacing between characters. Similarly to text expansion, these differences can have an impact on the width and height of localized paragraphs."
|
|
64
|
+
},
|
|
65
|
+
{
|
|
66
|
+
"type": "guideline",
|
|
67
|
+
"content": "Content volume expectation.\n\nDifferent cultures have varying expectations around volume of content. Japanese users generally prefer larger amounts of content and greater detail compared to North Americans, so content-heavy interface designers should consider the volume of content expected by these users. We recommend a modular design that allows for additional content. This is both for usability and user satisfaction of our products."
|
|
68
|
+
},
|
|
69
|
+
{
|
|
70
|
+
"type": "guideline",
|
|
71
|
+
"content": "Emphasis.\n\nUsing bold and italics to emphasize words or phrases is common in Western typography, but for certain languages it might not be the right way of highlighting content. For example, languages like Chinese, Korean, and Japanese do not commonly rely on italicization because they lack oblique faces, and use alternatives like emphasis dots."
|
|
72
|
+
}
|
|
73
|
+
],
|
|
74
|
+
"sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/inclusivity/internationalization",
|
|
75
|
+
"lastUpdated": "2026-09-03",
|
|
76
|
+
"status": "published",
|
|
77
|
+
"tags": [
|
|
78
|
+
"international design",
|
|
79
|
+
"localization",
|
|
80
|
+
"text expansion",
|
|
81
|
+
"globalization",
|
|
82
|
+
"cultural differences",
|
|
83
|
+
"iconography",
|
|
84
|
+
"metaphors",
|
|
85
|
+
"user interface localization"
|
|
86
|
+
]
|
|
87
|
+
}
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
|
|
3
|
+
"$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/layout-and-structure-containers.json",
|
|
4
|
+
"name": "layout-and-structure-containers",
|
|
5
|
+
"title": "Containers",
|
|
6
|
+
"category": "designing",
|
|
7
|
+
"documentBlocks": [
|
|
8
|
+
{
|
|
9
|
+
"type": "purpose",
|
|
10
|
+
"content": "In Spectrum 2, containers have more defined rules to help guide in the creation of custom containers for product-specific contexts. Containers are used across Spectrum 2 interfaces in multiple ways, but the commonality they share is that they group related concepts together into distinct areas. Some usages of containers have more detailed guidelines. For example, a card uses a container and inherits its properties, but it can only represent a distinct object (such as an individual asset or product). A block of marketing material containing multiple concepts (like subscription information plus actions to take) is grouped together in a container, but is not considered a card. Whether broad or specific, a user should be able to readily tell the purpose of a container. Separation of containers is marked through a clear visual change, such as contrast in a background color or through spacing. All containers share a common set of rules for styles, padding, and emphasis.\n\n### Example\n\nCards and select boxes share container styles. In this example, both use the emphasized style. Cards also have additional options that select boxes do not, like t-shirt size and layout. Examples of containers: two cards with different sizes and layout options, and a select box."
|
|
11
|
+
},
|
|
12
|
+
{
|
|
13
|
+
"type": "guideline",
|
|
14
|
+
"content": "All containers share a set of defined styles. Background color By default, containers are visually distinguished through a change in background color. Learn more about this in background layers. Emphasized In some situations, drop shadows are used to provide emphasis to a container or group of containers, like in a set of related cards. Emphasized containers should be used sparingly. View more about container emphasis. Border Borders can also be used around objects as an alternate style to a background color, and should be used without a fill. Vertical, full-width dividers can also be used to create separation for larger sections of content, like in a panel. View more about border width. Spacing This is the container style with the least emphasis. Instead of using a visible border, spacing is used to create separation between concepts. View more about spacing."
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"type": "guideline",
|
|
18
|
+
"content": "Example.\n\nThis medium card uses spacing-300 for internal padding."
|
|
19
|
+
},
|
|
20
|
+
{
|
|
21
|
+
"type": "guideline",
|
|
22
|
+
"content": "Example.\n\nIn this group of containers — each representing a product — different container styles can be used to draw attention to a specific item. In this case, the emphasized container is paired with a badge, and contrasts against the more subdued containers with filled (gray) backgrounds."
|
|
23
|
+
},
|
|
24
|
+
{
|
|
25
|
+
"type": "guideline",
|
|
26
|
+
"content": "States of interactive, emphasized containers.\n\nIf the whole container is interactive, hover is shown through a slightly more prominent drop shadow. When dragged, a much more prominent shadow is shown in order to bring focus to the dragged item and show elevation above the rest of the UI. Note that specific components might have different options and states. Emphasized, default Emphasized, hover Dragged"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"type": "guideline",
|
|
30
|
+
"content": "A consistent app frame helps create a sense of brand unity and helps users feel comfortable and familiar with our products. Predictable navigation is also especially helpful for users who work across multiple applications, and it makes it easier to learn how to use new products. The Spectrum 2 app frame framework provides a consistent visual style and navigation. It offers foundational structures and guidelines that product teams can adapt to their own contexts. View more details about the S2 app frame. The main content area is defined by a unique container style that's used only in the app frame. It has a subtle drop shadow to provide separation from the navigation. View more about using container styles to divide content within content areas. Example of an app frame with a side navigation."
|
|
31
|
+
}
|
|
32
|
+
],
|
|
33
|
+
"sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/layout-and-structure/containers",
|
|
34
|
+
"lastUpdated": "2026-09-11",
|
|
35
|
+
"status": "published",
|
|
36
|
+
"tags": [
|
|
37
|
+
"containers",
|
|
38
|
+
"cards",
|
|
39
|
+
"select boxes",
|
|
40
|
+
"padding",
|
|
41
|
+
"spacing",
|
|
42
|
+
"background color",
|
|
43
|
+
"emphasis",
|
|
44
|
+
"border",
|
|
45
|
+
"dividers"
|
|
46
|
+
]
|
|
47
|
+
}
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
|
|
3
|
+
"$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/layout-spacing.json",
|
|
4
|
+
"name": "layout-spacing",
|
|
5
|
+
"title": "Layout spacing",
|
|
6
|
+
"category": "designing",
|
|
7
|
+
"documentBlocks": [
|
|
8
|
+
{ "type": "purpose", "content": "Layout spacing" },
|
|
9
|
+
{
|
|
10
|
+
"type": "guideline",
|
|
11
|
+
"content": "Layout spacing governs object relationships, such as the spacing between components, patterns, and regions of a UI. It’s implemented through global tokens, which follow a geometric progression with values that round to familiar numbers: 2, 4, 8, 16. If you're used to an 8 px grid, these will feel recognizable. The scale provides consistent perceptual difference between adjacent values across its full range."
|
|
12
|
+
},
|
|
13
|
+
{
|
|
14
|
+
"type": "guideline",
|
|
15
|
+
"content": "Global tokens govern object relationships in a layout. They create and distinguish the relationships between the components that make up a product UI. Smaller values create tighter relationships. Larger values create more visual independence. The choice should reflect the actual relationship between the objects being spaced."
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"type": "guideline",
|
|
19
|
+
"content": "A common approach to spacing is to pick a base unit and build all spacing values from its multiples, such as 8, 16, 24, 32. These values are familiar and easy to remember, which is part of their appeal. This approach is called a linear progression. Linear progressions like this work well in many situations, but have two limitations. First, spacing needs to grow with the elements around it. A 4 px gap between an icon and label looks right in a small component, but as the component scales up, the nearest grid values (4 px or 8 px) no longer fit the relationship correctly. Second, linear scales lose differentiation at larger values. The difference between 4 px and 8 px is obvious. The difference between 72 px and 80 px is almost imperceptible. Both of these limitations come down to the same underlying cause: human perception doesn't measure space in fixed increments. Spectrum's spacing system is built around geometric progressions and semantic tokens to address this directly. The next page explains how."
|
|
20
|
+
},
|
|
21
|
+
{
|
|
22
|
+
"type": "guideline",
|
|
23
|
+
"content": "Use global tokens for layout spacing. TokenValuespacing-251pxspacing-502pxspacing-754pxspacing-856pxspacing-1008pxspacing-20012pxspacing-30016pxspacing-35020pxspacing-40024pxspacing-50032pxspacing-60040pxspacing-70048pxspacing-75056pxspacing-80064pxspacing-90080pxspacing-100096px"
|
|
24
|
+
}
|
|
25
|
+
],
|
|
26
|
+
"sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/layout-and-structure/spacing/layout-spacing",
|
|
27
|
+
"lastUpdated": "2026-08-13",
|
|
28
|
+
"status": "published",
|
|
29
|
+
"tags": [
|
|
30
|
+
"layout spacing",
|
|
31
|
+
"global tokens",
|
|
32
|
+
"geometric progression",
|
|
33
|
+
"semantic tokens",
|
|
34
|
+
"8 px grid",
|
|
35
|
+
"linear progression",
|
|
36
|
+
"perceptual spacing",
|
|
37
|
+
"spacing scale"
|
|
38
|
+
]
|
|
39
|
+
}
|