Draw Icons from Scratch Series: Detailed Explanation of Icon Application

In UI design, icons do not exist in isolation. We learn icon design not to draw a set of pictures and then upload them to the design platform to share or ask for likes, but to play a role in real projects. If you don’t understand the knowledge points of applying icons to projects, then the real icon design level will be lost during the project design process.

A set of icon specifications for an application

Icons are an indispensable component of an application and can be seen everywhere in the application interface. Because of the commonness of icons, we often need to use multiple sets of icons in one application, which deviates from the impression of advocating simplicity.

Many beginners think that we only need to design a large and comprehensive set of icons and extract them in the project. But in many scenarios, if only one type of icon is used, the effect will be very poor. For example, let's take a look at the Taobao settings page below, which contains more than 6 icons. It is too complicated, but what if we replace all the icons with the same set?

As you can see, the effect of the case on the right after replacement is very unsatisfactory. The interaction rules say: Do not add entities if it is not necessary, but for the use of icons, this is necessary.

Icons within an application have different specifications and can be divided into two attributes: size and style.

1. Icon size

Size refers to the size of icons. Some interface elements have low weight, so the icon size is small, while some have high weight and vice versa. For example, in the playback interface of Apple Music, the play fast forward button, as the most important button on the page, is very large, and other clickable icons are second, while the two buttons representing volume are the smallest.

Determining the icon size is one of the things we do when designing icons in a project. However, the size is not determined out of thin air. We must first build an actual "scenario" for analysis, that is, complete a high-fidelity prototype or interactive prototype of the interface.

Below is a prototype demonstration I made myself. After building such a page, I will check in the prototype how many icon sizes I have used in total, in which scenarios they will be used, and then sort them out. If there are some that I feel are unnecessary, I can adjust them and merge them into one size.

So, in this case, I came up with 4 icon sizes:

• 48pt: large icons for categories and quick entry
• 32pt: Bottom TabBar icon
• 24pt: Regular tool icons
• 16pt: Small tooltip

After we have determined these 4 specifications, we will have a clear design direction in the subsequent design. Let's review again why we need to determine the size first and then design, rather than designing a large set of icons and then shrinking them.

Because icons need to meet pixel alignment requirements as much as possible, icons that are scaled down often have problems such as misalignment, blur, or loss of details. Also, the visual feedback obtained from designing icons on a large canvas and designing them on a small canvas from the beginning is completely different. When you first draw on a large canvas and then scale it down to 16pt or 12pt, it often looks too complicated or has too thick strokes.

2. Icon style

After the icon size is confirmed, the next step is to confirm the icon style. Just like the size, the style of the icon we want to use needs to be determined by comparing it on a page that already has a visual prototype, and we cannot start designing in advance.

In my design process, I usually start designing icons at the end of a project. The reason is that the visual style of an icon depends on its location and environment. It is "interface style first, then icon style".

Under normal circumstances, if an application has multiple sets of icons, then ordinary small and medium-sized icons can use general linear or planar styles. In the decorative and large-sized types such as categories and quick entry, more radical design styles should be used. For example, the following figure is an example of the 58 Tongcheng client application icon:

Usually, one style is applied to one "category" of icons. The above example is an ideal state, where one category of icons corresponds to one size, but in more complex environments, the same size often includes icons of different categories.

Different states of icons

In a product, icons can be used as buttons in addition to decoration. Every application has a large number of icons that can be clicked and interacted with, such as the bottom navigation bar, the message icon in the header, the release icon, and so on.

When an icon can be operated, we should pay attention to its state changes. Take the navigation bar icon as an example. The conventional selected state is to change the color, but more and more applications will adopt different design styles in the selected state to improve the visibility through richer style performance. For example, the bottom navigation bar of Taobao and QQ.

In addition, some icons contained in the control will also change with the change of the control state. For example, in the account input box, if the input box is selected, the color of the icon will also change. If the input box is currently in a non-input state, the icon will also be grayed out accordingly.

A qualified UI designer will fully consider the various states of the icon, and will provide detailed descriptions and classifications when submitting it to the developer. In addition, he will make full use of the component functions in software such as Sketch to improve the efficiency and output of the project.

Icon labeling and cutting

After we have completed the design of the interface and icons, we need to submit our designs to the developers. This includes our annotations and cutouts. Putting aside other design elements, let's talk about the specifications that icon cutouts need to follow. It and fonts are the most error-prone areas in this process.

We have already mentioned the export of application icons in the previous chapter, so the following description will focus on tool icons.

1. Icon boundaries

Let’s go back to the specifications of tool icons in Chapter 2. When we determine the size of the icon, we don’t design the graphics to fill this size, but use a grid system to define their size.

Many newcomers will have doubts in this process. So in the process of marking, are we marking the distance from the graphic to other elements, or the distance from the outer contour of the icon to other graphics?

In fact, the distance of the icon is calculated based on the outer contour. Although this contour is invisible to our naked eyes, the inherent rules it contains can help us ignore some unnecessary small problems.

So, to make the annotation effective, don't be lazy and just place the icon in the canvas without a transparent rectangular background.

2. Icon Canvas

There are many collaborative tools that help us mark and cut pictures, such as Blue Lake, Zeplin, etc. We just need to upload the design draft, and the programmer can get the corresponding cut picture of the icon by himself.

It is very useful for cutting out some specific elements, but the method of exporting icons through online pages is very unreliable. As we have said, there may be multiple specifications of icons in an application, so reasonable icon cutting should be exported and sorted according to different specifications (as shown below), rather than letting programmers download them from online tools themselves, which is not only difficult to operate, but also difficult to easily obtain different states between icons.

Therefore, during the project design process, we need to create canvases (Symbols) of different sizes and arrange them into categories, which will not only facilitate our future icon calls, but also facilitate batch export of cut images to corresponding folders.

3. Naming icons

When it comes to exporting cutouts, we have to mention the icon naming standards. I have previously written an article about naming that mentions icon naming methods in more detail. You can read more: "Ten Thousand Words of Dry Goods! Probably the Most Comprehensive UI Designer File Naming Standards".

Let's briefly talk about the naming rules of icons. Many new UI designers who have just entered the workplace will emphasize that icons must be named in English without knowing the reason, and collect various common English naming words. First of all, I want to point out that this practice is wrong.

Because when it comes to the icon system of the entire application, there will be a large number of icons with "abstract" meanings. For example, in the example above, there is a startup icon with the Chinese name "中二", so how should this word be translated? Even if you are not restricted by your English level, the English you write does not mean that developers can understand it, and the accumulation of a large number of abstract words makes the naming unable to become an effective index condition, because no one can understand it. When developers need to find an icon, they still use thumbnails instead of names.

Therefore, if there is no specific naming convention internally or the programmer has no special requirements, I recommend using the Chinese naming system, because most domestic programmers are accustomed to renaming the obtained icons.

The naming format can be divided into 3 levels, the format is roughly: "Module_Name_Status@1x", such as the following case:

• [email protected]
• [email protected]
• [email protected]

Of course, we can adjust it freely according to the actual scenario, but everyone should keep in mind that the icon naming is to facilitate our search and retrieval.

The naming of the icon symbol should be consistent with the naming of the icon, so as to achieve twice the result with half the effort.

4. Icon Format

The export format of the startup icon in the previous chapter will export different sizes according to different devices and scenarios, and use the PNG format. Don't worry, although the tool icon also faces the problem of different devices, it does not need to export so many specifications. The following will talk about the export types of two icons.

Bitmap Format

The most commonly used export format is the bitmap PNG format. Because monitors have different display magnifications, we need to export images in 1x, 2x, and 3x magnifications. That is, if we design a 16pt icon, we need to export it in 16pt, 32pt, and 48pt sizes. The exported file name is suffixed with @1x, @2x, and @3x.

This specification is universal for both iOS and Android. Although there are devices with 3x or higher specifications, those devices only need to use the 3x specification.

Although it will be mentioned later that icons can be exported in vector format, icons that use gradients, projections, or skeuomorphic styles must be exported in bitmap format, otherwise the detailed elements of the graphic cannot be fully recorded.

Vector Format

Exporting icons of three different sizes is troublesome, and bitmaps often take up a lot of space. Therefore, in order to optimize this problem, iOS and Android both support vector-format cut-out files by default in previous system updates:

• iOS uses PDF 1x cut
• Android uses SVG 1x cut

Of course, if you export using a vector format, remember to save iOS and Android separately when classifying folders, rather than mixing them together.

Conclusion

I believe this is the most complete and detailed icon tutorial on the entire Internet. I hope that you can gain something from it and master the correct approach to entry-level icon design.