Desktop 1440, tablet 768, and mobile 375 are common handoff sizes, but real browsing widths extend far beyond those three. Designing for device models alone creates awkward gaps on split-screen laptops, landscape phones, and small tablets.
A more reliable method establishes flexible rules and introduces content breakpoints when navigation, headings, cards, or tables can no longer remain usable.
01 Set Content Priority Before the Grid
Define each page's core task, primary information, and supporting content. As the container narrows, decide what reorders, collapses, moves later, or changes form.
Do not assume mobile removes every detail. Critical decision information remains necessary on smaller screens.
02 Use Fluid Containers with Explicit Limits
As the viewport changes, let the content area flex within minimum and maximum bounds, preventing lines that are too long on ultrawide screens or content that touches small-screen edges.
Spacing and type can vary fluidly within limits while preserving readability and minimum touch sizes.
When to Add a Breakpoint
| Component Signal | Meaning | Common Response |
|---|---|---|
| Navigation wraps or compresses | Primary entries lack space | Collapse, group, or retain core items |
| Heading line length fails | Lines become too long or fragment | Adjust type size, width, and copy |
| Card content becomes unbalanced | Buttons and text collide | Reduce columns, reorder, or change card structure |
| Key table columns disappear | The comparison task fails | Prioritize columns, freeze columns, or open details |
| The image subject is cropped | The ratio does not fit the container | Provide focal points and alternate crops |
| Form controls are hard to touch | Fields and buttons are too small | Use one column and larger touch areas |
03 Let Components Have Their Own Breakpoints
The same component may appear on a full-width page or in a sidebar, so global viewport width alone is insufficient. Responding to the component container improves reuse.
Design files should show behavior at minimum, standard, and maximum component widths.
04 Redesign Mobile Navigation
A desktop mega menu cannot simply shrink its text. Mobile navigation needs hierarchical back behavior, adequate touch areas, focus management, and fast contact access.
Keep important CTAs where appropriate, but prevent fixed elements from covering content.
05 Challenge the Layout with Real Content
Test long company names, multiple languages, extreme numbers, missing images, error messages, and enlarged system fonts.
The neater the placeholder copy, the more likely it hides responsive problems.
06 Review Intermediate Widths Together
Gradual browser resizing, real devices, and automated screenshots all reveal issues. Pixel checks at only two endpoints cannot validate responsive rules.
After launch, continue improving based on real device distribution, page performance, and user behavior.
Frequently Asked Questions
Does a responsive site need a separate tablet design?
Yes when the layout or task changes significantly on tablets. Otherwise, rules and key examples may be enough.
Can a CSS framework decide every breakpoint?
Frameworks provide defaults, but validate them against content and components and adjust when necessary.
Can mobile content differ from desktop?
Order and presentation can change, but core facts should stay aligned to avoid SEO and comprehension conflicts.
How should responsive images work?
Serve appropriate assets for display size, pixel density, and crop instead of making every device download one large image.
How should a responsive site be accepted?
Cover key widths, real content, touch, keyboard, landscape, and multiple browsers—not screenshots alone.
| Service | View |
|---|---|
| Related service | View service details |
| Project inquiry | Contact JVDS Design Studio |
| Design and web articles | View all insights |
Link copied
