앱이나 웹 화면을 처음 디자인할 때 대부분 색감이나 아이콘, 버튼 모양부터 신경 쓰게 됩니다. 그런데 막상 완성된 화면을 보면 어딘가 어수선하고 무엇부터 읽어야 할지 헷갈리는 경우가 많아요. 그 원인은 의외로 글자에 있는 경우가 많습니다. 화면 속 정보의 대부분은 결국 텍스트로 전달됩니다. 공고 제목, 버튼 문구, 입력창 안내 문구, 작성 날짜까지 모두 글자죠. 그래서 글자의 크기, 색, 굵기, 줄 간격만 정리해도 화면은 훨씬 깔끔해지고 읽기 쉬워집니다. 이번 글에서는 UI 디자인 초보자도 바로 적용할 수 있는 타이포그래피 기본 원칙 다섯 가지를 실제 화면 예시와 함께 정리해 보겠습니다. 1. 글자 크기: 역할에 따라 크기를 나눈다한 화면에 들어가는 글자는 각자 맡은 역할이 있습니다. 가장 먼저 눈에 ..

회의실에서 "이 버튼 좀 더 눈에 띄게 해주세요", "화면이 너무 복잡해 보여요" 같은 말을 한 번쯤 들어본 적 있으실 거예요.그런데 막상 왜 눈에 안 띄는지, 어떻게 덜 복잡하게 만들 수 있는지 설명하기는 쉽지 않습니다. UI 디자인 원칙은 바로 이럴 때 쓰는 공통 언어예요. 이름은 거창해 보여도, 사실 매일 쓰는 앱과 웹사이트에 이미 다 들어 있는 상식에 가깝습니다. 디자이너는 물론이고 기획자, 개발자, 마케터까지 알아두면 시안 피드백이 훨씬 명확해지는 원칙 10가지를 하나씩 살펴볼게요. 사람의 시선은 정해진 길로 움직인다1. F패턴 - 글이 많은 화면을 읽는 방식 채용 사이트에서 공고 목록을 볼 때를 떠올려 보세요.맨 위 공고는 회사명부터 연봉, 근무지까지 꼼꼼히 읽지만, 아래로 갈수록 왼쪽 회사명..

프로젝트를 하다 보면 이런 장면을 자주 만나게 됩니다. 디자이너는 시안에 "메인 파란색"이라고 적어 두었는데, 개발자는 코드에서 #3366FF를 쓰고, 다른 화면에서는 누군가 #3465FE를 넣어 둡니다. 눈으로 보면 거의 같은 색이지만, 이런 작은 차이가 쌓이면 QA 기간마다 "이 버튼 색이 왜 달라요?"라는 이슈가 수십 개씩 올라오게 되죠. 이 문제를 근본적으로 줄여 주는 도구가 바로 변수(Variables)입니다. 피그마에서는 "변수", 개발 쪽에서는 보통 "토큰(Token)"이라고 부르지만 가리키는 대상은 같습니다. 색상, 간격, 글자 크기처럼 반복해서 쓰이는 값에 이름을 붙여 한곳에서 관리하는 방식입니다. 디자이너와 개발자가 같은 이름을 쓰기 시작하면 소통이 빨라지고, 구현이 쉬워지고, 화면 전..

"이 아이콘 원본 파일 어디 있어요?", "버튼 그림자 값이 화면마다 달라요." 디자이너와 개발자가 함께 일하는 팀이라면 한 번쯤 이런 메시지를 주고받아 봤을 거예요. 이런 질문이 반복된다면 대부분 에셋(Asset)과 스타일(Style)이 체계적으로 정리되지 않았다는 신호입니다. 디자인 시스템이라고 하면 버튼이나 입력창 같은 컴포넌트를 먼저 떠올리기 쉽지만, 그 컴포넌트를 이루는 재료가 바로 에셋과 스타일이에요. 재료가 정리되어 있어야 핸드오프가 매끄럽고, 개발자가 "디자이너님, 이거 확인 한 번만…"이라고 묻는 횟수도 줄어듭니다. 이번 글에서는 피그마를 기준으로 에셋과 스타일을 어떻게 준비하면 좋은지 차근차근 살펴볼게요. 에셋: 개발자가 '내려받아야 하는' 모든 것에셋은 쉽게 말해 개발자가 코드로 직..

신규 입사 디자이너가 Figma 라이브러리를 열었을 때 가장 먼저 마주치는 감정은 대부분 "이 버튼은 언제 써야 하지?"라는 막막함이다.컴포넌트는 잘 만들어져 있는데, 그 컴포넌트가 왜 존재하고 어떤 상황에 써야 하는지 알려주는 문서가 없는 경우가 특히 국내 스타트업에서는 흔하다. 디자인 시스템이 진짜로 힘을 발휘하는 순간은 컴포넌트와 문서가 한 몸처럼 움직일 때다. 컴포넌트를 만들 때 자주 놓치는 세 가지컴포넌트 하나를 만드는 일은 생각보다 손이 많이 가는 작업이다. 버튼 하나만 봐도 색상, 크기, 아이콘 유무에 따라 조합이 수십 가지로 늘어난다. 이 과정에서 자주 놓치는 부분들이 있다. 1) 상태(State)를 끝까지 정의하지 않는다많은 팀이 기본 상태와 눌렀을 때 상태 정도만 만들어두고 개발 단계로..