당신의 디자인 솔루션은 안녕합니까?
좋은 디자인을 위한 통과 기준
제가 근무하고 있는 제품 스쿼드는 Product Owner인 저 1명, 개발자 5명, 디자이너 2명으로 이뤄져 있습니다. 앱스토어의 특정 키워드 카테고리에서 1위를 차지하고 있으며, 글로벌 유저 대상으로 MAU가 약 20만 정도 나오는 앱 서비스입니다. 점점 치고 올라오는 카피캣들과 우리의 영역을 넘보는 대형 경쟁사들까지. 꽤 오랜 기간 위기감 아래 일하고 있던 스쿼드입니다.
합류 이후 몇 달, 지금은 참 다른 모습입니다. 위기감이 자신감으로 바뀌어 가는 중입니다. 팀 속도가 붙고 배포 주기가 빨라지자 프로덕트 디자이너의 생산성을 걱정하는 목소리가 나왔고, 이를 해소하기 위해 이 전 글에서 소개했던 디자인 스프린트를 도입했습니다. 지금은 'Discovery Track - Design Cycle'이라는 이름으로 불리게 되었지만요.
이제는 Product Designer들로부터 디자인 솔루션의 품질 기준을 높이자는 이야기가 나왔습니다. 빠르게 치고 올라오는 경쟁 서비스들의 신박한 디자인들과 고품질 경험을 의식해서도 있고, 충분히 빠른 릴리즈 주기 안에서 최대의 품질을 내고 싶은 욕구가 커진 것도 있습니다.
지난 6월, 가설 검증을 실패하고 진행한 회고에서 이 이야기는 더 심화되었습니다. 가설 자체가 틀렸다기보다는 도출된 디자인 솔루션이나 최종 결과물의 품질이 아쉬워서라는 의견이 있었거든요. 네. 저도 느꼈습니다. 분명 실패할 것 같은 여러 신호들이 있었습니다.
예를 들면 디자인이 무언가 아쉬운 상태이지만 due date에 떠밀려서 그대로 릴리즈하게 된다거나, 디자인 전문성이 없는 사람들이 제동을 걸자니 그럴 자격이 되는가에 대한 자조적 질문 말입니다. 우리는 왜 서로 신뢰하고 있는데도 멈추고 점검해야 할 때라는 말을 적극적으로 하지 못했을까요?
이제는 나가는데 급급하기보다 좋은 디자인이 무엇인지 이야기할 때가 온 것입니다.
우리 스쿼드는 '사용자가 만족할 수 없는 디자인이다', 'Not Enough to Ship이다( 이건 나갈 수 없다)'라는 판단을 미리 할 수 있게 하기로 했습니다. Product Designer의 직무전문성을 존중하면서도 우리의 디자인 품질은 안녕한가를 검토할 수 있도록 하는 게 가장 중요했습니다. 그래서 '내보낼 수 있는 좋은 디자인 품질인가?'를 정량화하여 판단해 보기 시작했습니다. 주체는 제품 총책임자, Product Owner인 저와 제품 디자인 전문가인 Product Designer가 가져가기로 했습니다.
Scoring process를 소개합니다
Scoring에는 총 5개의 Criteria가 있습니다. '좋은 디자인'의 기준을 총 5가지로 분류한 것입니다. 각 항목은 최저 0점에서 최대 4점까지 평가되며, 좌측에서 우측 순으로 1점부터 4점입니다.
1. Usefulness: Does the product solve the problems we mentioned?
☝ 우리의 디자인 솔루션이 Product owner와 Align 된 유저의 문제, 비즈니스 문제를 정말 해결하고 있습니까?
2. Ease of Learn: Can our users' learning curve be less steep? Are there obstacles when our users are learning to use our new feature?
우리의 새로운 기능, 또는 산출물을 유저가 사용할 때 배우기 번거로운가요? 유저가 쉽게 배우는 데에 장애물이 있지는 않을까요?
3. Ease of Use: Can users easily or efficiently understand how to use our new feature?
☝ 유저가 기능을 간편하게 사용할 수 있나요? 수십 가지의 단계와 상호작용이 필요해 유저가 귀찮거나 짜증을 느끼게 되지는 않을까요?
4. Coolness: How cool is our design? Is it make a first impact?
☝ 유저가 멋지다고 느낄 만한가요? 유저에게 감명 깊은 경험을 줄 수 있는 디자인인가요?
5. Quickness to ship: Do you think it can be delivered to users on time, without any delays?
☝ 일정의 지연이나 과다한 시간이 필요로 하는 솔루션인가요? 어느 정도 수준으로 빠르면 좋을까요?
총 5개 항목의 점수를 평가하고 나면 다음과 같은 오각형이 도출됩니다. 품질을 가시화할 수 있죠.
가시화 예시좋은 디자인을 점수화하기
Scoring은 가시화에서 끝이 아닙니다. 오각형을 그리는 데에 사용된 점수의 총합은 곧 Design Solution의 품질 점수로 환산됩니다. 점수 환산법은 다음과 같습니다.
1. 5개 항목에 대한 점수를 0점부터 4점 사이로 평가한다.
2. 릴리즈 직전까지 유지되어야 하는 디자인 품질에서 더 중요하게 여길 2개의 항목을 선정한다.
3. 점수를 합산할 때, 제일 중요한 것은 X2, 두 번째로 중요한 것은 X1.5를 해 더한다.
이렇게 도출된 점수가 '통과할 수 있는 상태'인지 점검하려면, 당연히 최저 점수를 넘어야 할 텐데요. 최저 점수는 여태까지 팀이 개발했던 디자인 솔루션 중 경험상의 Worst case (나가서는 안 됐던) 보다 조금 높은 선을 기준 삼는 것이 좋습니다. Worst Case는 당연히 재발되어서는 안 되고, 최저 기준선이 이보다 조금이라도 더 좋은 수준일 때, 이 점수를 통과한 디자인이 제품에 반영되어 평균 품질이 올라갈 수 있기 때문입니다.
얼마나 잘했는지를 아는 것이 중요하다면 Best case(나가길 정말 잘했던) solution을 선정하고 ETS scoring을 해보면 됩니다. 비교군이 있으니 좋은 디자인인지를 판별하는 데에 더 좋겠죠.
우리 팀은 이 방법을 ETS(enough to ship) scoring이라 부릅니다. 노션에 있는 Standard를 발췌했어요. 제 문체가 묻어나네요.
어떻게 일에 녹여낼 수 있을까요?
저희 스쿼드는 디자인 작업 착수를 위한 문제 정의 미팅에서 PO가 PD의 동의 하에 가중치를 곱할 항목을 설정합니다. 예를 들어 '이번 문제 해결에는 wow factor가 가장 중요하고, 그다음으로는 사용자에게 유용해야(usefulness)해요'라고 의견을 전달하는 것이죠. PD가 이에 동의하면, 본질적인 문제 해결에 집중하면서도 두 가치를 더 잘 달성할 수 있는 디자인이 시작됩니다.
개발팀에게 최종 UI spec을 전달하기 전, PO와 PD가 Scoring을 해봅니다. 최초 미팅에서 선정한 가중치 항목들도 잘 곱하여 점수를 도출합니다. 최저 기준을 넘는지를 보며 개발할 수 있는 디자인 품질인지를 확인하는 것입니다.
개발이 완료된 뒤에는 스프린트 리뷰에서 전체 팀원들과 다시 scoring 해봅니다. 여기서 최저점을 능가하는 점수가 도출되면 최종 QA를 진행합니다. 최고점에 가깝거나 좋은 점수가 나오면 증분에 대해 모두가 축하하는 자리를 가지죠.
살면서 만난 스크럼마스터 중 가장 유능한 저희 스쿼드의 DE님의 작품두 번의 점검이 있기에 우리의 디자인이 더 좋은 디자인일 가능성이 높다는 자신감이 생깁니다. 또 scoring에 모두가 참여하고 동의하여 릴리즈 되므로 무의미한 증분이 아닌 가치로운 시도가 사용자에게 전달된다는 인식이 있습니다. Scoring system을 업무 과정에 녹여내고 나니 경각심이 늘어서인지 16점 미만의 케이스는 도출되지 않았습니다. 이것이 쌓이면 과거보다는 더 준수한 디자인으로 제품이 가득 찰 것이 분명합니다.
Scoring 제작 시 참고한 글 : https://uxdesign.cc/what-is-a-good-product-design-6aa6c2a3fdeb
