Ququ Li, Interaction Designer
AntD Library is an Axure library of standard components in Ant Design Language, and this product has three purposes as following. First, AntD Library can prevent designers from making different styles of prototypes of internal desktop applications. Second, the components of Ant Design have relevant codes so that designers' prototypes are likely consistent with the final products, and the cost of communication between designers and developers are also cut down. Third, the library can acquaint designters with unfamiliar components and patterns. If you want to learn more from the library, please access the link and download the latest version.
The screen shot below is the information architecture of AntD Library V1.3. In this version, the module of the products are seperated so that users have to download and open different files to make a prototype, and this is the origin why I need to redesign this product. Besides, I find more serious problems after user interviews, and the following three points are the overview of the problems found in AntD Library V1.3.
Designers have different understanding of functions and they are often confused by the function-oriented classification. On the contrast, they are more sensitive to the frequency of use of the components, which is relevant to their integration levels.
AntD Library lacks several common components which are provided by Ant Design Language. Some designers have requirements such as icons, spacings, UX comments and industrial patterns.
In the previous version, AntD Library is divided into AntD Box and AntD Component so that designers should open these two files simultaneously and switch between windows frequently.
There are several methods of user research like quantitative analysis and qualitative analysis. Due to lack of history data when designers use AntD Library in Axure, I can only use the method of qualitative analysis, especially user inteview, in which six colleagues are invited. Not only interaction designers and product managers are involved, but also their proficiencies of Axure are different. The following four questions are the main content of the user inteview, and after one-on-one interviews and simple tests, a interview log can be drawn as the following diagram.
1. What the process of making prototype when you use AntD Library?
2. What do you think is the drawback of the library?
3. What is the most used components in the library?
4. What do you think of this component? Is it necessary?
Most interaction designers are familiar with Axure and the components of Ant Design, and they care more about the lack of components in Ant Library. So which components they need is the key point in their interview.
Product mangers almost feel strange with the classification and the name of the components and they care more about the learning costs and the efficiency of the library. So the hierachy of the library should be emphasized in their inteviews.
There is a lot of controversies in the current classification so that it is difficult for designers and product managers to find where the relevant coimponents are. Besides, the current hierarchy of the components is too deep to use.
It is difficult for Axure to import vector icons from other design libraries. But designers need icons so much that they have to draw by themselves. Besides, they also need some assistant components such as spacings and UX comments to communicate with developers more smoothly.
There are three key goals of the design solution. First, the operational efficiency of AntD Library should be improved, which involves redesigning the architecture of the library. Second, the library should provide plenty of components so as to reduce workload of making prototypes. Third, the library is also supposed to offer assistant components to regulate UX documents such as spacings and UX comments.
Function-oriented classification can be found in most to-C products such as online shopping and other consumer services, because people are familiar with the classification and accomstomed to the designation so that they will not be confused by where the certain items are. But for to-B products, a function-oriented classification is likely known only by the expert in related field. In this case, it is difficult for product managers to understand the classification, so a redesign of the architecture should be conducted.
In order to reduce the cognitive load of non-expert users, I adjust the architecture to integration oriented classification. For the basic componets and navigations, the integration of the elements is low, and their codes can be found in Ant Design Language. For patterns and best practices, the integration of the elements is high, and they are the precious experience from typical projects. In this way, both designers and product managers can easily access to the items they want.
The assistant components including spacings and UX comments are added in the library. In order to distinguish them from the content of the prototype, a striking color but not commonly used in UI is adopted.
Another bright spot is that the icons are vectors and can be changed color in Axure. In the previous version, icons were bitmaps and they had only one color, and it was hard to scale them or change their colors. But in the new version, iconfont is used to store the icons so that they can be scaled or changed colors like a normal font. These two changes really improve the efficiency when designers are making prototypes.
The basic navigations and patterns are integrated to the library from other toolkits. In this way, designers can make prototypes as long as they open only one library.
This project has inspired me how to make a UI toolkit for a team. At the beginning, we can conduct user research such as user interview or usability test to collect components, patterns and best practices from team's designers. Then we need to unite like terms, dismiss the minority and retain the typical ones. In this way, we can collect plenty of components which are proper to the team.
As for classification, we cannot draw the hierarchy from designers. On the contrast, the opinions from other toolkit users such as product managers and developers are much more important. The hierarchy from non-experts can give consideration to both stakeholders. Instead, the classification from designers is likely to confuse those who are not familiar with the components.
Copyright © 2017 Junyu Liu. All Rights Reserved.