Designing UX for Responsiveness
- Craig Morris
- Apr 1, 2023
- 5 min read
Updated: Apr 1, 2023
In this article, I'll be discussing the guidance I set for responsive design at my previous company. These were the guidelines I set for my team, and I believe they can be useful to other design teams as well.
In my opinion, these guidelines will work best for a team that is working on enterprise apps, and many of them at once. This was the situation for my team. We were an enterprise B2B company and our product suite was quite large - with over 100 applications of various scopes all using the same design rules, components, etc.
We arrived at these guidelines after a long evolution of our processes and after solving a number of design and technical challenges. Additionally, some of these recommendations are pulled directly from the biggest players in the space (Google, Apple, Microsoft) or adapted from their guidance.
They may not work for everyone, but they worked well for us, and there is surely something in this article that can help your team.
Design for the smallest screen first
Start by designing for the smallest screens first. Scale your small-screen designs up into the larger form factors. This allows you to reuse content and layouts in larger form factors.
Trying to scale large screens down simply doesn't work as well in practice.
Column-based layout
Break the viewport into 4 or 8 or 12 columns, depending on the platform. Generally speaking, UI elements should be no less than 2 columns wide. Be careful using widths of an odd number of columns, because depending on your layout rules, it can cause layout problems on certain form factors. We avoided it at our company because our layout components didn't support them well.
The Navigation areas of apps are not part of the column layout. See diagrams below.
Large screens are broken into 12 columns.
Tablets are broken into 8 columns.
Mobile devices are broken into 4 columns.
Margins and Gutters per Device
For each layout, the margins (space around the main content) and the gutters (space between columns) are tailored for the specific device to deliver the cleanest layouts.
Screen width in px | Device Class | Columns | Gutter Width | Minimum Margin Width (px) |
0-599 px | Mobile | 4 | 8 px | 16 px |
600-839 px | Foldable / Small Tablet | 8 | 8 px | 16 px |
840-1023 px | Tablet | 8 | 8 px | 16 px |
1024-1379 px | Desktop | 12 | 16 px | 16 px |
1380+ px | Widescreen Desktop | 12 | 16 px | 32 px |
Size Classes
iOS's Size Classes are a simple way to account for platform differences in your layouts. They define how a UI should look at different sizes and on different devices.
Personally, when I discovered these, they were a revelation. They made it so much easier for me to keep track of which variants I needed to create, and I was able to mix and match different variations of content in order to get the ideal layouts for each Size Class.
See a description of each Size Class below, and some layout tips:
Compact Width
Condense content into single columns.
Spawn additional views on top of the existing view (instead of beside)
Regular Width
Use multiple columns.
Consider line length for readability.
Some elements may still fit best as a popover or modal.
Expanded Width
Show side menus or lists for selection of critical records.
Most items should not need to be popovers.
Compact Height
Condense multi-line content into fewer lines.
Consider progressive disclosure of lower-priority information.
Regular Height
Items can be taller.
Content sections can contain more information without needing to select to see more.
Mixing and matching the above 5 Size Classes ends up creating 6 variations:
Regular Height, Expanded Width
Regular Height, Regular Width
Regular Height, Condensed Width
Condensed Height, Expanded Width
Condensed Height, Regular Width
Condensed Height, Condensed Width
These six variations can support a wide variety of device types and sizes.
Size Classes per Device
See below for the specific pixel sizes per device to determine which size class each device layout should use.
Screen width | Device Class | Device Posture | Horizontal Size Class | Vertical Size Class | Columns | Gutter | Min. Margin Width |
0-599 | Mobile | Portrait | Condensed | Regular | 4 | 8 | 16 |
| | Landscape | Regular | Condensed | 8 | 8 | 16 |
600-839 | Foldable / Small Tablet | Portrait | Condensed | Regular | 8 | 8 | 16 |
| | Landscape | Regular | Regular | 8 | 8 | 16 |
840-1023 | Tablet | Portrait | Condensed | Regular | 8 | 8 | 16 |
| | Landscape | Regular | Condensed | 8 | 8 | 16 |
1024-1379 | Desktop | Portrait | Condensed | Regular | 12 | 16 | 16 |
| | Landscape | Regular | Regular | 12 | 16 | 16 |
1380+ | Widescreen Desktop | Portrait | Expanded | Expanded | 12 | 16 | 32 |
| | Landscape | Expanded | Expanded | 12 | 16 | 32 |
Examples
4 column Mobile - Portrait
4 column Mobile - Landscape
8 Column Tablet - Portrait
8 column Tablet - Landscape (Mobile app)
12 column desktop - landscape
12 column desktop (Expanded)
Consider leaving 1 column of padding around app content areas that are wider than 960px.
Element Sizing
Be careful when stretching elements on large devices to be the full width of the screen. Consider line length and readability. Form fields should be no more than 4 cols wide, except in some special cases, like a Search Call-to-Action.
Modals and Dialogs should be full-screen on small devices, but may be small windows on larger devices.
Typography
Font sizes can be set as small, medium, large (possible other varieties) and they will scale depending on the platform.
Components
Layout components can expand into multi-column layouts for larger screens, or shrink down into a single column.
On Mobile, an ApplicationMobileMenu (v.8.0) should be used for navigation
On Tablet or Desktop, an ApplicationMenu (v.8.0) should be used for navigation.
Canonical Layouts
These are standardized layouts that can be reused to help developers build responsive apps quickly.
List-Body | Full Page | Body-Detail |
 |  |  |
List-Body
Good for showing a list of records with complex details.
Full Page
Good for workhorse apps and dashboards, or full-screen grids.
Body-Detail
Good for browsing a large collection in the Body area, and viewing record details in the Details area.
Touch
Generally speaking, when a user initiates a touch scroll, their intention is to scroll either vertically or horizontally. So, for general user comfort, the following guidelines should be followed. We did have a few apps where a users preferred to pan freely, but these were never simple content lists (think Google Maps).
But, for most of our enterprise productivity apps, on every screen the following guidelines applied:
When scrolling vertically via touch, the horizontal scrolling functionality on a page or section or app should be disabled.
When scrolling horizontally via touch, the vertical scrolling functionality on a page or section or app should be disabled.
Safe Areas
Leave margins on the edges
Leave room for the any status information
Account for dynamic island or camera bump
Reserve space for virtual keyboards
Foldables
Foldables are devices with expandable screens. They have one or more "postures," which are configurations of the hardware (folded or unfolded).
Typically, foldables support a single-column posture in their compact mode.
Common postures
Folded Landscape
Folded Portrait
Unfolded Landscape
Break content into two columns, make sure the central gutter is centered in the fold. This may mean that the two columns are unequal widths (for instance, if the left side includes a navigation bar)
Unfolded Portrait
Reflow content into a single column
Use caution when using two columns as they may not be wide enough to accommodate the content
Tabletop - Two portions of the screen are perpendicular, with one edge resting flat on a table
Considerations
Posture transitions
Center Hinge
Avoid placing key information on the center hinge. This includes modal dialogs that appear in the center of the viewport, and content sections that may stretch across the hinge.
Edges and corners
Elements on the edges or corners can be hard to hit reliably and comfortably
 |  |
Misc stuff
Context menus
For mobile these should be represented with an Action Sheet
For tablet, these should be represented by a Menu
For desktop, these should be represented by a Menu
Hover states
Items should have hover states when the device is using a pointer-based interaction mode (mouse cursor)
The cursor should change on hover to indicate navigable links
The cursor should change on hover of text content to indicate selection is possible It should NOT change when text is not editable or selectable
Keyboard
Software keyboards should appear when a user has focused an editable field. The virtual keyboard should not appear when a hardware keyboard is attached.
Keyboard Shortcuts
For devices with hardware keyboards, certain standard shortcuts should be supported where it makes sense
Copy (Ctrl-C / Cmd-C)
Cut (Ctrl-X / Cmd-X)
Paste (Ctrl-V / Cmd-V)
Delete (delete / backspace)
Submit (Enter)
Play/pause (Space)
Transitions
When moving from landscape to portrait modes and a list item is selected: show the detail view of the selected item following the transition to portrait mode.
If the user hasn't made a selection, return to the list view on portrait mode when switching orientation.
Drag and Drop
Coarse Targeting
Fine Targeting
Visual Indicators
Drop Zones
Persistent Zone
Hotspot
Pre-defined Zone
Windows
Sources
Size Classes on iOS: https://medium.com/swlh/ios-adaptive-layout-i-size-class-c561bd730e1
Right-to-Left Languages: https://developer.apple.com/design/human-interface-guidelines/foundations/right-to-left
Comments