How to establish the standard requirements for B-end products? I have summarized five aspects!

In recent days, I have been sorting out matters related to "specification requirements, testing methods and scoring methods" in design. In the reference to industry specifications and continuous practice, I have accumulated some small experiences, which I would like to share with you.

For many companies, the content related to experience design is basically triggered by "design walkthrough". The C-end pays more attention to design walkthrough, after all, the product is directly facing market competition and cannot be slack; but B-end designers always encounter the situation of "the required modification points are proposed, but the development is basically unchanged" during the design walkthrough. Therefore, it is particularly important to establish "standard requirements" and promote a virtuous cycle of design walkthrough. This is not only conducive to enhancing the value of experience design in the product, but also enhances the competitiveness of the product, and ultimately creates an "Aha moment" for customers and users.

This article will expand the specifications from the following five aspects. The specifications mentioned below do not only refer to design specifications, but also have a broad meaning:

• What are the regulatory requirements?
• The role of norms
• How to establish regulatory requirements
• How to formulate a test method
• How to formulate scoring rules
• Document directory structure

What are the regulatory requirements?

For an executable specification document, the specification requirements are composed of several items of different categories, which eventually form a guide for the object to be tested. The items in the specification requirements will be further constrained by level requirements due to the degree of difficulty of implementation, user impact, readability requirements, universality and scalability, so that the object to be tested can gradually achieve the result according to the actual situation.

It is also necessary to define the difference between standard requirements and standard principles. In some documents, standard principles are explained first, and then standard requirements. Standard principles are the generalization of standard requirements, and standard requirements are the specific details of standard principles.

For example, the regulatory principles of the "APP Age-Friendly Standards" require a reasonable structure, such as:

• Flatten the product information hierarchy according to the product design goals;
• Show the product functional architecture through good visual presentation and clear navigation to help users more clearly obtain information of different levels and structures;
• Information is clearly and concisely classified and displayed based on the needs and scenarios of elderly users.

The corresponding specification requirements are refined into some situations on the page layout. For example, the home page entrance under the page layout should adopt a large grid guidance method, and the number of main grid entrances should be controlled within 9. TAB navigation should be controlled within 5, and the TAB paging component should have a maximum of 7 pages on one screen, etc.

It can be seen that the normative principles will provide certain guidance to the normative requirements. They are inspiration and guide.

The role of norms

In different industries and fields, standards are everywhere, such as process standards for departmental collaboration, data standards for software systems, and service standards for APPs that are suitable for the elderly. However, for many products that are not yet subject to standard constraints, they will feel constrained once they are subject to standard constraints (for products, data security standards, personal information standards, etc. are easier to constrain, but design standards are more difficult to implement), but standards do have a certain role.

The significance and role of standards are self-evident, but many people always have resistance when they first come into contact with them. From the perspective of the standards themselves, they are a summary of the best practices of predecessors in a certain field, which can prevent beginners from repeating mistakes in the field and ensure the acceptability of the results to a certain extent. Of course, standards can be improved and revised, and are not immutable.

I saw this story online, and I feel that explaining the role of standards would make it easier for everyone to understand.

An officer had very high requirements for target shooting, but the soldiers did not understand and thought that as long as they could hit the target, there were no need for so many standards and requirements. The officer's explanation was probably: "None of the actions you are required to do now are redundant. They are not only based on the experience of our predecessors, but also summed up by them at a high price on the battlefield. It is not a big problem if you do not follow these actions here, but if you do not do so on the battlefield, it is likely to cause a big accident. Strictly following the requirements of the regulations is the prerequisite for becoming an excellent soldier."

Yes, isn’t the same principle also true for the norms of various industries?

Regarding design specifications, some designers have told me that there are two kinds of opinions: one is that since there are specifications, what else can I do? It's boring; the other is that working under specifications is too free and I can't give full play to my abilities. Is that really the case?

I think all designers who have just started will have this situation, which is understandable, but I feel that it is better to have design specifications than not to have them. It can not only ensure the consistency of product experience, enhance brand professionalism and influence, and ensure the unity of collaboration among members, but also is a way for team members to maintain consistent values. Many people think that great design lies in wild creativity and expression, but the real great design lies in how to create within the constraints of rules and regulations.

How to establish regulatory requirements

I have led the establishment of specifications and also participated in the customization of specifications. Leading the establishment of specifications requires thinking and pondering from 0 to 1, referring to industry standards, etc.; participating in specifications is more about learning and giving feedback, learning how they think about specifications, and helping to optimize specifications together.

When I participated in the "Securities and Futures Industry Mobile Internet Application Service Specification for the Aged", a specification participant from an institution proposed that a certain specification requirement was reasonable, but the technical difficulty was high, and suggested that this standard be included in the enhanced specification. This leads to two thoughts. I used to think that design specifications must be followed, so how can there be optionality? In fact, it is not. Due to various constraints, such as low user perception, high technical difficulty, and high development costs, some specifications do not need to be complied with and can be followed selectively. The second point of thought is that the establishment of design specifications is not simply based on the design itself, but also needs to consider other situations and look at them comprehensively.

In general, the establishment of regulatory requirements requires consideration of these aspects:

• What problem does the specification aim to solve?
• Scope of the specification
• Guiding principles for regulatory requirements
• Specific regulatory requirements
• Level required by the specification

Below I will explain one by one the "APP Age-Friendly Standards" which have received a lot of attention this year.

1. What problems does the "APP Age-Friendly Standard" want to solve?

With the rapid development of the Internet in my country, people's production and living styles have been profoundly changed, and the efficiency of social services has been improved. However, at the same time, the number of elderly people in my country is growing rapidly, and the majority of them cannot use mobile phones or surf the Internet, which makes them inconvenienced in their daily lives such as traveling, seeking medical treatment, and consumption. By promoting APPs that are suitable for the elderly, the country can also let the elderly feel the warmth of the information age and obtain more intimate and convenient social services.

2. Scope of the "APP Age-Friendly Standards"

When providing elderly-friendly services, companies can embed the elderly-friendly interface into the APP or develop a separate elderly-friendly APP based on actual conditions.

3. Guiding principles for the requirements of the "APP Age-Friendly Standards"

It includes design guidelines such as perceptibility, operability, understandability, compatibility, and security. There are detailed descriptions under each principle, so I won’t go into details one by one.

4. Specific requirements of "APP aging-friendly specifications"

According to the design guidelines, the specification expands on specific requirements, taking perceptibility as an example:

Font size adjustment

In mobile applications, it is recommended to use sans serif fonts. The font size should be adjustable (adjusted with the system settings, or there should be a font size setting option within the mobile application). The maximum font size of text information of main functions and main interfaces (excluding subtitles, text images, and text related to the functions and effects of mobile applications) should not be less than 30 dp/pt. The main text information in the elderly-friendly interface and a separate elderly-friendly version of the APP should not be less than 18 dp/pt, while taking into account the applicable scenarios and display effects of mobile applications.

Line Spacing

The line spacing of text in a paragraph should be at least 1.3 times, and the paragraph spacing should be at least 1.3 times larger than the line spacing, while taking into account the applicable scenarios and display effects of mobile applications.

Contrast

The contrast ratio between text/text image presentation, icons and other elements is at least 4.5:1 (the contrast ratio of text and text image is at least 3:1 when the font size is greater than 18 dp/pt).

Color usage

Text color is not the only means to convey information, indicate actions, prompt responses, etc. to distinguish visual elements. For example, if a user enters an incorrect password, you can use text or voice to directly prompt the user that the input is incorrect, and avoid using color as the only means of prompting.

Verification Code

If there are non-text verification codes (such as puzzle and image selection verification methods) and other verification methods that are difficult for the elderly to understand in mobile applications, alternative forms of expression that can be accepted by different types of senses (vision, hearing, etc.) should be provided, such as text or voice, to meet the usage needs of the elderly.

5. Level of requirements for "APP aging-friendly specifications"

If an enterprise participates in the assessment, the items listed in the specification need to be scored one by one, and a report will be output. A score of 60 or above is considered qualified. Therefore, the levels of the specification items are equal, and there is no progressive requirement.

How to formulate a test method

As the name suggests, the testing method refers to the process of testing a system software through manual or tool means. Its purpose is to detect whether it meets specific requirements and ultimately achieve the goal of delivering high-quality software to customers.

Generally speaking, there are two types of testing methods: manual testing and tool testing. Manual testing is relatively time-consuming and subjective; tool testing is black and white, time-saving and objective. In design specifications, manual testing and tool testing are used interchangeably.

In the "APP Age-Friendly Specifications", the specifications recommend that companies conduct evaluations based on actual conditions through automated testing tools, manual testing, and other means.

How to formulate scoring rules

Testing alone is not enough, we also need to formulate scoring rules. When I was leading the establishment of the standards, I racked my brains to think about the scoring rules. The difficulty lies in what kind of scoring rules are acceptable to everyone. If they are acceptable, it means that the scoring rules are relatively reasonable, and this thing can be handled. For example, out of 100 points, why is 60 points considered a pass, instead of 70 points? How is it calculated?

Different industries have different scoring mechanisms for their specifications. There are two commonly used scoring rules for design specifications:

• The first category is to classify the specification requirements into levels, for example, level one requirements must be fully met, while level two requirements can be met selectively.
• The second type is to score each specification requirement, and finally get a total score, which is compared with the score set by the scoring rules, and then the result is seen. Here, the scoring rules for each requirement are different.

The scoring rules of Alibaba Cloud's Consistency Checklist adopt the derivative rules of the second category. After scoring a single item, each dimension is weighted and scored. The following is the formula. Interested friends can reply "2" in the Zhiguo Diary WeChat public account to receive the model document for study.

Document directory structure

The directory structure of a specification document generally includes:

• background
• scope
• Normative references
• Terms and Definitions
• text
• appendix
• References

Summarize

These are some of my little experiences that I would like to share with you. I would like to say that the formulation of specifications is a systematic project. It is not enough to just make the documents look professional. The actual situation in which the specifications can be implemented must also be considered. This is why the specifications require multiple rounds of reviews by relevant experts in the industry.

If you take the lead in formulating the standards, then with everyone's feedback and self-revision, you can not only improve your professional ability, but also make the standards stand the test of time.