면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
프로토타입 제작에는 주로 Figma를 씁니다. 협업 기능이 강력해서 팀원이 실시간으로 같은 파일을 보고 피드백을 남길 수 있습니다. 인터랙션 프로토타입은 Figma의 프로토타입 기능으로 대부분 처리하고, 복잡한 애니메이션이 필요한 경우에는 ProtoPie를 추가로 씁니다. 툴을 선택하는 기준은 「어떤 것을 검증하려는가」입니다. 플로우 검증에는 간단한 클릭 프로토타입으로 충분하고, 세밀한 인터랙션이 필요한 경우에는 더 고도화된 툴이 필요합니다.
목적에 맞지 않는 툴을 쓰면 제작 시간만 늘어나고 피드백의 질이 높아지지 않습니다. 개발팀에 전달할 때는 Figma 링크 하나로 소통이 되는 것도 장점입니다.
Figma 프로토타입을 실제 사용자 테스트에 활용했을 때 어느 툴로 만들었느냐보다 무엇을 검증하려는지가 더 중요하다는 것을 배웠습니다. 온보딩 플로우를 Figma 클릭 프로토타입으로 만들고 5명에게 테스트했을 때, 3명이 같은 버튼에서 멈추는 것을 발견했습니다. 버튼 레이블을 바꾼 후 재테스트에서 그 지점의 오류가 사라졌습니다.
ProtoPie로 전환한 것은 제스처 인터랙션 검증이 필요한 경우뿐이었는데, 그때도 검증 목적을 먼저 명확히 하고 툴을 선택했습니다. 툴의 기능이 많을수록 제작 시간이 늘어나고 정작 검증에 집중하지 못하는 경우가 있었습니다. 가장 빠르게 검증 가능한 수준의 충실도를 선택하는 것이 좋은 프로토타이핑이라고 생각합니다.
프로토타입 툴을 선택할 때 팀 안에서 어떻게 전달되는지를 가장 먼저 고려합니다. 학부 프로젝트에서 XD로 작업했을 때, 개발 담당 팀원이 스펙을 확인하려면 파일을 직접 보내야 했고 버전이 맞지 않는 문제가 있었습니다. Figma로 바꾼 이후 링크 하나로 최신 버전을 공유할 수 있게 됐고, 개발팀이 직접 수치와 색상 값을 확인했습니다. 핸드오프 단계에서 왔다 갔다 하는 커뮤니케이션이 눈에 띄게 줄었습니다.
협업 효율이 올라가면 설계에 더 집중할 수 있는 시간이 생긴다는 것을 그때 처음 체감했습니다. 툴은 만드는 도구이기도 하지만 소통하는 도구이기도 해서, 팀 환경에 맞는 선택이 중요합니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.