온보딩 콘텐츠를 만드는 사람은 대부분 데스크톱 앞에서 만듭니다. 큰 모니터에서는 여덟 문장짜리 상황 설명도 한눈에 들어오고, 화면 가운데 뜨는 팝업도 불편하지 않습니다. 그런데 신규 입사자가 그 콘텐츠를 여는 곳은 출근길 지하철, 회의가 시작되기 전 5분, 점심 줄처럼 짧고 자주 끊기는 자리인 경우가 많습니다.
이 글은 First Run을 휴대폰에서 끝까지 플레이할 수 있도록 고치면서 정리한 설계 기준입니다. First Run은 브라우저에서 바로 열리는 웹 앱이므로, 여기서 다루는 내용도 설치형 앱 없이 웹에서 할 수 있는 것에 한정됩니다.
5분 단위로 쪼개기
모바일에서 한 번 붙잡고 쓰는 시간은 짧습니다. 그래서 설계의 출발점은 전체 분량이 아니라 한 번에 끝나는 단위입니다.
First Run에서 퀘스트 하나는 상황을 읽고, 선택하고, 피드백을 읽는 데 2~4분 정도 걸립니다. 5분이 생기면 퀘스트 하나를 끝내고 닫을 수 있습니다. 진행 상황은 브라우저에 자동으로 저장되므로 저장 버튼을 누를 필요가 없고, 다음에 열면 멈춘 곳에서 바로 이어집니다. 저장 위치가 브라우저라서 같은 기기, 같은 브라우저에서 열어야 이어진다는 점은 미리 안내해두는 편이 좋습니다.
이 구조에서 지킬 원칙은 두 가지입니다.
- 하나의 판단은 한 세션 안에서 끝납니다. 상황 설명을 읽다가 닫고 다음 날 선택지만 보게 되면 판단의 근거가 사라집니다.
- 다시 열었을 때 다음 행동이 바로 보입니다. 무엇을 하던 중이었는지 기억나지 않아도 HUD의 현재 목표와 길 안내 화살표가 다음 할 일을 알려줍니다.
엄지가 닿는 곳에 두기
휴대폰을 한 손으로 쥐면 엄지가 편하게 닿는 곳은 화면 아래쪽입니다. 자주 누르는 조작일수록 아래에 있어야 합니다.
조작은 화면 아래에
First Run은 세로 화면에서 D-패드와 A·B·MENU 버튼을 맵 아래에 따로 둡니다. 버튼이 맵을 가리지 않고, 엄지를 멀리 뻗지 않아도 됩니다. D-패드는 누르고 있으면 계속 걷고, 맵을 직접 탭하거나 밀어서 이동할 수도 있습니다.
가운데 팝업 대신 바텀 시트
화면 가운데 뜨는 팝업은 데스크톱에서는 자연스럽지만, 휴대폰에서는 닫기 버튼이 오른쪽 위 구석으로 가서 한 손으로 누르기 어렵습니다. First Run의 대화, 퀘스트, 피드백, 복습 화면은 모두 아래에서 올라오는 바텀 시트입니다. 제목과 버튼은 시트 위아래에 고정되고, 내용만 스크롤됩니다.
터치 영역과 안전 영역
버튼은 보이는 크기보다 눌리는 크기가 중요합니다. 터치 영역은 최소 44~48px을 확보하고, 아이콘이 작다면 보이지 않는 여백으로 눌리는 범위를 넓힙니다. 노치와 홈 바가 있는 기기에서는 버튼을 안전 영역(safe area) 안쪽에 두어야 홈 바를 쓸어 올리다 버튼이 눌리는 일이 없습니다. First Run의 오버레이는 모두 이 안전 영역을 반영합니다.
선택한 뒤에 확정하기
데스크톱에서는 마우스로 정확히 누르지만, 휴대폰에서는 스크롤하다 손가락이 선택지에 닿는 일이 흔합니다. 판단 문제에서 잘못 눌린 답이 그대로 제출되면, 플레이어에게는 틀린 이유 대신 억울함만 남습니다.
First Run은 터치 화면에서 선택지를 탭하면 선택만 되고, 아래의 이 답으로 결정 버튼을 눌러야 제출됩니다. 한 번 더 누르는 수고가 생기지만, 되돌릴 수 없는 순간에는 그 정도 마찰이 맞습니다. 대사 넘기기나 이동처럼 되돌릴 수 있는 조작은 한 번에 처리합니다.
기준은 단순합니다. 되돌릴 수 없는 결정은 두 단계로, 되돌릴 수 있는 조작은 한 단계로.
화면 높이를 끝까지 쓰기
요즘 휴대폰은 세로로 깁니다. 정사각형에 가깝게 설계한 맵을 그대로 넣으면 위아래가 비고, 정작 보이는 캠퍼스는 좁아집니다.
First Run은 세로로 긴 화면에서 맵을 위아래로 늘려 최대 가로 11칸, 세로 15칸까지 보여줍니다. 한 화면에 캠퍼스가 더 많이 보이면 전체 지도를 여는 횟수가 줄어듭니다. 맵 위에는 퀘스트 표시(! 와 ✓)와 NPC 이름표가 보여서, 작은 화면에서도 가까이 가지 않고 누구에게 할 일이 남았는지 알 수 있습니다. 전체 구조가 필요할 때는 플레이 영역 오른쪽 위의 지도 버튼으로 캠퍼스 전체를 봅니다.
작은 화면에서 읽히게 쓰기
모바일 온보딩이 실패하는 흔한 이유는 조작보다 글입니다. 데스크톱 기준으로 쓴 상황 설명은 휴대폰에서 두세 번 스크롤해야 끝나고, 스크롤하는 동안 앞 문장을 잊습니다.
- 상황 카드는 다섯 문장 이하로 씁니다. 시점, 주체, 사건, 제약 하나면 충분합니다.
- 퀘스트 하나에 판단 지점은 하나만 둡니다. 두 개를 넣으면 작은 화면에서는 무엇을 묻는지 놓치기 쉽습니다.
- 선택지는 한두 줄로 씁니다. 선택지가 길면 네 개를 비교하려고 위아래를 오가게 됩니다.
- 피드백은 이유 두세 문장과 핵심 학습 포인트 하나로 끝냅니다.
- 긴 배경 설명은 퀘스트 밖, 챕터 카드나 별도 문서로 뺍니다.
세로 우선, 가로는 대안
휴대폰을 쥐는 기본 자세는 세로입니다. First Run은 세로 화면을 기준으로 설계하고 가로 화면은 대안으로 둡니다. 세로에서는 조작 버튼이 맵 아래에 자리를 잡고, 높이가 낮은 가로 화면에서는 버튼이 맵 위에 겹쳐 떠서 맵 영역을 확보합니다. 가로 전환을 막지는 않되, 가로에서만 할 수 있는 조작은 만들지 않습니다.
데스크톱에 남겨둘 것
모든 온보딩을 휴대폰으로 옮길 필요는 없습니다. 작은 화면에서 억지로 하면 오히려 학습 효과가 떨어지는 과제가 있습니다.
- 코드가 많은 리뷰 과제. 수십 줄의 코드를 읽고 수정 지점을 찾는 일은 넓은 화면과 키보드가 필요합니다. 퀘스트에는 몇 줄짜리 코드만 두고, 실제 코드 리뷰 연습은 데스크톱에서 합니다.
- 긴 보고서와 산출물 작성. 주간 보고나 영향도 분석서를 쓰는 연습은 휴대폰에 맞지 않습니다.
- 여러 문서를 오가며 비교하는 작업. 창을 나란히 띄워야 하는 작업은 데스크톱이 맞습니다.
- 결과 리포트를 함께 보는 면담. 매니저와 같이 보는 자리라면 큰 화면이 낫습니다.
휴대폰에서는 판단을, 데스크톱에서는 산출물을 연습하는 식으로 나누면 양쪽 모두 무리가 없습니다.
모바일 온보딩 체크리스트
- 한 단위를 5분 안에 끝낼 수 있는가
- 진행 상황이 자동 저장되고, 다시 열면 이어지는가
- 다시 열었을 때 다음 행동이 바로 보이는가
- 자주 누르는 조작이 화면 아래쪽에 있는가
- 가운데 팝업 대신 바텀 시트를 쓰는가
- 터치 영역이 44~48px 이상인가
- 버튼이 노치와 홈 바를 피해 안전 영역 안에 있는가
- 되돌릴 수 없는 결정은 선택 후 확정의 두 단계인가
- 상황 카드가 다섯 문장 이하이고 판단 지점이 하나인가
- 세로 화면에서 모든 조작이 가능한가
- 데스크톱에 남길 과제를 따로 정했는가
모바일 온보딩의 목표는 데스크톱 콘텐츠를 작은 화면에 밀어 넣는 것이 아닙니다. 5분이 생겼을 때 판단 하나를 끝내고 닫을 수 있게 만드는 것입니다. 그 단위가 정해지면 나머지 설계는 대부분 그 단위를 지키는 방향으로 따라옵니다.
실무 상황을 퀘스트로 경험해보세요
휴대폰 브라우저에서 First Run을 열고 퀘스트 하나를 5분 안에 끝내보세요. 게임 시작하기