David.Cheon
UIpac
David.Cheon
  • UIpac (647) N
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (64) N
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (33) N
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352) N
      • Weekly Curation (251)
      • Performing Arts (17) N
      • Collection (6)
      • Books (0)
      • Life (78) N

인기 글

Tags

  • 애플리케이션
  • daumkakao
  • 다음카카오
  • Curation
  • trend
  • 가트너
  • UI
  • Gartner
  • 모바일
  • 기획
  • 2015
  • 디자인
  • 사이트
  • UX
  • 반응형웹
  • 트랜드
  • Mreport
  • 디자인참고
  • 세계 게임시장 규모
  • 큐레이션
  • 트렌드
  • 벤치마킹
  • 사물인터넷
  • 인공지능
  • 동향
  • 분석
  • 기획참고
  • 유니티
  • 2014
  • 웨어러블

최근 댓글

방명록

전체 방문자
오늘
어제
hELLO · Designed By 정상우.
David.Cheon

UIpac

Planning · PM/일하는 방법

프로토타이핑 도구 고르는 기준

2020. 6. 9. 00:52

 

 

프로토타이핑 도구는 정말 많아서, 새로 시작하려는 분들이 "뭘 써야 하나요" 하고 자주 물어보세요.
저도 처음에는 평이 좋은 도구부터 깔아 보다가 시간을 꽤 썼습니다.
그러다 알게 된 건 도구 이름보다 먼저 정해야 할 기준이 있다는 점이었어요.
그래서 특정 제품을 추천하기보다, 제가 도구를 고를 때 쓰는 기준을 정리해 보려고 합니다.

 

같은 프로토타입이라도 보여 줄 대상에 따라 필요한 수준이 달라집니다.
팀 안에서 구조를 빠르게 합의하는 용도라면 손으로 그린 스케치도 충분해요.
개발자에게 넘길 용도라면 간격과 상태 정의가 정확해야 하고, 사용자 테스트용이라면 눌렀을 때 실제처럼 반응해야 합니다.

가정 예시를 들어 볼게요.
새 가입 화면의 단계를 줄이는 아이디어를 팀에 설명해야 한다고 해 보죠.
이때는 화면 다섯 장을 종이나 단순한 도구로 그려서 화살표로 잇는 정도면 됩니다.
반대로 외부 사용자 다섯 명에게 가입을 시켜 보는 테스트라면, 입력과 버튼 반응까지 되는 도구가 필요해요.
목적이 정해지면 도구 후보가 절반쯤은 줄어듭니다.

 

충실도는 완성품에 얼마나 가까운가를 말합니다.
흑백 박스로 구조만 보여 주는 저충실도와, 색과 글꼴까지 입힌 고충실도로 나눌 수 있어요.
처음부터 고충실도를 만들면 보기에는 좋지만 수정 비용이 커지고, 회의가 구조 대신 색 이야기로 흘러가는 일이 많았습니다.

가정 예시로, 검색 결과 화면의 필터를 새로 기획한다고 해 보죠.
초반에는 필터가 위에 있을지 옆에 있을지, 항목은 몇 개일지만 박스로 그려 보면 됩니다.
구조가 정해진 뒤에야 선택된 필터의 표시 방식이나 결과가 없을 때의 문구 같은 세부를 올려요.
이 순서를 지키면 회의가 구조 논의와 디테일 논의로 나뉘어서 훨씬 깔끔해집니다.

정리하면 저는 초반에는 저충실도로 구조를 먼저 확정하고, 합의된 부분만 고충실도로 올리는 순서를 선호합니다.
도구를 고를 때도 저충실도에서 고충실도로 이어서 키울 수 있는지, 아니면 용도가 한쪽으로 고정되어 있는지를 확인합니다.

 

화면 전환만 되면 되는지, 입력값에 따라 분기가 되어야 하는지, 애니메이션까지 보여 줘야 하는지를 정해야 합니다.
인터랙션이 복잡해질수록 도구를 익히는 시간이 늘고, 만드는 시간도 늘어납니다.
특히 기획자가 직접 만들 때는 "이 정도 반응이면 충분하다"는 선을 먼저 긋는 편이 좋아요.

예를 들어 예약 시간 선택 화면이라면 이런 질문을 던져 봅니다.
날짜를 누르면 시간 목록이 바뀌는 것까지 보여야 하는가.
아니면 완성된 두 가지 상태를 나란히 놓으면 설명이 되는가.
후자로 충분한 경우가 생각보다 많았습니다.

 

혼자 쓰는 도구와 여럿이 함께 쓰는 도구는 선택 기준이 다릅니다.
여러 사람이 같은 파일을 보고 의견을 남길 수 있는지, 링크 하나로 공유되는지, 보는 사람이 별도 프로그램을 깔아야 하는지를 확인해요.
의견이 메신저나 메일에 흩어지면 나중에 반영 여부를 추적하기가 어려워집니다.

의견을 받는 방식도 도구 선택에 영향을 줍니다.
화면 위에 바로 코멘트를 남길 수 있으면 "여기 이 문구요"라고 설명할 필요가 없어서 피드백이 정확해져요.
반대로 코멘트 기능이 없으면 캡처 이미지에 화살표를 그려 메신저로 주고받게 되는데, 이 방식은 몇 번 오가면 어느 의견이 반영됐는지 알 수 없게 됩니다.

개발자에게 넘기는 단계도 중요합니다.
간격이나 색상 값을 확인하기 쉬운지, 화면 이미지를 뽑아 낼 수 있는지, 이전 버전으로 돌아갈 수 있는지를 봅니다.
이 기능이 부족하면 기획자가 화면 설명 문서를 따로 만들어야 해서 일이 두 번이 됩니다.

 

가장 현실적인 기준은 팀이 이미 쓰는 도구와의 궁합입니다.
좋은 도구여도 팀원 대부분이 낯설어하면 결국 기획자 혼자 쓰게 되더라고요.
무료로 쓸 수 있는 범위와 유료 전환 시 비용, 파일을 다른 도구로 옮길 수 있는지도 확인합니다.
나중에 도구를 바꾸게 될 때 작업물이 묶여 있으면 곤란하니까요.

체험 기간이 있다면 실제 업무 하나를 정해 그 기간에 끝까지 해 보는 것을 권합니다.
기능 목록을 비교하는 것보다, 내가 매일 하는 작업이 막힘없이 되는지를 보는 쪽이 정확해요.

체크리스트로 줄이면 이렇게 됩니다.
보여 줄 대상이 누구인지, 필요한 충실도가 어느 정도인지, 인터랙션이 얼마나 필요한지, 공유와 핸드오프가 편한지, 팀과 비용에 맞는지입니다.
다섯 가지에 답을 적어 두고 후보 두세 개를 직접 한 화면씩 만들어 보면 판단이 빨라집니다.

 

도구는 계속 새로 나오고 기능도 빠르게 바뀌기 때문에, 오늘의 정답이 내년에도 정답이라는 보장은 없다고 생각해요.
그래서 도구를 외우기보다 기준을 갖고 있는 편이 오래 갑니다.

한 가지 더 말씀드리면, 도구를 바꾸는 시기도 고려해야 합니다.
프로젝트 중간에 도구를 바꾸면 익히는 시간과 파일 옮기는 시간이 한꺼번에 들어서, 보통은 새 프로젝트가 시작될 때 바꾸는 편이 부담이 적었어요.

아직 답을 못 찾은 질문도 있습니다.
기획자가 어디까지 직접 만들고, 어느 지점부터 디자이너에게 맡기는 게 좋은지가 팀마다 달라서 계속 고민하고 있어요.
목업을 만들 때 지키는 원칙은 앞서 따로 정리했으니, 함께 보시면 도움이 될 거예요.

 

https://brunch.co.kr/@mmmangchi/17

저작자표시 비영리 변경금지 (새창열림)

'Planning · PM > 일하는 방법' 카테고리의 다른 글

분석 도구를 도입할 때 확인할 3가지  (0) 2020.08.12
화면정의서(스토리보드) 작성 노하우  (0) 2020.07.16
웹 서비스 기획 시행착오와 도구 정리 (1)  (0) 2020.06.09
목업 도구를 쓸 때의 원칙  (0) 2020.06.06
기획 메시지를 발전시키는 방법  (0) 2020.06.06

티스토리툴바