Showing Posts From

리서치

포트폴리오 정리, 리서치 프로세스 공개할까 말까

포트폴리오 정리, 리서치 프로세스 공개할까 말까

포트폴리오 정리, 리서치 프로세스 공개할까 말까 9년 차의 포트폴리오 주말이다. 노트북을 켰다. 포트폴리오 파일 이름: "Portfolio_Final_v23.pdf" 23번째 버전이다. 9년 차가 됐다. UX 기획자로. 포트폴리오를 다시 정리하기로 했다. 이직 때문이 아니다. 그냥, 정리가 필요했다. 파일을 열었다. 첫 페이지. "○○○ | UX Planner | 9 Years" 경력 요약, 주요 프로젝트, 사용 툴. 깔끔하다. 전문적이다. 그런데. 뭔가 비어있다. 프로젝트 1: "커머스 앱 리뉴얼"유저 인터뷰 32명 전환율 23% 증가 만족도 4.2 → 4.7숫자는 좋다. 결과도 좋다. 근데 이게 다인가. 32명을 어떻게 모집했는지. 인터뷰 질문을 몇 번이나 수정했는지. 녹취록을 밤새 들으며 패턴을 찾던 과정. 기획팀과 3시간 논쟁하며 설득하던 순간. 그건 없다. 포트폴리오에.결과만 보여주는 게 맞나 월요일 아침이다. 후배가 물었다. "선배님, 포폴 검토 부탁드려요." 받아봤다. 25살, 2년 차. 페이지마다 화려하다. 피그마 목업, 유저플로우, 와이어프레임. "여기 이 기능, 어떻게 도출했어?" "아, 벤치마킹이요." "유저 리서치는?" "시간이 없어서요. 그래도 결과는 좋았어요." 결과는 좋았다. MAU 15% 증가, 체류시간 2분 증가. 수치로는 성공이다. 근데 왜 증가했는지는 모른다. 어느 유저군이 반응했는지도. 다음엔 어떻게 개선할지도. "포폴에 프로세스 넣어봐." "네? 그럼 결과 공간이 줄어서..." "결과만으론 부족해." 말하고 나서 생각했다. 나도 결과 위주잖아. 포트폴리오. 화요일이다. 점심시간. UX팀 회의실에서 선배랑 얘기했다. 12년 차, 우리 회사 UX팀장. "팀장님, 포트폴리오 어떻게 만드세요?" "왜? 이직하게?" "아뇨. 그냥 정리하려고요." 팀장님이 웃었다. "나도 고민이야. 프로세스 공개하면..." "보안 문제요?" "그것도 있고. 근데 더 큰 건." 팀장님이 화면을 켰다. "리서치 프로세스 보여주면 다들 따라해." "그게 문제예요?" "문제가 아니라, 오해가 생겨." "프로세스만 따라하면 같은 결과 나올 거라고 생각해." "실제론 다르죠." "맞아. 맥락이 다르니까."리서치 케이스, 어디까지 보여줄까 수요일 저녁이다. 집에서. 리서치 케이스를 다시 봤다. 작년 프로젝트: "금융 앱 온보딩 개선" 리서치 기간: 6주 인터뷰 대상: 40대~60대 20명 프로세스: 사전 설문 → 인터뷰 → 사용성 테스트 결과:온보딩 완료율 34% → 67% 고객센터 문의 52% 감소 앱 삭제율 41% 감소숫자는 완벽하다. 발표 자료에도 넣었다. 임원 보고에도. 근데 과정은. 1차 인터뷰: 질문지 3번 수정"얼마나 자주 사용하세요?" → 너무 포괄적 "어려운 점이 뭔가요?" → 유도 질문 "이 화면에서 무엇을 하시겠어요?" → 구체적2차 인터뷰: 장소 실패회의실 환경 → 부담스러워함 카페로 변경 → 편안한 대화3차 테스트: 프로토타입 문제고해상도 목업 → 완성본인 줄 알고 평가 저해상도로 재작업 → "아직 만드는 중이구나" 인식이런 시행착오. 포트폴리오에 넣을까. 남편한테 물었다. "이런 거 보여주는 게 나아?" "뭐가?" "실패한 거. 수정한 거." 남편은 개발자다. 같은 회사. "당연하지. 개발도 그래." "처음부터 잘 짠 코드 없어." "리팩토링 과정이 더 중요해." "근데 면접관은 결과를 보고 싶어하잖아." "면접관 수준에 따라 다르지." "좋은 면접관은 과정을 물어봐." 맞는 말이다. 작년에 후배 면접 봤다. 포트폴리오 화려했다. 결과 완벽했다. "이 기능, 왜 이렇게 기획했어요?" "...벤치마킹이요." "다른 앱이랑 뭐가 달라요?" "...비슷한데, 우리 서비스에 맞게?" 탈락이었다. 결과만 있고, 사고 과정이 없었다.보안과 투명성 사이 목요일이다. 출근길. 보안 가이드 메일이 왔다. "외부 공개 시 프로젝트명, 수치 비공개" 이해한다. 대기업이니까. 경쟁사가 볼 수도 있고. 내부 전략이 노출될 수도. 근데 그럼 뭘 보여주나. "○○ 서비스 개선"유저 리서치 진행 핵심 페인포인트 도출 개선안 적용 긍정적 결과 확인이게 뭔가. 누구나 쓸 수 있는 문장. 구체성이 없다. 점심시간이다. UX 커뮤니티 슬랙을 봤다. 누가 물었다. "리서치 케이스 공유할 때 어떻게 하세요?" 댓글 40개. "프로젝트명 가명 처리" "수치는 비율로만" "스크린샷 블러 처리" "프로세스 중심으로 작성" 모두 비슷하다. 보안 때문에 가린다. 그런데 한 댓글이 눈에 띄었다. "프로세스 공개하면 오히려 경쟁력 아닐까요?" "어차피 같은 방법 써도 결과는 다르니까." 맞다. 리서치 방법론은 공개됐다. 심층 인터뷰, 설문, 사용성 테스트. 구글에 검색하면 다 나온다. 근데 실제로 잘하는 사람은 적다. 왜? 방법을 아는 것과 적용하는 건 다르니까. 질문 하나 던지는 타이밍. 침묵을 견디는 인내. 예상 밖 답변에 대응하는 순발력. 이건 경험이다. 노하우다. 프로세스 공개한다고 복사되지 않는다. 오후 3시다. 회의. 서비스 기획팀과 협업 미팅. 기획자가 물었다. "이번 기능, 리서치 필요해요?" "당연하죠. 유저 니즈 확인해야죠." "근데 시간이... 2주밖에 없어요." 또 시작이다. "2주면 빠른 리서치 가능해요." "어떻게요?" 화이트보드에 그렸다. 1주차:1~2일: 리서치 설계 34일: 인터뷰 (810명) 5일: 분석2주차:1~2일: 인사이트 도출 3~4일: 기획 반영 5일: 검증 테스트"이렇게요. 해본 적 있어요." "오, 이거 문서로 있어요?" "...아뇨. 그냥 제 방식이에요." 회의 끝나고 생각했다. 이런 걸 정리해야 하나. "빠른 리서치 프로세스" 공개하면 도움될 사람 있을 거다. 초보 기획자, 리서처. 시간 부족하다는 핑계 대는 팀. 근데 공개하면 내 경쟁력은? 아, 맞다. 이미 답했잖아. 방법 아는 것과 실행은 다르다. 과정의 가치 금요일 저녁이다. 퇴근 후. 카페에서 포트폴리오를 다시 열었다. 새 섹션을 만들었다. "Research Process & Learnings" 프로젝트 이름: 가명 처리 수치: 비율로만 표기 하지만 과정은 구체적으로. 금융 앱 온보딩 개선 케이스 배경:타겟: 금융 앱 처음 쓰는 40~60대 문제: 온보딩 중단율 66% 목표: 완료율 50% 이상리서치 설계:왜 중단하는가? (Why) 어디서 막히는가? (Where) 무엇이 어려운가? (What)1차 시도와 실패:온라인 설문 100명 → 표면적 답변만 "어려워요", "복잡해요" → 구체성 없음 학습: 정량보다 정성이 필요2차 인터뷰 설계:대면 인터뷰 20명 장소: 카페 (편안한 환경) 방식: 실제 앱 사용하며 Think Aloud인터뷰 중 발견:"이 버튼 누르면 돈 나가요?" (불안) "다음 화면 뭐 나올지 무서워" (예측 불가) "글씨 작아서 안경 써도 안 보여" (접근성)핵심 인사이트:문제는 '어려움'이 아니라 '불안' 설명 추가가 아니라 '신뢰' 구축 필요 단계별 '예측 가능성' 제공개선 방향:각 단계마다 "다음엔 이런 화면이 나와요" 미리 알림 "이 과정에서 결제는 발생하지 않아요" 명시 글자 크기 2단계 증가, 대비 강화결과:완료율 2배 증가 고객센터 문의 절반 감소교훈:표면적 불편이 아닌 근본 감정 파악 정량 데이터는 'What', 정성은 'Why' 가설 검증보다 발견이 더 중요이렇게 쓰니까 다르다. 단순 결과가 아니라, 사고 과정. 누군가 이걸 보면. "아, 이렇게 접근하는구나." "실패해도 괜찮구나." "과정에서 배우는구나." 주말이다. 토요일 오전. UX 스터디 모임에 갔다. 주니어 기획자 5명, 나. 한 명이 물었다. "선배님, 리서치 어떻게 배우셨어요?" "학교에서? 책에서?" 웃었다. "실패하면서." "처음엔 질문지 만들 때 유도 질문 가득했어." "인터뷰 시간 30분 계획했는데 10분 만에 끝났어." "녹취록 듣다가 내 질문이 답을 강요했다는 걸 알았어." "그런 거 포트폴리오에 써요?" "쓰려고. 이제." "왜요? 실패한 건데." "실패가 배움이니까." "과정이 없으면 결과도 의미 없어." 다들 고개를 끄덕였다. 한 명이 말했다. "저도 그렇게 써볼래요." "결과만 쓰니까 제가 뭘 했는지도 모르겠더라고요." 맞다. 그거다. 결과만 나열하면 나조차 기억 못 한다. 3년 전 프로젝트, 숫자는 기억나는데 과정은 흐릿하다. 과정을 기록해야 한다. 나를 위해서라도. 공개의 기준 일요일이다. 집에서. 포트폴리오 거의 완성됐다. 남편이 물었다. "다 된 거야?" "응. 근데 고민이야." "뭐?" "이거 블로그에 올릴까." "포트폴리오를?" "아니. 리서치 프로세스." "케이스 스터디 형식으로." "보안 문제 없게 각색해서." 남편이 생각하더니. "올려." "왜?" "첫째, 너한테 도움돼." "글 쓰면서 정리되잖아." "둘째, 남한테 도움돼." "검색하는 사람들 있을 거야." "셋째는?" "없어. 둘이면 충분하지." 웃었다. 그래, 충분하다. 공개 기준을 정했다. 공개 O:리서치 방법론 프로세스 설계 시행착오와 학습 질문 설계 팁 분석 프레임워크공개 X:구체적 프로젝트명 실제 수치 (비율로 변환) 회사 내부 전략 개인정보 관련 경쟁 민감 정보이 기준이면 괜찮다. 방법론은 공유하되, 맥락은 보호. 저녁이다. 포트폴리오 최종 버전. "Portfolio_2024_Final.pdf" 목차를 봤다.Career Summary Core Projects Research Process & Insights ← 새로 추가 Methodology & Tools Growth & Learnings ← 새로 추가섹션 3, 5가 새로 생겼다. 예전엔 없었다. 결과만 있었다. 이제는 과정이 있다. 실패도 있다. 배움도 있다. 더 진짜 같다. 나답다. 9년 차의 깨달음 월요일 아침이다. 출근했다. 컴퓨터를 켰다. 메일이 와있다. 작년에 강연 들었던 주니어에게서. "선배님, 포트폴리오 조언 구합니다. 결과만 쓰니까 공허해요. 과정을 넣고 싶은데 어떻게 해야 할까요?" 답장을 썼다. "실패한 것부터 써보세요. 처음 계획했던 것. 실제로 어떻게 바뀌었는지. 왜 바꿨는지. 결과가 좋았던 이유. 운이었는지, 실력이었는지. 다음엔 무엇을 다르게 할지. 이게 진짜 포트폴리오예요. 숫자가 아니라 사고방식을 보여주는 것." 보내고 나서 생각했다. 나도 이제야 알았다. 9년 차가 되어서야. 포트폴리오는 이력서가 아니다. 성과 자랑이 아니다. 사고방식을 보여주는 거다. 문제를 어떻게 바라보는지. 해결을 어떻게 접근하는지. 실패를 어떻게 배움으로 바꾸는지. 그게 진짜 경쟁력이다. 점심시간이다. 후배가 다시 왔다. "선배님, 포트폴리오 수정했어요." 봤다. 달라졌다. 프로세스가 추가됐다. 시행착오가 있다. 학습이 보인다. "훨씬 좋아졌네." "그죠? 근데 분량이 너무 길어졌어요." "괜찮아. 읽을 사람은 읽어." "안 읽을 사람은요?" "그 회사 안 가면 돼." 후배가 웃었다. "그것도 맞네요." 맞다. 결과만 보는 회사. 숫자만 중요한 회사. 그런 곳엔 안 가면 된다. 과정을 이해하는 곳. 사고방식을 평가하는 곳. 그런 곳이 좋은 회사다. 저녁이다. 퇴근 전. 블로그에 글을 쓰기 시작했다. 제목: "UX 리서치 케이스 스터디: 금융 앱 온보딩 개선" 부제: "결과가 아닌 과정, 성공이 아닌 배움" 서론을 썼다. "이 글은 완벽한 케이스가 아닙니다. 시행착오를 거친 과정입니다. 실패도 포함돼있습니다. 하지만 그게 현실이고, 그게 리서치입니다." 쓰면서 후련했다. 더 이상 결과만 포장하지 않아도 된다. 과정을 보여줘도 된다. 9년이 걸렸다. 이걸 깨닫는 데.공개할까 말까 고민했는데, 결국 과정 자체가 답이었다.

유저 리서치 비용이 너무 높다고요? 그럼 이렇게 설득해보세요

유저 리서치 비용이 너무 높다고요? 그럼 이렇게 설득해보세요

유저 리서치 비용이 너무 높다고요? 그럼 이렇게 설득해보세요 또 시작이다 월요일 아침 9시. 임원 메일이 왔다. "UX팀 리서치 예산 재검토 요청. 분기 3천만원은 과하다고 봄." 커피 들고 앉았는데 손이 떨렸다. 아니 떨린 건 아니고 어이가 없어서. 작년에도 똑같았다. 재작년에도. 9년 동안 매번 이거다. "리서치 비용 줄이고 빨리 만들면 안 돼요?" 안 된다. 절대로 안 된다. 근데 매번 이렇게 말할 수는 없으니까. 데이터로 말해야 한다. 숫자로.작년 실패 사례를 꺼낸다 회의실에 들어갔다. CFO, CTO, CPO 다 모였다. 준비한 자료 첫 장. 작년 실패 케이스. "작년 4월 출시한 ○○ 기능 기억하시죠?" 다들 고개 끄덕였다. 기억하지. 쪽팔린 기억. "개발 기간 3개월, 비용 2억. 출시 후 사용률 2.3%." "리서치 없이 기획했습니다. 유저 니즈 검증 안 하고." CPO 표정이 굳었다. 본인이 밀어붙인 건데. "2개월 뒤 서비스 중단. 2억이 증발했습니다." "리서치 비용은 500만원이었을 겁니다." 숫자를 비교하면 된다. 2억 vs 500만원. 실패 비용이 리서치 비용의 40배다.ROI 계산은 이렇게 다음 장으로 넘어갔다. 성공 케이스. "작년 9월, △△ 결제 플로우 개선 건." "리서치 비용 800만원. 유저 인터뷰 20명, 사용성 테스트 3라운드." "발견한 문제: 본인인증 단계에서 47% 이탈." "개선 후: 이탈률 12%로 감소." 숫자를 계산했다. 월 결제 건수 15만 건. 이탈 47%에서 12%로 줄면 5만 건 증가. 객단가 3만원이면 월 15억 매출 증가. 연 180억이다. "리서치 비용 800만원 투자해서 연 180억 매출 증가." "ROI는 2250배입니다." CFO가 계산기 두드렸다. 맞다는 표정. 이게 핵심이다. 리서치 비용을 비용으로 보지 말고 투자로 봐라. 실패 방지 비용이 아니라 매출 증대 투자다. 경쟁사는 뭐하나 자료 넘겼다. 경쟁사 벤치마크. "○○페이는 분기 리서치 예산 5천만원." "□□몰은 8천만원." "우리는 3천만원인데 삭감하면 1500만원." "경쟁사 절반도 안 쓰면서 UX로 이기겠다는 건가요?" CTO가 고개 들었다. "경쟁사도 저만큼 써요?" "네. 작년 UX 컨퍼런스에서 □□몰 팀장한테 들었습니다." "실제로 분기 8천에서 1억까지 씁니다." 숫자를 비교하면 된다. 절대액이 아니라 상대액. 우리 매출 대비, 경쟁사 대비. 3천만원은 전체 개발 예산의 1.2%다. 98.8%는 만드는 데 쓰고 1.2%는 검증하는 건데. 이게 과하다고?숨은 비용을 말한다 다음 슬라이드. 리서치 안 하면 생기는 숨은 비용. "첫째, 재작업 비용." 작년 통계 꺼냈다. 리서치 없이 기획한 기능 중. 출시 후 3개월 내 수정률 68%. 재작업에 들어간 개발 공수. 평균 2주. 개발자 1명 일당 50만원이면 2주에 500만원. 10건이면 5천만원 재작업 비용이다. "둘째, 기회비용." 잘못된 기능 만드느라 2개월 썼으면. 그 시간에 제대로 된 기능 만들었으면 생겼을 매출. 이건 계산도 안 된다. "셋째, 브랜드 신뢰도." 구린 UX로 유저 한 명 잃으면. 그 유저 평생 가치는 얼마인가. LTV 계산하면 50만원이다. 유저 1000명 이탈하면 5억 손실. 리서치 비용 3천만원이 아깝나? 작게 시작하는 법 CFO가 물었다. "그래도 3천은 부담이에요. 줄일 방법 없나요?" 있다. 당연히 있다. "우선순위 정하면 됩니다." 모든 프로젝트에 풀 리서치 안 해도 된다. Impact 크고 Risk 높은 것만 집중. 분기 5개 프로젝트면 2개만 깊게 파도 된다. "심층 인터뷰는 비싸니까 설문으로 대체." "사용성 테스트는 10명 대신 5명." "리모트 인터뷰로 출장비 절약." 이렇게 하면 3천이 2천으로 줄어든다. 근데 0으로는 못 줄인다. 최소선은 있다. "차라리 외주 리서치 줄이고 인하우스로." "Maze 같은 툴 쓰면 건당 비용 절반." "커뮤니티 패널 활용하면 리크루팅 비용 제로." 방법은 많다. 근데 없앨 수는 없다. 실전 팁 9년 하면서 터득한 것들. 타이밍이 중요하다. 예산 회의 때 말하지 말고 성공 직후에 말해라. 큰 프로젝트 성공하고 나서 "이거 리서치 덕분"이라고. 그때 다음 예산 이야기 꺼내면 통한다. 숫자를 준비한다. "유저가 불편해해요"는 안 먹힌다. "47%가 이탈했고 월 5만 건 손실"이라고 해야 한다. GA4, Hotjar, 설문 데이터 항상 준비. 실패를 기록한다. 리서치 안 한 프로젝트 실패하면 꼭 기록해둬라. 날짜, 비용, 결과, 원인. 나중에 증거로 쓴다. 동맹을 만든다. 개발팀장 설득하면 반은 이긴 거다. 개발자들도 재작업 싫어한다. "리서치 하면 재작업 줄어요"라고 하면 편 들어준다. 작은 성공을 쌓는다. 처음부터 큰 예산 받으려 하지 마라. 500만원으로 작게 시작해서 성과 내고. 그걸 근거로 1000만원, 2000만원 늘려가라. 진짜 이유 솔직히 말하면. 예산 삭감 요구의 진짜 이유는 돈이 아니다. 리서치의 가치를 모르는 거다. 눈에 안 보이니까. 당장 매출 안 나오니까. 개발은 눈에 보인다. 화면 나오고 기능 돌아간다. 리서치는? 보고서 나온다. PDF 파일 하나. 그게 얼마나 중요한지 경험 안 해보면 모른다. 내 역할은 그걸 보여주는 거다. 숫자로, 사례로, 비교로. 계속 보여주다 보면 언젠간 안다. "아, 리서치 없으면 안 되는구나." 9년 걸렸다. 우리 회사는. 작년부터 예산 삭감 요청 안 온다. 오히려 "더 필요한 거 없어요?" 물어본다. 포기하지 않기 이번 회의는 통과했다. 3천만원 그대로 유지. 근데 다음 분기에 또 올 거다. 분명히. "이번엔 좀 줄여야죠." 그때 또 싸워야 한다. 데이터 들고. 지친다. 솔직히. 매번 증명해야 하는 게. 디자이너는 디자인 예산 설득 안 한다. 개발자는 서버 비용 설득 안 한다. 왜 UX만 매번 싸워야 하나. 근데 이게 현실이다. 받아들여야 한다. 싸우는 방법을 배워야 한다. 숫자를 무기로. 후배들한테 말한다. "리서치 잘하는 것도 중요한데." "리서치 가치 설득하는 것도 실력이야." "그것까지 할 수 있어야 시니어지." 9년 차 되니까 안다. 진짜 싸움은 유저 리서치가 아니라 예산 회의실에서 벌어진다고.오늘도 이겼다. 다음 분기까지는.