Icon Guidelines

Using Icons

Using icons is a great way to make the UI less text-heavy and easier to comprehend, either by replacing common text labels, or attaching them to less common labels.

Common labels can be replaced with icons altogether, reducing the text on the page. These can be common actions (e.g. instead of "Delete" we can just display a trash can  icon), status labels (Instead of "Warning" we can display ), or even logos ().
When replacing a label with icon, we recommend using the replaced text label as a tooltip. E.g. for a button with the trash can icon, display "Delete" as a tooltip.

For less common labels, icons can make the label easier to understand by displaying it nearby (e.g. " Media Database").

Take a look around Emarsys to see how icons are used, so you can use these icons consistently across the software.

Contributing Icons

1. Icons don't have to be super-specific to be useful for our users. E.g. we don't really need a separate "edit campaign" icon, the regular "edit" () works perfectly fine. If you can get away with using an existing generic icon, you don't need to make a new one!
2. Our generic icon library should be expanded with icons that can be used in multiple contexts ("edit" () is a good example).
   • There's a bit more flexibility with service-specific icons (e.g. "ac-*" icons), but we still recommend being mindful about the necessity of new icons. The more icons we have, the harder it becomes to maintain the library.
3. We recommend product teams to draft icons themselves, and collaborate with a Design System designer to apply the finishing touches (making sure the icon fits well in our library, cleaning up the SVG file, etc.)
   • The closer you can get to a "finished state" before involving the Design System the better!
   • When creating a draft design, we recommend testing it on the UI! Icons might look and feel different in-use than on their own.
4. Picking the right icon name is more important than drawing the right graphic, as the name will get implemented in the UI code, and that's harder to change retroactively. If we want to modify the graphic of the icon, we can easily do that anytime.

Creating Icons

At a glance:

• Draw the icons on a 24x24 px canvas with 2px padding.
• Use 2px thick strokes.
• Round corners.
• Give the icon an “outline” style instead of a “filled” style.
• Use existing icons as a reference and make sure they look similar in style.

Style

Canvas:

• Use a 24x24 px artboard for the icon.
• Most of our icons will be displayed in a 24x24 px container, occasionally in a smaller 16x16 one. We’re aiming to use 24x24 icons everywhere, eventually.
• In some specific cases, icons can be used in larger sizes, e.g. 48x48 in the Empty State component.

Stroke width:

• Use 2px strokes.
• Avoid using 1px strokes.
• In some rare cases, it makes sense to use thicker, 3px or 4px strokes. Eyeball it!

Filled or outline style?

• Use outline style instead of filled style when possible.
• Really small elements of the icons, which would look off in outline style, can be filled.

Rounded corners:

• Round the corners of rectangular objects to give them a smoother look.
• Use 2px rounded corners.

Arrows:

• Arrowheads should be V-shaped, not triangle-shaped.

Negative space:

• Avoid using negative space to depict forms (e.g. the arrow in the FedEx logo).

Badges:

• Display badges at the bottom right for complementary meanings, e.g. “add”, “remove”, “check”, etc.

Composite icons:

• Reuse objects from other icons when it makes sense. E.g. use the same “profile” graphic in “add profile” and “remove profile”.
• Avoid using more than 2 parts to make an icon, e.g. “add user” should be made out of “user” and “add”.
• When making an icon out of multiple parts, arrange it diagonally: one part in the top left, one part in the bottom right.

Technical

Avoid anti-aliasing:

• Hard vertical and horizontal edges should be aligned on the pixel grid, to avoid sub-pixel anti-aliasing that would make the icon appear blurry.
• Circles and diagonal lines don't have to be perfectly aligned to the pixel grid.

Padding:

• Try providing a 2px (but at least 1px) padding in the artboard for the icon. This makes sure the icon is rendered nicely, especially when you scale the icon to different sizes.

Merge icons into a single shape:

• The end result should be a single vector layer with a fill attribute (no borders!), otherwise browsers might have issues rendering it properly.
• In Sketch, turn all borders and paths into outlines, combine layers, and use the “flatten” command.

Remove unnecessary info from the SVG file (compress / minify it):

• SVGs are written in XML, so they can be edited in text editors (e.g. Sublime Text, Atom). You can check them on your own to make sure they're nice and tidy!
• Sketch has a plugin called SVGO Compressor, which cleans up SVG exports: https://www.sketch.com/extensions/plugins/svgo-compressor/
• Make sure to remove the "fill" attribute (otherwise the UI Framework won't be able to recolor the icon).

Ultimately, the SVG file should look clean and simple like this:

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
    <path d="M5 8v4.52A10.7 10.7 0 0113 9c3.4 0 6.43 1.54 8.35 3.93l-1.67 1.21A8.54 8.54 0 0013 11a8.55 8.55 0 00-6.56 3H11v2H3V8h2z"/>
</svg>

Naming:

• It’s important to pick the right name for your icon, as once developers start implementing it in the UI code, it'll be hard to rename it.
• Our generic icons come with an "e-" prefix. E.g. "e-save", "e-reset", "e-clear", etc.
  • Service-specific icons come with different prefixes, e.g. "ac-", "nav-", "des-".
• Try making the name "as semantic as possible", so it's easy to reuse. E.g. instead of "e-attach-pricetag", something like "e-tag-add" would make more sense in our system.
• Try making the name as short as possible. E.g. instead of “e-save-new-document”, use “e-save”.
• If you have a slight modifier for the icon, add it to the end of its name. E.g. for “e-tag”, you can add the modifier “e-tag-add” or “e-tag-remove”.