Constraints(제약조건)이란?

Constraints는 부모 Frame과 자식 요소가 있을 때, 부모를 기준으로 요소에 적용하는 조건입니다. 이때, 조건은 부모 Frame이 커지거나 줄어들 때, 요소가 미리 정해진 조건에 따라 크기와 위치를 변화시키는 것을 말합니다. Constraints를 사용하는 이유는 다양한 기기, 해상도에 적응하여 요소의 크기와 위치를 고정하기 위함입니다. Auto Layout과 함께 사용하면, 반응형 디자인을 만들 수 있습니다.

 

Figma의 변경된 UI에서는 X, Y 좌표 옆의 [+] 같이 생긴 버튼을 눌러보시면 Constraints 설정창이 펼쳐집니다.

Figma에서 Constraints 설정창

 

저는 Constraints를 Vertical Constraints와 Horizontal Constraints로 두 가지로 나눠서 설명해 보겠습니다.

 


Horizontal Constraints

부모의 수평(가로)을 기준으로 요소의 위치와 크기를 어떻게 대응시킬지에 대한 조건입니다.

 

- Left : 부모의 Left에 위치&크기 고정

- Right : 부모의 Right에 위치&크기 고정, 앱 SideBar 고정할 때 활용한다.

- Center : 부모의 Center에 위치&크기 고정

- Left+Right(L+R) : 부모의 Left, Right 여백(padding)을 고정하고, 부모의 Width 크기 변화에 따라 자식의 Width 크기 가변

  예: 부모W100>W200(+100), 자식W50>W150(+100)

- Scale : 부모의 가변 비율에 따라 자식의 크기 가변

  예: 부모W100>W200(x2배), 자식W50>W100(x2배)

 

Horizontal Constraints 예제

Center, Scale, Left&Right의 자식 Width는 어떻게 변했을지 답을 맞혀보시고 , 이미지도 머릿속으로 그려보시면 좋습니다.

 

더보기

1. W50 : Center는 자식의 위치와 크기가 고정된다.

2. W150 : Scale은 부모가 늘어난 비율(2배)만큼 자식의 크기가 늘어났다.

3. W100 : Left&Right는 부모의 여백을 고정하고, 부모가 늘어난 크기만큼 자식의 크기가 늘어났다.

 


Vertical Constraints

부모의 수직(세로)을 기준으로 요소의 위치와 크기를 어떻게 대응시킬지에 대한 조건입니다.

 

 

- Top : 부모의 Top에 위치&크기 고정, 웹 상단 Menu 고정할 때 활용

- Bottom : 부모의 Bottom에 위치&크기 고정, 앱 하단 Navigation 고정할 때 활용

- Center : 부모의 Center에 위치&크기 고정

- Top&Bottom(T+B) : 부모의 Top, Bottom 여백(padding)을 고정하고, 부모의 Height 변화에 따라 자식의 Height 크기 가변

  예: 부모H100>H200(+100), 자식H50>H150(+100)

- Scale : 부모의 가변 비율에 따라 자식의 크기 가변

  예: 부모H100>H200(x2배), 자식H50>H100(x2배)

 

Vertical Constraints 예제

Center, Top&Bottom, Scale의 자식 Height은 어떻게 변했을지 답을 맞혀보세요.

 

더보기

1. H50 : Center는 자식의 위치와 크기가 고정된다.

2. H100 : Top&Bottom은 부모의 여백을 고정하고, 부모가 늘어난 크기만큼 자식의 크기가 늘어났다.

3. H150 : Scale은 부모가 늘어난 비율(2배)만큼 자식의 크기가 늘어났다.

 

 

Vertical, Horizontal 차이

차이를 정리해 보면,

Horizontal은 부모의 가로(Horizontal, Width) 변화에 따라 자식의 Left, Right가 관련이 있고,

Vertical은 부모의 세로(Vertical, Height) 변화에 따라 자식의 Top, Bottom이 관련이 있습니다.

Center, Scale의 개념은 둘 다 동일합니다.

 

Center, L+R/T+B, Scale의 차이

Left, Right, Top, Bottom은 위치를 한 곳으로 고정하는구나라고 직관적으로 이해할 수 있는 반면에 Center, L+R/T+B, Scale는 헷갈릴 수 있습니다. 차이를 제대로 구분하시면 Constraints를 자유롭게 활용할 수 있습니다.

 

- Center : 위치는 Center로 고정, 자식의 크기는 변하지 않음

L+R/T+B : 부모의 좌우/상하 여백을 고정, 부모(화면 크기)의 가변 크기만큼 자식의 크기도 같이 변함

- Scale : 부모의 가변 비율(%)만큼 자식의 크기도 변함, 정밀한 레이아웃보다는 비율을 유지할 때 활용(예: 화면의 30% 유지)

 

Position 정렬과 Constraints의 관계

위치(Position)를 바꾸는 정렬(Align) 기능과 Constraints는 연결되어 있습니다.

Left, Right, Horizontal Center를 정렬하면 Horizontal Constraints도 함께 바뀌고,

Top, Bottom, Vertical Center를 정렬하면 Vertical Constraints도 함께 바뀝니다.

따라서, 일일이 자식 요소마다 Constraints를 설정할 필요는 없습니다.

정렬 외에 의도를 가지고 설정하는 것은 Left&Right / Top&Bottom, Scale입니다.

 


 

정리

Constraints를 처음 배울 때는 Center, Left&Right/Top&Bottom, Scale가 언제 필요한지 잘 안 느껴집니다. 하지만 그 차이를 이해한다면, Auto Layout과 함께 반응형 디자인을 더 쉽게 만들 수 있습니다.

 

정리해보면 정렬(Align)만 잘 써도 Constraints는 자동으로 따라옵니다. Left&Right/Top&Bottom, Scale은 필요에 따라 의도적으로 설정하면 됩니다.

 

이 글이 Constraints가 헷갈렸던 분께 도움이 되셨길 바랍니다.

다음 글에서 뵙겠습니다.👋


🖇️ 레퍼런스

Figma 공식문서/Apply constraints to define how layers resize

디자인베이스, 리사이징 대응을 위한 Constraints 이해하기 – 피그마 강좌 2-3

도널드 노먼의 디자인과 인간 심리, The Design of Everyday Things(DOET) 는 경험 디자인의 고전으로 언급되는 책입니다. 2016년에 초판 발행되어, 제 책은 9년이 지난 2025년에도 10쇄를 찍어낼 만큼 독자들에게 검증된 책입니다. 대학 시절, 학술동아리에서 보고 처음 다시 펼쳐봅니다.

 

책에서 저자는 'Norman doors'를 검색하면, 재밌는 내용이 있을 것이라고 말합니다. 저도 책을 덮고 검색해봤습니다.

Norman Door는 밀지, 당길지 헷갈리게 하는 문에 비유해서 사용자를 혼란스럽게 하는 디자인을 말합니다.

 

문의 미는 문, 당기는 문, 미닫이문, 회전문 다양한 문의 형태가 있다.(출처: Unsplash)

 

책에서는 좋은 디자인의 중요한 특성 두 가지를 설명합니다.

- 발견 가능성(discoverability) : 어떻게 할 수 있는지, 어떤 행동이 가능한지

- 이해(understanding) : 무슨 의미인지 아는 것

 

디자이너는 사용자에게 가능한 행위에 대해 힌트를 줘야 합니다. 문에서 줄 수 있는 힌트는 손잡이(Knob/Lever), 문짝(Slab), 문틀(Frame), 경첩(Hinge), 레일 등이 해당됩니다. 저자는 이 힌트를 어포던스, 기표로 설명합니다.

- 행위지원성(Affordance)=행동유도성 : 대상과 사람과의 관계에서 만들어지는 행위의 '가능성'입니다. 사람은 대상을 보고 '어떤 행동이 가능한지' 알아냅니다. 디자인했든 안 했든 어포던스는 존재하는 것이고, 한 물체가 가지는 어포던스는 여러가지일 수 있습니다. 예를 들어, 높이가 있는 평평한 면은 앉는 행위, 올라가는 행위의 가능성이라는 어포던스를 가집니다.

- 기표(Signifiers) : 어포던스를 알려주는 '신호'입니다. 디자이너가 의도적으로 넣는 장치입니다. UX의 핵심으로, 시각, 청각, 촉각적 요소 등이 될 수 있습니다. 예: 문의 손잡이, PULL 글자, 표지판의 색상/아이콘/텍스트, 비상구의 화살표 등

 

다시 위 사진을 보면, 첫 번째 사진은 한 손으로 잡을 수 있는 짧은 손잡이(기표)를 통해 당기는 행위(어포던스)를 생각할 수 있습니다. 두 번째 문은 기댈 수 있는 평평한 면(기표)을 통해 미는 행위(어포던스)를 생각할 수 있습니다. 세 번째는 가로의 레일과 파인 손잡이(기표)를 통해 옆으로 미는 미닫이 행위(어포던스)를 생각할 수 있습니다.

 

예시(출처: Interaction Design Foundation)

 

- 당기는 행위의 기표=손잡이(handle) : '잡고 당기세요'라는 신호

- 미는 행위의 기표=수직판(push plate) : '여기를 손바닥으로 미세요'라는 신호

- 계단의 어포던스=높이가 있는 평평한 판(step) : '밟고 올라가는 행위, 앉는 행위'를 가능하게(Afford) 한다.

 

문화에 따른 문 개폐 방식의 차이

도널드 노먼은 '문화'도 중요하다고 말합니다. 문을 예시로 들어보겠습니다. 문화마다 문의 개폐방식은 다릅니다.

출처: APRO

 

- 인스윙(Inswing) : 실내에서 당기고, 외부에서 안쪽으로(inside) 미는 문

- 아웃스윙(Outswing) : 실내에서 당기는 문, 외부에서 밖으로(outside) 당기는 문

 

지역마다 '안전'에 대한 문화적 차이가 존재합니다.

한국은 한옥에서 미닫이문을 사용했는데, 자연과의 조화를 중시했던 문화를 반영합니다. 문을 열면 외부와의 공간과 연결되는 개방성을 줍니다. 한옥의 경우, 대문은 '인스윙', 방문은 '아웃스윙'으로 열리는 형태였습니다. 현대에는 주거형태가 바뀌면서 현관문은 아웃스윙, 방문은 인스윙으로 바뀌게 되었습니다.

서양은 밀고 당기는 여닫이문을 사용했는데, 개인의 사생활보호와 보안을 중시했던 문화를 반영합니다. 특히 외부에서 안쪽으로 미는 '인스윙'을 선호하는데, 외부침입을 막는데 효과적이라고 생각했습니다. 중세시대에 성문의 빗장도 안쪽이었습니다. 드라마에서 침입자를 막기 위해 안쪽에 가구를 설치하는 장면들을 떠올려보시면 이해가 됩니다. 눈이 많이 오는 지역은 안전하게 '인스윙'을 사용합니다. '아웃스윙'은 높이 쌓인 눈 때문에 문을 못여는 상황이 발생하기 때문입니다. 바람이 많이 부는 지역은 '아웃스윙'을 선호합니다. 인스윙을 사용하는 경우 바람 때문에 문이 안 열리거나 문을 여는 사람이 문에 다칠 수 있습니다. 대신, 아웃스윙은 지나가는 행인이 다칠 수 있다는 문제도 함께 존재합니다. 그럼에도 문의 목적은 여는 행위이기 때문에 이 상황에서는 아웃스윙을 선호한다고 생각했습니다. (일부러 이미지 자료를 안 올렸으니 상상해보세요!)

 

현대의 한국 사회는 여닫이문을 사용할 때 주로 '아웃스윙'을 사용합니다. 사람들이 밀집된 아파트, 사무실, 고층건물, 종교시설 등은 피난 시에 바로 문을 열고 대피할 수 있는 형태가 아웃스윙이기 때문입니다. 이는 건축법으로도 규정되어 있습니다. 가정집에서는 현관문에서 아웃스윙을 사용합니다.

인스윙
외부에서 안으로 미는 문
- 사생활보호, 보안
- 서양권, 호텔, 은행 선호
- 한국 가정집의 방문, 화장실문
- 눈이 많이 오는 지역
- 경첩이 실내 방향에 있어 외부 조작 위험이 적음
아웃스윙
외부에서 밖으로 당기는 문
- 밀집 건물의 피난 시 빠르게 대피 가능
- 한국 가정집의 현관문(신발이 문에 걸리지 않음)
- 바람이 거센 북유럽
- 지진이 잦은 일본

 

 

정리

오늘 문이라는 예시를 통해서 UX의 핵심인 어포던스, 기표에 대해 알아보았습니다.
또, 기후, 문화에 따라 안전의 기준이 다르며 설계도 달라진다는 점을 알게 되었습니다.

이번 시간을 통해 좋은 디자인이란 적절한 시각적 힌트(기표)를 제공하여 사용자가 적절한 행위(어포던스)를 선택할 수 있도록 돕는 직관적인 디자인이라고 정의해봅니다. 반대로, 나쁜 디자인이란 사용자를 좌절시키고 혼란스럽게 하는 디자인으로 Norman Doors로 비유합니다.

 

앞으로도 책의 인상깊은 구절을 소개하면서 글을 써보겠습니다.

책을 저와 같이 천천히 읽어보셔도 좋을 것 같네요.

 

reference.

[추천🌟] Interaction Design Foundation,Your Gateway to UX Design: Norman Doors

Medium, Intro to UX: the Norman door, 2018.12.29

한화건설 공식블로그, 문 여는 방향, 각기 다른 이유가 있다?!, 2018.9.17

APRO, Inswing vs. Outswing Doors: Which Is Best for You?, 2025.09.11

티스토리, 앰코인스토리 [미국 특파원] 한국과 미국의 현관문 구조, 2025.2.28

 

 

 

 

디자인 전에 모바일 화면 사이즈를 어떻게 잡아야할지 고민이 됩니다.

저는 많이 사용되는 Android(360x800), iOS 사이즈(375x812)를 사용했었는데요.

새로운 프로젝트에 들어갈 때마다 고민이 되어 "왜 그렇게 사용되는지" 알아보고 선택 기준을 세워보려고 합니다.

 

본 글에서는 해상도 시장점유율과 사용자 연령별 기기 사용 데이터에 따라 기준 화면 사이즈를 선택하는 방법을 다룰 예정입니다.

 

1. Statcounter 해상도 시장점유율

먼저 소개할 사이트는 Statcounter입니다. Statcounter은 전세계 온라인 방문자 통계를 제공하는 사이트인데요. 여기서 국가, 기기별로 화면해상도, 운영체제(OS), 브라우저, 검색엔진 등 다양한 시장점유율을 알 수 있습니다.

그렇다면, 어떻게 시장점유율을 봐야 할까요? reddit의 한 게시글 댓글에서 가이드라인 예시를 발견했습니다.

 

예시/최근 1년간 한국의 화면해상도 시장점유율

All Platforms(Desktop+Tablet+Mobile) + Korea, Republic of + 최근 1년

Statcounter, "최근 1년간 한국의 모든 화면해상도 시장점유율"

 

조건을 모바일로 좁혀보겠습니다.

 

예시/최근 1년간 한국의 모바일 화면해상도 시장점유율

Statcounter, "최근 1년간 한국의 모바일 화면해상도 시장점유율"

 

10% 상위에 몰려있는 6위까지 추려보면 Android의 기준 너비인 360px과 iOS의 375px이 가장 작은 것을 알 수 있었습니다.

 

예시/최근 1년간 전세계 모바일 화면해상도 시장점유율

Statcounter, "최근 1년간 전세계 모바일 화면해상도 시장점유율"

 

글로벌 기준에서는 360x800이 가장 높은 점유율을 차지하고 있네요.

 

그렇다면, 시장점유율 1위인 사이즈로 디자인을 해야 할까요?

스레드에는 이런 의견이 있습니다.

 

이 분은 Full HD 해상도 표준인 1080x1920 배수에 맞는 360px을 추천하고, 375px을 기준으로 사용할 경우, 360px에서 UI가 깨지는 경우도 있다고 하네요. 그래서 auto layout을 사용해서 반응형 디자인을 도입하는 것을 추천한다고 합니다.

 

2. 사용자 분석 - iOS/Android 시장점유율

서비스에 따라 iOS를 기준으로 할지, Android를 기준으로 할지도 고민점 중 하나입니다.

하지만, Statcounter에서는 연령별 시장점유율은 살펴볼 수 없었습니다.

서비스의 사용자 타켓에 맞는 연령별 자료도 살펴본다면 더욱 좋지않을까 해서 자료를 찾아보았습니다.

 

한국의 연령/성별에 따른 OS 시장점유율

한국갤럽이 2025년 7월 성인 1,001명을 대상으로 실시한 조사에 따르면, 현재 사용중인 스마트폰에 대해 재밌는 연구 결과를 보여줍니다. 연령별로 보았을 때 18~29세는 애플을 사용하는 경우가 60%였습니다. 성별로는 20-30대 남성은 삼성을, 20-30대 여성은 애플을 선호하는 경향을 보였습니다. 특히 20대 여성의 경우에는 78%가 애플을 사용하고 있었습니다. 20-30대만 보았을 때 남성은 갤럭시를, 여성은 애플을 선호하는 경향을 보입니다.

 

소비자가 A를 선택했을 때 다른 선택지로 바꾸기 어려운 효과를 '락인효과'라고 하는데요. 락인효과를 고려해봤을 때도 주사용자의 성향에 따라 OS 기준을 잡아보는 것도 방법이 될 수 있겠습니다. 또는 출시 전 렌더링 이미지의 기기를 주사용자의 선호도에 맞게 준비해보시는 것도 좋을 것 같네요.

선택의 조언

화면사이즈 선택 기준
- Statecounter 해상도 시장점유율에서 작은 해상도 선택하기
- 사용자 타겟에 따른 OS 기준 설정하기
- 반응형(Auto Layout) 디자인 도입하기

 

신규 프로젝트를 위한 Figma 모바일 화면 사이즈 기준을 정하기 위해 Statecounter 시장점유율과 사용자 분석 데이터를 살펴보았습니다. 2025년 11월을 기준으로 Android 360px, iOS 375px가 상위 시장점유율 가운데 가장 작은 사이즈라는 것을 알 수 있었습니다. 시장점유율이 1위라고 해서 기준으로 정하기 보다 서비스에 맞게 Statcounter의 지표와 사용자의 OS 선호도를 분석해서 작은 사이즈를 선택하고 반응형으로 디자인해보면 좋겠습니다.

 


 

🖇️ 레퍼런스

Statcounter - GlobalStats 무료 통계 도구 *연령대별 데이터 없음

reddit/모바일 웹 디자인에 사용할 템플릿 크기는?

[내배캠,3주차] UX/UI Figma 활용법 3

한국갤럽 스마트폰 관련 조사 2012-2025

 

 

👋[모바일 기준 사이즈 정하기]

도움되셨길 바래요!

이미지 검색 서비스를 만드는데 이미지를 어떻게 가져올지에 대한 고민을 하고 있습니다.

백엔드가 없어 데모 버전에 사용할 무료 API를 알아보았습니다.

규모가 크고 이미지 품질도 괜찮은 3가지 웹사이트의 API를 비교해보겠습니다.

- Unsplash

- Pixabay

- Pexels

Unsplash API

https://api.unsplash.com/
https://api.unsplash.com/search/photos/
  • 이미지 제공
  • 제한 : (데모)시간당 50개 요청 (프로덕션)시간 당 5000개 요청
    • 다른 API와 달리 핫링킹만 사용, 추적이 용이하기 때문이다.
    • 페이지네이션 : 기본 10개, 최대 30개

Pixabay API

https://pixabay.com/api
  • 이미지/비디오 제공
  • 제한 : 분당 100개 요청, 핫링킹(Hotlinking) 금지
  • 쿼리 제한 : 100자 이하 “yellow+flower”

Pexels API

https://api.pexels.com/v1
https://api.pexels.com/videos // 비디오
  • 라이브러리/이미지/비디오 제공
  • 가이드라인
    • Photos provided by Pexels 또는 로고 표기
    • 사진 작가 이름 표기
    • 요청 제한 : 시간당 200개, 월 20,000개
  • 페이지네이션 : 요청 1개 당 최대 80개

 

정리

  Unsplash Pixabay Pexels
리소스 이미지 이미지/비디오 이미지/비디오/라이브러
요청 제한 시간당 50개 분당 100개 시간당 200개 월 20,000개
핫링킹 핫링킹만 사용 금지 없음 (비권장)
페이지네이션 O (기본 10, 10~30) O (기본 20, 3~200) O (최대 80)

 

저는 요청 제한은 적지만 고품질의 이미지를 제공하고, 프론트엔드에서 핫링킹을 사용할 수 있는 Unsplash를 최종 선택했습니다.

이번에 핫링킹(hotlinking)에 대해 알게 되었습니다. API 문서에서 hotlinking 내용을 반드시 확인하시고, 관련 내용이 없다면 핫링킹을 사용하지 않는 것이 안전하겠습니다.

 

 

 

사람들은 습관적으로 버튼을 누릅니다. 버튼의 위치에 따라 의도치 않게 취소 버튼을 눌러 작업을 반복하는 일이 생길 수 있습니다. UX에서는 버튼 위치를 어떻게 선택하는지 두 가지 관점을 소개해 보겠습니다.

 

이 글을 읽을 때 "특정 행동을 유도하는 버튼"에 기준을 두면 이해하는 데 도움이 될 것입니다. 특정 행동은 다음에 수행할 행동일 수 있고 상대적으로 중요한 작업일 수 있습니다. 이 글에서는 이 행동 유도 버튼을 작업 버튼이라고 명칭하겠습니다.

 

작업 버튼의 위치를 결정하는 데는 두 가지 관점이 있습니다.

  • 인지 관점
  • 인지심리학 관점

이 두 가지 관점에 대해 자세히 알아보겠습니다.

1. 인지 관점

'인지'는 버튼을 보고 이해한 다음 행동을 결정하는 것을 말합니다. 저는 인지심리학보다 좀 더 '직감적'인 사고 과정으로 이해했습니다.

시선의 흐름=글의 흐름
한국은 글을 왼쪽에서 오른쪽으로 읽습니다. 자연스럽게 왼쪽에서 오른쪽으로 시선이 이동하기 때문에 중요한 작업버튼을 시선이 먼저 닿는 왼쪽에 두는 것입니다. 그렇게 하면 [취소] 버튼을 읽지 않아도 [확인] 버튼을 누를 수 있게 됩니다.
*이 내용은 뒤에서 다룰 인지심리학 관점에서는 다르게 활용됩니다.
말의 순서: 선 긍정-후 부정
말을 하거나 생각을 할 때 '선 긍정-후 부정'의 순서(예: 할까, 말까?)이기 때문에 긍정 버튼을 먼저 배치한다고 합니다.

 

인지 관점에서는 작업버튼을 '왼쪽'에 둡니다.

2. 인지심리학 관점

'인지심리학'은 인지 과정에서 뇌가 어떻게 정보를 처리해서 행동을 결정하는 것을 연구하는 학문입니다. 저는 직감 뒤에 오는 '뇌의 정보처리 과정'으로 이해했습니다.

시선의 흐름=글의 흐름
시선의 흐름이 왼쪽에서 오른쪽으로 흐르기 때문에 자연스럽게 마지막에 작업버튼을 오른쪽에 둡니다. 인지 관점과 이유는 동일하지만, 확인-취소 버튼을 배치했을 때 확인→취소→확인으로 시선이 다시 이동하기 때문에 시선의 이동이 불필요하다고 본 것입니다.
Right의 중의적 의미
오른쪽을 영단어로 Right라고 씁니다. Right는 긍정의 의미(옳은)와 오른쪽을 의미합니다. 따라서 오른쪽에 긍정적인 버튼을 두기도 합니다.
스위치의 위치
스위치의 위치를 보면 OFF가 왼쪽이고 ON이 오른쪽입니다. 그 배치와 동일하게 오른쪽에 버튼을 배치합니다.
다른 컴포넌트의 순서(예: Pagination)
다른 컴포넌트를 예로 들어보겠습니다. 이전 버튼(<)은 왼쪽에, 다음 버튼은 오른쪽(>)에 위치합니다. 따라서 이전 작업버튼은 왼쪽, 다음 작업버튼을 오른쪽에 두는 것입니다.
MUI의 Pagination

 

엄지 영역(Thumb Zone)
개인적으로 모바일 OS에서 인지심리학을 차용하는 이유에 대해 생각해 보았습니다. 모바일 기기에는 엄지손가락이 이동하는 영역을 엄지 영역(Thumb zone)이라고 합니다. 엄지 영역에 주요 작업버튼들을 위치시키면 좋습니다. 네비게이션 바가 밑에 있는 경우가 많은 이유도 그중 하나입니다. 그래서 다음 작업이 엄지에 쉽게 닿을 수 있기 때문에 취소 버튼을 멀리 두었을 가능성도 생각해 보았습니다.

 


 

버튼 위치가 헷갈리는 이유는 어찌 보면 당연합니다. OS 별로 다른 관점을 적용하고 있기 때문입니다.

  • 윈도우는 작업버튼을 왼쪽에 배치합니다. 예를 들어, 확인-취소 순으로 배치합니다.
  • 애플, 구글은 작업버튼을 오른쪽에 배치합니다. 예를 들어,  취소-확인 순으로 배치합니다.

저는 현재 프로젝트가 웹 기반이기 때문에 인지 관점을 사용하여 왼쪽에 작업버튼을 배치했습니다. 앱 기반이라면 인지심리학 관점에서 오른쪽에 작업버튼을 두었을 것입니다.

 

선택의 조언

하나로 통일하면 좋겠지만 두 가지 관점을 모두 사용하고 있는 상황에서 맞고 틀린 것은 없다고 생각합니다. 서비스의 특성에 따라 직감을 따르는 인지 관점으로 할지, 뇌의 정보 처리 과정을 따르는 인지심리학 관점으로 할지 선택하면 좋겠습니다. 그럼에도 웹, 모바일 유저를 모두 고려할 경우 고민이 될 수 있습니다. 그럴 때는 어떤 관점을 선택하든 중요도에 따라 버튼 컬러를 다르게 해서 시각적으로 중요도를 분리하면 더 좋을 것 같습니다. 하나의 요소로만 문제를 해결하지 않고 다른 요소도 복합적으로 사용한다면 더 좋은 UX를 만들 수 있을 것이라고 믿습니다.

 


🔗 레퍼런스

요즘IT 버튼 위치는 어떻게 결정해야 할까요?

사물궁이 ‘확인-취소 vs 취소-확인’ 버튼 순서의 기준은?

 


👋

[버튼 위치 결정하기]

도움이 되셨길 바래요!

 

피그마 웹에서 기본으로 제공되는 폰트는 Google fonts인데요. 기본 글꼴 외에 다른 글꼴을 사용하고 싶은 경우에는 별도의 설정이 필요합니다.

 

로컬 폰트를 사용하는 두 가지 방법

피그마에서 로컬 폰트를 사용하기 위해서는 두 가지 방법 중에 선택하시면 됩니다.

1. <피그마 데스크톱 앱> 설치하기
2. <글꼴 설치 프로그램> 설치하기

 

피그마 데스크톱 앱을 설치하면 Figma font helper가 포함되어 있기 때문에 2번을 건너뜁니다.

저는 데스크톱 앱을 사용하지 않기 때문에 <웹에서 로컬 폰트를 사용하는 방법>을 소개하겠습니다.

 

그 이전에 안내사항을 읽어주시고 설정에 참고하시길 바랍니다.

⚠️ 로컬 폰트 관련 안내사항
- 공유된 팀 사용자의 경우, 모든 팀원이 동일한 로컬 폰트를 컴퓨터에 설치해주셔야 합니다.
- 참고로, 피그마는 .TTF .OTF 폰트 파일만 지원합니다.
- 피그마는 ChromeOS, Linux 운영체제의 기기에서는 로컬 폰트를 지원하지 않습니다. 기본 폰트를 사용해주세요.
[Windows] 로컬 폰트를 컴퓨터에 설치하는 방법
1. 폰트를 다운로드합니다.
2. C:\\Windows\\Fonts 위치에 폰트 파일을 붙여넣기하면 설치가 완료됩니다.

 

[피그마 웹] 글꼴 설치 프로그램 다운 받기

 

Figma 다운로드 페이지에서 [글꼴 설치 프로그램]을 OS에 맞게 다운로드합니다.

Figma 글꼴 설치 프로그램 다운로드하기

 

InstallFigmaAgent.exe 파일을 열어 [Install] 버튼을 클릭하면 설치가 진행됩니다.

다운로드 창에서 Install 클릭하기

 

Figma 창을 다시 열면 이제 로컬 폰트를 사용할 수 있습니다.

Figma 웹에서 로컬 폰트가 적용된 모습

 

 

👏 여기까지 잘 따라오셨다면 문제 없이 설치되셨을 거예요.

 

Missing fonts 에러

만약 Missing fonts 에러가 발생한 경우 몇 가지 팁을 알려드리겠습니다.

- 폰트가 잘 설치되었는지 확인해주세요.
  로컬 폰트가 잘 설치되었다면 다른 프로그램(예: 파워포인트)에서도 잘 보여야 합니다.
- 팀원과 버전이 동일한 폰트 파일을 설치해보세요. 버전이 맞지 않다면 충돌할 수 있습니다.
[Windows] 글꼴 버전 확인하기
   [시작]-[설정]-[개인 설정]-[글꼴]에서 해당 글꼴을 검색하세요. 메타데이터의 [버전]을 확인해보세요.
Variable 폰트인지 확인하기
하나의 파일인 가변 폰트(Variable Fonts)는 웹폰트로 유용하지만, Figma에서 적용이 안 되는 경우가 있습니다.
굵기별(light, bold 등)로 개별 파일이 있는 고정 폰트(Static Fonts)를 사용해주세요.

 

 

👋

[웹에서 로컬 폰트 사용하기]

도움이 되셨길 바래요!


🔗 레퍼런스
[Figma 공식문서] Add a font to Figma design

 

 

+ Recent posts