모바일 개발자와 디자이너가 함께 일하는 법 (2)

디자인 QA가 필요한 이유

*지극히 개인적인 경험을 담았습니다.

지난 포스팅에서 스프린트 계획 회의에서부터 개발 과정을 담았다면, 이번 글에서는 개발 이후의 내용을 담아보았다. 실제 배포 전까지 우리는 계속해서 신경써야할 부분이 많다.

디자인 QA가 왜이렇게 많아요?

1. 디자인 QA의 중요성

개발자, QA는 디자이너가 아니다. 디자이너는 디자인을 보는 사람이다. 1px이 틀어진 아이콘과 폰트, 시안보다 탁한 컬러 값을 읽어낼 수 있는 유일한 직군이다. 개발자나 QA 검수자는 디자이너가 아니다. 그들은 주로 동작이 잘되는지, 서버에서 받아온 값에 문제가 없는지, UI가 해당 자리에 잘 들어갔는지를 확인한다. 

2. 디자인 QA는 디자이너만이 볼 수 있는 영역

그렇기 때문에 디자인 QA는 꼭 필요하다. 디자이너만이 최종적으로 퀄리티를 올릴 수 있는 사람이기 때문이다. 하지만 대다수의 회사를 비롯하여 우리 회사에서도 디자인 QA는 중요한 영역이 아니었다. QA 기간에 함께 진행했기 때문에, 동작 이슈에 밀려 툭하면 minor 이슈 처리되었고, 심심치 않게 (디자이너 눈에) 어색한 결과물이 나가곤 했었다. 하지만 점점 더 디자인 QA의 중요성이 눈에 띄기 시작했다. 과정을 모르는 사용자들이 첫눈에 보았을 때, 이상하다면 그건 이상한거니까. 스프린트 QA를 시작하면서 본격적으로 디자인 검수를 도입했다. 

디자인 검수를 도입하기 전, 우리의 스프린트 프로세스는 대략 이러했다. 

기획 - 디자인 - 프로젝트 킥오프 - 스프린트 계획회의 - 개발 (데일리스크럼) - 데모 - 프로젝트 QA - 배포 

디자인 QA는 대개 데모 또는 프로젝트 QA에서 함께 진행했다. 하지만 화면에서 하나의 기종으로 보는 데모는 실제 폰에서 보는 디자인과는 많이 달랐다. 그렇기에 점점 프로젝트 QA에서 감당하기 어려울 만큼 QA 이슈가 나오자, 우리는 디자인 검수를 도입했다. 

* 디자인 검수? 

디자인 검수란 개발 단계에서 본인의 작업 (티켓)이 완료될 때마다, 실제로 3개의 해상도에서 잘 나오는지, 직접 에뮬레이터로 체크한다. 디자인 검수를 하면 좋은 점이 있다. 해당 디자인만 확인하면 되어서 놓치는 일이 적다. 개발자도 바로바로 수정이 가능해서, 데모 또는 QA 기간에 이슈가 나올 여지가 적다.

개발과 디자이너가 함께 윈윈하는 법 

1.  개발을 고려한 디자인 만들기 

얕게나마 개발이 어떻게 돌아가는지 배웠기에, 앞으로 디자인을 할 때는 개발자의 입장에서 한번 더 생각하는 방법을 알았다. 디자이너는 사용성을 중시해야하는 입장이지만, 동시에 아무리 좋은 사용성이어도 배포가 되어야 사용자들이 써볼 수 있다. 그래서 늘 일정과 요구사항을 신경쓰지 않을 수 없다. 

2.  결정보다는 논의를 

개발에서 이런저런 질문이 들어올 때, 가끔은 나도 모르겠을 때가 많다. 그럴 때는 내가 알아서 결정하거나 일정을 스스로 판단하여 나중에 부채가 쌓이는 방향으로 우회하지 않는게 좋다. 개발자들은 나보다 더 ios/aos에 있어 지식이 충분한 사람들이고, 결정을 내리기 보다는 이렇게 하고 싶은데 다른 방법이 있을까요? 하면서 논의를 하는걸 택하자. 논의를 할 수록 쉽게 문제를 해결할 수 있고, 함께 일하고 있다는 느낌도 얻을 수 있다. 

3.  축하는 다같이! 

고생해서 함께 일하고, 성공적으로 배포한 후에는 꼭 회고와 회식을 진행한다. 회고를 하면서 이번 스프린트에서 어려운 점이 무엇인지, 내가 부족한점, 잘한 점, 좋았던 점 등을 이야기 해보는 시간이 필요하다. 당장 다음의 스프린트에서 우리가 또 만날 수도 있고, 받은 피드백을 바탕으로 우리는 점점 더 성장할 수 있기 때문이다. 회식 역시, 일적으로만 만났던 동료들의 사적인 이야기를 들어보며 친해질 수 있는 기회라고 생각한다. 가볍게 점심이라도 좋으니, 함께 식사하며 프로젝트를 잘 마무리하는 시간으로 삼으면 좋겠다.