Design the Timeline four things I learned

It's not particularly difficult to design the timeline. It's easy to judge a cornice, but to design a building, you need to start with every tile, and this is where design and engineering are connected. The design timeline also seems to be a handy thing, but sometimes it is flying blind to do the details. Look at the four experiences that designer Garron Engstrom has learned in designing the timeline of the tax system. It's like crap, all right? Product look ~

You have to admit that the timeline is everywhere. The most typical is social media, such as Facebook and Renren, SNS community will show your life as a timeline of the form, micro-blog and Twitter, also do not have to say, also in the timeline to arrange information, and mobile app path is more famous for the timeline. The timeline not only helps the user to comb the information, but also is the basic rule of user interaction.

Can the timeline handle information just stop there? I don't think so. I want to apply the timeline to the tax system. So how do you present the confusing data information in the tax system through the timeline? How to make people feel at ease, so that users can easily access important financial information?

I do not know.

I hope I said, "Yes, I know!" But it's really too early to say. In the tax system timeline I recently participated in, I provided the user with the function of the tax history query. For ordinary users, the experience of their interactions on the timeline of the social network will be more easily migrated. The success of this design remains to be seen, given that the whole system is just in use. However, anyway, I learned four things in the design project:

1, the time axis design does not need so clear-cut

What surprises me most is that, in many cases, the design of the timeline does not need to be designed so clearly that it is not necessary for the user to realize that it is a timeline. The most traditional and typical time axis is a continuous horizontal line representing the distribution of points on different time/events. The timeline I designed is not horizontal, but vertical, with different events on it, and each event can be folded and expanded. The only thing that reminds you of the timeline is the time that is marked on the breakpoint for each event. Fortunately, this design does not break the user's perception of the timeline.

2, each point on the timeline must correspond to an event

This is obvious. This concept should be understood in our history class, and every point on the timeline must represent an important historical event. But when we start to render data through the timeline, we need to consider the meaning and events represented by each data on the timeline. So, when you want to present a tax refund amount of data, rather than focus on the tax, rather than focus on the user submitted amounts, time and corresponding operations. If you extend it, you will not only present a complete event (time, amount, operation), but also display the data that the user cares about most, including supporting documents, order details, application status, and so on. (Of course, you don't have to present all the complete information, but it should at least exist, let the user know.) )

3, do not show all the things at once

The information should be gradually disclosed. That's why I'm adding folded functionality to every tax event. This design helped me accomplish two things:

Tell users what they care about most is not overload information

Tell the user to expand the fold in other places to see more information

4, let the user as much as possible to render data (and 3 does not conflict)

When the user presents the information, is it better to show the good or less to show the appropriate? Show me more.

The chart above is the timeline of our tax system.

The tax system is to help users manage their data, and using the timeline allows users to view and manage their tax information more systematically. In the past, our system has encountered this situation: users use our system in the first year, the next year may be transferred to other tax management system, and the third year to reuse our tax system back. As a result, a full year of data will be vacant on the display of the timeline. In this case, we give the user a portal that allows them to postpone submitting data for the previous year, which can help them manage the data more systematically, or win more loyal users.

In addition, we also need to consider the first time users of our system. Indeed, when they just joined, there was no data to fill the timeline, and this time we did two things:

Guide users to use the timeline and tell them how to access/manage data for the previous year

If they accidentally generate extra accounts, tell them how to handle and circumvent this

The timeline is bi-directional, not only allows users to manage future data, but also directs them to manage past information.

　　Conclusion

The above is my experience in this design revision, with the arrival of the tax season, our tax system ushered in more users, the design of the timeline also needs to be based on the needs of users gradually add more functions. For example, we have just added the time axis refresh function, as of now, feedback information is very good!