현재 내 상황에서 얻을 수 있는 인사이트들이 있어서 아카이빙 목적으로 가져왔다. 첫 번째 링크는 분석가로 일할 때 링크드인 팔로우도 해놓고 여러 유용한 정보들을 받아보곤 했던 데이터리안의 수강생 인터뷰 글이고 두 번째 링크는 디자이너 현직자의 글이다. 두 개 글의 핵심을 한 문장으로 요약해보면 결국 '프로덕트 디자이너도 데이터를 볼 줄 알아야 한다.'는 것이다. 아래는 위의 글들과 그동안 분석가로서의 경험을 바탕으로 작성하였다.
프로덕트 디자이너, 왜 데이터를 읽을 줄 알아야 하는가?
프로덕트 데이터 분석가로 일하면서 PO, 프로덕트 디자이너, 개발자들과 크로스펑셔널하게 원팀으로 함께 협업을 했었다. 우리가 맡은 프로덕트를 개선하기 위해 다양한 실험들과 배포를 진행했었는데 당시의 내 역할은 '데이터에 기반한 문제 정의', '실험 설계, 지표 구조화', '실험 성과 분석' 등이었다. 분석을 통해 발견한 인사이트나 실험 결과에 대해 PO와 프로덕트 디자이너에게 공유를 하고 이후의 액션에 대해 논의하는 게 반복되었다. 이 과정들을 통해 느꼈던 건 프로덕트 디자이너 역시 데이터와 굉장히 가까이에 맞닿아 있는 직무라는 점이었다.
프로덕트 디자이너는 프로덕트를 사용하는 사용자의 경험을 개선하기 위한 여러 문제들을 디자인으로써 해결한다. 문제를 해결하려면 먼저 문제가 정의되어야 하는데 사용자들의 모든 행동들이 데이터로 남는 상황에서 데이터는 문제를 정의하는 데에 강력한 실마리를 제공한다. 핵심 퍼널에서 특정 단계의 이탈률이 높다면 해당 단계에서 문제가 있을 것이라는 합리적인 의심을 가져볼 수 있다. 그렇다면 해당 페이지에서 무엇이 문제인지를 구체화해볼 수 있고 가설을 세울 수 있다. 기존에 쌓아둔 로그 데이터로 검증할 수 있는 가설들은 검증해보고 만약 유력 가설에 대해 당장의 데이터로 검증할 수 없다면 실험을 통해 데이터를 쌓은 후 확인해볼 수 있다.
문제 정의와 가설 설정을 직감에 의존했을 시 생길 수 있는 리스크와 사이드이펙트에 대해선 많은 조직들이 이미 잘 알고 있기에 데이터에 기반한 사고는 필수적으로 요구되는 추세다. 특히 정성적 데이터를 많이 다뤄왔던 프로덕트 디자이너가 정량적 데이터까지 익숙하게 활용할 수 있게 된다면 디자인 의사결정에 있어서 좀 더 설득력을 가질 수 있게 될 것이다.
데이터 분석가가 조직 내에 있는 경우엔 프로덕트 디자이너가 직접 데이터를 분석할 필요는 없다. 다만, 데이터 분석을 통해 도출된 결과들을 보면서 '해석할 줄 알면' 좋다. 사용자의 행동은 생각보다 복잡도가 높기 때문에 분석 결과를 단편적으로 해석하면 왜곡된 결론으로 이어질 수 있기 때문에 데이터 리터러시 역량을 기르는 게 중요하다. 프로덕트 디자이너는 그 어떤 직무보다도 사용자의 경험과 사용성을 적극적으로 고려해야 하는 직무이기 때문에 이와 관련된 문제들을 발굴하고 정의하는 역할에도 주체적으로 임해야 한다고 생각한다. 이러한 관점에서 데이터를 잘 해석할 줄 아는 역량은 점점 더 요구될 것이다.
데이터는 프로덕트 디자이너의 효과적인 도구가 될 수 있다.
데이터를 제대로 해석할 줄 아는 역량은 이제 프로덕트 디자이너에게도 필수 역량으로 자리잡아갈 것 같다.
여기서 더 나아가 데이터 분석 캠프 등을 수강하는 디자이너들이 생기고 있다는 걸 봤을 때엔 분석에 대한 니즈도 생기고 있는 것 같다. 데이터 분석가가 없는 조직이라면 정량적 데이터를 직접 보고자 하는 프로덕트 디자이너들의 니즈가 꽤나 강할 것이다. 물론 분석가들처럼 SQL 쿼리를 날리거나 파이썬으로 EDA나 머신러닝 모델링까진 힘들겠지만 적어도 GA나 믹스패널, 앰플리튜드와 같이 로그 데이터를 수집하는 서드파티 툴을 활용해서 데이터를 보는 것은 충분히 가능하다.
또한, 데이터 분석가가 있는 조직이라고 하더라도 프로덕트 디자이너가 보고자 하는 데이터를 원하는 기간 내에 받아볼 수 있을지는 사실 미지수다. 분석가 역시 우선순위에 따라서 봐야하는 것들이 있기 때문에 요청에 대해 늘 신속하게 대응하지는 못할 수 있다. 그런 상황에서 마냥 분석가를 기다리고 있는 것보단 조직에서 활용하는 툴들을 활용해 간단하게라도 지표들을 확인해보고 해석할 수 있다면 PO나 분석가와의 커뮤니케이션 코스트도 줄어들 것이다. 따라서, 이런 이유로 정량적 데이터에 대한 프로덕트 디자이너의 니즈는 더욱 강해질 수밖에 없다.
몇 년 전에 마케터와, 기획자, PO와 PM 사이에서 데이터 활용에 대한 니즈가 강했었던 적이 있었다. 그래서 이들을 대상으로 한 SQL 강의들이 꽤나 인기를 끌었었고 나 역시 사내에서 SQL 쿼리 교육을 진행했던 적이 있었다. 그리고 이러한 바람이 앞으로는 프로덕트 디자이너들 사이에서도 불지 않을까 조심스레 예상해본다. 생성형 AI로 인해 다양한 직무들에서 자동화와 효율화가 진행되고 있다. 분석 역시 프롬프트 명령만 구체적이고 확실하다면 꽤나 그럴듯한 결과들을 보여주고, 개발자들 역시 cursor 등의 AI 도구들을 보조적으로 활용하고 있다. UI 디자인 분야 역시 자동화 측면에서 다양한 플러그인과 라이브러리를 통해 (물론 아직 많이 부족해보이긴 하지만) 새로운 상황에 직면한 것으로 보인다. 많은 것들이 자동화 될 머지 않은 미래엔 문제를 정의하고 뾰족한 가설을 세우는 역량이 프로덕트 디자이너에게 강하게 요구될 것으로 보인다. 그리고 그런 역량을 위해 정성적 데이터 뿐만 아니라 정량적 데이터까지 잘 활용할 수 있다면 많은 도움이 되지 않을까.
'Product Design > 아티클 스터디' 카테고리의 다른 글
[아티클 스터디] 토스 가입완료율 개선을 위한 유의미한 분투기 (2) | 2024.12.28 |
---|---|
[아티클 스터디] 좋은 디자이너와 나쁜 디자이너? (0) | 2024.12.15 |
[아티클스터디] UX 디자이너는 서비스를 어떻게 뜯어볼까 (2) | 2024.12.08 |