brunch

You can make anything
by writing

C.S.Lewis

by 허지인 Oct 03. 2022

프로덕트 디자이너의 디자인 QA

어떻게 해야 QA를 잘할 수 있을까? 고민하는 글

들어가기 전

이 글에서 언급하는 QA는 기획과 개발 단계서부터 참여하는 QA팀의 업무가 아닌 제품 배포 전, 프로덕트 디자이너의 디자인 QA 리뷰(이하 QA로 통일)를 의미한다. 몇 개의 제품을 배포하면서 진행했던 디자인 QA의 느낀 점을 공유하고자 한다.




첫 번째

내 디자인은 피그마가 아니라 퍼블리싱 화면에 있다.


디자이너는 피그마에 있는 디자인보다 퍼블리싱되어 나온 화면이 내 디자인이다라고 생각해야 한다. 그만큼 디자인 QA에 책임을 가지고 가야 한다는 의미다. 내가 어떻게 디자인했는지는 나밖에   없으며, 디자인만큼은 누가 챙겨주지 않기 때문이다.


사용자는 물론이고, 회사 내부 크루들도 퍼블리싱되어 나온 화면을 그대로 디자이너의 작업물이라고 인식한다. 그러니 디자인 QA를 진행할 때는 눈을 부릅뜨고 샅샅이 다른 UI 디자인은 없는지, 설계한 플로우로 진행되는지 체크해야 한다.


물론 사람인지라 작은 부분만큼은 모든 것을 QA기간 내에 못 알아차릴 수도 있다. 하지만 그런 부분들이 많을수록 나중에 수정 요청하는 횟수도 많아질 거고, 큰 이슈가 아닌 이상 우선순위에서 밀려 엄청 나중에야 수정이 들어갈 수도 있다. 


그때까지는 사용자는 그 이슈 있는 화면을 그대로 사용하고 있는 거니까, 되도록이면 적은 횟수에 걸쳐 수정하도록 하자.



두 번째

당연히, 어련히 '잘' 작업되는 것은 없다.


개인적으로 디자인 QA 리뷰를 꼼꼼하게 하는 방법은 "당연한 건 없다"라는 마인드를 가지는 것이다.


디자이너는 피그마에 디자인도 다 했고, 인터랙션에 대한 코멘트도 남겼으며, 케이스 별로 대응할 수 있는 디

자인도 다 작업해뒀으니, 내가 설계해둔 대로만 개발되기만을 기다릴지도 모른다. 당연하게.


하지만 종종 설계와는 다른 화면을 본 적이 있지 않은가?


이 경우는 두 가지 케이스가 있다.

1. 프론트엔드 개발자 혹은 퍼블리셔가 내가 작업한 화면 및 코멘트(당연히 봤을 거라 생각한)를 놓쳤거나.
2. 내가 (당연히) 넣었을 거라고 생각했는데 누락했거나.


1,2번 둘 다 역량이나 능력을 떠나서 사람이니까 발생할 수도 있는 일이다. 1번 같은 경우는 언급 후, 수정 요청을 하면 되는 부분이고, 2번은 내 영역이기에 다음에 내가 더 조심하고 주의하면 되는 부분이다.


그러니 당연하게 프론트엔드 개발자와 퍼블리셔가 내 피그마를 샅샅이 확인하고 체크했을 거라는 생각은 말고,

나 또한 빠짐없이 모두 다 설계했을 거라는 생각은 하지 않는 것이 좋겠다.


그렇게 생각하고 나면, 개발자에게 작업물을 넘길 때도 한번 더 점검하여 추후에 발생하는 수정 요청을 줄일 수 있을 것이고, 또한 개발 후 디자인 QA리뷰를 할 때도 내 의도와 맞게 설계가 되었는지 A부터 Z까지 샅샅이 비교할 수 있을 것이다.



세 번째

작업 시 '만약에 사용자가 ~게 사용하면 어떻게 될까?' 생각하기


위에 '나 또한 빠짐없이 모두 다 설계했을 거라는 생각은 하지 않는 것이 좋겠다.'라는 말의 연장선이다.

무슨 말이냐 하면, 제품을 디자인할 때 '만약에' 케이스를 많이 생각해 보는 것이다. 특히 사용자가 컨트롤을 하는 플로우나 기능에서는 말이다.

검색, 필터 및 정렬, 내 정보 수정, 장바구니, 쿠폰 적용, 글쓰기 등 


사용자가 개입되지 않는 플로우에서는 우리가 예상하는 대로 플로우가 전개될 수 있고 그렇지 않다고 하더라도 대응 케이스가 많지 않기 때문에 비교적 쉽게 설계할 수 있지만, 사용자가 개입되는 플로우나 기능에서는 그 수가 적다고 하더라도 우리의 예상에 벗어나는 케이스가 많이 발생할 수 있기 때문이다.


이걸 설명하기 위해 이번 3월에 릴리즈 된 쿠폰 적용 기능을 소개하고 싶다.


우리 커머스에서는 장바구니 화면, 구매하기 화면에서 쿠폰을 적용할 수 있다. 사용자의 구매 프로세스가 [상품 상세페이지에서 상품을 확인] > [옵션을 선택해서 장바구니에 넣고] > [장바구니에서 구매할 물건만 추린 뒤] > [구매하기에서 배송지, 결제 방법 설정 후 구매 완료하기] 라면 장바구니 화면, 구매하기 화면 2개의 화면에서 쿠폰을 적용할 수 있는 것이다.  


내가 간과했던 '만약에' 케이스는 "만약에 사용자가 쿠폰 적용 후 쿠폰 적용 취소를 하면 어떻게 될까?"였다. 너무 당연하게 생각할 수 있는 케이스인데도 불구하고 생각하지 못했다. 놀랍게도 실화..


문제는 QA기간에 발생됐다. 쿠폰 적용 페이지의 CTA 버튼은 '쿠폰 적용하기' 버튼이다. 나는 쿠폰을 선택해야 만 CTA 버튼이 활성화되는 정책을 설정했었다. 들었을 때는 문제가 되지 않는 정책인 것 같다. 장바구니 화면에서 쿠폰을 선택하고 적용하는 것 까지는 말이다. 


하지만 장바구니에서 쿠폰을 선택한 사용자가 장바구니나 구매하기 화면에서 쿠폰 선택을 해제한다면 CTA 버튼은 어떻게 되어야 할까? 쿠폰을 선택하지 않았음에도 버튼은 활성화를 유지해야 한다. 하지만 내가 정한 정책으로 쿠폰을 해제해도 버튼은 활성화되지 않았다.

버튼 활성화 정책은 쿠폰 선택 시 활성화가 아니라, 쿠폰 상태 변경 시 활성화로 했어야 하는 것이다.

(세세하게 챙길 수 없다면 활성화 정책을 없애고 열어두는 것도 방법이다..)


QA기간이라 정책을 변경할 수 있었지만, 디자인 작업 시에 더 디테일한 케이스를 설정했더라면 프론트엔드 개발자 분이 고생을 하지 않았을 텐데 아쉬움이 남는다. 비모.. 죄송합니다..


여하튼, 그 이후 사용자가 컨트롤하는 기능을 디자인할 때는 다양하게 질문을 던져보고 케이스를 쪼개려고 노력한다.

상태별, 시기별, 조건별 등등 중요한 건 계속 물어보는 일이다.

여러분도 나 같은 실수 하지 마시고, 지속적으로 기능과 플로우에 물음표를 던져보시라.


'만약에 사용자가 첫 정보 입력 시 이탈을 하면 어떻게 될까? 만약 수정 시 이탈을 한다면?'
'만약에 사용자가 A, B를 설정했다가 A, C로 바꾸고 싶어 하면 어떻게 할까? A 설정은 오래 걸리는데..'
'만약에 사용자가 A, B, C'를 취소했다가 다시 설정하고 싶어 한다면?


묻다 보면 케이스 나누기는 물론이요, 더 좋은 경험을 주기 위한 하나의 아이디어도 생길지 모른다.






QA를 잘하고 싶어서 작성해본 글이다. 적다 보니 아직 배울 점이 많다고 느낀다. 

더 넓고 다양한 시각에서 쪼개는 버릇을 들여야 한다는 생각이 든다. 이러한 경험에 대해서 조언을 주고 싶은 분들이 있다면 댓글로 해주시길 바란다. 의견은 언제나 환영이다. =)


아래 글은 글 작성 시 도움이 된 글 리스트이다.



매거진의 이전글 프로덕트 디자이너 이직
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari