How to create an excellent C-end component library? Let’s take a look at the actual cases of Shell Design!

"Components" are a very important part of platform-level products. Designing components can not only save design and development costs, but also reflect the constraints of design concepts. However, with the increasing complexity of platform-level product business scenarios, the interaction modes and visual forms of the design components that have been accumulated in the past cannot keep up with the demands of business development. Therefore, we think about how to build and iterate an excellent component library - not only to maintain good universality and solve the problem of experience consistency of all platform products; but also to maintain the characteristics and customized needs of each business line, that is, the so-called "harmony in diversity" of platform-level components.

Background and goals of upgrading component libraries

With the development of the business in the past two years, the components accumulated in the early stage have gradually failed to meet the business demands, and the utilization rate and coverage rate of some components are very low.

Therefore, we decided to upgrade the Shell platform components. Our goal is not only to optimize the "basic components" to maintain their good versatility and achieve the purpose of "harmony", but also to carry the needs of more experience scenarios of business lines (second-hand houses, new houses and rental houses) to serve the "difference" of the business.

In order to better achieve the upgrade goals, we considered the following questions:

1. What are the different roles of people who use the design component library? Are their demands different?

In our eyes, design components are a kind of management of design work. In the complete chain of design work from output to implementation, there are mainly three types of people:

Shell platform designers and designers of various business lines: Platform designers exhaustively list component usage scenarios while refining business demands to help business line designers complete design work more efficiently and save time and effort through components.

Development team: Through the designer's output, clarify the specific framework and degree of freedom of component development (for example, whether the button color supports customization for different businesses, etc.)

Product team: Clarify the design standards through design component documents. When all roles have a common understanding of the standards, there is no need to repeat the requirements for parts that can be built using components, saving costs for all parties.

Therefore, what designers need to produce is not a simple component library source file, but a design component expression document that can be understood from the perspective of partners with different roles.

2. Are more components really better?

Our conclusion is: it is difficult to know where to start if you try to cover everything. When designing components, most students tend to be anxious about gains and losses, thinking that if there are enough components, they can handle more usage scenarios and the specifications are detailed and unified enough.

However, this is an ideal state. If the granularity is too low, the design will be unbalanced. The imbalance here means that the balance between innovation and standardization is broken, which is obviously not what we want. In addition, the platform-level component library has the ability to regenerate and develop continuously, so there is no need to pursue quantity blindly.

3. What methods can be used to reasonably control the quality and quantity of components and select components with high versatility?

We prioritized the core key pages with the top 30 traffic on the Shell platform, defined the scope based on the data, and then sorted out the components. As shown in the figure below, we found that the top ten components with the highest usage rate are arranged in descending order: tabs selection>Navbar>House card (common business component)>Agent booth (common business component)>Button>Notification and prompt>Popup>Search box>Action menu>Standard floating ball.

In this way, we can design and code components with higher frequency of use according to the above priorities.

We broke up all the components in Shell's original component library and redefined them into three categories:

• Platform basic components: refers to elements and basic components that do not have business attributes, such as buttons/forms/lists/search bars/system feedback pop-ups/action bars/Navbars, etc.
• Business common components: refers to components that span multiple businesses but vary slightly in different business scenarios and have common elements that can be refined, such as broker booths/property cards.
• Business feature components: refers to components that belong only to a certain business application category. There are no common components to be refined, but the reuse rate in a single business line is high.

The clear classification of components can help us summarize and organize them according to unified standards and principles whenever new components are added in the future.

Optimize common business components

In addition to optimizing the basic components of the platform, we also optimized the property listings, a common business component that is used frequently.

Listings of properties are usually presented in a linear structure on the Shell platform. Users scan vertically to obtain macro information about properties, and browse horizontally to understand the details of a single property entry and perform related operations. It is often used in second-hand housing, new housing, rental, overseas and other business lines. Due to the development of the business, the original listing style of the Shell platform required more and more information to be displayed, which was listed in the list in sequence, resulting in low display efficiency and no highlights to attract users, which ultimately led to "lower decision-making efficiency" for users on the listing.

In order to improve decision-making efficiency and enable the optimized list to be used in various business lines, we must first understand what content should be displayed on the property card in different business scenarios? Here we apply the conclusions drawn from previous research - the mental model of users browsing property lists.

Figure 3: The mental model of users browsing listings

Guided by the mental model, we conducted “element enumeration”.

After getting the specific elements to be displayed, we began to think about what the underlying structure of an inclusive list should look like. After several repeated deliberations and attempts, we came up with the three-layer structure shown in the figure: container backplane layer, interactive operation layer, and content display layer.

△ Figure 5 The three-layer structure of the property listing

• Container backplane layer: It is a box that carries all the contents inside the list. In this layer, we define the shape, rounded corners and other properties of the container to make it a unified underlying template.
• Interactive operation layer: This layer contains all the operations that users can perform on the list, such as following, viewing VR pictures, etc. In addition, we define a unified interaction method for each specific operation behavior.
• Content display layer: This layer covers all specific information that users can view, including the property title, building name, property details and dynamic floating changes in price.

Through the three-level division, we can clearly define the specific responsibilities of each level, which will help us better summarize and organize the presentation of information when faced with complex business scenarios and massive information content in the future.

After completing the element enumeration and structural layering, we drew a basic framework template, as shown below:

Then we embedded the detailed information of different business lines into the templates and designed them into listings for different businesses and scenarios. With this design result, we had an in-depth discussion with the product managers and designers of the business lines and determined the rhythm of possible iterations.

Data and Results

Based on the 14-day data, the CTR of the second-hand housing listing increased from 44.65% to 51.35% after the revision, which is very rare for a housing listing.

Summarize

The above is the full content of this article. I believe that everyone has mastered the basic method of establishing a C-end component library. Here we summarize the creation process of the component library:

The component library is a design asset accumulated by every user experience designer in their daily work. Components should be "harmonious but different". "Harmonious" means using standardized underlying containers to wrap the extracted elements with high reuse rates to form encapsulated modules with consistent experience and interaction. "Different" means that each business line can define the elements to be displayed in the content display layer according to its specific usage scenarios, ensuring a certain degree of freedom and the ability for each to grow.

The house listings have been online on the homepage of the Shell platform for about half a year. Through the revision, the decision-making efficiency of users when using the house listings has been improved to a certain extent, and the business coverage has gradually expanded. With the collaboration of R&D teachers, the encapsulation of Native and Flutter components has been realized, which greatly shortened the development time and thus improved the overall R&D efficiency of the product.

I hope this will bring some inspiration to fellow designers who are also building component libraries. The Shell User Experience Team will continue to work on exploring more business feature components and look forward to your attention.