On mobile admin tables, users keep missing the right-hand columns — should we add a hint or switch to cards?

You should not simply let a wide desktop admin table scroll horizontally on mobile. The deciding factor is not the small screen, but what the user is actually doing on this screen: if they are comparing the same set of fields row by row, horizontal scrolling with a frozen first column can still work; if they are handling one record, breaking each row into a card is more reliable. Based on common 2026 mobile admin delivery experience, when there are more than 5–6 columns and only a small portion is visible on the first screen, horizontal scrolling becomes noticeably less efficient for finding information.

1. A mobile table is not a scaled-down desktop table

On desktop, a table supports same-screen comparison: a dozen rows and eight to ten fields can all be seen at once, and a quick scan lets users spot anomalies. On a mobile portrait screen, the effective width typically falls between 360–430px; after subtracting page padding, the actual content width is even smaller. The same number of columns gets squeezed into narrow strips only a few dozen pixels wide, and even two Chinese characters may wrap to the next line.

• Horizontal scrolling is a hidden behavior: users cannot see that there are more columns on the right, so they easily assume the data ends there — a frequent source of misjudgment in admin scenarios.
• Touch targets fall short: mobile tappable areas are commonly checked against an experience range of 44–48px, while text links and small icon buttons in tables are almost always below that line.
• Thumb occlusion: when scrolling horizontally, the right-hand fields are exactly where the finger presses, becoming visible only after release, which makes checking data a poor experience.

So on mobile, either reduce the columns or change how rows are presented. Simply wrapping a horizontal scrollbar around the outside essentially hides the problem rather than solving it.

2. First determine whether this screen is for comparison or for handling a single record

This is the dividing line between horizontal scrolling and cards. In the same order table, finance checking amounts is a comparison perspective, while customer service handling after-sales is a single-record perspective. The more suitable solution differs for each, and much rework comes from treating the two as the same thing.

1. Comparison perspective: users need to compare different rows of the same field horizontally, such as sorting by amount or filtering by status. The number of fields should not exceed 5–6; keep horizontal scrolling and freeze the first column.
2. Single-record perspective: users tap in to handle just one thing. There can be many fields, but only one row matters at a time, so a card layout is clearly more suitable.
3. Mixed scenario: the list shows 3–4 main fields as cards, and tapping through to a detail page reveals the full fields. This is a relatively common compromise in 2026.

One reminder: once a comparison need is turned into cards, and the cards lack columns that can be compared, users can only tap into each one individually, which actually drags down efficiency.

3. How the three common approaches compare

Horizontal scrolling, cards, and collapsing secondary fields each have their own trade-offs. Choosing wrong is often not because something looks bad, but because the approach does not match the task type.

• Horizontal scrolling with a frozen first column: suitable when there are few fields and horizontal comparison is needed. The delivery experience range is 3–6 fields, with total column width kept within 600–900px. The trade-off is that users easily miss columns on the right.
• Breaking each row into cards: suitable for single-record handling with many fields but only one row viewed at a time. A single card commonly has 4–7 fields plus 1 primary action. The trade-off is that long lists require more scrolling, and only 2–3 items may be visible per screen.
• Collapsing secondary fields: the list shows only primary fields, while secondary fields are expanded or moved to a detail page. Suitable for tables with a stable field structure and a clear primary key. The trade-off is that expanded states and post-expansion hierarchy require extra design.

The three are not mutually exclusive. A common combination is: cards in the list showing primary fields, full fields on the detail page, and filter and sort entries kept at the top of the list.

• Number of fields: horizontal scrolling suits 3–6 columns; cards suit 4–7 fields per record.
• Items visible per screen: horizontal scrolling commonly shows 6–10 items (row height about 48–64px); cards commonly show 2–4.
• Main risk: horizontal scrolling risks missed columns; cards risk scroll fatigue and a primary key that does not stand out.
• Implementation cost: horizontal scrolling requires handling fixed columns and nested horizontal/vertical scrolling; cards require restructuring the layout and re-planning row height and action areas.

4. Three common pitfalls when switching to cards

A common situation in projects: the prototype only provides a horizontal-scrolling table, development implements it 1:1, and only during testing does everyone discover that operations staff cannot find the amount column on mobile at all, forcing a return to rearrange cards. Based on typical delivery ranges, this kind of rework usually takes 2–3 working days and also eats into later acceptance time. In enterprise project delivery habits, field priority and primary key are checked before deciding on the presentation.

• Flattening all fields into the card: information density is actually no lower than horizontal scrolling, and users still have to read line by line, so the point of the card is lost.
• Losing the primary key identifier: if the top of the card has no order number, name, or ID, users cannot identify which record they mean when copying, taking screenshots, or reporting errors.
• Piling all action buttons in the top-right corner: three or four buttons squeezed together cause touch hotspots to overlap, noticeably increasing accidental taps.

A rough pass line is: a clear primary key at the top of the card, 3–5 key fields in the middle, 1 primary action kept at the bottom or top-right, and all other actions tucked into a more menu.

5. How to tell whether the redesign passes

The criteria must be checkable, not left to feeling. The following items can be reviewed one by one before launch.

• The primary key and status field are visible on the first screen without scrolling or tapping.
• One screen shows at least 2 complete cards, or 6+ rows of table data.
• The horizontal scrolling approach has a scroll hint, such as an edge gradient or letting the next column peek out by 8–16px.
• Touch targets are checked against the 44–48px experience range; even dense lists should not go below 40px.
• Verify on real devices, not just in a scaled design preview, because fonts, spacing, and fixed positioning often behave differently.

6. Applicable scenarios and boundaries

Switching tables to cards suits admin systems used frequently on mobile, such as orders, tickets, approvals, and customer lists, where users need to push each record forward one by one. Conversely, if mobile is only used to check data occasionally — not even a few times a week — horizontal scrolling with a frozen first column is enough, and there is no need to rebuild the entire list for it.

• Suitable for cards: many fields, each record handled independently, and users need to tap into a detail page to continue.
• Suitable for keeping horizontal scrolling: few fields that must be compared horizontally, and users are experienced operations or finance roles.
• No need for major changes: mobile is only for low-frequency checking, and the redesign payoff is lower than the cost of revisions and integration testing.
• Not suitable for forcibly splitting into cards: when fields are strongly related and must be viewed side by side on the same screen, splitting them only makes users tap back and forth.

FAQ

Do mobile tables always have to be changed to cards?

Not necessarily. When there are 5 columns or fewer and users need horizontal comparison, horizontal scrolling with a frozen first column is easier; only when there are many fields and each record is handled independently should cards be prioritized.

Users keep saying they cannot find the right-hand columns in a horizontally scrolling table. What should we do?

Add a gradient hint at the right edge of the table, or let the next column peek out by 8–16px. At the same time, fix the horizontal scrollbar below the table header to reduce the misunderstanding that there are no more columns.

What if there are too many fields in a card?

Keep only the primary key, status, and 3–5 key fields in the card, and move the rest into the detail page or an expandable area. The criterion is that at least 2 complete cards can be seen on one screen.

Is it too few if a card list only shows two items per screen?

It depends on information density. When each item has a lot of content, 2–4 per screen is a typical range. You can use a more compact layout to fit 3–4, but do not squeeze touch areas below 44px.

Do mobile lists need sorting and filtering?

Yes, but prioritize filtering. When there are many fields, sort entries are easily tapped by mistake. A common approach is to put filters at the top of the list and tuck sorting inside the filter panel.

Before starting, ask one question: on this screen, is the user comparing fields or handling a single record? Then decide between horizontal scrolling or cards based on the number of fields. Before launch, use real devices to verify whether the primary key appears on the first screen, whether touch hotspots meet the standard, and whether horizontal scrolling has a hint. For admin systems that only do low-frequency queries on mobile, there is no need to force a card redesign; based on common 2026 delivery habits, horizontal scrolling with a frozen first column is already enough.