Traffic lights and design specifications

When crossing the road, I suddenly noticed the traffic lights, and the recent new traffic rules were also in full swing, So I thought about the "design specifications.

When it comes to design specifications, many people think it is a very virtual and not pragmatic performance project. Many enterprises design specifications for design specifications, set rules with their heads, and put their energy into it, and finally died. In the past, I was reluctant to develop design specifications. After suffering from the design of multiple terminals, I gradually understood the significance of the design specifications "existence is reasonable. A front-end UI framework that can improve development efficiency by 500%!

 

Revelation of traffic lights

Before you talk about it, let's go back to the traffic lights:

This is another common traffic light. When the industrialization and urbanization reach a certain level, and complex traffic is like a horse or a dragon, traffic lights also emerge. Here, the traffic lights play a normative role. passers-by and drivers reach an agreement that the red light stops and the green light goes. Everything goes in order. Without it, crossing the road will become thrilling.

This is a simple and common sense, but the migration of the same thinking to design will lead to a lot of interesting thinking.

It is often seen that product design teams often have heated discussions on interaction issues such as navigation and feedback. Although multi-element collision is a good thing, once the system starts to be large, the problem will also be exposed: the team members have their own creative pursuits, especially those who consider innovation as life. The pursuit of Rule innovation is even more prominent. If the team lacks the consensus and design constraints such as "Red Light stops and green light goes, this will lead to unordered superposition of rules, making the overall interaction of the software messy and complex. A front-end UI framework that can improve development efficiency by 500%!

 

Three sins of design specifications

1. Too early/too late for Standardization

The road in a small village does not need traffic lights, because they are not needed at all. The existence of traffic lights limits people's freedom to move around. However, there is a type of company that, when its products grew up in an early age and its scale was small, it took a lot of effort to develop design specifications early, but it was unacceptable and difficult to implement. It is neither too early nor too late. Large Companies may make such mistakes, such as Google and Android, which had a very rough and absent standard before 4.0, the problem will not be detected until your system runs many iPhone-like apps.

2. The specifications are too detailed

The traffic light is a simple "constraint". When the red light stops and the green light goes, you can decide how to stop and how to proceed. The makers of iPhone design guideline are very insightful. They chose a broad expression when writing specifications, there is no definition of how big the "click button" should be, there is no definition of "Return button" must be long in the upper left corner, there is no definition of deletion, there must be an animation thrown into the bin... The finer the expression, the larger the limit, will become the shackles of design team innovation.

3. The specifications remain unchanged

There were only two colors to replace in the early periods of traffic lights, but there was still some danger, after continuous improvement, a three-color signal lamp consisting of red, yellow, and green has been in use until now (some people have come to deny the yellow light ). The traffic lights are no longer a simple color replacement, but a complete signal system, sidewalk, Lane, with direction instructions... The same is true for design specifications. When the product becomes more complex and as big as a giant such as QQ, the specifications will be gradually improved and clarified to ensure the consistency of experience. The establishment of specifications is a long-term process. Broad design guidelines should keep pace with the times.

 

Big guidance and small specifications

Prior to the formal discussion, many predecessors have made various kinds of thinking and debate. As for implementation, the team may also have different projects.

Taking iPhone product design as an example, Apple's official IOS Human Interface Guidelines (formerly called iPhone Human Interface Guidelines) comparison system, many product designs directly refer to this document to build their own apps. The only design specification in the product lifecycle is this ready-made reference. In addition to the official design guidelines, we will also refine the design specifications to 1 + 1 (platform specifications and application specifications) based on the project requirements) to sort out the complex interaction details of the software.

Standardized case (1): Information System

As a small part of the software design, the prompt system won't be noticed by many teams. In the past, we had a complete information prompt system, which divided the prompts into four categories: A front-end UI framework that can improve development efficiency by 500%!

3.0 during the design process, we optimized the entire system, removed the toast prompt, and unified the banner tips into a style, directly under the navigation bar.

Standardized case (2): Menu System

Menus are another common interactive system in software design. When our first version came out, we used a concealed (slide) design menu. After several versions of evolution, the appearance of menus is more direct and easier to expand, and provides explanations for non-operational exceptions.

 

IPhone QQ music is now a huge product, with a massive music library, information organization, personal music Asset Management, and basic playback experience ....

In addition to the above information prompts and menu systems, we also provide some simple guidelines for some common interaction systems of the product, including:

1. Navigation: defines global navigation rules, including normal Hierarchical Access, temporary interface, interface interadjustment, and cross-product interadjustment

2. Exception Handling: alerts and guidance for network interruptions and empty content .. A front-end UI framework that can improve development efficiency by 500%!

3. Brand communication: Visual Communication of music brands in terms of exceptions, Edge Conditions, and product slides

Of course, if something cannot be met, we will review it and adjust it in time. An efficient and controllable interaction system needs to change.

Finally, since most custom specifications have little significance (except for platform-level specifications), why should we put a lot of effort into it? In fact, the cost of small specifications other than the official specifications is very low. You do not need to organize a complete Style Library, but simply list the specifications on a large image, for reference by team members or intermediate designers. Mobile Internet products with extremely fast pace are simple and most vital.

Traffic lights and design specifications