이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
복잡한 도메인에서 시스템 설계를 할 때 사용자가 이 도메인을 어떻게 이해하고 있는지, 즉 멘탈 모델을 먼저 파악하는 것이 가장 중요하다고 생각합니다. 시스템의 실제 로직과 사용자의 기대가 어긋날수록 혼란이 생기기 때문에, 둘 사이의 간격을 좁히는 방향으로 UI를 설계했습니다.
상태 전이 다이어그램을 그려두면 어떤 상태에서 어떤 액션이 가능한지 전체 흐름이 보여서 빠뜨리는 케이스가 줄었습니다. 도메인 전문가와 초기에 인터뷰를 통해 업계 용어와 사용자가 실제로 쓰는 언어 사이의 차이를 파악했고, 화면 문구에 사용자 언어를 쓰는 것이 학습 부담을 크게 낮췄습니다. 복잡한 시스템일수록 단순하게 보이게 만드는 설계의 정교함이 중요하고, 그 과정이 가장 많은 시간을 요구한다는 걸 경험했습니다.
복잡한 도메인을 다룰 때 처음에 화면을 먼저 만들다가 도메인 용어를 잘못 쓴 사례가 있었습니다. 업무용 시스템을 설계할 때 일반 사용자 언어로 라벨을 정했는데, 실제 사용자인 담당자들이 자기 업무 용어를 기대하고 있었습니다. 용어 차이 하나가 화면 전체를 다시 검토하는 상황을 만들었습니다. 이후 설계 초기에 도메인 전문가와 인터뷰를 통해 실제로 쓰는 용어와 그 의미를 먼저 파악하는 순서를 넣었습니다.
아는 것처럼 느껴지는 도메인일수록 가정을 빨리 검증해야 한다는 것을 그때 배웠습니다. 도메인 이해 없이 만든 설계는 완성도가 높아도 현장에서 수정이 필요하다는 것을 경험했습니다.
복잡한 시스템 설계에서 상태 전이 다이어그램을 그리지 않고 화면을 먼저 만들다가 빠뜨린 케이스를 뒤늦게 발견한 경험이 있습니다. 특정 상태에서 어떤 액션이 가능한지를 명확히 정리하지 않은 채 진행했는데, 개발 단계에서 이 상황에서 버튼을 눌렀을 때 어떻게 되는지에 대한 답이 없었습니다. 다시 설계 단계로 돌아가야 했고, 그 시간이 낭비됐습니다. 이후 설계 전에 상태 다이어그램을 먼저 그리는 순서를 고정했습니다.
시각화된 상태 흐름이 없으면 누락 케이스를 나중에야 발견하게 된다는 것을 배웠습니다. 복잡한 도메인일수록 설계 전에 전체 흐름을 먼저 정리하는 것이 결과적으로 더 빠른 경로라는 것을 그때 이해했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.