<주간 UIUX 디자인 : 디자인 qa>

디자인 qa 뜻부터 하는 방법까지, 현직 프로덕트 디자이너와 알아보기!

제로베이스 UIUX 디자인 스쿨

안녕하세요, 스타트업에서 프로덕트 디자이너로 약 2년째 근무 중인 이예서입니다. 저는 새로운 프로덕트들이 수없이 생겨나고 사라지는 스타트업 씬에서, 제품이 만들어지는 0 to 1 과정에 주로 참여해왔어요. 이 과정에서 제품의 목적에 따라 앱, 웹 등 다양한 환경에서 우리 팀이 만든 제품이 어떻게 보여지는지 꼼꼼히 확인하는 과정이 필요했는데요. 오늘은 이 과정 중 가장 애매하고, 소통 난이도가 높다고 느꼈던 디자인 QA 에 대해 소개해보려고 해요.

00ㅣ 디자인 QA(Quality Assurance)란?

디자인 QA란, 시각적인 UI 혹은 인터랙션 요소 등 디자이너가 최초로 의도한 미세한 디자인 요소들이 실제 개발된 화면에서 올바른 방식으로 구현되는지를 확인하는 프로세스를 의미해요.

내 Figma 화면에서 보여지는 이상적인 디자인은 문서를 아무리 잘 작성한다 해도, 기준이 되는 규격 1개만으로 완벽하게 디자이너가 원하는대로 프론트(개발 환경)에서 구현되기는 어려워요. 그래서 서비스가 출시되기 전 실제 구현된 테스트 버전과 내가 의도한 디자인에 차이가 있을 경우, 실제 개발 환경에서 어떤 것을 수정해야 하는지 개발자와 소통하는 과정이 필요해요. 이 모든 과정을 디자인 QA라고 부를 수 있어요.

디자인 관점에서 시각적으로 보여지는 것을 더 중점적으로 테스트한다는 점에서 기능 중심의 일반적인 QA와는 다르고, 이 때문에 만약 빠르게 제품을 내야 하는 조직이라면 우선순위에 따라 디자인 QA를 프로세스에 포함시키지 않는 등 조직의 상황에 따라 필수적인 과정으로 여기지 않을 수도 있어요.

01ㅣ 왜 디자인 QA가 필요할까요?

우리 제품이 고객을 만날 화면은 Figma가 아니라 실제 구현된 앱 혹은 웹이기 때문이에요. 간혹 Figma 화면에서는 괜찮았는데, 개발된 버전에서 원하는 화면이 나오지 않는 경우 디자이너의 책임이 아니라고 생각하는 경우도 있어요. 어떤 파트의 실수 혹은 전달 부족이든, 화면의 완성도를 정확히 판단하고 제대로 구현되지 않은 원인을 찾을 수 있는 것은 그 화면을 디자인한 디자이너이기 때문에 완성도에 책임감을 가지고 최대한의 구현을 위해 노력해야 해요. 작은 요소라도 일관성이 무너지면 제품에 대한 고객의 신뢰와 직결될 수 있어, 이 부분은 항상 명심하고 가져가는 것이 좋아요.

디자인할 때는 알지 못했던 멈춰있는 화면 밖의 오류들을 자세히 관찰할 수 있어요. 디자인할 당시에는 최대한 많은 케이스를 생각하고, 엣지 케이스까지 고려했다고 생각했지만 실제로 기능이 붙어 구동이 되는 테스트 버전을사용할 때는 최초에 생각하지 못한 많은 기획/디자인적 공백을 발견할 수 있어요. 특정 영역에 대한 실제 서버 호출 시간이 예상보다 짧거나 길어서 로딩의 형태가 적합하지 않거나, 실제 디바이스에서 테스트하니 일부 기기에서 터치 영역과 인터랙션 영역이 겹친다던가 하는 등의 문제들을 실제로 QA 기간에 발견했던 적이 있는데 이러한 오류들을 발견할수록 그때 발견한 오류와 동일한 관점에서 다른 화면을 보며 더 세밀하게 자체 점검을 할 수 있는 시각이 생기게 돼요.

이슈를 미리 파악하고 다음 스프린트의 우선순위를 계획하기 용이해요. 사실 MVP를 개발하는 조직에서는 작동상 오류가 있는 정말 크리티컬한 이슈가 아니라면, QA 과정에서 발견된 대부분의 이슈들(특히 디자인적인 이슈)은 *노운 이슈로 아카이브하고 당장 해결할 수 없는 경우가 많아요. 대신 간단하게라도 시스템을 만들어 디자인 QA를 함께 거친다면, 관련 화면 작업이 필요할 때 더 효과적으로 개발 리소스를 계획할 수 있어 조직의 갈등을 최소화하며 더 좋은 제품을 만드는 데 기여할 수 있어요.

*노운 이슈(Known Issue): 이슈가 있는 것을 알지만 방치하기로한 이슈

02ㅣ디자인 QA, 언제 진행할까요?

사전 점검: 시작하기 전에 알아두면 좋을 사항
위에서 간단히 언급했지만, 디자인 QA는 작은 조직의 경우 *스프린트의 필수 프로세스로 포함되어 있지 않을 때가 많아 팀에게 해당 과정을 기획해서 제안하거나 필요성을 설득해야 하는 경우가 생기곤 해요. 이 경우 사전 스프린트 기획 시 PM과 의논하여 조율하거나, 배포 전 QA를 준비할 때 함께 발제하면 좋아요. 디자인 QA에 참여해야 하는 포지션은 프로덕트 디자이너와 프론트엔드 개발자가 필수로 포함되어야 하고, 개발자가 판단했을 때 백엔드에도 영향을 미치는 일이라면 요청 시 다른 포지션의 인력들도 함께하는 것이 좋아요.

*스프린트(Sprint): 구글 수석디자이너 제이크 냅이 고안한 기획실행법으로, 팀원들과 토론을 통해 도출된 아이디어를 단기간 내에 프로토타입으로 제작하고 테스트하여 중요한 문제들에 대한 답을 찾아가는 과정을 말함.

03ㅣ디자인 QA 프로세스

1단계: 스프린트에서 다룰 화면 단위를 플로우별로 분리해요.

한꺼번에 프로덕트를 구축하는 MVP 단계도 있겠지만, 대부분의 경우 특정 기능 플로우를 나누어 작은 단위로 스프린트를 진행해요. 그래서 스프린트에 필요한 스크린과 플로우의 범위를 나누고, 소통할 수 있는 스크린명을 가지고 분류해주는 작업이 필요해요.

2단계: 디자인 QA의 체크리스트 양식을 팀의 요구사항에 맞춰 작성해요.

디자인 QA에 앞서 조금이라도 양식을 만들 수 있는 목록들을 추려보세요. 미리 항목화되어 있다면, 체계적으로 QA를 진행하기 쉬워져요. 아래는 작성할 수 있는 체크리스트의 예시에요.

3단계: 화면별로 QA 가능한 체크리스트, 테스트 케이스를 간략하게 정리해요.

앞서 작성한 체크리스트를 기반으로 화면별로 체크가 가능한 간단한 표를 만들고, 팀원들과 테스트 케이스를 정리하여 QA를 진행할 준비를 마쳐보세요.

4단계: 개발자가 공유해준 테스트 버전을 사용하며 의도와 다른 부분을 탐색해요.

개발자가 공유해준 테스트 버전의 앱/웹을 사용해보며 위에서 만든 표를 참고해서 꼼꼼하게 의도와 다른 부분을 탐색해요. 기획이나 디자인의 요구사항을 맞추는 것도 중요하고, 진짜 고객의 입장에서 어떤 부분이 어색한지 발견하는 것도 중요해요.

5단계: 탐색한 것들을 업무 티켓으로 만들고, 우선순위를 지정해요.

탐색한 것들을 항목화하고 리스트로 만들어요. 그리고 그 안에서 적용할 수 있는 우선순위를 팀 차원에서 합의해요. 스케일은 2가지가 될 수도 있고, 5가지가 될 수도 있어요. 팀에서 의사결정을 하기 쉬운 방식으로 우선순위 라벨을 지정해요. 아래 예시를 보면, 1순위로 지정된 것들은 바로 티켓으로 만들고 2순위 중 일부는 팀 차원의 리소스에 따라 유연하게 결정해요.

6단계: 개발자들과 우선순위에 맞게 이슈 픽스를 진행해요.

스프린트 안에 고치기를 결정한 티켓들을 확인하고, 간략한 문제 발생 원인을 찾아 개발자들과 해결 방안을 논의해요. 이것을 고치는 과정에서 다른 요소들이 바뀌지는 않는지, 기존의 서비스 품질을 유지하며 고칠 수 있는 것들인지 타협을 통해 최적의 방안을 탐색해요. 개발자에게 위임하기보다 함께 협업하며 소통에서의 병목을 최소화하는 것이 좋아요.

7단계: 업무 테스크를 마무리하고 스프린트를 종료해요.

테스크가 일정에 맞게 완료되면, 제품이 수정된 방향으로 잘 작동하는지 확인하며 스프린트 업무를 종료해요.

04ㅣ디자인 QA를 마치고

모든 과정을 진행한 후 팀에서 회고를 통해 같은 실수가 반복되지 않도록 방지하는 것이 중요해요. 휴먼 에러나 단순 커뮤니케이션 오류로 발생한 항목들부터, *핸드오프 문서에서부터 잘못된 표현은 없었는지 그리고 해결 방안을 찾는 과정에서 열린 태도로 임했는지 등 전반적인 진행 과정을 성찰하며 반복하지 않아도 좋을 부분들을 점검하고 팀 차원에서 공유하는 과정이 필요해요. 이러한 회고 과정이 있으면, 의식적으로라도 이후 일을 진행할 때 짚었던 부분들은 피해서 접근할 수 있어요. 러닝을 쌓아두는 것이 중요해요.

*핸드오프(Hand-off): 개발자가 구현할 수 있도록 디자인 작업물을 만들어 떠나보냈다는 의미

앞서 기획했던 디자인 QA에 대한 기획 리뷰를 받고, 다양한 관점에서 피드백을 받아요. 회고와는 다르게, 일을 진행한 방식 자체에 대한 피드백을 수집해보는 것도 좋아요. 이 프로세스가 팀의 업무 효율성에 도움이 되었는지, 오히려 너무 세세해서 팀의 업무 생산성을 해치지는 않았는지 진단하고, 다음 과정에서 더 팀에 적합한 형태의 디자인 QA 방식을 찾아내는 것을 목표로 피드백을 진행해요. 열린 태도로 피드백을 수용할수록, 팀원들은 나와 협업하는 것의 가치를 더 높이 평가할 수 있어요.

05ㅣ디자인 QA 진행 tip!✨

어떻게든 더 좋은 제품을 만들기 위함이라는 목표를 잃지 않는 것이 중요해요. 꼼꼼함을 추구하다 보면, 가끔 우리 팀의 상황이나 제품 규모를 생각하지 않고 이상적인 기준을 따라가려고 할 때가 있어요. 그래서 팀의 상황에 맞지 않게 부담이 되는 작업 우선순위를 높여 진행한다던지, *trade-off를 생각하지 않고 높은 완성도만을 주장한다던지 하는 경우가 발생해요. 이 상황에서 가장 좋은 단서는 내가 주장한 것에 대한 팀원들의 태도이므로, 만약 갈등 상황이 발생할 때는 더 넓은 목표로 돌아가 내가 판단하고 있는 기준을 성찰해보는 것도 좋아요.

*trade-off: 사전적 의미는 상충관계. 즉, 하나를 얻으면 다른 하나를 잃을 수 있는 관계를 의미함

너무 많은 것들을 3,4순위로 가져가다 보면 *디자인 부채가 생길 수 있음을 알고 있어야 해요. 위와는 반대의 태도로, 너무 많은 타협을 해서 노운 이슈를 많이 생성하고 해결하지 않을 경우 추후 제품 개발 시 디자인 부채가 생길 수도 있어요. 좋은 고객 경험을 잃지 않는 선에서, 이미 잘못됨을 인지하고 다음 버전에서는 없애야 하는 *레거시를 최소화하려는 노력이 필요해요. 이를 위해서는 지속 가능한 운영을 고려하며 최선의 해결 방안을 위해 팀원들과 끊임없이 노력하고 소통하는 연습이 필요해요.

*디자인 부채: 실험 중심의 디자인 프로세스를 채택할 때, 변동 사항이 빠르고 반복적으로 진행되어 발생하는 예측할 수 없는 부작용. 시간이 지남에 따라 점진적인 변경 사항이 모여 사용자 경험의 무결성에 영향을 주고 디자인의 일관성과 구조를 해치는 것을 말함.
*레거시: 낡은 기술 또는 방법론, 시스템, 소프트웨어 등을 의미. 현대까지 남아 쓰이는 기술이나 더이상 쓰이진 않아도 계속해서 현대 기술에 영향을 주는 경우도 포함.

앞으로 변화하는 툴에도 흔들림 없는 취업 준비를 이어가고 싶다면? UIUX 디자인 스쿨을 추천드립니다. 트렌드에 맞는 실무 중심 커리큘럼으로 취업까지 빠르게 도착할 수 있기 때문이죠! UIUX 디자인 스쿨에서 정확하게 배우고, 제대로 취업해 보세요.

UIUX 디자인 스쿨은 '취업'까지 단 4개월,
새로운 여정을 함께할 분들을 기다립니다.

추천 컨텐츠