이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Wireframe, FRD, Prototype 작성에서 가장 중요하게 생각하는 건 수신자가 혼자 읽어도 이해할 수 있는 명확함입니다. FRD를 처음 작성했을 때 기능 목록만 나열했는데, 개발팀에서 에러 처리와 상태 분기를 어떻게 처리하는지 질문이 많이 왔습니다.
상태를 명시하지 않은 것이 원인이었습니다. 이후로 Wireframe에도 정상·에러·로딩·빈 상태를 함께 포함하는 방식을 씁니다. 엣지 케이스 커버리지가 문서 품질을 가르는 기준이라고 생각합니다. Prototype은 플로우 검증 수단이지 완성품 시뮬레이션이 아니라는 인식으로, 인터랙션이 복잡한 구간 위주로 만듭니다. 문서의 목적은 기록이 아니라 합의이고, 읽는 사람이 달라도 같은 이해에 도달하는 것이 목표입니다.
Wireframe, FRD, Prototype 작성에서 아직 충분하지 않다고 느끼는 부분은 Edge Case를 빠짐없이 커버하는 것입니다. 정상 흐름은 상세히 정의하지만, 빈 상태(Empty State)·오류 상태·권한 없는 사용자가 접근했을 때 어떻게 되는지를 초기 FRD에서 빠뜨리는 경우가 있었습니다.
개발팀에서 나중에 예외 처리를 어떻게 할지 질문이 올 때, 그 시점에서 정의하면 이미 다른 부분과 일관성을 맞추기 어려워지는 것을 경험했습니다. 긴 텍스트나 특수문자 입력 시 UI가 어떻게 반응하는지처럼 극단적인 케이스를 작성 시점에 모두 떠올리는 것은 아직 훈련이 더 필요한 영역입니다. Prototype에서도 핵심 플로우 외의 분기를 포함하는 것이 시간 제약 때문에 종종 생략되는데, 이것이 사용성 테스트에서 빠진 시나리오가 되곤 합니다. 한계를 아는 것은 체크리스트를 더 철저히 만들어야 한다는 방향을 줍니다.
Wireframe과 FRD를 처음 작성했을 때 가장 크게 배운 것은 상태를 명시하지 않으면 구현 단계에서 판단을 다른 사람에게 넘기는 것이라는 사실이었습니다. 버튼이 있는 화면을 정의했는데, 로딩 중일 때, 에러가 났을 때, 권한이 없을 때 어떻게 보이는지를 작성하지 않았더니 개발팀에서 각자 다른 방식으로 처리하는 일이 생겼습니다.
그 이후로 모든 컴포넌트에 정상·로딩·에러·빈 상태를 함께 그리는 방식으로 바꿨습니다. 엣지 케이스 체크리스트 — 빈 화면·긴 텍스트·네트워크 오류·권한 없음을 작성 전에 미리 펼쳐두면, 빠뜨리는 항목이 줄어들었습니다. Prototype도 완성도보다 테스트하려는 인터랙션에 집중하는 방향으로 목적을 명확히 하면 만드는 시간이 줄고 피드백이 더 구체적으로 나왔습니다. 문서는 읽는 사람이 같은 판단을 내릴 수 있게 돕는 것이 목표입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 PTKOREA UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.