실무에서 우리만의 UX 호흡 만들기
Product Team에서 UX를 제대로 하기 위한 고민들-
Summary. 내부 유관부서 담당자들이 원하는 생산성 향상을 위한 어드민 중심적 프로젝트와 고객 경험을 향상하기 위한 UX 프로젝트는 별도로 관리되어야 합니다. 또한, UX를 고민하는 Product Team 담당자는 항상 누군가 1명 이상은 UX프로젝트를 어떤 단계라도 진행하고 있어야 합니다.
제가 스타트업에서 Product Team을 리딩 하며 가장 많이 고민하는 주제는
다음 작업은 뭐부터 해야 하지?
입니다. 제한된 리소스와 시간을 전제로, 기술적/운영적 제한 범위 안에서 프로젝트의 우선순위를 아무리 판단한다고는 하지만, 그 결정조차도 비지니스적인 관점에서, 내부 운영/생산성 관점에서, 고객관점에서, 기술 관점에서는 모두 다른 결론으로 나오기 때문이죠. 저 같은 경우는 프로젝트의 기대효과를 평가할 때 1차적으로는 누구를 위한 경험인지를 기준으로 분류를 하고 고민을 시작합니다: 우리 서비스의 내부 이해관계자를 위한 경험 vs. 우리 고객을 위한 경험인지요. 거시적인 관점에서 보았을 때 내부 이해관계자를 위한 경험도 작업을 하고 있고, 우리 고객을 위한 경험에 대한 작업도 하고 있습니다. 저의 경우, 전자의 프로젝트(우리 서비스 내부 이해관계자를 위한 경험)라고 판단되는 경우에는 작업의 난이도를 파악 후 유관부서 및 개발 담당자까지 포함하여 미팅을 진행하고, 기획적인 맥락에서의 방향성과 기대 결과물에 대한 협의를 한 후, 그 이후부터는 실무자(개발 담당자)가 주도적으로 프로젝트를 리딩 할 수 있도록 환경 지원을 하는 방식으로 협업하고 있습니다. 그리고, 후자의 프로젝트라고 1차적으로 판단이 되는 경우에는 요구사항 등을 취합하는 수준으로만 앞단에서 프로젝트의 유관부서들과 사전협의를 한 후 프로덕트팀이 주도적으로 요구사항들을 포함하여 기획/설계/디자인할 수 있도록 가이드를 합니다. 프로덕트 팀에서 독립적인 Sprint의 우선순위에 따라 프로젝트의 기획/설계/디자인이 구체화되는 단계에 개발팀과 협업을 시작하고, 저는 그 단계에서는 전체적인 프로젝트의 일정관리를 하는 방식으로만 실무자 및 유관부서와 소통합니다.
제 개인적인 경험을 기반으로 판단했을 때 위의 방법은 상당히 프로젝트를 효율적으로 운영할 수 있는 방법입니다. 항상 프로젝트들이 병렬적으로 진행되고 있으며, 각 프로젝트별 일정/호흡은 상이하겠으나 거시적인 관점에서는 서비스의 변화는 거의 항상 끊이지 않고 어드민 시스템이든, 고객 인터페이스든 어디선가에는 발생하고 있기에 조직적인 측면에서도 성과를 극대화할 수 있는 방법일 수도 있는 것 같습니다. 다만 수개월 동안 개인적인 시행착오를 겪으며 저 방법론을 실무에 적용한 후 개인적으로 도달한 결론은 다소 회의적입니다. 고객과 내부적인 니즈를 순발력 있게 대응하고 최적화된 페이스로 결과물을 구현해내는 데는 이상적일 수는 있겠으나, 제가 제일 아쉬운 부분은 작업의 효율을 위해 고객의 경험이 뒷전 된 것 같다는 생각이 들어서입니다. 사실 위의 작업방식을 고민하고 이런저런 실험을 통해 고도화시켰던 개인적으로 가장 큰 이유는, 현업에서 발생하는 많은 니즈를 최대한 해소하고 '우리만의 호흡'을 확보하기 위해서였습니다. 우리만의 호흡을 확보하여 고객을 좀 더 다양하고 깊게 이해할 수 있었으면 했고, 그 고민에서 나오는 기존과는 다른 경험들을 주도적으로 주체적으로 만들어내는 조직으로 성장하고 싶었습니다. 하지만 막상 해당 방식을 도입하여 일을 본격적으로 하며 알게 된 사실이 몇 가지 있는데요, 크게는 아래와 같이 세 가지 정도였던 것 같습니다.
1. 효율성이 높아질 수는 있지만 해야 할 일들이 줄어들지는 않습니다.
초반에 프로젝트들을 관리하며 접수(?)되는 유관부서의 요구/요청 사항들을 가시화했었을 때 그 양이 비현실적으로 크지는 않았었습니다. 즉, 프로젝트를 진행하는 효율을 좀만 높이면 들어오는 요구사항들을 근 미래에는 모두 해소하고 그동안 충원하는 리소스들을 통해 자체 프로젝트들을 진행하면 될 거라고 생각했습니다. 다만, 막상 그 효율성을 도달했더니 예전보다는 훨씬 더 많은 요구/요청 사항들이 더 빈번하게 발생하게 되었습니다. 내부 담당자들의 입장에서는 지금까지 거의 안된다고 생각했던 변화들이 서서히 생기기 시작하는 것을 목격하며 새로운 욕심/기대들이 생기기 시작했었던 것이죠.
반대로 개발적인 관점으로 판단을 했을 때는 점점 들어오는 요구사항들은 그 난이도가 높아져갔습니다. 그럴 수밖에 없는 것이, 쉬운 작업들은 벌써 다 완료를 해 버렸으니까요. 기존 기능들을 응용을 한 새로운 기능이라든가, 조금 더 근본적인 맥락에서 시스템 간의 연동이 필수적으로 이루어져야만 할 수 있는 프로젝트들이 발의되기 시작하면서 분명 프로젝트를 진행하는 효율성은 높아졌지만 해야 하는 일들은 더 어렵고 더 많아지는 상황이 되었습니다.
2. 고객 경험을 '고민'하는 것과 actionable 한 프로젝트로 구체화하여 진행하는 것은 또 다른 이야기입니다.
요구사항들을 기반으로 기획/설계/디자인을 하는 것은 쉽습니다. 도달하려고 하는 목표가 처음부터 가시화가 되기 때문이죠. 다만, 고객의 경험은 총체적이기에 서비스에서 작은 경험 하나를 개선한다고 했을 때 그 잠재적 영향범위는 의도했던 범위보다 클 수밖에 없습니다. 서비스의 후기 작성을 개선하는 프로젝트를 진행한다고 했을 때 고객상담팀에 유입이 될 1:1 문의/VOC 접수량과는 처음부터 그 상관관계가 가시화되지는 않습니다. 하지만 고객의 경험을 기준으로 본다면, 후기 경험이 어떻게 설계가 되어 있는지에 따라(혹은 1:1 문의하기 flow가 어떻게 설계/디자인되어 있는지에 따라) 긍정 후기가 더 올라올 수도, 반대로 기존 1:1 VOC가 고객들에게 노출되는 부정 후기로 노출될 수도 있습니다. 고객은 우리의 상식대로 행동하지 않기 때문이고, 그렇기 때문에 프로덕트팀은 더더욱 많은 가능성과 영향범위를 확인하고 고민하면서 프로젝트를 기획하고 설계하고 디자인해야 합니다.
그런데 제가 이렇게 고객 경험이라는 것은 섬세하고 총체적이고 조심스럽게 접근해야 하는 것이라고 강조를 하다 보니 프로젝트 자체가 고민만 하고 진도는 안 나가는 상황이 되어버리고 말았습니다;;;; A/B Testing을 하려고 해도, 그 경험을 증명할만한 기준과 가설이 필요하며, 정량화하여 검증할 수 있는 가설을 구체화하려면 사전에 이 경험이 영향을 주는 영역들에 대한 적어도 논리적인 영향도 검사는 필요합니다. 그런데 고객의 경험이 총체적이라는 이유로 '후기 개선'이라는 주제로 시작한 이야기가 우리 서비스의 브랜딩에 대한 영향범위로까지 이야기가 번지는 상황이 되면 그만큼 다시 실제로 오늘 당장 진행해야 하는 작업으로 구체화하는 단계는 그만큼 또 어렵고 시간이 소요되게 됩니다.
3. 고객관점에서 시작되는 고객 경험 변화와, 그 외 관점에서 시작되는 고객 경험 변화의 결과물은 다릅니다.
사실 위에서 언급한 1, 2번의 이슈는 Product Manager, Product Owner, UX Manager 등 프로젝트를 관리하는 주체들의 노력으로 어느 정도 관리가 가능한 영역의 문제입니다(라고 저는 생각합니다). 하지만 1, 2번 이슈를 인지하면서 잠재적으로 가장 큰 리스크라고 판단한 부분은, 고객관점을 가지지 않은 사람이 고객의 경험을 만들어내는 것이었습니다. 겉으로는 큰 티가 안 나고, 단기적으로는 고객 경험에 큰 악영향을 미치지 않는다고 하는 결정들은 중/장기적으로 점진적으로 총체적인 문제를 가지고 오게 됩니다.
예를 들어보겠습니다. 제가 일하고 있는 마켓 컬리에서는 상품 상세 페이지에서 동종업계 타 서비스에서는 제공하지 못하는 수준의 상품정보를 제공하고 있습니다. 사진 한 장 한 장을 촬영하는데도 기획서가 존재할 정도로 많은 리소스를 투입하여 양질의 컨텐츠를 생산하고 고객에게 제공하고 있습니다. 그런데, 만약 그 '양질의 컨텐츠'때문에 고객들이 장바구니 페이지까지 넘어가는 동선에 방해가 되기 때문에, 서비스의 전환율 최적화를 위해서 컨텐츠를 최소화한다는 결정을 내리면 어떻게 될까요? 그 컨텐츠를 줄이는 과정 속에서 발생하는 고객 경험의 부재는 나중에 총체적인 개념으로 비지니스 KPI에 티가 날 정도의 문제점으로 돌아오게 될 겁니다. 상품페이지를 컨텐츠를 최소화할 것이라면 정보를 줄이는 액션을 하기 전에 이 상품 페이지에서 어떤 정보가 고객을 설득시키는 정보인지, 어떤 정보가 부수적인 정보인지를 가시화한 후 점진적으로 개선해나가야 합니다. 고객을 설득시키는 정보는 더 시각화하고 체계적으로 관리하고, 고객을 설득시키지 않는 정보들은 점진적으로 그 양을 줄여가 보는 방식으로 말이죠. 제가 생각하기에 UX 관점을 가지고 일을 한다는 것은 이런 방식으로 일한다는것이라 생각합니다. 고객이 감당할 수 있는 만큼의 변화를 점진적으로 도입하고 실험하면서 비논리적인 경험까지도 포괄하는 브랜드 경험을 제공하는 것이 제가 지향하는 UX 관점을 중심으로 둔 일하는 방식인 것 같습니다.
실무에서 우리만의 UX 호흡 만들기
그래서 Product Team은 실무를 하며 '우리만의' UX 프로젝트를 진행할 수 있는 호흡을 만들려고 노력중입니다. 마켓 컬리에서 Product Team은 2주 단위로 Sprint를 진행하고 있는데요, 최근 제가 Product Team과 시도하고 있는 부분은 '모든 스프린트에 적어도 한 사람은 자체적인 UX 프로젝트를 진행하고 있기'입니다. 그 작업이 리서치가 될 수도 있고, 리서치 다음에 기획/설계 작업이 될 수도, 디자인이 될 수도 있겠으나 우선은 우리 고객의 경험을 Product라는 영역에서 누군가는 한 명은 고민하고 있어야 한다는 것입니다. 그렇다면 나머지 팀원들은? 위에 제가 언급한 것과 같이 내부적인 요구/요청 사항으로 발의되는 프로젝트들을 주도적으로 담당하고 있겠지요. 주체적으로 UX 프로젝트를 진행하는 사람은 꼭 진행상황들에 대해서 주기적으로 팀원들에게 공유해야 하며, 모든 팀원들은 그 역할을 돌아가면서 진행하여 특정 인물들에게만 UX 프로젝트가 할당되지는 않도록 합니다. 이런 방식으로 일을 하는 이유는:
1) Product Team 담당자 모두에게 UX관점이 탑재될 수 있도록 하며,
2) 각 실무자들이 주체적으로 일하는 방식을 학습하길 바라고,
3) 주체적으로 진행하는 UX 프로젝트의 성과가 Product Team 공동의 성과가 되길 원하기 때문입니다.
프로덕트를 담당하고 있는 입장에서, 중요하지 않은 프로젝트는 없습니다. 그저 그들만의 상대적인 우선순위만 존재할 뿐입니다. 그리고 저는 그 우선순위에 꼭 UX 프로젝트가 살아남았으면 좋겠습니다. 이 부분은 제 개인의 욕심과 의지로만 되는 건 아닌 것을 요즘 정말 많이 느끼고 있는데요, 이제는 성과나 혹은 방법론에 집착하기보다는 고객 경험을 중심으로 고민을 하는 태도에 더 집중을 하고 있습니다. 물론 쉽지는 않지만, 충분히 노력할 가치가 있는 도전이라 생각하기에 저도 계속 고민하고 있습니다 -
