4-1) 프로토타입과 제품 설계
프로토타입의 목적
- 사용자의 목적에 맞는 흐름을 잘 만들었는지를 검증하는 것
- 프로토타입을 만드는 이유
- 기획서에 있는 플로우를 화면으로 구체화하고 싶어서
- 개발자에게 전달하기 위해
- 디자인 팀 내부에서 구조를 리뷰받기 위해
- 유저 테스트를 준비하기 위해
북극성 지표와 프로토타입
- 북극성 지표는 우리 제품이 성공시켜야 하는 가장 중요한 사용자 행동 혹은 수치를 의미
- 그 지표를 높이려면? ▶️ 사용자의 행동을 설계하고, 적합한 UI로 화면을 설계해야 함
- 마지막으로 그 행동이 실제로 자연스럽게 연결되는지를 흐름으로 확인해야 함
- 프로토타입은 그 흐름을 확인하게 해주는 효과적인 방법 중 하나
사용자 흐름을 검증하는 도구
- 내가 디자인한 제품이 실제로 사용자의 목적에 부합하는 지 확인하는 실험 도구
피그마 프로토타입의 특징
- 장점
- 화면 간의 전환을 직관적으로 보여줄 수 있음
- 인터랙션 없이도 흐름을 빠르게 확인할 수 있음
- 공유 링크 하나로 누구와도 쉽게 리뷰할 수 있어
- 단점
- 실제 동작을 보여주는 정교한 인터랙션 구현은 어려움
- 데이터 입력, 조건 분기, 애니메이션 등은 제한적
- 모바일 앱처럼 터치에 따라 반응하는 행동을 완전히 시뮬레이션하긴 어려움
프로토타입 설계의 핵심 질문
- 이 흐름은 사용자 목적을 충실히 따라가고 있나요?
- 어떤 화면이 꼭 필요한가요? 어떤 화면은 과잉인가요?
- 중간에 사용자가 헤매거나 벗어날 여지는 없나요?
- ▶️ 이 질문들은 디자인의 목적과 흐름의 연결성을 검토할 수 있게 도와줄 수 있음
4-2) 프로토타입과 사용자 흐름 설계
사용자 흐름 설계 전략의 필요성
- 사용자는 예상대로 행동하지 않음 ▶️ 그럼 어떻게 사용자를 유도하는지?
- e.g. 회원가입 → 로그인 → 대시보드 진입 같은 직선형 흐름이 대표적
- 하지만 실제론 사용자가 중간에 나가기도 하고, 정보를 뺴먹거나 이상한 경로로 이동한 경우가 많음
- 프로토타입을 통해 디자이너는 가장 이상적인 사용자 흐름뿐 아니라, 예외 상황이나 오류까지 포함한 전체적인 사용자의 여정을 관찰할 수 있어야 함
사용자 흐름의 3가지 종류
- Happy Path: 우리가 바라는 이상적인 사용자 흐름
- Edge Case: 예상치 못한 상황에서 발생하는 예외적인 흐름 (중간에 인터넷 끊김, 비밀번호 재설정 이메일 미도착, ... )
- Alternate Path: 같은 목적을 다른 방법으로 도달하는 흐름(상품 상세 페이지에 가려면? 검색창에 직접 입력·카테고리에서 탐색·홈 추천 상품에서 유입, ...)
- 💡 프로토타입 실전 설계 팁
- 해피패스를 먼저 정리한 후, 여기서 문제가 생기면 어떻게 될지 계속 질문해보기
- 사용자가 다르게 행동할 수 있는 지점(입장 방식, 검색 방식 등)을 표시하기
- 각 흐름을 플로우차트로 간단히 그려놓으면, 놓치는 흐름 없이 설계할 수 있음
흐름 설계와 사용자 목적
- 질문을 수도 없이 반복하면서 사용자의 목적에 집중해야 해야 함
- 이 흐름은 사용자 목적 달성에 효과적인가요?
- 어떤 단계에서 이탈할 가능성이 높은가요?
- 흐름 중간에 사용자가 무기력하거나 혼란스러울 여지는 없나요?
- 실전에서 꼭 고려해야 할 흐름 설계 시나리오 (대표적인 예시)
- 회원가입 중간에 나가는 경우: 재방문 시 어디부터 다시 시작하게 할 것인가?
- 입력값 오류 발생: 사용자가 원인을 쉽게 이해하고 수정할 수 있도록 돕고 있는가?
- 조건 분기: 유저 상태(예: 로그인 여부)에 따라 다른 흐름이 구현되고 있는가?
- 중단 이후 재시작: 임시 저장, 복구, 또는 다음 행동으로 자연스럽게 유도하는가?
사용자 흐름 구조적으로 정리하기
- 플로우차트 (Flowchart): 전체 행동 흐름과 분기 조건을 시각화하는 가장 기본적인 방식
- 시나리오 플로우(와이어프레임이나 사용자 여정 지도): 사용자 페르소나별 또는 목적별 흐름을 나눠서 설계하는 방식 (예시: 신규 가입자 vs 기존 유저, 웹 vs 모바일 사용자 등)
- 피그마 프로토타입 + 설명 텍스트: 실제로 움직이는 화면으로 문서에선 놓칠 수 있는 디테일한 엣지 케이스를 찾아내기 좋은 방법, 인터랙션 흐름과 함께, 각각의 화면 상단에 간단한 설명을 추가하는 것도 효과적
4-3) 프로토타입과 UX 설계 고도화
프로토타입과 UX 설계 고도화
- 사용자가 길을 잃지 않고, 자연스럽게 다음 행동으로 넘어가게 만들기 위한 UI 전략이 필요함
- 현실의 사용자는 어디서든 멈출 수 있음
- 흐름이 ‘있다’와 흐름을 ‘잘 유도한다’는 전혀 다른 문제
사용자가 멈추지 않게 만드는 UI 전략 5가지
- Dead-end(막다른 길) 제거하기
- 사용자가 도달한 이후, 할 수 있는 행동이 아무것도 없는 상태
- 사용자가 미처 예상하지 못했거나 준비되지 않은 상태
- 예시
- 검색 결과가 0개일 때
- 방금 가입했는데 친구 목록이 비어 있을 때
- 장바구니에 상품이 아무것도 없을 때
- 해결 전략: 빈 상태와 리디렉션으로 보완
- 빈 상태: 빈 곳에 도달했을 때, 뭔가 할 수 있는 행동을 제안해서 막다른 길처럼 느껴지지 않게 함
- 리디렉션: 정상 흐름에서 벗어난 사용자에게 자연스럽게 다른 행동을 제안하거나 다른 경로로 유도
- Affordance(어포던스)를 확실히 전달하기
- 사용자에게 가능한 행동을 시각적으로 암시하거나 유도하는 UI의 성질
- UI가 사용자가 할 수 있는 ‘행동 가능성’을 자연스럽게 드러내는 것
- 단순히 ‘누를 수 있어 보이는 것’이 아니라 사용자가 실제로 취할 수 있는 행동과 연결된 시각적 힌트
- 예시
- 이건 클릭할 수 있어요
- 이건 넘길 수 있어요
- 이건 입력하는 칸이에요
- 해결 전략:
- 클릭 가능한 요소는 디자인적으로 분명하게 보여주기
- 반복적으로 동일한 디자인 원칙을 사용해서 사용자의 학습 도와주기
- Nudging(넛징)으로 부드럽게 다음 행동 유도하기
- 강요하지 않고도 원하는 방향으로 유도하는 UI 전략
- 서비스를 처음 방문한 사용자는 무엇부터 해야 할지 모를 때, 가이드가 됨
- 예시
- 이 기능이 처음이신가요? 따라하면서 배워보세요
- 내 프로필이 비어 있어요. 다른 사람들에게 나를 알려 보세요.
- 주의할 점
- 넛징은 설득이나 강요가 아니라 제시하는 것
- 거부감이 들지 않도록 선택권을 사용자에게 넘기기
- Hierarchy Back vs. History Back
- History Back (히스토리 복귀): 사용자의 방문 이력을 ‘시간 순으로’ 되돌아감 (A → B → C → B)
- Hierarchy Back (계층 복귀): 기능·계층 구조상 ‘상위 단계’로 이동 (A(홈) → A.1(리스트) → A.1.1(상세) → A.1(리스트))
- ‘뒤로 가기’ 버튼을 눌렀을 때 현재 화면의 맥락이나 사용자가 누른 의도를 파악해서, 둘 중 적합한 것으로 제시해줘야 함
- 터치 영역은 ‘보이는 것’보다 커야 함
- 버튼의 시각적 크기와 실제 누를 수 있는 영역의 차이 고려해야 함
- 작은 텍스트나 아이콘은 디자인적으로 예뻐 보일 수 있지만, 실제로 누르기 어렵다면 사용자에겐 실패 경험으로 남을 뿐임
- 최소 사이즈 (최소 40px는 되어야 함)
- 애플: 44px
- 구글: 48px
4-4) 프로토타입 점검하기
프로토타입 점검 체크리스트
- 이 화면에서 사용자가 해야 할 ‘행동’이 단 하나로 잘 보이나요?
- 이 화면은 정보 전달용인가요, 아니면 판단이 필요한 화면인가요?
- 사용자가 꼭 눌러야 할 버튼이나 해야 할 행동이 너무 많거나, 애매하진 않나요?
- 핵심 행동(CTA)은 한눈에 잘 보이게 배치되어 있나요?
- 흐름에 꼭 필요한 화면만 포함되어 있나요?
- 이 화면은 정말 필요한가요, 아니면 디자이너 입장에서 넣은 화면인가요?
- 이 화면이 없어도 흐름이 문제없이 작동하진 않나요?
- 비슷한 역할을 하는 화면이 여러 개 존재하진 않나요?
- 사용자가 중간에 멈출 만한 지점이 있진 않나요?
- 흐름 중간에 무언가 막혀 있거나, 선택지가 너무 많아 혼란스러운 화면은 없나요?
- 빈 상태일 때 사용자가 할 수 있는 행동을 제안해주고 있진 않나요?
- 에러 상황이나 중단된 흐름에서, 다시 시작하거나 복구할 수 있는 방법이 잘 제시되어 있나요?
- 화면 구성은 목적과 지표에 부합하나요?
- 이 흐름은 우리가 원하는 핵심 지표(예: 전환율, 소비시간 등)에 실제로 기여하고 있나요?
- 유도하고 싶은 행동은 시선이 먼저 닿도록, 덜 중요한 정보는 시선이 나중에 닿도록 했나요?
- 화면을 탐색한 후 자연스럽게 핵심 행동으로 닿을 수 있나요?
- 상태에 따라 흐름이 잘 분기되나요?
- 로그인 여부나 유저 상태에 따라 이동 경로가 다른 부분들이 잘 설계되어 있나요?
- 사용자 상태에 따라 보여줘야 할 정보나 행동이 달라지는 경우, 그 조건이 잘 반영됐나요?
- 시선 흐름이나 시각적 위계가 잘 반영됐나요?
- 사용자의 시선은 중요한 정보부터 자연스럽게 이동하나요?
- 타이포그래피, 컬러, 여백, 정렬 등이 정보의 우선순위를 잘 전달하고 있나요?
- 너무 많은 색상이나 폰트 크기, 비슷한 버튼들이 혼동을 주고 있진 않나요?
- 💡 요약
- 이 화면은 사용자에게 어떤 판단을 하게 만들려고 존재하나요?
- 그 판단을 위해 필요한 정보는 잘 정리돼 있나요?
- 다음 행동을 어떤 방식으로, 얼마나 분명하게 유도하고 있나요?
- 흐름은 사용자의 목적을 따라 매끄럽게 이어지나요?
- 그리고 그 목적은 우리가 세운 핵심 지표와 연결되어 있나요?
4-5) 프로토타입으로 협업하기
프로토타입과 커뮤니케이션
- 함께 제품을 만드는 구성원들과 제품 사용자에게 제품을 소개하는 과정
- 프로토타입의 핵심 목적은 이 제품이 어디로 가는지 모두 이해하게 만드는 것
- 단순히 ‘보여주는 것’이 아니라, 함께 ‘이해하고 조율하는 도구’
실무 프로토타입 활용 사례
- 디자인 리뷰
- 본격적인 개발에 들어가기 전에, 기획과 디자인이 서로 이해한 바가 맞는지, 또는 디자이너들끼리 UX에 문제될 만한 부분은 없는지 맞춰보는 과정
- 피그마에서 프로토타입을 실행해 공유하면서 서로 피드백을 남김
- 디자인 리뷰는 ‘내가 만든 흐름이 맞는가?’를 확인받는 가장 빠른 방법
- 기획·개발과 스펙 협의
- 개발에 필요한 자원을 가늠하고 개발 범위와 조건을 조율하는 목적
- 조건 분기, 에러 상황, 상태 변화 등을 화면 옆에 설명하기
- 필요하다면 플로우차트나 기획 문서도 함께 제공하기
- 유저 테스트(UT) 시나리오 구성
- 실제 제품 출시 전에 사용자에게 제품와 유사한 형태의 프로토타입으로 테스트를 진행 함
- 가능하다면 빈 상태, 에러 흐름도 반영해 현실감을 높이고 핵심 행동 중심으로 흐름을 설계 함
- 실제 기능 구현 없이도 테스트 가능하다는 점이 피그마 프로토타입의 가장 큰 장점
- 그 외 활용법
- QA나 고객지원팀에게 신기능 흐름을 설명할 때 (→ 프로토타입을 보여주면 말보다 빠르게 이해됨)
- 마케팅팀이나 비즈니스팀에게 제품 구조를 소개할 때 (→ 전체 서비스 흐름이 담긴 프로토타입은 좋은 자료가 됨)
- 새로 온 팀원에게 온보딩 자료로 활용할 때 (→ 제품의 핵심 흐름을 빠르게 이해할 수 있음)
'강의 정리 > 실전 UI 디자인' 카테고리의 다른 글
| [실전 UI 디자인] CH3: 컴포넌트 설계의 목적 (3) | 2025.08.08 |
|---|---|
| [실전 UI 디자인] CH2: 정보 구조와 시각 흐름을 통한 UI 설계 (4) | 2025.08.08 |
| [실전 UI 디자인] CH1: 사용자 목적과 UI 디자인 이해 (3) | 2025.08.07 |
