Much has been made of utilising icon fonts. I don’t want to go into too much depth of whether they are appropriate, or better than SVG in this article. Instead I would like to share a way for designers to use icon fonts to improve their workflow. First an overview around implementation.
Trust your developers
I really don’t care if icon fonts are used to deliver icons. You can use SVG, or PNG. It doesn’t matter to me as long as this criteria is hit:
– The performance is optimal
– It looks good everywhere
– It doesn’t impact negatively on people with different needs, such as those using assistive technology (A11Y Y’all).
It’s an implementation detail
As such, it falls to engineering the determine the most appropriate solution. If, however, engineering are already using icon fonts, or you are working on white label solutions this article might be helpful, and provide you with some workflow tips.
Be a D.R.Y. aul yolk
D.R.Y. is a acronym used by engineers. It means don’t repeat yourself. I want to make a case for designers to think more like engineers for a change. Don’t worry, no coding is required. This principle boils down to reusing code, instead of rewriting it. It’s pretty fundamental. Write a piece of code once, put it into a function, and call the function wherever you need it.
Say no to manual labour
Thanks to Sketch, much of the manual processes required to produce screens has been eliminated. Nowadays, the dull UI production of screens is a distant, yet vividly horrible, memory. Symbols and styles reduce monkey work tremendously, and allow for automation to take place. Don’t. Repeat. Yourself.
Some context to the bad old days
In the rare auld times, you would have to manually design and maintain each screen. It was an art of pressing Cmd+C followed by Cmd+V. Doing that today is not just inefficient–It is also very boring, and leaves you open to making mistakes.
If a component appears on more than one screen it deserves to be a symbol. If a component appears just two times (unsymbolised?), you double the risk that your design will be out of sync. You need to update both components if there is a change. This risk increases and multiplies with each instance in the design. Remember: Don’t repeat yourself.
What is good about icon fonts
Icon fonts hold all of your icons in a single font file. This means that you have a better chance of achieving consistency. Done correctly, you will have a single source of truth for icons that both design and engineering can reference. I’ll try to communicate a few ways that this can be valuable.
Be consistent, and avoid death by duplication
Often in products you see a variety of idioms used in the design. There can be multiple different icons in place that do the same job. This means that people need to first discover that two icons represent the same thing, and store this information in memory. Then they have to recall this quirk each time they return to the interface. This is stupid, needless, and makes the product just a little bit more complex.
You may argue that this is not that big a deal. You’re actually (sort of) right. In isolation it is not. But, think of it as a small snowball rolling down a hill. It’s accumulating little issues along the way, increasing not only in size, but in velocity. By the time it becomes a big deal, it is too late. You might even have a metaphor, before you are crushed by an avalanche of little inconsistencies.
Here’s a good post about applying recognition over recall by our friends at NNGroup, and understanding the principles of cognitive load and cognitive barriers.
An example of “The Frankenstein effect”
Let’s take Facebook as an example. In the mobile app notifications is represented as a bell icon. If you visit their mobile website it uses a globe icon for notifications.
Screenshot of the Facebook navigation bar as it appears on the native android app, with another screenshot showing how it appears on the mobile site below.
How did this happen?
Honestly, there’s probably a decent reason. I don’t know, and it would be easy to criticise. The globe icon is a likely just a leftover legacy from the web that works for the audience who use the website. It’s design debt that doesn’t probably cost too much to them (people are addicted to Facebook, and probably don’t think much about what goes where).
It’s safe to assume Facebook has a bunch of different design teams. The web team, and the app teams. Also, I do realise the mobile website for Facebook is (probably) a keep the lights on initiative, with most of the website use being done on a laptop. Facebooks primary focus is mobile, but it’s (a bit) interesting that the experience is out of sync between the app and the web version.
“The Frankenstein effect” is not a real term as far as I am aware, but one I feel describes the issue appropriately.
Nerdy game time
I personally like my tabs to be labeled. Obvious always wins as Luke Wroblewski would say. Coincidently, he has been collecting data on the navigation versions Facebook A/B test. At the time of this post it was up to 56 variants. You can view the documented versions here.
A quick fun exercise is to ask people to open an app they use all the time with icon only navigation (such as the Facebook app).Then, get them to tell you what the tabs mean before they navigate.
This can yield some interesting results. Efficiency is often impacted, when clean design gets priority over clarity. Wayfinding requires thinking. You can see the cognitive cogs turning in people when faced with this challenge. Put labels on the tabs and try this test. People will look at you as though you are insulting their intelligence.
In conclusion to this detour, unless your app is going to be used as much as Facebook and Twitter, you might want to consider labels. It’s just a kind thing to do. Form should not lead function–at least, this is what I tell myself when I look at this ugly site.
Get to the point. You promised me workflow tips
So now that I have rabbited on about some of the benefits of icon fonts, I’d like to share a way of using icon fonts within Sketch in a smart way that embraces D.R.Y. The main technique comes from this post on Medium (go and share some claps, or whatever Medium do now to show appreciation).
In this article Peter takes you through a step by step technique for using icon fonts in Sketch. It’s really efficient. I won’t repeat this, but I will add one thing to it. In the article, he mentions copying and pasting icons from font-book into Sketch. This is kind of weak as a process & something that would be a hard sell to the designers.
However, he goes on to show that you can reference the icons and call them by a friendly name. He points out that Googles material design icon font does this, and it is way better, and a much easier sell.
I wanted to understand how this was done, so I downloaded the material icons and did some investigating. This took a little time, as I was trying to uncover where the voodoo was happening. It took me a while to realise that the article was wrong in it’s assessment on the situation. The icons had not been named at all. Instead the folks at Google had utilised ligatures.
The magic of Ligatures
In typography, a ligature occurs where two letters are joined as a single glyph. Here’s some code to show how it works:
sub m e n u by uniE961;
Essentially this script says that when the letters that make up the word menu are written, you want to substitute it for the glyph(icon) with a unicode of uniE961.
This is a pretty clever solution, and might have good benefits towards improving a11y. It won’t be an easy way of working if you have to write a piece of script for every icon. I knew the designers would (probably) be even less happy with this approach then copy and pasting from font book. I almost gave up…
Icomoon is a free service for creating icon fonts. It, rather usefully, has the capability to add ligatures to your icons in a way that doesn’t require scripting. It is also conveniently the tool that design team was creating their icon fonts with. This was a big win. It meant I didn’t need to introduce any new tools to the team. It simply added to the process that was already in place.
Show. Don’t tell
I’m a big fan of showing rather than telling (although this might not be so obvious with the textual nature of my site). Here’s a video I made with loom, showing how to go about creating your own icon font using friendly ligatures using icomoon and Sketch. I’ll upload a narrated version during the week. I’m too self conscious to talk to myself (what if I like it to much), so if anyone wants a remote walkthrough I can provide it!
Note: Loom is great by the way, and free to use (yeah this is a referral link).
Potential Benefits of using icon fonts this way
- Single source of truth: Engineers and designers are using the same file.
- Control in the designers hands (they need to reinstall new font releases)
- Whitelabel rebranding potential. If you establish a naming convention, you simply need to change the font the icon is pointing at, and don’t spend hours swapping individual icons.
- It’s much faster, and reduces production work. Who has times to resize and slice each icon in sketch at 25pts and 24dpi for iOS & android
Tip: If you are using something like Zeplin for redlines, it might makes sense that the ligature you use matches the CSS modifier. This way they would be able to just copy the content from Zeplin with a click. For example:
span class="icon [modifier class]"
Who’s job is it anyway?
Really, it is the designers responsibility (if they exist) to step up, and ensure that there are at some guiding principles in place. If not a full design system, then at least a set of icons, and components, that consider the future of the product. Go beyond addressing just the immediate need.
Some caveats to this approach. It has not been tested to scale, and there are likely potential issues that I haven’t seen. I don’t know what the release of Sketch Libraries means, as I have yet to dive in to it. I just think that we should be a little bit more clever about how we do the production work.
Download a Sketch file to play with, and an icon font here.