Interface design
Designing a Two-Column Mobile Store Without Tiny Controls
Last updated
Two columns create a real constraint
Showing two products per row on a phone makes the store faster to scan, but it cuts the available width for every label and control. The solution cannot be to shrink everything until it technically fits. Product art still needs a stable area, prices must remain readable, and Buy and Sell must remain dependable touch targets.
The card uses a fixed visual hierarchy: image first, then product name and price, then the three-part control row. Descriptions were removed from compact cards because repeated marketing text consumed space without helping the purchase decision.
Stable dimensions prevent jumping
The image area keeps a consistent aspect ratio, and product artwork uses object containment so different shapes do not resize the card. The quantity field has a stable width. Names can wrap, but controls do not move when a number changes from one digit to several digits.
On larger screens the same data expands into three columns with more breathing room. The component does not maintain separate desktop and mobile business logic; only the presentation changes.
Touch behavior is part of accessibility
Buttons have explicit accessible names, visible disabled states, and enough height for touch. A disabled Sell button communicates that the quantity is zero. A disabled Buy button communicates that the remaining balance is too low. Keyboard users can reach the same controls in a predictable order.
Color is not the only state indicator. Disabled controls also change contrast and stop responding, while quantities and totals update as text. Motion respects reduced-motion preferences so the game remains usable without animated feedback.
Testing the actual narrow cases
The layouts most likely to fail are not the average cards. I test long translated labels, twelve-digit quantities, the narrowest supported phone width, browser text scaling, and the sticky balance while the on-screen keyboard or browser chrome changes the viewport.
A responsive layout is successful when the player can continue the core loop without zooming, horizontal scrolling, or guessing whether a control is active.