QA 담당자가 생각하게 하지마!
좋은 설명서가 아닌, 설명서가 없어도 쓸 수 있는 제품을 만들 것
Last updated
좋은 설명서가 아닌, 설명서가 없어도 쓸 수 있는 제품을 만들 것
Last updated
MVP 스펙을 구체화하고, 프로토타입으로 솔루션 검증 인터뷰까지 진행하던 우리 팀은, 처음 생각했던 스펙보다 더 스펙을 추가해야할지 고민에 빠지게 됐다. 그러던 중 대표님께 약 2주의 기획 내용을 보고하는 미팅을 갖게 되었다.
린캔버스에 이어 IA를 열심히 그리며 기획을 하고 있었기 때문에, 초기 기획부터 고객의 사용 방법까지 발표를 차근차근 진행하려고 했다. 그러나 사용자가 처음 가입하고 로그인하는 부분을 설명하던 중 대표님이 말씀하셨다. "그런 건 다 알아서 잘 하셨겠죠. 그래서 어떻게 써야돼요?" 이 회의의 목적이 무엇인가?를 항상 생각하면서 핵심만 짚어야 한다는 생각이 순간 퍼뜩 들었다. 부랴부랴 프로토타입을 보여드리며 녹화를 켜고 QA를 한 후 녹화를 종료하는 플로우를 보여드렸다.
프로토타입을 간단하게 보여드리고, 가이드가 필요하리라 생각해 가이드 페이지가 따로 있다고 말씀드렸을 때 해주신 말씀이 확 와닿았었다.
선풍기를 딱 보면 그냥 이렇게 쓰면 되겠네하고 버튼을 누르게 만들어야지 '이건 어떻게 쓰는 거지? 하고 설명서를 봤는데 이야 설명서 잘써놨네! 이해가 아주 잘되네!' 하면 안된다
사실 여기서 더 앞뒤로 기능이 추가되어야하는 것이 아닐까 하는 고민을 하고 있던 우리에게, '너무 복잡하다는' 말씀은 신선한 충격이었다. '진짜 고객이 원하는 게 뭘까?'라는 관점에서 그들이 이 서비스를 어떻게 사용할까?를 고민하는 것이 핵심이었다는 생각이 들었다. 우리 고객들은 QA를 빨리 끝내고 본업으로 돌아가고 싶어한다. 그런 관점에서 서비스는 더욱 간편하고, 시간을 절약시켜줄 수 있는 서비스가 되어야 했다.
그렇게 기존의 스펙을 유지하면서, 어떻게 하면 사용자가 고민 없이, 빠르게 사용하게 할 수 있을까를 다시 고민하게 됐다. 우선 가장 큰 뼈대가 되는 IA를 먼저 수정했다. 전과 후의 가장 큰 차이점은 페이지 하나를 아예 없앴다는 것이었다.
기존에는 사용자가 버그 리포팅을 위한 파일을 저장하고 나면 각각을 수정하기 위해 편집 페이지로 이동해야했는데, 이를 따로 페이지로 넣지않고, 모든 파일을 한 곳에서 보고 편집할 수 있도록 수정했다. 이렇게 비교해보니 구조를 바꾼 것이 돌아보니 아주 중요한 결정이었다는 생각이 다시 든다.
그렇게 수정된 IA에 맞춰 와이어프레임도 수정하는 과정에서, 또 다시 책의 도움을 구하게 되었는데, 아래 두 개의 책을 많이 참고했다.
가장 기억에 남는 부분은 아래 부분이었다. 우리는 기획하고 디자인하는 과정에서 너무 많이 고민하고, 너무 자주 본 나머지 '그렇게 복잡하지 않은데?' '이 정도면 찾겠지'라는 생각을 하곤 하는데, 완전히 처음 보는 고객의 입장은 전혀 다르다는 것이었다.
첫 번째 진실 : 사용자는 웹 페이지를 읽지 않는다. 훑어본다 두 번째 진실 : 사용자는 최선의 선택을 하지 않는다. 최소 조건만 충족되면 만족한다 세 번째 진실 : 사용자는 작동방식까지 이해하려 하지 않는다. 적당히 임기응변한다
특히 우리 서비스가 해결하고자 하는 QA 분야의 QA 담당자들은 더욱 시간에 쫓기는 상황이기 때문에, 복잡해보이는 서비스라면 시도조차 해보지 않을 가능성이 높았다. 우리는 이제 정말 고객의 입장에서, 페이지마다, 사용자가 하고자하는 행위에 맞게 '의문점 없이' '명료하게' 방법을 찾을 수 있는지의 관점에서 와이어프레임을 뜯어 고칠 수 있었다.
그 결과, 그냥 봐도 복잡하게 느껴지던 파일 페이지가, 훨씬 간결하게 바뀌게 되었다. 이후 고객분들도 항상 해주시던 피드백도 '디자인이 간결하고 직관적이다'라는 말씀을 많이 해주시게 되었다.
다른 툴들과 다르게, 이슈 저장 시 이미지와 앞뒤 10초씩 총 20초의 영상이 동시에 저장되는 서비스였기 때문에 개인적으로는 기존 데스크탑에서 그러한 것처럼 파일 확장자명으로 이미지, 영상을 구분해서 볼 수 있도록 하는 의견도 있었지만, 너무 보기 어려울 것 같다는 우려로 기각되었다. (아주 잘한 선택인 것 같다) 그렇게 여러 고민 끝에 한 페이지에서 이미지와 영상을 모두 보고 편집할 수 있는 구조를 최대한 간결하게 만들게 됐다!
이렇게 와이어프레임을 만들고, 디자인도 진행이 되고 있다보니 우리는 이미 완전히 특정 '페이지' 단위로 아주 자세한 기획을 다루고 있었다. 굉장히 세세한 나무 하나하나를 자세히 보고 있었던 것이다. 하지만 동시에 그 다음에는 무엇을 해야하는지에 대해서도 생각을 해야했다. 늘 차고 넘치는 '백로그' 관리가 관건이었던 것이다. 이 지점에서는 IA를 백로그를 정리하는 용도로 쓰기에는 적합하지 않고, 와이어프레임은 너무 자세하고, 어떻게 가시성을 높여서 계획을 정리할 수 있을지가 고민이었다. 이번에도 책의 도움을 많이 받았는데 이번에는 '사용자 스토리 맵 만들기'라는 귀여운 노란색 책이었다.
다양한 이해 관계자들이 실제로 포스트잇에 사용자가 필요로 하는 단계들을 적어 나가면서 중요도에 따라 분류하고, 과정을 정의하고, 백로그를 분류하는 과정을 사례로 들어 제품을 만드는 과정을 설명하는 책이다. 실제로 포스트잇에 적어서 우리도 벽에 포스트잇을 붙여보기도 하면서 스토리 맵을 만들어 갔다.
처음에 화이트보드에 포스트잇으로 붙였던 것을 그대로 피그잼으로 옮겨서 정리한 후, 계속해서 업데이트해나갔다. 특정 기능이 완성된 후에 들어갈 수 있는 것들을 이어서 표시하니, 노션에서 백로그를 정리하던 때보다 더 가시성 높게 백로그 관리가 가능했다.
그렇게 솔루션을 수정한 후, 개발을 진행하게 되었다. 프론트 사이드에서는 우리 페이지 외에도 크롬 익스텐션 작업이 있었고, 백엔드는 영상 파일 처리로 복잡도가 높다보니 작업이 쉽지 않았다. 최대한 돕고 싶은 마음에 GPT에 물어가며 코딩도 잠시 하게 되었다. 이 시절 문제 해결을 위해서 고민하다가 집가는 길에 난 생각을 테스트해보기 위해서 밤새 코드를 붙잡고 있거나 주말에 출근해 밤을 새기 일쑤였다. 쉽지 않은 일들이었지만, 돌아보면 소소한 추억이 되는 것 같다.
그런데 이렇게 서비스를 열심히 만들수록, 그만큼, 아니 그보다 더 중요한 '고객'을 모으는 일이 시급해져갔다. 아무도 안 쓸 서비스를 열심히 만드는 것만큼 허무한 일도 없기 때문이다. 우리는 어떻게 QA 담당자들을 모셔올 수 있을지를 머리를 싸매고 고민하게 됐다.
