QA 툴이 탄생하는 과정 - 2탄
스케치와 검증의 연속
유저 스토리맵 구축
유저 인터뷰를 진행하면서 유저 스토리맵과 IA를 구축하기 시작했어요. 저번 책 소개 편에서 언급했던 '유저 스토리맵 만들기'를 참고하며 PO님과 함께 만들었어요.
처음에는 회의실의 큰 화이트보드에 포스트잇을 나열했어요. 스토리맵을 짜기 전, 먼저 '( )인 나는 ( )하고 싶다. 그래서 ( )하길 원한다.' 구절을 써 붙였어요. 그리고 (1)우리 주요 타겟이 누군지, (2)그 타겟이 느끼는 현재 문제점과 (3)QAing이 제공하는 주요 가치, 그리고 (4)QAing이 미래에 어떤 가치를 실현할 수 있는지를 먼저 정리했어요. 스토리맵을 짜기 전 이렇게 주요 정보를 정리해두면, 우리 서비스의 주요 타겟에 적합한 스토리를 만들면서 방향성을 잘 유지할 수 있어요.
처음 유저 스토리맵을 작성할 때는 깊이 보다 너비가 더 중요해요. 저희도 각 단계마다 너무 디테일한 부분까지 깊게 들어가려 하지 않고, QA의 전반적인 과정의 시작부터 끝까지 최대한 빠뜨리지 않고 작성하려 했어요.
큐에잉의 첫 유저 스토리 맵가장 첫 줄은 유저가 우리 서비스를 이용하는 큰 단위의 활동 단계를 나열해요. 큐에잉의 경우에는 랜딩페이지 -> 가입 및 로그인 -> 사전정보 입력 -> 메인 페이지... 등이 될 수 있겠죠.
두번째 줄은 내부적인 단계를 의미해요. 첫 줄의 '활동'보다 조금 더 구체적인 정보죠. 각 활동 단계에서 유저가 어떤 활동을 하는지를 적어요. 큐에잉은 '가입 및 로그인'='구글계정으로 시작하기' 클릭 -> 구글 계정 선택..이 될 수 있겠죠. 여기서 주의해야 할 점은 유저가 하는 행위를 적어야 한다는 점이에요. 서비스상에서의 어떤 액션이나 피드백 말고, 유저가 무엇을 읽고 누르고 보게 되는지를 적어요.
셋째 줄에는 세부사항을 적어요. 가령 큐에잉의 '이슈 공유' 단계의 세부사항으로는 썸네일 위 링크복사/미리보기 모달에서 링크복사 -> 노션 임베드/슬랙 공유/스프레드시트 붙여넣기... 가 되겠죠.
피그잼에서 더욱 확장중!이렇게 전반적인 과정을 나열한 다음, 저희는 피그잼으로 옮겨 더 상세하게 작업했답니다. 아래에는 '백로그' 섹션을 추가해서 각 단계에서 나중에 추가되면 좋을 기능, 추가 예정인 부분들을 같은 형식으로 기록해두었어요.
이렇게 유저 스토리맵을 적고 기획단에 변화가 있을 때마다 PO님께서 업데이트를 해주고 계신답니다!
전체적인 플로우를 한 눈에 볼 수 있고, 디자이너인 저는 이 맵을 통해 플로우에서 허들이 있는 부분이 있는지, 끊기는 부분이 있는지 확인하기도 해요. 또 팀원들 간 공유된 이해를 구축하는 데도 큰 도움이 돼요.
IA 구축
큐에잉의 IAIA는 저희 PO님께서 만들어 주셨는데요, 서비스의 뎁스를 빠짐없이 꼼꼼히 적는 것도 물론 중요하지만 모든 팀원들이 이해하기 쉽게 만드는 것도 아주 중요하구나를 배울 수 있었어요.
일반적으로 인터넷에 IA를 검색하면 보게 되는 템플릿들이 있는데, 사실 그런 템플릿들은 서비스가 커지면 커질수록 직관적으로 보기가 어렵더라구요.
저희 PO님께서는 아주 깔끔하게 정리해주셔서 저를 포함한 팀원들이 한 번에 알아보기가 너무 편했던 것 같아요 ㅎㅎ 이렇게 내부 페이지/모달/외부페이지/인풋/버튼..을 직관적으로 표현해주셨어요. IA를 단순히 나열하기 보다는, 미로그인 상태/가입 과정/로그인 상태 혹은 각 프로덕트에 맞는 플로우로 구분해두면 더욱 보기가 편리해요.
타겟의 변화
이렇게 스토리맵과 IA를 만들고 유저 인터뷰를 지속하다 보니, 타겟을 다시 정의해야겠다는 결정을 하게 되었어요. 처음 저희가 정의한 주요 타겟은 IT 중소 스타트업의 PM, 디자이너, 개발자였어요(IT 중소 스타트업인 이유는 규모가 있는 기업은 주로 QA팀이 따로 있거나 자동화 툴을 사용하고 계시기 때문이었어요).
그러나 인터뷰를 하다보니 개발자분들은 저희 서비스의 니즈에 맞지 않는다는 걸 알게 되었어요. 아무래도 주로 공유를 하기보다는 받는 경우가 더 많고, 오류 상황의 코드나 로그 기록에 대한 니즈가 크다는 것을 느꼈어요. 아직 저희 서비스가 바로 제공해드릴 수 있는 부분이 아니다 보니, 타겟은 PM과 디자이너로 더 좁히게 되었어요.
그러던 중, 우연히 QA 엔지니어 몇 분을 인터뷰하게 되었는데, 생각보다 우리 서비스를 잘 사용하실 수 있겠다 싶은 지점을 발견하게 되었어요! 저희는 QA 전담팀이 있는 경우엔 다 자동화로 돌리는 걸로 알고 있었는데, 알고 보니 간단한 QA를 할 때는 직접 수동으로 병행하시는 경우도 많더라구요. 수동 QA를 하실 때 저희 서비스를 이용하실 수 있겠다 싶어 타겟을 PM > 디자이너 > QA 엔지니어 순으로 정의했어요.
유저 인터뷰를 꾸준히 진행하면서 저희가 정의한 주요 타겟을 검증해나갔던 것 같아요.
저희 QAing의 성장 스토리는 다음 화에서 또 전해드리도록 할게요!
여러분의 QA 시간을 획기적으로 줄여줄 서비스, QAing을 지금 바로 사용해보세요!
