Breakpoints add another layer of inheritance, as declared styles cascade from the Desktop viewport down to the Mobile viewport. It’s important, therefore, to always begin declaring styles at Desktop viewport, treating smaller viewports as varying degrees of exceptions.
Many styles declared at the Desktop viewport won’t need to be changed at smaller viewports. Styles like fonts, colors and borders don’t often change from viewport to viewport. But things like sizes, padding and positioning often do need adjustments in order to accommodate smaller screen sizes. It’s best, then, to define these exceptions as needed in order of Desktop down to Mobile.
A good way to think of breakpoint style inheritance is like a mountain climbing team, with members each tethered together on their summit. The Desktop viewport is like the team leader, so his behavior directly impacts the entire team. The behavior of the Tablet viewport, second in line, will impact the Mobile viewports, who bring up the rear. For the team to efficiently ascend the mountain, this hierarchy needs to be observed, relying on the team leader for direction and only deviating when necessary with the understanding that each member’s deviations impact the climbers behind them.
Because of inheritance, it’s important to be aware of the viewport you’re in when making declarations. It’s easy to accidentally make adjustments to styles in Tablet viewport that will also need to be applied to the Desktop viewport. These styles will then need to be redundantly applied to the Desktop viewport, and future updates to these styles will require adjustments at both viewports unless the original Tablet viewport declarations are removed to allow for inheritance. This is all a lot of extra work when the styles could’ve simply been applied once at the Desktop viewport.
It's important that styles aren't simply different across viewports, but are instead optimized for that viewport. Which means making as few changes as possible in order to give the user the best experience. Styles that accomplish the look and feel of the project (fonts, colors, etc.) will often remain the same, but things like sizing (fonts, spacing), layouts (columns become stacked rows) and navigation may need optimization. Additionally, it may be necessary to put content inside hide/show components or slideshows on mobile in order to avoid conspicuously tall layouts.
You might think of optimizing for smaller screens not as shrinking the design, but instead as reducing the dynamics. Body copy, for instance, might remain the same size, but the headlines may all become smaller to accommodate less horizontal real estate, and smaller link copy may need to be enlarged to optimize for touch interactions. This compression means less differentiation between headline types, for instance, so it's important to consider the impact on hierarchy.
Units can be tricky. A one-size-fits-all approach may serve well at first, but eventually you’ll need to make more purposeful decisions and utilize specific units for specific assets to achieve your desired result.Take me there