하이브리드 앱 제작기 (완)
디자인 완_서비스 QA에 대하여
3개월의 짧지만 길었던 하이브리드 앱 제작 여정이 마무리되었다. 실제 스토어에 올리고 실제 고객에게 내보이기까지 최소한의 디자인 QA 과정을 거치면서 느꼈던 점들을 정리하고자 한다. 미묘한 변화였지만 그에 따른 결과물과 만족감은 훨씬 컸다.
앱을 제작하면서의 겪었던 디자이너로서의 QA 경험과 함께 그 중요성과 개발자에게 효율적으로 디자인 피드백을 전달할 수 있는 방법에 대해 간략히 소개하고자 한다.
QA가 꼭 필요할까?
QA는 Quality Assurance의 의미로 서비스의 품질을 보증하며 사용자에게 최대의 서비스 가치를 제공하는 것을 목표로 한다. 서비스 기획에서 개발 그리고 출시까지의 전반적인 QA를 통해 더욱 발전된 UX를 가진 서비스를 만들 수 있다. 보통 디자인 뷰가 일차적으로 개발된 후 진행된다. 이는 직접 개발자와 소통하면서 디테일을 결정하는 과정이다.
QA시 확인하면 좋을 요소들을 정리하자면,
0. 기획 오류 - 시나리오별 이슈가 없는지 찾기, 기획 텍스트 오류 찾기, 문안 및 정책 문제 찾기
1. 개발 오류 - 브라우저별 이슈가 없는지, 기능적 버그 찾기
2. 디자인 오류 - 레이아웃, 이미지, 인터랙션 문제 찾기
3. 피드백받기
나는 특히 이번 기회에 피드백 과정의 중요성을 다시 한번 깨닫게 되었다. 이때의 피드백은 팀 내부 외에도 외부의 사람들이 주는 피드백이 있다. 이는 더욱 신선하고 핵심을 찌르는 조언이 될 수 있다. 실제로 외부 사람의 피드백에 따라 서비스의 전반적인 이미지 수정이 이루어졌고 그 효과는 대단했다.
효율적으로 피드백을 전달하는 방법
프로젝트를 진행하다 보면 기획에서 벗어난 요구사항이 추가되거나 개발에 오랜 시간이 걸려 빠듯한 일정을 소화해야 하는 변수가 발생할 수 있다. 이러한 긴박한 상황에서는 QA 과정을 상세하게 정리하고 화면에서 고쳐야 한다고 생각하는 지점을 정확하게 짚어 전달하는 것도 중요하다고 생각한다.
크리틱 한 문제점을 얼추 추려낸 후 세밀한 디자인 QA를 위해 개발자에게 공유할 때에는 화면을 녹화하거나 캡처한 후 자세하게 고쳐야 할 점을 정리하였다. 구글 개발자 도구를 열어 실제 개발된 화면의 스타일과 그 간격을 디자인과 직접 비교해 가며 확인하였다. 추가적으로 기존 디자인 이미지 자료를 첨부하여 개발자들이 참고할 수 있도록 했다.
디자인 QA 예시 화면_콩소스실제로 디자인 QA를 준비하면서 다른 점이 많이 발견되었지만 이를 모두 QA에 담아내지는 않았다. 이는 초기 서비스 운영에 다른 기획, 개발 오류에 비해 큰 영향을 미치지 않으며, 3개월의 시간 안에 이런 사소한 것들을 고치기에는 벅찰 것이라는 생각이 들었다. 충분히 커버할 수 있는 범위 내의 디자인 오류는 너그럽게 넘어가는 경우가 많았다.
짧은 시간에 만들어내야 하는 프로덕트에서 디자이너는 포기해야 할 것들이 존재한다. 이를테면 디자인 디테일보다는 기능 에러를 고치는 것이 더 중요하다. 디자인 QA를 하는 과정에서 중요한 것은 서비스의 핵심을 파악하는 것이라고 생각한다. 디자이너가 사소한 것을 내려놓음으로써 개발자의 피로도도 낮추고 결과적으로도 더 완성도 있는 서비스를 만들 수 있을 것이다.
