Mobile

First, a little history…

Responsive design, originally defined by Ethan Marcotte in A List Apart , responds to the needs of the users and the devices they're using. The layout changes based on the size and capabilities of the device. For example, on a phone users would see content shown in a single column view; a tablet might show the same content in two columns. This serves as guide for designing for those smaller known viewports including guidelines for touch-devices.

Mobile-first is a design strategy first brought to light by Luke Wroblewski in 2009 where he challenges designers to think about mobile devices first, then for larger screens later. This mobile-first approach forced designers to design for the most constrained viewport thereby “focusing on only the most important data and actions”. The downside in the mobile first approach, meant oceans of empty space in the layout with extremely paired down menus that, in research shows, users struggling to understand the full context.

Now it’s 2020, a decade later, and there are too many screen sizes and other variables in play for us to favor designing for a particular "device" over another. We can take the lessons we learned from the mobile-first approach (focus on key tasks and content) and apply those lessons as we work to effectively accommodate all screen sizes. More recently, designers of products are choosing to start where the most dominant use cases lie, in the case of WM products where majority of users are on devices >1024, we set our artboards to accommodate that, keeping in mind the constraints that smaller viewports will require.

On Smaller Screens

Our products are currently designed to work seamlessly across a minimum viewport of 1024px (1x, standard resolution). For viewports <1024, our products will gracefully degrade, meaning, while not optimized for mobile, will pass the following guidelines for >320px (1x, standard resolution):

fully functional
not appear broken/abandoned
content will be readable
not contain horizontal scrollbars AND vertical scrollbars at the same time, as per WCAG 2.1 1.4.10

Exceptions: content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

For workflows and products that have been identified as a mobile-priority we need to make sure all content and patterns used are fully optimized for viewports under 1024px up until our minimum supported width of 320px is reached.

Need help on a design originally designed for larger screens?

Tip: Start from the outside and work your way in.

Start Big
Think in larger layouts and containers first: header areas, sidebars, and main content sections. How can these be fluidly presented and stacked to fit my now smaller viewport? Instead of designing a layout based on rigid pixels, a fluid grid is more carefully designed in terms of proportions. This way, when a layout is squeezed onto a tiny mobile device or stretched across a huge screen, all of the elements in the layout will resize their widths in relation to one another.

Spoiler Alert: On the smallest viewports, these larger, multi-column designs will likely end up in a single stacked column.
Find alternatives
What interior components can be collapsed or made more mobile friendly (think about touch targets)? Most controls should have a minimum height and/or width to accommodate our minimum target size (see Designing for Touch). You may have to introduce a different version of a UI pattern. It helps to start with a comparative analysis, find some examples of that same pattern made responsive to see what solutions already exist.
Don't limit your user's access
It is a false assumption to think your users tasks will be different simply because they are on a different device. It's important to keep the information hierarchy similar, there was a reason for it in the first place.
Scroll
Always remember, users scroll/swipe down.

Designing for Touch

Users navigating with their fingers and thumbs require larger targets. We require a minimum of 44px wide and tall for touch targets. The size is similar to the Apple iOS and Android user interface guidelines for size of controls, but is dictated in the revision of WCAG 2.1, 2.5.5 Target Size.

Target Spacing

In most cases, touch targets should be separated by 16px of space or more to ensure balanced information density and usability.

What about links?

It does not make sense to have linked text within a sentence be larger than the surrounding text. So, any links inside a sentence or paragraph are not included (nor required for WCAG 2.1 AA compliance). Footnote or help links at the end of a sentence are also exempt from these target size requirements. Links are best when they are placed at the end of the sentence as per localization best practices.