디자인 면접 질문

제가 가장 애착을 갖는 건 지역 독립서점 앱 리디자인 프로젝트입니다. 처음 화면에 배치한 이유는 이 프로젝트가 제가 지원한 직무와 가장 닿아 있기 때문입니다. 사용자 인터뷰부터 정보구조 설계, UI 시안, 프로토타입 테스트까지 전 과정을 직접 경험해서 제가 문제를 어떻게 정의하고 풀어가는지 가장 잘 보여줄 수 있다고 생각했습니다. 또 결과물만이 아니라 중간에 방향을 두 번 바꾼 과정도 함께 담아서, 제가 근거를 갖고 판단하는 사람이라는 점을 전달하고 싶었습니다.

기준은 세 가지였습니다. 첫째, 제가 문제 정의부터 과정을 설명할 수 있는 작업인지. 둘째, 지원 직무와 결이 맞는지. 셋째, 서로 다른 역량을 보여주는지였습니다. 그래서 UX 리서치 중심 프로젝트, UI 시스템 구축 프로젝트, 브랜드 그래픽 작업을 각각 하나씩 넣었습니다. 반대로 학교 과제로 예쁘게 그린 포스터 시리즈는 결과물은 마음에 들었지만 왜 그렇게 만들었는지 근거를 설명하기 어려워서 제외했습니다. 양보다 설명 가능한 작업이 낫다고 판단했습니다.

문제 정의는 디자인의 나침반이라고 생각합니다. 문제가 뾰족하지 않으면 화면은 예뻐지지만 사용자 입장에서는 아무것도 나아지지 않는 결과가 나오기 쉽습니다. 저는 학교 프로젝트에서 '앱을 세련되게 만들자'로 시작했다가 방향을 계속 바꿨던 경험이 있는데, 이후에 '처음 쓰는 사용자가 3분 안에 첫 주문을 끝내지 못한다'로 문제를 좁히니 무엇을 빼고 무엇을 강조할지 판단이 훨씬 빨라졌습니다. 문제 정의가 곧 의사결정의 기준이 된다고 느꼈습니다.

중고 거래 앱 개선 프로젝트에서는 세 가지를 했습니다. 먼저 앱스토어 리뷰 200개를 읽고 불만을 유형별로 분류했고, 실제 이용자 6명을 인터뷰했고, 유사 서비스 3개의 거래 흐름을 화면 단위로 비교했습니다. 그 결과 '거래 약속을 잡는 단계에서 대화가 길어지고 약속이 깨진다'는 공통 패턴이 보였습니다. 리뷰에서도 노쇼 관련 언급이 가장 많았고요. 그래서 문제를 '약속 조율 과정이 채팅에만 의존해 확정되지 않는다'로 정의하고 해결 방향을 잡았습니다.

4인 팀이었고 저는 UX 리서치와 정보구조 설계, 그리고 주요 플로우 5개의 UI 시안을 담당했습니다. 구체적으로는 인터뷰 가이드를 작성해 6명 인터뷰를 진행하고 인사이트를 정리했고, 그걸 바탕으로 사이트맵과 와이어프레임을 그렸습니다. 비주얼 컨셉과 일러스트는 다른 팀원이 맡았고, 저는 그 컨셉을 실제 화면에 적용하는 역할을 했습니다. 프로토타입 사용성 테스트는 제가 설계하고 팀원 한 명과 함께 진행했습니다. 포트폴리오에도 제 담당 범위를 표기해 두었습니다.

저는 읽는 분이 스크롤만 내려도 흐름이 이해되도록 구성합니다. 맨 위에 프로젝트 한 줄 요약과 기간, 역할, 툴을 넣고, 다음에 문제 정의와 그 근거를 배치합니다. 그다음 과정에서는 리서치, 아이디어 정리, 시안 변화 같은 핵심 의사결정만 골라 보여주고, 이어서 최종 솔루션 화면과 그 화면이 어떤 문제를 해결하는지 캡션으로 붙입니다. 마지막에는 결과나 사용성 테스트 반응, 그리고 아쉬운 점과 배운 점을 짧게 씁니다. 모든 과정을 다 넣기보다 근거가 되는 것만 남기려고 합니다.

저는 크게 다섯 단계로 진행합니다. 먼저 리서치 단계에서 사용자와 서비스 맥락을 파악하고, 두 번째로 발견한 내용을 묶어 문제를 한 문장으로 정의합니다. 세 번째로 해결 아이디어를 넓게 펼쳐보고 기준에 맞춰 후보를 좁히고, 네 번째로 와이어프레임과 프로토타입을 만들어 실제로 만져보게 합니다. 마지막으로 테스트 반응을 반영해 다듬습니다. 다만 실제로는 일직선이 아니라 프로토타입 단계에서 문제 정의로 돌아간 경험도 여러 번 있었습니다. 저는 그 되돌아가는 과정도 프로세스의 일부라고 생각합니다.

네, 있었습니다. 처음에는 '레시피 앱의 검색이 불편하다'로 문제를 정의했는데, 프로토타입을 5명에게 보여줬을 때 검색보다 '재료가 애매해서 시작 자체를 못 한다'는 말이 반복됐습니다. 검색 개선안을 써도 이탈 지점이 그대로였고요. 그래서 문제를 '가진 재료로 만들 수 있는 요리를 판단하기 어렵다'로 다시 정의했습니다. 그 뒤에는 검색창 개선 대신 보유 재료 기반 추천 흐름을 설계했고, 재테스트에서 첫 레시피 선택까지 걸리는 시간이 눈에 띄게 줄었습니다. 문제 정의를 고치는 게 화면을 고치는 것보다 효과가 크다는 걸 배웠습니다.

학생 프로젝트라 실제 서비스 지표는 볼 수 없었기 때문에 두 가지로 확인했습니다. 정량적으로는 같은 과업을 기존 앱과 제 프로토타입으로 각각 수행하게 해서 완료 시간과 오류 횟수를 비교했습니다. 6명 기준으로 평균 소요 시간이 약 40퍼센트 줄었습니다. 정성적으로는 테스트 중 나온 발언을 기록해 '어디서 멈추는가'를 봤습니다. 다만 표본이 적고 참가자가 지인 위주라 편향이 있다는 한계는 인지하고 있습니다. 그래서 결과를 단정하지 않고 '개선 가능성이 확인됐다' 정도로 정리했습니다.

제 추측만으로 시작하지 않으려고 외부 근거를 최대한 모았습니다. 먼저 해당 서비스 앱스토어 리뷰와 커뮤니티 게시글을 모아 불만 키워드를 정리했고, 관련 산업 리포트에서 이용 행태 통계를 인용했습니다. 그다음 실제 사용자 5명을 짧게라도 인터뷰해서 리뷰에서 본 문제가 실제로 반복되는지 확인했습니다. 이렇게 하면 '제가 불편해서'가 아니라 '여러 경로에서 같은 문제가 관찰됐기 때문에'라고 말할 수 있게 됩니다. 포트폴리오에도 근거 출처를 함께 적어 두었습니다.

저는 세 가지를 지킵니다. 첫째, 페이지 상단에 팀 규모와 제 역할, 기간을 명확히 적습니다. 둘째, 화면 캡션에 '제가 설계한 플로우', '팀원과 함께 정리한 컨셉'처럼 담당 범위를 구분해 표기합니다. 셋째, 제가 하지 않은 부분도 왜 그렇게 결정됐는지는 설명할 수 있도록 준비해 둡니다. 과장하면 면접에서 바로 드러난다고 생각하고, 오히려 남의 아이디어를 어떻게 화면으로 잘 구현했는지도 충분히 역량이라고 봅니다. 협업 과정에서 제가 낸 의견과 그 결과를 구체적으로 쓰는 게 가장 신뢰를 주는 방법이라고 생각합니다.

세 가지 안을 놓고 비교했습니다. 기준은 문제 해결 직접성, 사용자 학습 부담, 구현 현실성이었습니다. 첫 번째 안은 대화형 챗봇이었는데 문제는 해결하지만 학습 부담과 개발 난이도가 컸습니다. 두 번째는 필터 강화였는데 기존 사용자 습관과 충돌이 적지만 핵심 원인은 그대로 남았고요. 최종으로 고른 세 번째 안은 재료 기반 추천 카드였는데, 기존 흐름을 크게 흔들지 않으면서 이탈 지점을 직접 건드릴 수 있었습니다. 포트폴리오에도 탈락한 안과 그 이유를 함께 남겨서 판단 과정을 보여줬습니다.

카페 브랜딩 프로젝트가 가장 아쉽습니다. 로고와 패키지 비주얼은 만족스러웠지만, 그 브랜드가 왜 그런 톤을 가져야 하는지 근거가 약했습니다. 타깃을 '20대 여성' 정도로만 잡고 실제 방문객을 관찰하거나 이야기를 들어보진 못했습니다. 다시 한다면 매장에 며칠 나가서 어떤 손님이 어떤 이유로 오는지 관찰하고, 경쟁 카페와의 인식 차이를 정리한 다음 톤앤매너를 정하겠습니다. 또 로고 하나로 끝내지 않고 실제 적용 상황을 여러 개 만들어 검증하고 싶습니다. 지금은 비주얼보다 근거가 먼저라는 걸 배웠습니다.

5분이면 프로젝트를 두 개로 줄이고, 각 프로젝트를 문제, 판단, 결과 세 덩어리로 말하겠습니다. 남길 것은 문제를 왜 그렇게 정의했는지, 그리고 방향이 바뀐 결정적인 순간, 마지막으로 그 결정이 화면에서 어떻게 드러났는지입니다. 덜어낼 것은 리서치 방법의 세부 절차, 컬러나 폰트 선정 과정, 그리고 모든 화면을 다 보여주는 부분입니다. 대신 세부 내용은 뒤에 부록으로 준비해서 질문이 들어오면 바로 펼칠 수 있게 하겠습니다. 발표는 궁금증을 만들고 질문에서 깊이를 보여주는 게 낫다고 생각합니다.

제 프로젝트들은 대부분 사용자 불편에서 출발했고, 그 불편을 해결하면 서비스에 어떤 이득이 있는지까지는 연결하지 못했습니다. 예를 들어 온보딩을 간소화했지만 그게 가입 전환이나 리텐션 중 어떤 지표를 움직이는지는 정의하지 않았습니다. 또 개발 리소스나 운영 부담 같은 제약을 고려하지 않아서 실무에서는 채택되기 어려운 안도 있었을 겁니다. 실무에서는 문제 정의 단계에서 '이걸 해결하면 어떤 지표가 얼마나 개선될 것으로 기대하는가', '지금 조직이 감당할 수 있는 범위인가'를 함께 확인해야 한다고 생각합니다. 그 관점을 빠르게 익히고 싶습니다.

먼저 어떤 지점에서 헷갈릴 것 같다고 느끼셨는지 여쭙고 싶습니다. 제가 놓친 사용 맥락이 있을 수 있기 때문입니다. 제 근거는 5명 사용성 테스트에서 해당 화면에서 멈추는 사람이 없었고, 첫 과업 완료 시간이 기존 안보다 짧았다는 점입니다. 다만 표본이 적고 참가자가 20대에 몰려 있어서 다른 연령대에서는 말씀하신 혼란이 생길 가능성이 충분히 있다고 봅니다. 그래서 제 주장을 고집하기보다, 지적해 주신 부분을 가설로 놓고 기존 방식과 나란히 비교 테스트를 해서 확인하고 싶습니다. 결과가 반대로 나오면 방향을 바꾸는 게 맞다고 생각합니다.

먼저 반대의 이유를 개발 리소스, 일정, 정책 중 어디에 있는지 구분해서 듣겠습니다. 그다음 제 안을 통째로 지키려 하지 않고, 문제 해결에 꼭 필요한 핵심과 있으면 좋은 부분으로 쪼개겠습니다. 예를 들어 재료 기반 추천에서 자동 인식 기능은 개발 비용이 크니 1단계에서는 사용자가 직접 선택하는 형태로 낮추고, 효과가 확인되면 다음 단계에서 확장하자고 제안하는 방식입니다. 이때 왜 이 부분이 핵심인지는 리서치와 테스트 근거로 설명하겠습니다. 결국 제 시안을 지키는 게 목표가 아니라 문제를 실제로 줄이는 게 목표라고 생각합니다.

처음 작업들은 '보기 좋은가'가 기준이었습니다. 레이아웃과 컬러에 시간을 가장 많이 썼고, 왜 그렇게 했느냐는 질문에 감각적으로만 답했습니다. 두 번째 시기에는 사용성 테스트에서 제 시안이 무참히 막히는 걸 보면서 기준이 '이해되는가'로 옮겨갔습니다. 그때부터 문제를 문장으로 적고 시작하는 습관이 생겼습니다. 최근 프로젝트에서는 '이 개선이 서비스에 어떤 의미인가'까지 생각하려 했습니다. 아직 비즈니스 관점은 부족하지만, 지금 제 기준은 근거로 설명되고 사용자 행동으로 확인되는 디자인이어야 한다는 것입니다.

직접 써보면서 느낀 점을 기준으로 가설을 세우겠습니다. 저는 첫 사용 이후 다시 들어올 이유를 찾기가 어렵다고 느꼈는데, 이걸 '재방문 동기가 화면에서 드러나지 않는다'는 가설로 두겠습니다. 다만 이건 제 한 사람의 인상이라 순서상 먼저 검증이 필요합니다. 그래서 앱 리뷰와 커뮤니티 언급을 모아 같은 문제가 반복되는지 확인하고, 실제 이용자 몇 분을 인터뷰해 이탈 시점을 듣겠습니다. 그 뒤에 문제를 한 문장으로 좁히고 개선안을 두세 개 만들어 프로토타입 테스트로 비교하겠습니다. 내부 데이터를 볼 수 없다는 한계는 명확히 적어 두겠습니다.

팀 프로젝트에서 정보를 다 보여달라는 요청을 반영하다 보니 카드 안 요소가 너무 많아져서 정작 핵심 정보가 안 읽히게 됐습니다. 저는 그때 제 느낌만 말하기보다, 처음 안과 수정 안을 같이 띄우고 '사용자가 3초 안에 가격을 찾을 수 있는지'라는 기준으로 팀원들에게 직접 찾아보게 했습니다. 다들 수정 안에서 더 오래 걸리는 걸 확인하고, 정보를 다 넣는 대신 상세 페이지로 넘기는 방향으로 합의했습니다. 되돌리는 제안도 근거가 있으면 충분히 받아들여진다는 걸 배웠습니다.

저는 반대부터 하지 않고, 그 요청이 해결하려는 목적을 먼저 확인합니다. 예를 들어 배너를 더 크게 키워달라는 요청이면 목적은 노출이니, 크기를 키우는 대신 위치나 색 대비로 시선을 끄는 대안을 함께 제시합니다. 그리고 요청대로 하면 어떤 리스크가 있는지, 이탈률이나 접근성 기준 같은 근거를 들어 공유합니다. 그래도 그대로 가기로 결정되면 저는 따르되, 나중에 성과를 함께 확인해서 개선 근거로 삼자고 제안합니다.