---
title: How Can I Design for Different Screen Sizes Effectively?
description: Learn how to design for different screen sizes and resolutions, covering layout, navigation, typography, touch input, testing and common mistakes to avoid.
image: https://weareaffective.com/hubfs/learning-centre-images/how-can-i-design-for-different-screen-sizes-effectively.webp
---

[Skip to content](https://weareaffective.com/learning-centre/how-can-i-design-for-different-screen-sizes-effectively#main-content)

[![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com)

- [Home](https://weareaffective.com)
- About Us 
  
    - [Our Story](https://weareaffective.com/about)
    - [How We Work](https://weareaffective.com/how-we-work)
- Our Services 
  
    - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy)
    - [App Design](https://weareaffective.com/app-design-agency)
    - [App UX Design](https://weareaffective.com/app-ux-design)
    - [App UI Design](https://weareaffective.com/app-ui-design)
    - [App Technical Architecture](https://weareaffective.com/app-architecture)
    - [Existing App Audits](https://weareaffective.com/app-audit)
- [Case Studies](https://weareaffective.com/case-studies)
- [Pricing](https://weareaffective.com/pricing)
- [Learning Centre](https://weareaffective.com/learning-centre)

- [Get Started](https://weareaffective.com/get-started)

Expert Guide Series

# How Can I Design for Different Screen Sizes Effectively?

 Table of Contents

Open the same product on a 27-inch monitor and on a phone held one-handed on a crowded bus, and you're looking at two different products. The pixels change, obviously, but so does the posture, the lighting, the patience and the reason the person opened it at all. That's why the question of how to design for different screen sizes is rarely answered well by resizing. Resizing moves furniture around. The harder work is deciding what the person needs in that moment, on that device, and letting everything else wait.

> The screen shrinks, and so does the attention, the patience and the time people give you.

We spend a lot of our time on products where the emotional stakes are high, so this matters more than it sounds. A parent checking a baby monitor at 3am and a product manager reviewing the same data on a laptop are not the same user, even when they're the same person. Their emotional state is different, their tolerance for detail is different, and the design has to meet both.

What follows is how we think about screen sizes and resolutions across a build, from the smallest phone to the widest desktop, including the awkward middle that nobody enjoys designing for. Less about breakpoints as a technical chore, more about what each screen is actually for.

## What Actually Varies Across Devices

Width is the variable everyone talks about and the least interesting one. A phone and a desktop differ in how people hold them, how long they stay, how much light is hitting the glass and how precisely they can point at things. A thumb is a blunt instrument. A mouse is a surgical one. Designing the same interface for both and hoping it works out is how you get buttons that sit a few pixels too close together and a form nobody finishes.

There's also the question of what breaks first on each device, which is a useful thing to know before you start.

| Device | Usual input | Usual posture | What breaks first |
| --- | --- | --- | --- |
| Phone | One thumb | Moving, distracted, brief | Tap targets and long forms |
| Tablet | Two hands or thumb | Lounging, longer sessions | Stretched desktop layouts |
| Laptop | Trackpad and keyboard | Focused, seated, varied | Hover-only interactions |
| Large desktop | Mouse and keyboard | Working, comparing, deep | Empty space and lost hierarchy |

Resolution sits underneath all of this and rarely behaves the way people expect. Two phones with the same physical size can report very different pixel counts, and a high-density screen makes thin type look crisp while making it no easier to read in sunlight. Physical size is what the hand and the eye respond to, so that's what we design against.

## Mapping Intent to Screen: Why the Same User Behaves Differently

People come to a phone to check, confirm or act quickly. They come to a desktop to compare, read properly and commit to something bigger. The same person shopping for a sofa browses on their phone during the day and places the order on a laptop in the evening, because one screen is for wanting and the other is for deciding.

This is where a lot of [multi-screen app development goes sideways](https://weareaffective.com/app-ui-design). A client will point at a competitor and say their mobile experience makes more sense, and the instinct is to copy the sequence of steps. You can't lift the same sequence, drop it into your product and expect the same clarity of purpose, because the brand is different, the context is different and the overall use case is different. What feels obvious in a running app makes no sense in a skincare routine builder.

#### Ask what the screen is for

Before any layout work, we write down what each screen size is being used for in that specific product. Then every feature gets checked against it. Is this helping the person do what they came here for, or is it working against their stated intentions? On a phone, most of the answers are no, and that's the useful part.

## UX/UI design built around *real* psychology

We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package.

[See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started)

No commitment

## Deciding What Survives the Smallest Screen

The small screen is the honest one. Everything that survives it had to earn the space, and everything that didn't survive was probably decoration on the larger screens too. So we start there, and we start by asking what we actually need from the person in this moment. If something can be left until later, don't ask for it now.

Chrome is the quiet thief here. Nielsen Norman Group put the cost of a navigation bar in the Stocks watch app at [16% of available pixels](https://www.nngroup.com/articles/smartwatch/), space the primary content needed more, and the same arithmetic runs on a phone. Headers, banners, cookie bars and a sticky promo strip can eat a third of the first view before anything useful appears.

> Every element on a small screen is taking space from something else that needed it more.

So we sort content into three piles. What the person needs to see without doing anything, what they need one tap away, and what only exists for a small group on rare occasions. That last pile can live deeper, or on desktop only, or nowhere at all.

Cutting things from mobile has a habit of improving desktop too, because it forces a decision that the extra width let you avoid.

## Layering Information by Criticality, Not Complexity

Progressive disclosure usually gets built around how complicated something is, with simple things first and hard things later. We'd rather build it around how critical something is. We worked on a baby monitor product where we surfaced the really critical information parents needed first, and then let them go further into the data behind it if they wanted to. The deeper layer wasn't more advanced, it was just less urgent at 3am.

That distinction changes what goes above the fold on a phone. A temperature reading and a clear state is critical. The twelve-hour trend chart is supporting material. On a tablet propped by the bed, both can sit together, and the parent chooses where to look.

Write your content list twice, once ordered by complexity and once ordered by how urgently someone needs it. The gap between the two lists is your mobile design brief.

#### Emotional state sets the order

We worked on a health and wellness product where the layering was built to reduce anxiety, so the top level used very simple metaphors about the human body, and the science-based detail arrived further in as people got more comfortable. The phone version carried the reassuring layer. The desktop version let people go deeper, because that's where they had the time and the headspace to want it.

## Preserving Hierarchy When the Layout Changes

Hierarchy on a wide screen is built from position, scale and space. Three columns tell you instantly what's primary and what's supporting. Collapse that to one column and all of it flattens into a single vertical list, where everything looks equally weighted because everything is now the same width.

Order becomes the main signal, and order alone is a weak one. Somebody scrolling past four stacked blocks reads them as a sequence of equals unless you do something about it. Scale, colour weight and generous space around the primary element do most of that work. A heading that's a comfortable step larger than the body, a single bright element in an otherwise quiet view, and enough breathing room that the eye knows where to land.

#### Hold the story, change the shape

We keep a simple rule across screen sizes and resolutions. The first three things a person understands should be the same three things in the same order, whatever the width. The layout can rearrange itself freely underneath that. What can't move is the answer to the question they arrived with, because a reorder button that sits beside the product on desktop and lands below a review carousel on mobile has quietly changed the product.

## Navigation Patterns That Scale Up and Down

The hamburger menu solved a space problem and created a discovery one. Hiding everything behind one icon works when people already know what's in there, and it works badly when the point is to show people what you offer. For a fashion brand with six categories, a scrollable row of labels across the top does more for browsing than a tidy icon ever will.

Patterns that hold up reasonably well across widths tend to share a few traits.

- Primary destinations stay visible rather than hidden, with four or five at most
- The current location is obvious without reading anything
- Going back takes one tap and lands where people expect
- Search is reachable from everywhere, not buried in a menu
- The same labels appear on every screen size, so nobody has to relearn

A bottom bar on phones and a persistent side or top navigation on desktop is a sensible default, as long as the contents match. Where it goes wrong is when the mobile menu quietly carries half the items of the desktop one, so a person who found something on their laptop can't find it again on their phone and assumes it's gone.

## Touch, Reach and Input Across Device Types

Thumbs reach about two-thirds of the way up a modern phone before the hand has to shift grip. Anything you ask people to tap repeatedly belongs in that lower zone, and anything destructive belongs well away from it. Nielsen Norman Group recommends a [touch target of at least 1 cm by 1 cm](https://www.nngroup.com/articles/touch-target-size/), which is larger than most design files assume once you measure the actual tappable area rather than the icon inside it.

> Thumbs are blunt instruments, and the bottom of the screen is where they live.

Spacing matters as much as size. Two correctly sized buttons sitting flush against each other still produce mistaps, because the finger lands somewhere between them and the device picks a winner. A clear gap between adjacent targets fixes more mistakes than making either one bigger.

#### Hover doesn't exist on half your screens

Anything revealed by hovering is invisible to a touch user, so tooltips, dropdown previews and delete icons that appear on mouse-over need a touch equivalent designed deliberately. The same goes for right-click menus and keyboard shortcuts, which work beautifully on a laptop and carry no weight at all on a phone. Design the touch version first and let the pointer version add precision on top.

## Typography, Density and Readability at Every Resolution

Reading on a phone is genuinely harder, and the numbers back up what anyone feels in their own hand. UX Magazine reports comprehension falling from [39% on desktop to 19% on mobile](https://uxmag.com/articles/why-reading-on-mobile-is-uniquely-challenging) in a cloze test, which is a reminder that shrinking a paragraph down doesn't shrink the effort of reading it. Shorter sentences, shorter paragraphs and more space between lines all buy back a little of that.

Line length is the lever people forget. Around 45 to 75 characters per line reads comfortably, and a wide desktop column that runs to 120 characters loses the reader at the end of every line. Capping the text column on large screens costs nothing and makes long content far easier to get through.

Test your body text at arm's length in daylight, outdoors, on the cheapest phone in the office. If it's hard work there, it's hard work everywhere.

Density is the other half. A desktop view can carry more items per row and more supporting labels because the eye has room to scan. Carrying that same density down to a phone produces a wall of small grey text where nothing has priority, and people respond by scrolling past all of it.

## Designing for Pressured and Diverse Users

We worked on a [document portal for the film industry](https://weareaffective.com/learning-centre/what-film-industry-document-portal-users-taught-us-about-designing-for-people-wh), used by a wide mix of people in a fast-paced environment. Because it dealt with documents and files that people needed while standing on set, we made accessibility an active design priority rather than a compliance check. The design was large-scale and easy to move around, and everything about it was built around getting to the information as quickly as possible in the simplest way.

That project changed how we think about small screens generally. Somebody on set, somebody on a train and somebody using a phone with one hand while holding a dog lead are all working under pressure of a kind. Large touch targets, high contrast and short paths stop being accommodations and start being the sensible default.

#### Unburden rather than instruct

When people are under pressure, the useful question is what's the absolute minimum we can ask of them, and what's the absolute maximum we can do to help. Pre-fill what you already know. Defer anything that can be asked later. Guide people through a process rather than assuming a task that's straightforward in calm conditions stays straightforward in difficult ones. On a small screen, with a distracted person, that difference decides whether the task gets finished.

## Tablets, Foldables and the Awkward Middle

Tablets get designed by accident. The phone layout gets stretched until the line lengths are unreadable, or the desktop layout gets squashed until the tap targets are too small, and nobody owns the result. It's worth treating the tablet as a screen with its own job, because the posture is different from both. People use tablets slowly, often lying down, often for longer sessions, and often for reading and browsing rather than quick tasks.

Foldables add a wrinkle, because the same device changes size mid-session. Somebody opens the phone and the layout has to rearrange without losing their place, their scroll position or the thing they'd half typed. Handling that well is mostly about continuity rather than clever layout work.

A few habits keep the middle sensible.

1. Cap text columns so the tablet never runs to desktop line lengths
2. Use the extra width for a second column of supporting content, not for stretched everything
3. Keep touch targets at phone size, because fingers don't grow with the screen
4. Design the landscape view deliberately, since tablets spend half their life sideways
5. Preserve state across a size change so nothing is lost when a device unfolds

## Building a System Your Developers Can Actually Implement

A set of beautiful screens at three fixed widths is a drawing. What a developer needs is a set of rules that describe what happens at every width in between, because real devices sit everywhere along that line and always have.

So we define behaviour rather than pictures. How a card grid reflows as the container narrows. What the minimum and maximum size of each text style is. Where a component stacks, where it truncates and where it scrolls sideways instead. Spacing that steps up predictably rather than being eyeballed per screen.

> Developers build what the rules say, so write rules rather than drawing screens.

Breakpoints then come from the content itself. Pick the width where your card grid starts looking cramped and break there, instead of inheriting a list of device widths from a framework that was written years ago for phones nobody owns now.

#### Design for different screen sizes as one conversation

We do this work with developers in the room early, because the cost of a particular behaviour is something they know and we don't. Playing it back to the client matters too. Showing a change and asking how does that feel to you is a natural step, and clients are users of these products as well, so the response is immediate and honest.

## Testing on Real Devices and What to Look For

Browser resize tools tell you about layout. They tell you nothing about thumb reach, screen glare, a slow connection or what it's like to tap something while walking. Those are the conditions where products actually fail, so some of the testing has to happen in them.

A practical order of work for a release.

1. Check the three or four devices your analytics say people really use, including the older cheap ones
2. Run the primary task one-handed, standing up, without looking at a keyboard
3. Repeat it outdoors in daylight and note anything you can't read
4. Throttle the connection and watch what appears first while the rest loads
5. Rotate every screen to landscape and look for anything that collapses
6. Run the whole flow with text size bumped up in the operating system settings

Keep one deliberately old, small, slow phone in the office and make it the device every build gets opened on first. It catches more problems than any emulator.

What you're watching for is hesitation. Somebody pausing before a tap, scrolling back up to check they read something right, or missing a target twice. Those small moments are where the design is asking more of people than it should.

## Common Mistakes That Break Multi-Screen Design

The same handful of problems turn up across most builds we're asked to look at, and almost all of them come from treating the small screen as a compressed version of the big one.

- Hiding content on mobile that people need, then wondering why mobile converts poorly
- Tap targets sized to the icon rather than the area a finger lands on
- Different navigation items on mobile and desktop, so people can't find things again
- Fixed headers and banners eating the top third of a phone screen
- Forms that ask for everything up front, when half of it can wait
- [Copying a competitor's mobile flow](https://weareaffective.com/learning-centre/what-features-must-your-social-media-app-include-to-succeed) without their context, brand or use case

The deeper mistake sits underneath all of them. Teams decide what goes where based on what makes sense from a product point of view, when the useful question is what makes sense from a human and an emotional point of view. A person checking an order status on their phone while late for something wants one answer, large and immediate. The full order history, the recommendations and the loyalty balance are all real features, and none of them belong in front of that person at that moment.

Fix the order of priority and most layout problems solve themselves.

## Conclusion

Designing well across screens comes down to a few decisions made properly and then held onto. Know what each screen size is genuinely being used for in your product. Sort your content by how critical it is rather than how complicated it is. Ask the smallest possible amount of people when they're under pressure, and do the maximum you can to help them through. Then write rules a developer can build from, rather than three pretty pictures.

The projects where this went well for us had something in common. On the baby monitor, we knew which single piece of information a parent needed first. On the film industry document portal, we knew people were standing on set with no time, so large and simple beat clever and dense every time. In both cases the screen size question got easier because the human question had already been answered.

If you're working through this on a product right now, whether that's a new build or an existing one that falls apart somewhere between phone and desktop, we're happy to look at it with you. [Let's talk about your multi-screen design](https://weareaffective.com/get-started).

## Frequently Asked Questions

Isn't designing for different screen sizes just a matter of resizing the layout?

No. Resizing only moves elements around, while the real work is deciding what someone needs in that moment, on that device, and letting everything else wait. A phone user on a bus and a desktop user at a desk have different attention spans, postures and reasons for opening your product.

What actually changes between devices, if not just the width?

Input method, posture, lighting, session length and pointing precision all change. A thumb is a blunt instrument and a mouse is a surgical one, so interfaces that ignore that difference end up with cramped tap targets and forms nobody finishes.

What tends to break first on each type of device?

On phones it is tap targets and long forms, on tablets it is stretched desktop layouts, and on laptops it is hover-only interactions. On large desktops the usual failure is too much empty space and a hierarchy that gets lost across the width.

How much should resolution influence my design decisions?

Less than most people assume. Two phones of the same physical size can report very different pixel counts, and a high-density screen makes thin type look crisp without making it any easier to read in sunlight. Design against physical size, because that is what the hand and the eye actually respond to.

Why does the same person behave differently on mobile and desktop?

People use phones to check, confirm or act quickly, and desktops to compare, read properly and commit to something bigger. Someone might browse sofas on their phone during the day and place the order on a laptop that evening, because one screen is for wanting and the other is for deciding.

Can I copy a competitor's mobile experience if it works well?

Not directly. You can't lift someone else's sequence of steps and expect the same clarity, because the brand, the context and the use case are all different. What feels obvious in a running app will make no sense in a skincare routine builder.

How should emotional context shape responsive design?

A parent checking a baby monitor at 3am and a product manager reviewing the same data on a laptop are not the same user, even when they are the same person. Their emotional state and tolerance for detail differ, so the design has to serve both rather than assuming one neutral user.

What about tablets and other awkward in-between sizes?

Mid-size screens suffer most when a desktop layout is simply stretched to fill them, because the posture is closer to lounging and sessions tend to run longer. Treat them as their own context with their own purpose rather than as leftovers between your phone and desktop breakpoints.

## Related Articles

[![How do I test dark mode across different devices and operating systems?](https://weareaffective.com/hubfs/learning-centre-images/how-do-i-test-dark-mode-across-different-devices-and-operating-systems.webp)](https://weareaffective.com/learning-centre/how-do-i-test-dark-mode-across-different-devices-and-operating-systems)

### [How do I test dark mode across different devices and operating systems?](https://weareaffective.com/learning-centre/how-do-i-test-dark-mode-across-different-devices-and-operating-systems)

Dark mode looks simple from the outside. A user flips a switch, the background goes dark, the text...

by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee)

[![How Do I Sync Data Between My Phone App and Smartwatch](https://weareaffective.com/hubfs/learning-centre-images/how-do-i-sync-data-between-my-phone-app-and-smartwatch.webp)](https://weareaffective.com/learning-centre/how-do-i-sync-data-between-my-phone-app-and-smartwatch)

### [How Do I Sync Data Between My Phone App and Smartwatch](https://weareaffective.com/learning-centre/how-do-i-sync-data-between-my-phone-app-and-smartwatch)

We worked on a water tracking product that started life as a phone-only app, and partway through...

by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee)

[![How do I localise my app store listing for different countries?](https://weareaffective.com/hubfs/learning-centre-images/how-do-i-localise-my-app-store-listing-for-different-countries.webp)](https://weareaffective.com/learning-centre/how-do-i-localise-my-app-store-listing-for-different-countries)

### [How do I localise my App Store listing for different countries?](https://weareaffective.com/learning-centre/how-do-i-localise-my-app-store-listing-for-different-countries)

Launching an app in Germany is a different task from launching it in Japan, and not because of...

by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee)

[![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com)

20-22 Wenlock Road  
London, N1 7GU  
United Kingdom

+44 20 4572 8062  
[hello@weareaffective.com](mailto:hello@weareaffective.com)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

Services

[App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit)

Legal

[Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70)

Case studies

[TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift)

About us

[Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work)

Guides

[Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth)

 Copyright © 2026, weareaffective.com. All rights reserved.