피그마를 실무 흐름으로 이해하기 : UI 설계 → 프로토타입 → 핸드오프

기능 자체에 집중하기보다 디자인을 어떤 구조로 설계하고, 어떻게 검증하고, 어떻게 개발자에게 전달할 것인가를 중점으로 봐야 한다

 

UI 패턴

 

1. 홈 → 목록 → 상세 → 액션

• ex1. 쇼핑앱 : 홈 화면에서 상품을 발견한다
  → 목록 화면에서 여러 상품을 비교한다
  → 상세 화면에서 상품 정보를 확인한다
  → 구매하기 버튼을 누른다
• ex2. 배달앱 : 홈에서 음식 카테고리를 본다
  → 가게 목록을 본다
  → 메뉴 상세를 본다
  → 주문 버튼을 누른다

→ UI 설계는 단순히 화면을 채우는 일이 아니라, 사용자의 다음 행동을 자연스럽게 이어주는 구조를 만드는 일

• 이 화면에서 사용자는 무엇을 해야 하는가?
• 어떤 정보가 의사결정에 필요한가?
• 가장 중요한 행동은 무엇인가?
  → 위 조건을 만족해야 UI 설계가 명확해진다

 

2. UI 6가지 분류 : 같은 모양처럼 보여도 어떤 상황에서 쓰이는지에 따라 역할이 달라질 수 있다

타입	설명	예시
Action	사용자의 행동을 실행(직관적/행동 유도성)	버튼
Input	사용자의 입력을 받음 (사용자가 무엇을 입력해야 하는지 쉽게 이해하는 것)	텍스트필드, 셀렉트박스
Information	상태나 안내를 전달 (사용자의 행동 흐름을 방해하지 않으면서 필요한 정보 알림)	토스트, 스낵바, 라벨
Container	여러 정보를 묶음(정보 구조를 정리하는 역할)	카드, 리스트, 바텀시트
Navigation	화면 이동을 도움	앱 바, 탭 바, 사이드바
Control	설정이나 값을 변경 (미리 정해진 상태나 옵션을 선택하는 경우 多)	체크박스, 라디오, 스위치

 

 

3. Pseudo State : 의사 상태

• 의사 상태는 같은 컴포넌트가 상황에 따라 다르게 보이는 상태를 말한다
  • ex. 기본 상태, 마우스를 올린 상태, 누르고 있는 상태, 비활성화된 상태, 로딩 중인 상태
• 왜 상태 설계가 중요할까?
  • 사용자는 UI의 상태를 보고 지금 무엇을 할 수 있는지 판단한다
    • ex. 버튼이 회색이고 흐리게 보이면 사용자는 '지금은 누를 수 없구나'라고 이해한다
  • 즉, 상태는 사용자의 행동을 안내하는 중요한 피드백이다
• 상태 설계가 없으면 생기는 문제
  • 상태를 설계하지 않으면 사용자는 헷갈린다
    • 비밀번호 조건을 만족하지 않아서 버튼이 비활성화된 것인지
    • 네트워크 문제인지
    • 필수 약관을 체크하지 않아서인지
      → 이유를 알 수 없으면 사용자는 멈춘다
• 중요 포인트
  • 사용자가 할 수 있는 것
  • 사용자가 할 수 없는 것
  • 지금 시스템이 처리 중인 것
  • 오류가 발생한 것
  • 성공적으로 완료된 것
    → 이런 상태를 화면에서 명확하게 보여줘야 한다

 

4. Prototype : PM에게 중요한 검증 도구

• 실제 개발 전에 화면 흐름과 동작을 테스트해보는 시제품(검증이 핵심)
  • 사용자가 이 흐름을 이해하는가?
  • 버튼을 어디서 눌러야 하는지 아는가?
  • 다음 화면으로 자연스럽게 이동하는가?
  • 중간에 막히는 지점은 없는가?
  • 기획 의도가 화면 흐름으로 잘 전달되는가?
    → 위와 같은 내용을 개발 전에 확인하기 위해 프로토타입을 만든다
• 프로토타입의 기본 구조
  • Trigger(무엇을 하면) → Animation(어떻게 움직이며) → Action(무엇이 일어난다)
    • ex. 상품 이미지를 클릭하면 → 부드럽게 전환되며 → 상세 화면으로 이동한다
      • Trigger: 클릭
      • Animation: 부드러운 전환
      • Action: 상세 화면으로 이동
  • Trigger : 액션이 시작되는 조건
    • On click: 클릭했을 때
    • On drag: 드래그했을 때
    • While hovering: 마우스를 올리고 있는 동안
    • Mouse enter: 마우스가 영역에 들어갔을 때
    • Mouse leave: 마우스가 영역을 벗어났을 때
    • After delay: 일정 시간이 지난 후
  • Action : 트리거 이후 발생하는 결과
    • Navigate to: 다른 화면으로 이동
    • Back: 이전 화면으로 이동
    • Change to: 다른 컴포넌트 상태로 변경
    • Open overlay: 팝업이나 바텀시트 열기
    • Close overlay: 오버레이 닫기
    • Scroll to: 특정 위치로 이동
    • Open link: 외부 링크 열기
  • Animation : 액션이 실행될 때 어떻게 보일지를 결정
    • Instant: 바로 전환
    • Dissolve: 흐려지며 전환
    • Move in/out: 화면이 들어오거나 나감
    • Push: 기존 화면을 밀면서 전환
    • Slide in/out: 슬라이드 전환
    • Smart animate: 동일 요소를 자연스럽게 변화
      → 사용자가 화면 변화를 자연스럽게 이해하도록 돕는 역할

 

5. Smart Animate

• 화면이 전환될 때, 두 화면에 같은 이름의 레이어가 있으면 피그마가 그 변화를 자연스럽게 연결해준다(인터랙션 품질 ↑)
• 작동 조건
  • 레이어 이름이 같아야 한다
  • 레이어 구조가 같아야 한다
    → 이 두 가지가 맞지 않으면 피그마는 '같은 요소가 변화한 것'으로 인식하지 못한다
• 어디에 사용하는가?
  • 상세 페이지 이동
    • 목록의 이미지가 상세 화면의 큰 이미지로 이어지면 사용자는 '내가 선택한 상품이 상세로 열렸다'고 자연스럽게 이해한다
  • 탭 이동
    • 하단 탭이나 상단 탭에서 선택 표시자가 부드럽게 이동하면 현재 위치 변화가 더 명확해진다
  • 리스트 삭제
    • 아이템이 삭제되고 나머지 항목이 위로 자연스럽게 올라가면 삭제 결과를 직관적으로 이해할 수 있다
• 남발하지 말 것 → 사용자의 이해를 돕는 방향으로 사용
  • 화면 변화의 원인을 보여주기 위해
  • 선택한 요소가 어디로 이동했는지 보여주기 위해
  • 상태 변화가 자연스럽게 느껴지도록 하기 위해

 

6. Scroll과 Overflow

• 콘텐츠 > 프레임 → 스크롤
  • 프레임 안의 콘텐츠가 프레임보다 커야 스크롤이 생긴다
• 오버플로우(Overflow)란?
  • 콘텐츠가 프레임 밖으로 넘치는 상태를 말한다
    • 어떤 프레임이 스크롤 컨테이너인가?
    • 내부 콘텐츠가 프레임보다 긴가?
    • 고정되어야 하는 요소는 무엇인가?
    • 함께 스크롤되어야 하는 요소는 무엇인가?
      → 위와 같은 조건을 만족할 경우 스크롤 설계

 

7. Hand-off(== 명세서)

• 디자인을 개발자가 구현할 수 있도록 전달하는 과정이다
  • 디자인 의도와 구현에 필요한 정보를 함께 전달하는 것
• 왜 중요한가?
  • 디자이너가 의도한 것과 개발자가 이해한 것이 다르면 결과물이 달라진다
    • ex. 디자이너는 버튼을 화면 하단에 고정하려고 했는데, 개발자가 일반 콘텐츠처럼 구현하면 스크롤할 때 버튼이 위로 올라가 버릴 수 있다
  • 디자인만 보고는 개발자가 모든 의도를 알 수 없다 → 핸드오프 필요
    • 이 화면의 핵심 행동은 무엇인가?
    • 어떤 상태를 반드시 구현해야 하는가?
    • 어떤 부분은 MVP에서 제외할 수 있는가?
    • 개발자가 헷갈릴 만한 예외 상황은 무엇인가?
      → 핸드오프가 명확하면 커뮤니케이션 비용이 줄어든다
• 핸드오프에 포함해야 할 것
  • 구조 : 화면이 어떤 영역으로 구성되어 있는지 설명해야 한다
    • App Bar
    • Hero Section
    • List Container
    • Action Button
      → 위의 예시와 같이, 구조를 알려주면 개발자는 컴포넌트를 어떻게 나눌지 이해하기 쉽다
  • 크기 : 각 요소의 크기를 전달해야 한다
    • 버튼 높이: 56px
    • 썸네일: 40 × 40px
    • 앱 바 높이: 56px
      → 위의 예시와 같이, 크기가 명확해야 구현 결과가 디자인과 달라지지 않는다
  • 간격 : 간격은 UI 품질을 크게 좌우한다
    • 좌우 글로벌 마진: 20px
    • 리스트 아이템 내부 간격: 16px
    • 텍스트필드 사이 간격: 12px
    • 버튼 영역 패딩: 20px
      → 위의 예시와 같이, 간격을 명확히 전달하지 않으면 개발 과정에서 임의값이 들어가기 쉽다
  • 스타일 : 컬러와 폰트 정보를 전달해야 한다
    • Primary color: #000000
    • Text color: #333333
    • Font: Pretendard
    • Size: 16px
    • Weight: 700
    • Line-height: 150%
      → 위의 예시와 같이, 스타일은 디자인 시스템과 연결되어 있으면 더 좋다
  • 인터랙션 : 정적 화면만 전달하면 개발자는 사용자가 클릭했을 때 어떤 일이 일어나는지 알 수 없다
    • 버튼 클릭 시 상세 화면으로 이동
    • X 버튼 클릭 시 이전 화면으로 이동
    • 구매 버튼은 화면 하단에 고정
    • 리스트는 세로 스크롤
    • 오류 발생 시 텍스트필드 하단에 에러 메시지 표시
      → 위와 같은 동작을 함께 전달해야 실제 제품에 가깝게 구현된다

 

8. 파일 정리 & 공유

• 피그마의 강점은 팀이 함께 볼 수 있다는 점이다
• 파일이 정리되어 있지 않으면 발생하는 문제
  • 어떤 화면이 최신인지 모름
  • 컴포넌트가 어디 있는지 못 찾음
  • 피드백할 위치를 찾기 어려움
  • 개발자가 필요한 화면을 확인하기 어려움
    → 파일 구조가 엉망이면 협업 효율이 떨어진다

8-1. 표지 페이지 : 파일을 열기 전에 어떤 프로젝트인지 바로 알 수 있게 해줌

• 피그마 기초
• 커머스 앱 UI 실습
• 로그인 플로우 개선안
  → 이런 식으로 제목을 넣고 썸네일로 설정하면 파일 목록에서 식별하기 쉽다

8-2. 디자인 페이지 : 디자인 페이지에는 실제 화면을 정리

• 홈 화면
• 목록 화면
• 상세 화면
• 로그인 화면
  → 흐름 순서대로 배치(로그인 → 홈 → 목록 → 상세 → 구매)

8-3. UI키트 페이지 : 컴포넌트를 모아둠

• Button
• TextField
• Checkbox
• App Bar
• List
• Tab
  → 종류별로 정리하고 이름을 명확하게 붙이는 것이 좋다(이름만 봐도 어떤 용도인지 알 수 있어야 함)

 

※ 공유 방식(목적에 따라 나눔)

공유 방식	상황	설명
파일 링크	전체 파일을 함께 볼 때	전체 프로젝트를 공유할 때 사용 ex. 팀원이 UI키트와 전체 화면을 모두 확인해야 한다면 파일 링크를 공유하면 됨
프로토타입 링크	사용 흐름을 테스트할 때	사용자 흐름을 보여주거나 테스트할 때 사용 ex. '로그인 후 홈으로 이동하고, 상품을 눌러 상세 화면으로 가는 흐름'을 보여주고 싶다면 프로토타입 링크가 적합
특정 프레임 링크	특정 화면 피드백을 받을 때	특정 화면에 대해서만 피드백을 받고 싶을 때 사용 ex. 상세 화면의 버튼 배치만 논의하고 싶다면 전체 파일 링크보다 해당 프레임 링크를 보내는 것이 효율적