이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
UI/GUI 설계에서 가장 자주 겪은 어려움은 요구사항이 구체적이지 않을 때 해석이 엇갈리는 상황이었습니다. 기획자나 개발자와 같은 문서를 보고도 다르게 이해한 경우가 있었고, 초기에 시각적 기준을 맞추는 회의를 먼저 가지는 것이 나중의 수정을 줄이는 방법이었습니다.
시각 계층을 정리하는 것도 어렵게 느껴지는 부분이었습니다. 무엇이 먼저 보여야 하는지, 어디에 시선이 머물러야 하는지를 결정하는 과정에서 직관이 아닌 근거를 가지고 설명하는 능력이 필요했습니다. 이를 위해 사용자 행동 패턴을 학습하면서 기준을 잡아나갔습니다.
피드백 수용도 설계에서 중요한 과정이었습니다. 처음 만든 결과물에 애착이 생기면 피드백을 방어적으로 받는 경우가 있었는데, 설계 결정의 근거를 명확히 해두면 피드백에서 무엇을 바꿔야 할지가 더 분명해진다는 것을 배웠습니다.
졸업 프로젝트에서 처음으로 모바일과 웹 양쪽을 함께 설계하는 UI/GUI 작업을 맡았습니다. 팀 4명이 10주 동안 진행한 프로젝트였는데, 반응형 레이아웃을 직접 설계한 경험이 없어서 화면 크기에 따라 어떻게 달라지는지 감이 없었습니다. 처음에는 웹 버전만 완성하고 모바일은 나중에 조정하려 했는데, 그렇게 하면 거의 처음부터 다시 잡아야 한다는 것을 뒤늦게 알았습니다. 이후 모바일 퍼스트로 레이아웃을 잡고 웹으로 확장하는 방식으로 바꿨습니다. 완성 후 팀원들에게 보여줬을 때 화면 전환이 자연스럽다는 피드백을 받았습니다.
경험 없는 영역을 먼저 작게 실패해보는 것이 가장 빠른 학습이라는 것을 그때 배웠습니다.
UI 설계에서 어려움을 겪은 또 다른 경험은 다크 모드를 추가로 구현해야 했던 상황이었습니다. 라이트 모드만 설계한 상태에서 다크 모드를 추가하려고 하니, 색상 토큰 없이 직접 입력한 색상 값들이 화면마다 달라서 일관성 유지가 어려웠습니다. 특히 버튼과 배경의 대비가 화면에 따라 달라지는 문제가 생겼고, 수작업으로 수정하는 데 시간이 많이 들었습니다. 이후 컬러 시스템을 토큰 기반으로 다시 정리하고, 각 색상에 의미 이름을 붙이는 방식으로 바꿨습니다. 이후 모드 전환 시 토큰 값만 바꾸면 전체 화면이 바뀌는 구조가 됐습니다.
색상 토큰 없이 설계를 시작하면 나중에 다크 모드나 테마 변경에서 반드시 대가를 치른다는 것을 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 한양대학교병원(서울) UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.