이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
금융 앱 과제에서 트레이딩뷰를 직접 사용하면서 어떤 컴포넌트로 구성됐는지 분해해서 정리한 경험이 있습니다.
차트 툴바, 캔들스틱, 지표 레이어, 그리기 도구로 분류하였는데, 처음에는 툴바 아이콘이 너무 많아서 초보자가 어디서 시작해야 하는지 모르겠다는 문제가 보였습니다. 제 설계에서는 자주 쓰는 도구 3개는 항상 노출하고, 나머지는 '더 보기'로 접는 방식을 사용하였습니다. 프로토타입 테스트에서 주식 투자 입문자 3명이 '뭘 눌러야 하는지 바로 보인다'는 반응을 보였습니다.
이 경험에서 전문 차트 도구일수록 기능이 많아서 우선순위 설계가 중요하다는 것을 배웠습니다. 모든 기능을 보여주는 것이 아니라 사용 빈도에 따라 노출 수준을 다르게 해야 한다는 점도 깨달았습니다.
개인 포트폴리오 프로젝트로 모바일 차트 앱을 설계할 때, 초보 투자자와 단타 트레이더가 원하는 기능이 완전히 다르다는 걸 발견했어요.
주변 2명(입문자, 경력 3년)을 인터뷰했는데 입문자는 '보조 지표가 너무 많아서 뭘 봐야 할지 모르겠다'고 했고, 경력자는 반대로 '지표가 없으면 불편하다'고 했습니다. 이 둘을 한 화면으로 해결하려니 어느 쪽도 만족 못 하는 구조가 됐어요. 온보딩에서 '간단히 보기 / 전체 보기'를 선택하게 했더니 각각에 맞는 인터페이스를 제공할 수 있었습니다.
이 경험에서 차트 UI는 기능 수보다 누가 사용하느냐에 따라 설계 방향이 완전히 달라진다는 걸 배웠어요. 타겟 사용자를 먼저 정의하면 기능 우선순위가 바로 보인다는 것도요.
수업 과제에서 모바일 주식 차트 앱을 설계하면서 핀치 줌 기능을 넣었는데, 테스트에서 문제가 생긴 경험이 있어요.
핀치 줌을 넣었더니 참가자 2명이 화면 전체를 줌인하려다가 차트 데이터가 줌인되는 게 혼란스럽다고 했습니다. 차트 영역 줌과 시스템 화면 줌이 충돌했던 거예요. 차트 영역을 가로로 드래그해서 기간을 조정하는 방식으로 변경하니 참가자들이 '이쪽이 더 자연스럽다'는 반응을 보였어요.
이 경험에서 모바일 차트 인터랙션은 일반적인 앱 제스처 규칙과 충돌할 수 있어서 별도로 테스트해봐야 한다는 걸 배웠어요. 익숙한 제스처가 새로운 맥락에선 혼란을 만들 수 있다는 것도요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.