How we fit the tables into the smartphone screen and unified them as part of the design system

We develop working tools for employees and partners of the customer. Most of the modules we created contain tables, registers, cards with detailed information.

Initially, the main part of the modules was sharpened for the web, because office workers from stationary computers work with the systems. About how we worked out a design system for the web, we wrote earlier .

But life is constantly accelerating, so that the speed of decision-making increases significantly. Our users need to be up to date at any time, and not just sitting in the workplace. And we understand that we must provide mobile information sufficient to make operational decisions.

For design design, this poses us 2 tasks:

1.Turn big to small - translate large lists into a mobile presentation.



2. Develop a unification approach - unify the mobile presentation for different lists within our ecosystem. So that the user experience is consistent, regardless of the module with which the user works.

In this note, we will share how we approached the solution of the problems of translating tables into lists and unifying the presentation of different lists.

We agree on the concepts on the shore.

The design object we have, in fact, is a row in the table.

For instance,

• Travel application
• expense report
• sales information
• Application for connecting a partner and so on.

Further in the article we will call our object a line.

Decomposing the task

First of all, we put together and analyzed all our services, in fact, disassembling them into components.

We determine the data that needs to be transferred to the mobile version

Despite the fact that there is a lot of data, and they are different, each unit - the line of the table (application, transaction, news, etc.) - has an identification number, a humanoid name, date (creation, update), status and opportunity with this to do something. And then varieties and details begin.

Defining a table pattern

How will we fit this amount of data on one page? Google’s Material Design system is similar in structure to ours, and their solutions turned out to be quite applicable to our realities.

The concept of Material Design data displayed lists ( a List ) and cards ( Card , Card collection ).

We decided to work with cards, because there is a lot of information and it needs to be clearly separated. And the list is more suitable for simple structures.


Image source

In fact, the card represents a single, self-sufficient and indivisible block of information. Plus, cards have many options for showing additional information and actions, which is important for business data.

We fixed the rules on how to unify data

When creating a system, it is important to ensure uniformity so that cards are presented equally regardless of the nature of the information.

1. Unified rules for building a card. Cards should be similar in structure: the user should not be retrained for each new service. Therefore, information blocks and the priority of their display are fixed in the rules.
2. The card - not all, but the most significant information from the table - should be visible on the smartphone screen.
3. The methods for obtaining (displaying) additional detailed information from the table should also be uniform.

Build the constructor

We highlight the essence in the line

In order for the user to immediately recognize the desired card in the list, we select the information that identifies the line, and we make the additional data less noticeable.

We divided the content of the card into 3 degrees of significance:



1. Key information - it is necessary, but possibly insufficient to make a decision. But this is exactly what is in all modules, and it is precisely her presentation that we unify.

1.1. Object identifier - ID, number, date and other unique values ​​for each card.

1.2. Status is what happens to an object. By status, users decide what to do with the card. Often they just come from a smartphone to check the status.
We set the actions next, because the status, as a rule, determines the possible actions, and the actions lead to a change in status.

1.3. Actions - each line always has target actions (accept / reject) and a number of additional actions (redirect, ask a question, etc.).

Key actions cannot be more than one or two. We make them available explicitly - we place them directly on the card. And we hide additional ones under Action.

2. The specific information of each of the modules is the details that clarify the information and are important for understanding the task and making decisions. We hide them in a detailed view and show them on request. This way we avoid overloading with details, leaving additional information readily available.

3. Additional details, information that is needed for a thorough study of the situation, but does not affect decision-making. We can’t put it in a mobile presentation at all. It remains only in the web version.

Card construction principle

We act in accordance with the F-pattern .

• We place the key information in the upper left corner.

Picture source

• We arrange the information on the left - this is familiar to the user, he is more likely to read the information located there in the first place.

Picture source

• We present information in text, not in pictures or icons. They did so, because in our case they clutter up the place and can often be ambiguously perceived.
• We avoid excessive content and do not transfer additional details from the web.

Picture source

Filters and Sorting

Regardless of whether it’s a web or a mobile presentation, a table or cards, any complex list needs to be sorted and filtered.

For the mobile presentation, we agreed on the following:

• Sections with filters and sorting are collapsed to the appearance of a button.
• When you click on filters, a lightbox with settings opens.
• When clicking on sorts, a drop-down list for the device opens.

Result

So, guided by the techniques described above, we prepared mobile presentations for different modules of the customer’s ecosystem:

• Applications for connecting a partner to the agent network
• Corporate News Administration Panel
• Travel Requests

Total

We unified the list data in the mobile application in structure and appearance. Regardless of the essence of the possible actions with the card or the essence of the information in it, the cards look uniform. In each case, it is intuitively clear what actions will lead to what result.

The development of mobile presentations for the following modules is limited to what you need.

1. Define a set of information
2. Prioritize information blocks,
3. Write the appropriate texts in the interface,
   
   
   • “Date of posting” / “Date of departure” / “Date of publication”.
   • “Agree / Reject” or “Agree / Disagree”.
4. If necessary, work out individual visual elements.