애자일 조직에서 디자이너와 협업하는 법
<린 UX>를 읽고
들어가면서
이번에 유저 프론트와 연관된 프로덕트 기능 개선을 진행하면서, 이직 후 처음으로 디자이너와 함께 협업을 했습니다. 협업 과정에서 좋았던 점은, 제가 작성했던 의도와 문구들이 조금 더 유저 친화적으로 변모했다는 점입니다.
예를 들면, 저처럼 B2B 대상의 커머스 서비스에서 일했던 사람은 PG사 할인 같은 용어가 어렵다는 생각을 별로 못해봤습니다. 그래서 저 용어를 그대로 가져다 썼는데, 디자이너님이 딱 보시고 유저 친화적이지 않다고 결제수단 할인 (카드사, 페이앱 등)과 같은 용어로 작업해 주셔서 고마움을 느꼈습니다. 디자이너가 이런 UX를 고민해 주고 의견을 주는 거는 꽤나 낯설지만, 너무 반가운 경험이었습니다.
좋은 동료와 잘 일해보기 위해서 나름대로 협업하는 방식을 고민해보던 중, 오늘 소개하는 책 <린 UX>를 읽어봤습니다. 과연 IT조직에서 제품 관리자는 디자이너와 어떻게 협업해야 할까요?
ChatGPT린 UX 이해하기
우선 '린 UX'라는 개념을 이해할 필요가 있습니다. 린 UX는 IT 서비스 업무 환경에서 디자인 조직의 일하는 방식이라고 볼 수 있습니다. 보통 IT 프로덕트팀에서 일하는 방식으로 언급되는 디자인적 사고, 애자일 프로세스, 스타트업 방법론 등이 이런 린 UX의 토대에 있습니다.
왜 디자인 조직도 '린 UX'라는 개념이 필요하게 되었을까요? 이는 '제조'가 아닌 '배포'하는 환경으로 업무 환경이 변화했기 때문입니다. 예를 들어, 자동차 회사의 디자이너는 디자인을 정말 신중하게, 긴 호흡으로 '완벽'에 가깝게 해야 합니다. 왜냐하면 자동차가 한번 특정 디자인으로 생산되고 나면, 이미 생산된 것을 다시 돌리는 것은 정말 큰 비용이 들기 때문입니다. 반면, 배포하는 IT서비스는 그런 부담이 적습니다. 빠르게 이런저런 시도를 해보고, 실패하더라도 제조업보다 돌이키는 비용이 훨씬 적습니다.
현대차는 새 디자인센터 구축으로 지금까지 3년 정도 걸리던 신차 디자인 개발 기간을 절반인 1년 6개월로 단축할 수 있을 것으로 내다봤다. 대부분 완성차업체들은 6~7년에 한 번 ‘완전 변경(풀체인지)’ 신차를 내놓으며, 그 사이 3~4년 주기로 디자인에 변화를 준 ‘부분 변경(페이스리프트)’ 모델을 내놓는다.
출처 : 현대차, 신차 디자인 기간 18개월로 절반 줄인다 (한국경제, 2017.08.16)
당시 배민 앱은 2주 주기의 배포 주기를 선택했습니다. 그리고 우리는 2주 보다 더욱더 빠르게 기능이 배포(고객에게 가치가 전달) 되길 바랐습니다. 위와 같은 상황에서 저에게 주어진 미션은 아래와 같다고 판단했습니다. ...
출처 : 가파르게 성장하는 서비스를 담당한, 한 품질담당자의 회고 (우아한기술블로그, 2022.10.6)
따라서 프로덕트팀의 디자이너는 '린 UX'에 따라 일하며, 아래의 15가지 원칙을 고려하는 것이 좋다고 말합니다. 대략 요약하면, 스쿼드 구성원 및 고객과 협업할 수 있는 최고의 환경을 만들고, 문제해결과 성과에 집중해서, 빠르게 시도해 보고 학습하자는 내용입니다. (다른 린 방법론과 많이 유사하네요!)
<린 UX의 15가지 원칙>
1. 다분야 융합팀 : 스쿼드 단위로 일한다
2. 작게, 집중하도록, 같은 공간에 배치 : 협업, 소통의 극대화
3. 진전은 산출물이 아닌 성과
4. 기능보다 문제에 집중하는 팀
5. 불필요함 제거
6. 최소 존속 크기 : 필요한 디자인만 하면서 나아간다.
7. 지속적인 발견 : 고객과 지속적으로 교감하며 발견해야 한다.
8. GOOB, 새로운 사용자 중심성 : 고객을 이해해야 한다.
9. 상호이해 : 공동의 지식을 만든다.
10. 안티패턴 : 스타직원, 권위자 등 협업에 방해되는 인물은 제거한다.
11. 작업물 공개 : 항상 공유하고 소통한다.
12. 분석보다 제작
13. 확장보다 학습
14. 실패를 용인
15. 산출물에서 벗어나기
출처 : 도서, <린 UX>
린 UX 프로세스
빠르게 실행하는 디자인 프로세스
팀은 협력적이고 반복해서 병렬로 일을 진행하며, 최소한의 산출물과 아주 적은 양의 문서를 만들어 내는 동시에 작동하는 소프트웨어와 시장의 피드백에 집중한다.
출처 : 도서, <린 UX>
(1) 비전 정의, 실행 계획과 성과
앞서 원칙에서 언급한 것처럼 린 UX의 핵심은 기능과 산출물보다 문제해결과 성과에 집중하는 것입니다. 이를 위해서 기능적인 요구사항이 아니라, 가정assumption과 가설hypothesis을 수립하고, 이를 토대로 어떤 성과outcomes를 기대하는지 중심으로 프로젝트를 정의해야 합니다.
IT 조직에서 일하면 가설은 꽤나 많이 사용하는데, 가정을 활용하는 경우는 별로 보지 못한 것 같습니다. 가정과 가설은 어떤 차이가 있을까요?
가정 : 실제로 일어날 것이라 믿는 대전제
가설 : 제품이나 이용과정의 특정 부분에 대한 가정을 실험에 맞게 작은 단위로 기술한 것
ChatGPT예를 들면, 배달서비스에서 한집배달 프로덕트를 예로 들어보겠습니다. PO는 프로덕트 분석, 비즈니스 분석을 통해 아래와 같은 가정을 세워볼 수 있습니다.
"우리 고객들은 음식을 빠르게 받아보고 싶은 니즈가 있다."
"이러한 니즈는 빠른 배달로 해결될 수 있다."
"우리는 한집배달을 통해 이 문제를 해결할 것이다"
이런 가정을 세웠다면, 이제 이를 위한 가설을 수립해 볼 수 있습니다. 가설은 가정을 테스트할 수 있는 단위로 쪼개는 것이며, 이를 토대로 실제 정량적 수치 또는 정성적 통찰의 내용이 검증됐는지 확인하는 가정입니다. 따라서 아래와 같이 가설을 세워볼 수 있습니다.
"한집 배달 서비스를 만드는 것으로 고객의 이용률과 만족도가 증가할 것이다. 이는 기존 배송보다 추가로 지불하는 평균 배송비를 통해 확인할 수 있을 것이다"
이처럼 린 UX는 성과를 높이기 위한 학습을 중요하게 생각합니다. 따라서 어떤 기능을 만들겠다고 접근하는 것이 아니라, 가정과 가설 수립이 끝나고 이를 검증할 수 있는 수단으로 기능에 대한 도출이 이루어져야 합니다. 제가 최근 PRD 문서를 작성할 때, 기능을 어느 정도 염두에 두고, 그 기능을 통해 검증할 수 있는 가설을 역으로 썼던 것 같아 다시금 반성과 마음을 다잡을 수 있었습니다. :)
(2) 협업기반 디자인
기능이 정의됐다면, 이를 위한 디자인이 나와야 합니다. 린 UX는 프로세스 초기부터 팀 내 다양한 구성원의 이야기를 들으면서, 팀의 주체성과 협업 정도를 높이고, 역설적으로 디자인 작업의 효율성을 최대로 끌어낼 수 있다고 이야기합니다.
Style Guide (Figma)특히 이 단계에서 가장 중요한 원칙 중 하나가 '상호이해'입니다. 상호이해는 린 UX를 움직이는 화폐로, 상호이해가 잘 갖춰져 있을수록, 구성원들 간 소통이 더 원활히 진행될 수 있습니다. 프로덕트 컨셉에 대해 모두가 동일한 뷰를 갖고, 성능요인, 인터페이스 등을 고려할 때 어떤 게 최선의 기능인지도 미리 논의할 수 있습니다.
이를 위한 도구로 디자인 스튜디오, 스타일 가이드와 패턴 라이브러리 등에 대해서 이야기합니다. 이와 같은 디자인 프로세스를 활용해서 디자이너는 필요한 디자인 가설을 수립할 수 있게 됩니다.
(참고) 디자인 스튜디오
디자이너와 비디자이너가 함께 작업하는 공간입니다.
팀원 모두가 참여하여 고객에 대한 통찰력을 키우고 같은 목표를 공유합니다.
빠른 프로토타이핑과 실험을 통해 아이디어를 신속하게 테스트할 수 있습니다.
(참고) 스타일 가이드와 패턴 라이브러리
스타일 가이드와 패턴 라이브러리는 디자인 시스템 결과물 중 일부입니다.
이들은 제품의 일관성을 유지하고 팀 간 커뮤니케이션을 돕는 도구로 사용됩니다.
린 UX에서는 이러한 문서들이 최소한으로 유지되며, 실제 개발에 직접적으로 도움이 되는 요소들만 포함하게 됩니다.
(3) MVP와 실험하기
디자인 가설 수립까지 완료됐다면, 이제 MVP를 만들게 됩니다. MVP를 만들 때는 명심할 점은 반드시 가치를 제공할 필요는 없다는 점입니다. 물론, 시장에 빠르게 진입해 보기 위해서 소규모 버전이나 기능을 통해서 MVP를 만들 수 있겠지만, 시장이 원하는 것이 맞는지 학습하는 것이 가장 주된 목적입니다.
MVP의 Best Practice인 토스 MVP (Toss)MVP를 만들 때는 기본적으로 솔루션에 대한 니즈, 기능이 유용한지, 기능의 사용성이 좋은지를 생각해 보는 것이 좋다고 말합니다. 이를 위해 UX 디자이너가 가장 잘 활용하는 방법은 프로토타이핑입니다. 프로토타입은 경험을 추정하는 것으로 막연하게 머릿속에 있는 제품이나 서비스가 어떻게 나올지를 재연해 보는 것입니다. 흔히 말하는 '시제품'과 유사한 개념입니다.
여기에는 로우파이 프로토타입, 미드 앤 하이파이 프로토타입, 코드 프로토타입 등이 존재합니다. 로우로 갈수록 적은 시간으로 빠르게 의견을 주고받으면서 수정해 보기 좋겠지만, 미완성된 제품으로 느껴질 수 있다는 점이 단점이 될 수 있습니다.
반면, 미드 앤 하이파이 프로토타입, 코드 프로토타입으로 갈수록 보다 완성된 느낌을 주며, 해당 산출물을 최종 구현 제품에 활용할 수 있다는 장점은 있습니다. 다만, 작업까지 소요가 길기 때문에 가설검증까지 필요한 기간이 길어진다는 점이 문제가 될 수 있습니다.
끝으로
책을 통해 디자인 방법론에 대한 기초 개념과 함께 협업하는 방법에 대해 생각해 볼 수 있었습니다.
읽으면서 반성을 했던 부분은 최근 기능 개선을 위한 디자인 요청을 할 때, 프로토타입에 대한 형태까지 다 정의해서 요청했던 점입니다. 물론, 그런 이유에서 디자이너분께서 프로토타입을 보시고 내용 자체가 복잡한 것은 아닌 것 같다고, 일정을 짧게 잡고 작업을 빠르게 끝내주셨던 점은 긍정적인 부분이었습니다.
다만, 장기간 지속적으로 협업을 해가면서, 구성원들이 프로덕트에 조금 더 주체성을 갖도록 만들려면 담당자들이 전문성을 발휘하고, 관여할 수 있는 폭을 넓게 제공하는 것이 중요하다고 느꼈습니다. 롤에서 탑이 탑 라인에만, 미드가 미드라인에만 있는 것보다 필요한 라인을 오고 갈 때 기댓값이 큰 것처럼 말입니다.
또한 프로덕트 관리자로 나는 어떤 영역에 더 집중해야 하는가에 대해 생각해 볼 수 있었습니다. 예를 들면, 앞단의 가정, 가설을 수립하는 단계를 보면 팀이 해결할 문제를 위해 제품 사용현황 분석, 사용성 평가, 실적과의 연관성이나 경쟁자에 대한 분석의 준비가 필요하다고 말합니다. 위에서 말한 '상호이해'를 어떻게 잘 구축해 갈 수 있을지, 조직이 애자일 하게 움직이는 것에 병목은 없을지를 고민하면서, 내가 필요한 부분이 무엇인지를 더 고민하면서 일을 해가야 할 것 같습니다.
재미있게 읽으셨다면 구독과 좋아요 부탁드립니다. 감사합니다. :)
