스터디카페 예약 IA — 이용자·운영자 탭을 먼저 나눠요

스터디카페 예약 앱에서 이용자 메뉴와 운영자 메뉴를 한 줄에 섞으면, 나중에 권한과 상태가 같이 깨져요. IA(메뉴·화면 구조표)는 그 경계를 먼저 그리는 일이에요.

이 글은 구조만 다뤄요. 아이디어 인터뷰도, 화면 일곱 장 나열도 여기서는 안 해요. 표 원본은 스터디카페 IA예요. 출시 전 가정이에요.

이용자 탭 / 운영자 탭

한 앱 안에 역할이 두 개예요. 메뉴를 나누지 않으면 「좌석을 고르는 사람」과 「좌석 조건을 고치는 사람」이 같은 버튼을 보게 돼요.

로그인 후에도 기본 랜딩을 역할별로 나눠요. 운영자가 이용자 찾기 화면에 떨어지면, 「설정」과 「예약」이 섞인 것처럼 보여요.

뎁스 — 어디서 멈추나요

이용자 쪽은 얕게 가요. 찾기 → (좌석) → 확인·결제 → 상세/QR. 한 뎁스에 결제와 입실을 같이 두지 않아요.

운영자 쪽은 「설정」과 「예외 처리」를 갈라요. 좌석 콘센트·정숙·가격대 같은 마스터는 설정 뎁스. QR이 안 될 때 넣어 주는 일은 예외 뎁스. 설정 화면에 입실 버튼을 넣으면, 평소에도 예외가 기본이 돼요.

상태 경계 — 빈 · 결제 · 입실

메뉴 이름보다 중요한 건, 각 화면이 상태를 하나만 대표하느냐예요.

• 빈자리 — 조회·고르기 구간. 아직 확정 아님. 홀드 없음(가정)
• 돈 낸 자리 — 결제 승인 성공 뒤. 취소·환불 정책이 붙는 구간
• 들어와 쓰는 자리 — QR 입실 성공 뒤. 이용중·미입실과 구분

한 화면에 「결제하기」와 「입실하기」를 같이 두면, 이용자는 언제부터 자리가 자기 것인지 몰라요. IA에서는 그 두 행동을 다른 칸·다른 권한으로 잘라요.

권한이 안 나뉘면 깨지는 점

• 이용자가 좌석 마스터를 고치면, 빈자리 조회가 거짓이 돼요
• 운영자 계정으로 일반 결제를 반복하면, 테스트 예약과 실결제가 섞여요
• 취소 권한이 입실 화면 안에 있으면, 이용중에도 「되돌리기」가 보여요

그래서 IA 검수는 기능 개수가 아니라 역할 × 상태 표로 해요. 이 탭에서 이 상태가 보여도 되나요?

되는 것 vs 안 되는 것

• 되는 것 — 이용자/운영자 탭을 나누고, 빈·결제·입실을 화면 경계로 두기
• 안 되는 것 — 메뉴를 기능 나열로만 채우고, 권한·상태를 나중에 붙이기

자주 묻는 질문

화면은 몇 장이어야 하나요?

IA는 장수 게임이 아니에요. 탭·뎁스·상태 경계가 맞으면 돼요. 대표 화면 줄기는 화면설계에서 봐요.

아이디어·범위는 어디에 있나요?

기획(아이디어 인터뷰)에 있어요. 빈 표부터면 IA 만들기.

아이디어 한 줄이면 기획 인터뷰, 같이 보면 상담. 이용자·운영자 경계를 구조로 나눈 기록이에요. 아이디어 한 줄이면 시작돼요.