← All categories

Responsive & devices

"Make it responsive" can also mean at least two sets of mockups. Quote the job without knowing that and the work doubles or triples on you.

12 terms12 live demos

Give widths, not device names

Say "below 767px", not "on iPhone". iPhones come in several widths → Deep dive: what happens as the window narrows

Responsive

반응형

When this comes up

"Make it responsive" — which also means at least two sets of mockups.

A layout that stretches and rearranges flexibly with the screen width. One screen serves every device.

See it Try clicking

Header

Content

Side

Header

Content

Side

Header

Content

Side

The same content rearranges with the width. → Narrow it yourself in the deep dive

Easy to get wrong

"Make it responsive" also means desktop mockups alone are not enough. You need at least two sets, desktop and mobile, and usually three including tablet. Quote without knowing that and the work doubles or triples.

Using it on the job

The word "responsive" on its own settles nothing. Write down what changes, and at which widths, range by range.

Ask for it like this

Please build it responsive. Breakpoints are mobile up to 767 / tablet 768–1023 / desktop 1024 and up. On mobile: one column, sidebar hidden, menu becomes a hamburger.

Adaptive

적응형

When this comes up

"Desktop and mobile need to be completely different" — that is not responsive, it is adaptive.

Building separate layouts for a few fixed sizes in advance and serving whichever matches the device.

See it Try clicking

Responsive

One layout · flexes with the width · holds up at in-between sizes

Adaptive

Several layouts · optimised for fixed sizes only · can look awkward in between

Easy to get wrong

Easily confused with responsive, but the work and the quote are different. Responsive is one thing that flexes; adaptive is several built separately. Korean practice still often splits desktop and mobile into entirely separate pages (m.domain), which is adaptive.

Ask for it like this

If desktop and mobile are structured completely differently, this is adaptive rather than responsive. It means building two sets of screens, so the effort and schedule change. Please decide which approach we are taking first.

Breakpoint

브레이크포인트

When this comes up

"Make it one column on iPhone" — the moment you have to convert that into a number.

The screen width at which the layout changes. The number in a rule like "below 768px, single column".

See it Try clicking

Mobile~ 767px

Tablet768 ~ 1023px

Desktop1024px ~

These are the most widely used defaults. Adjust them per project if you like, but write down whatever you settle on.

Easy to get wrong

Specify and communicate numbers, not device names. Not "on iPhone" but "at 767px and below". iPhones come in several widths.

Ask for it like this

Please set breakpoints as numbers — mobile up to 767px / tablet 768–1023px / desktop 1024px and up. I will work to these numbers rather than device names.

Viewport

뷰포트

When this comes up

"The screen jumps on mobile" — a problem caused by the address bar.

The area in the browser where content is actually visible. Measured by window size, not monitor size.

See it Try clicking

Browser address bar · tabs (not the viewport)

Viewport — this is the area actually visible

Easy to get wrong

On mobile browsers the address bar appears and disappears as you scroll, so the viewport height keeps changing. That is why elements set to "100% of screen height" jump around.

Ask for it like this

There is a height-jump problem on mobile. Use 100dvh instead of 100vh so it handles the address bar appearing and disappearing.

Mobile First

모바일 퍼스트

When this comes up

"Which screen should we draw first?" — deciding the order of work.

Designing the mobile screen first and expanding outward to larger screens.

See it Try clicking

Mobile

① first

→

Tablet

② expand

→

③ expand

Easy to get wrong

Starting narrow forces you to keep only what genuinely matters, which produces a tidier result. Clients often want to see the desktop mockup first, though, so agree the order up front.

Ask for it like this

I will work mobile-first — confirm the mobile mockup (375px) first, then expand to tablet and desktop. Let me know if you would rather see the desktop version first.

Desktop · Mobile

PC · MO · 피시 / 모바일

When this comes up

"Send me the MO mockup" — an abbreviation you will see daily in Korean project files.

The Korean industry shorthand for the desktop and mobile versions. "Send me the MO mockup" means send the mobile screen design.

See it Try clicking

Based on 1920 · 1440

Based on 375

Mockups are usually drawn at 1440px for desktop and 375px for mobile.

Easy to get wrong

Used only in the Korean web industry. Spec and mockup filenames are usually split the same way — main_PC.png, main_MO.png. MO is short for mobile, PC for the desktop version.

Ask for it like this

I will deliver mockups in two sets, PC (based on 1440px) and MO (based on 375px). Filenames will follow screenname_PC / screenname_MO throughout.

Safe Area

세이프 에어리어

When this comes up

"The bottom button is cut off on iPhone" — a problem that only appears on iPhones.

The safe region that avoids the notch (the camera cutout) and the home indicator (the bar at the bottom).

See it Try clicking

Safe
area

The safe region is what remains once the notch at the top and the home bar at the bottom are avoided.

Easy to get wrong

The classic case is a fixed bottom button hidden behind the home bar. It shows up only on iPhone, so testing on Android will not catch it. If you have anything fixed to the bottom, check on a real device.

Ask for it like this

Apply the safe area to the fixed bottom button and the tab bar (env(safe-area-inset-bottom)). Nothing should sit under the iPhone home indicator.

Related terms

Touch Target Viewport Units (vw / vh)

Touch Target

터치 타깃

When this comes up

"The button is hard to press" — a regular in mobile support tickets.

The minimum area that can be pressed with a finger. Separate from the visible size of the icon.

See it Try clicking

20px — too small

44px — about right

The icons are the same size; the pressable area is not.

Easy to get wrong

At least 44×44px (Apple) or 48×48dp (Google) is the recommendation. Even a 16px icon needs padding around it to reach 44px. Fall short and the tickets say "the button is hard to press".

Ask for it like this

Give every button and icon a touch target of at least 44×44px. Keep the icon size as it is and widen only the area with padding. Leave at least 8px between adjacent buttons.

Related terms

Safe Area Viewport Units (vw / vh)

Viewport Units (vw / vh)

뷰포트 단위

When this comes up

"Make it full screen height" — a request with a trap on mobile.

Units that size things as a proportion of the screen. 100vh means the full height of the screen.

See it Try clicking

100vwThe full screen width

50vhHalf the screen height

100dvhThe real height, allowing for the address bar

Easy to get wrong

100vh is a trap on mobile. The height changes as the address bar comes and goes, so the screen jumps or gains a scrollbar. The current answer is 100dvh — mention that word to a developer and they will know immediately.

Ask for it like this

Use 100dvh instead of 100vh for full screen height, so it does not jump because of the mobile address bar.

px · rem · %

When this comes up

"Enlarging the text does nothing" — from people using browser zoom settings.

px is a fixed size, rem a multiple of the base font size, and % a proportion of the parent element.

See it Try clicking

16pxAlways fixed at 16 pixels

1rem1× the base font size (usually 16px)

50%Half the parent width

Easy to get wrong

px does not grow when someone sets a larger font size in their browser. For accessibility, specify text sizes in rem. Mockups are normally still marked in px, with development doing the conversion.

Ask for it like this

Specify text sizes in rem rather than px. The mockup is marked in px (on a 16px = 1rem basis) — please convert. Text should scale when someone increases their browser font size.

Cross Browsing

크로스 브라우징

When this comes up

"Make it work in every browser" — a request whose scope must be pinned down in the contract.

The work of making something look and behave the same across browsers.

See it Try clicking

✓Chrome · Safari · Edge — latest two versions

✓iOS Safari · Android Chrome

⚠Internet Explorer — end of life. Quote separately if it is required

Easy to get wrong

Always pin the support range down in the contract. "Every browser" is not a real requirement. The usual scope is the latest two versions of Chrome, Safari and Edge, plus mobile Safari and Chrome. Including old browsers adds substantial effort.

Ask for it like this

Please confirm the supported browser range. The default is the latest two versions of Chrome, Safari and Edge, plus iOS Safari and Android Chrome. Internet Explorer is end-of-life and excluded; supporting it would need a separate quote.

Related terms

Requirements Document

Native · Web · Hybrid App

네이티브 · 웹 · 하이브리드 앱

When this comes up

"Build it as an app" — the quote varies several times over depending on which kind of app.

Native is built in the platform language for iOS and Android separately, a web app is responsive web running in a browser, and hybrid wraps web in an app shell.

See it Try clicking

Native — built separately for iOS and Android · store review required · cost ↑↑

Web app — opened in a browser · no review · deploys instantly · cost ↓

Hybrid — web wrapped in an app shell · can be listed in stores · in between

Easy to get wrong

"Build me an app" is not something you can quote against. Native means building two of them, plus app store review and release. A web app has none of that. Budget and schedule differ several times over.

Ask for it like this

When you said "app", which did you mean? ① a native app published to the app stores ② a mobile website opened in a browser ③ a hybrid that wraps the web in an app shell. The budget and schedule differ considerably between them.