.png&blockId=2d73189e-09e1-804b-a55d-c0b0c183f99f)
.png&blockId=2d73189e-09e1-804b-a55d-c0b0c183f99f&width=256)
✦ Lesson & Learned ✦
잘한 점 →•
다방면으로 사용자 이해하기
프로젝트마다 데이터로 사용자의 반응을 확인하고, 인터뷰로 이유를 알고자 했다. 인사이트는 팀에 공유했고, 서비스 개선을 함께 만들었다.
HOW | 어떻게 했는가? →
1.
데이터 | 프로젝트를 마치고 주기적으로 데이터로 사용자 반응을 확인하며 팀원들에게 공유했다. 이건 이전 회사에서 스스로 잘하고 싶던 역할이라, 새로운 환경에서도 지속했다.
2.
인터뷰 | 데이터로 알 수 없는 사용자 목소리는 인터뷰와 UT로 적극적으로 수집했다. (+. 사용자 인터뷰 모더레이팅의 재미도 느꼈다.)
WHY | 왜 그렇게 생각하는가? →
1.
같은 직무의 동료로부터 일하는 방식에 있어 좋은 자극이 되었다고 피드백을 받았고, 팀 문화로 점차 정립되었다.
2.
이전 회사에서는 데이터로 사용자 반응을 확인할 수는 있었지만, 그 이면의 이유까지 파악하기에는 한계가 있었다. 이곳에서는 실제 사용자를 만나 인터뷰를 진행하며 예상하지 못했던 사용 맥락과 인사이트를 발견할 수 있었고, 그 결과를 서비스 개선으로 연결할 수 있었다는 점에서 가장 의미 있었던 경험이라고 생각한다.
배운 점 → •
사용성 지키는 일도 비즈니스 관점으로 설득할 수 있다는 것
사용성과 이벤트성 화면 변경을 두고 논의가 있었고, 결과적으로는 사용성을 지키는 방향으로 정리되었다. 이후 리더님과의 1:1을 통해, 사용성 또한 비즈니스 관점에서 설득할 수 있었어야 했다는 피드백을 받았다.
사용성 개선이 곧 전환율, 이탈률, 반복 사용성과 같은 비즈니스 지표와 어떻게 연결될 수 있는지를 구체적인 예시로 이해할 수 있었고,
사용성을 ‘옳은 방향’이 아닌 ‘설득 가능한 논리’로 설명하는 관점을 배웠다. 아직은 연습이 더 필요한 영역이지만, 앞으로 의식적으로 시도해보고 싶은 중요한 배움이었다.
•
데이터 좀더 제대로 보게 된 것
이전에는 프로젝트 종료 후 클릭률이나 전환율 중심으로 결과를 확인하는 데 그쳤다면,
이곳에서는 이벤트 로그 설계 단계부터 어떤 지표로 UX 성과를 검증할지 사전에 정의했다.
클릭·전환율 외에도 전환 소요 시간, 검색 키워드 변화, 노출 시점에 따른 클릭·전환율 등 다양한 지표를 통해 사용자 반응을 해석하는 방식을 경험했고, 데이터를 ‘결과 확인’이 아닌 ‘가설 검증 도구’로 바라보는 관점을 갖게 되었다.
(+. 이건 PO와 아주 가까이 일하는 작은 조직에서만 참여할 수 있는 경험이라 의미 있게 경험할 수 있었다.)
아쉬운 점 → 가장 아쉬웠던 점은, 1년도 채 안되어 결정된 “서비스 종료”
•
‘이럴 땐 어떻게 나와요?’의 질문
예외케이스 화면을 개발자 요청에 의해 발견하고, 만드는 일이 잦았다.
해피패스를 제대로 그리는 건 당연하고 예외케이스까지 잘 챙겨야 한다는 걸 체감했다.
HOW | 다음에는 어떻게 할 것인가? →
이후 MECE, 로직 트리 등의 방법론을 활용해 디자인 시작 전 예외 케이스를 구조적으로 정리하는 방법을 학습했고, 새로운 환경에서는 이를 실제 설계 과정에 적용해보고자 한다.
•
맥락에 맞는 UX를 정말 제공했는가?
여러 가설과 A/B 테스트를 통해 사용자 반응을 검증하는 시도를 했지만, 주로 홈 화면 중심으로 이루어졌다. 노출이 많은 영역 외의 맥락에서는 사용자를 충분히 만나고 검증하는 데 한계를 느꼈다.
HOW | 다음에는 어떻게 할 것인가? →
새로운 환경에서는 사용자의 맥락을 더 입체적으로 고려한 UX를 설계하고, 각 맥락에 맞는 시점과 방식으로 사용자 반응을 검증하는 경험을 쌓고 싶다.
(+. ‘이 순간에 왜 이 기능이 필요한지’를 논리적으로 설명할 수 있는 UX를 제안하는 것이 목표다.)
