사용자 흐름과 와이어프레임

화면 설계에서 다룰 것

• 핵심 과업을 사용자 흐름으로 표현한다
• Auto Layout으로 콘텐츠 변화에 견디는 구조를 만든다
• 정상·로딩·빈·오류·권한 상태를 설계한다

정보 구조에서 화면까지

사이트맵·사용자 흐름·화면의 차이

사이트맵만으로 과업의 실패 경로를 설명할 수 없고 화면 모음만으로 정보 구조를 설명할 수 없습니다. 네 산출물을 같은 용어와 상태 이름으로 연결합니다.

사용자 흐름 먼저 그리기

시작점, 사용자 행동, 시스템 응답, 완료 또는 실패 상태를 연결합니다.

1세션 목록 → 세션 선택 → 상세 확인 → 신청 제출 → 완료 확인2                              └ 오류 → 입력 수정

화면 이름보다 사용자의 행동을 기준으로 흐름을 작성하면 빠진 단계와 예외를 찾기 쉽습니다.

프레임과 레이아웃

• 실제 지원할 모바일·데스크톱 너비로 프레임을 만듭니다.
• Auto Layout으로 간격과 정렬 규칙을 표현합니다.
• 텍스트가 길어지거나 항목이 늘어날 때 레이아웃이 유지되는지 확인합니다.
• 절대 좌표는 겹침처럼 의도된 표현에만 사용합니다.

와이어프레임

색과 장식보다 정보 우선순위에 집중합니다. 페이지마다 사용자가 해야 할 한 가지 핵심 행동, 그 행동에 필요한 정보, 되돌아갈 경로가 보여야 합니다.

컴포넌트와 변형

반복되는 버튼, 입력, 카드, 내비게이션은 컴포넌트로 만듭니다. 상태 차이는 복제된 프레임보다 variant로 관리합니다.

• 버튼: 기본 / hover / disabled / loading
• 입력: 비어 있음 / 입력됨 / 오류 / 도움말
• 카드: 기본 / 선택됨 / 마감됨

화면 상태 설계

정상 데이터만 그리면 구현 단계에서 빈틈이 생깁니다. 최소한 로딩, 빈 상태, 오류, 성공, 권한 없음, 긴 텍스트를 확인합니다.

개발 전달

디자인에는 구현에 필요한 규칙이 보여야 합니다. 컴포넌트 이름, 간격, 상태, 반응형 변화, 에셋 형식을 정리하고 개발자와 함께 실제 데이터 예시를 검토합니다.

화면 설계 레퍼런스

화면을 만들기 전에 정보와 상태를 표로 정리하면 Figma 프레임 수를 줄이고 구현 누락을 찾기 쉽습니다.

컴포넌트 이름 규칙

1Button / Primary / Medium2Button / Secondary / Medium3Input / Text / Error4Card / Session / Closed5Navigation / Sidebar / Desktop

보이는 색 이름보다 역할과 상태를 이름에 담습니다. BlueButton보다 Button / Primary가 테마와 브랜드가 바뀌어도 의미를 유지합니다.

참고: Auto Layout을 적용할 때 먼저 “내용이 늘어나면 어느 방향으로 커지는가”를 답하세요. 고정 너비와 Hug contents를 습관적으로 선택하지 않습니다.

개발 전달에 포함할 것

핸드오프 확인 항목

• 실제 이름과 긴 텍스트를 넣어 확인했습니다.
• 컴포넌트 variant가 코드 상태와 대응합니다.
• 키보드 포커스와 오류 메시지가 설계되어 있습니다.
• 개발자가 추측해야 하는 수치를 최소화했습니다.

와이어프레임 예제

예제: 신청 흐름 설계

세션 목록 → 상세 확인 → 신청 입력 → 확인 → 완료 흐름을 Figma로 만듭니다. 먼저 저충실도 와이어프레임으로 구조를 검증하고 이후에만 시각 스타일을 추가합니다.

반드시 포함할 프레임

Auto Layout 점검

카드 제목을 두 배 길게 만들고 태그를 0개·5개로 바꿉니다. 요소가 겹치면 고정 높이, Hug, Fill의 선택 이유를 다시 확인합니다.

개발 전달

각 프레임에 실제 URL, 상태 이름, 사용 데이터, 반응형 변화, 키보드 포커스 순서를 주석으로 남깁니다.

주차별 실습: 3주 정보 구조 · 4주 흐름 · 6주 와이어프레임

이 문서는 세 주차에 걸쳐 사용합니다. 5주에는 별도 ‘Figma 컴포넌트와 Auto Layout’ 문서로 이동한 뒤 6주 와이어프레임으로 돌아옵니다. 각 주차마다 다른 산출물을 남깁니다.

3주: 정보가 어디에 속하는가

권장 90분: 콘텐츠 수집 20분, 분류·이름 정하기 30분, 찾기 과업 25분, 리뷰 15분입니다. 세션 제목·일정·준비물·마감·신청 상태·내 신청을 카드로 적고 목록·상세·내 신청 중 어디에서 필요한지 분류합니다. 같은 정보가 여러 곳에 필요한 이유도 기록합니다.

가상 구조 예시는 ‘세션 목록 → 세션 상세’, ‘내 신청 → 신청 상세’입니다. 준비물은 상세에서 전체를 보고 목록에서는 유무 정도만 보여 줄 수 있습니다. 이 구조가 실제 사용자에게 맞는지는 리서치 근거와 찾기 과업으로 확인합니다.

완료 기준: 콘텐츠 목록·사이트맵·용어 사전이 있고 팀원이 ‘다음 주 준비물 찾기’와 ‘내 신청 확인’의 위치를 설명합니다. 아직 버튼 좌표와 시각 스타일을 확정할 필요는 없습니다.

4주: 행동과 시스템 분기

권장 90분: 핵심 과업 15분, 정상 흐름 25분, 예외 분기 30분, 역할 검토 20분입니다. 사용자 행동과 시스템 판단을 다른 기호와 텍스트로 구분합니다.

흐름 예: 상세 열기→신청 선택→로그인 여부 확인→신청 가능 여부 재확인→저장→완료 안내. 비로그인은 로그인 후 복귀, 마감은 다른 세션 탐색, 응답 실패는 신청 상태 확인으로 연결합니다. 중복 신청의 정책은 기획·개발과 합의할 항목으로 표시합니다.

완료 기준: 시작·완료·실패·되돌아가기가 연결되고 이미 로그인한 사용자와 비로그인 사용자의 차이가 드러납니다. 화면 이름만 나열한 도식은 사용자 흐름을 대신하지 않습니다.

6주: 우선순위를 화면으로 검증

권장 100분: 정보 우선순위 20분, 저충실도 화면 35분, 상태·폭 변화 25분, 리뷰 20분입니다. 5주 컴포넌트를 활용하되 먼저 목록·상세·신청·결과의 정보를 낮은 충실도로 배치합니다.

제목 60자, 준비물 없음, 신청 마감, 제출 중, 입력 오류를 각각 넣어 봅니다. 360px와 1280px는 검사 출발점이며 실제 지원 범위는 팀에서 정합니다. 긴 문장이 잘리면 작은 글자로 감추기 전에 레이아웃과 콘텐츠 규칙을 검토합니다.

완료 기준: 핵심 과업을 화면으로 따라갈 수 있고 정상 화면 외에 실패·복구 상태와 다음 행동이 있습니다. 결과는 7주 기능 명세의 입력·응답·수용 기준으로 연결합니다.

더 읽어보기

• Figma Auto layout
• Figma Components overview
• Figma naming components

다음 단계

4주를 마쳤다면 Figma 컴포넌트, 6주를 마쳤다면 기능 명세로 이어갑니다.

연결된 PBL 미션과 VOD

PM은 ‘PM업무, 강의 하나로 정리하기’, Figma는 ‘Figma로 앱 디자인부터 포트폴리오까지’를 뜻합니다.

강좌 안내: 참고 강좌 1 · 참고 강좌 2. 이 문서는 영상 전체를 옮긴 전사 자료가 아닙니다. 세부 내용은 위 공식 문서에서 확인합니다.