내 경험 회고하기 노션 템플릿

안녕하세요, AWE님!제가 13일에 오픈하며 급하게 먼저 올려두느라 누락이 있었네요. 방금 과제와 템플릿 리스트, 셀프 코칭 체크리스트도 노션에 추가해두었습니다. (링크는 이게 전체 공개라서, 따로 걸지 않을게요 🙏) 과제 노션 문서만 따로 워크 스페이스에 복제해서 기한 입력해서 활용하시면 될 거 같아요. 질문 남겨주셔서 감사해요. 제가 놓치고 있던 부분인데, 덕분에 챙길 수 있었어요.좋은 밤 되세요!

영화님! 프로덕트 중심과 콘텐츠 중심이 약간 헷갈립니다

안녕하세요! 🙂말씀하신 것 처럼 구분이 다소 어려울 수 있습니다. 오히려 극단적인 경향성을 가진 회사들을 좀 더 짚어드리면 이해가 쉬우실 것 같아요. 콘텐츠 중심 회사는 말그대로 콘텐츠가 주가 되고 프로덕트는 보조해주는 역할을 합니다. 쉬운 예시는 강의 판매 플랫폼들이나 유튜브로 시작한 회사들이 그렇다고 해석할 수 있어요. 클래스 101, 인프런 등 강의 콘텐츠를 판매하는 회사는 프로덕트를 개선하는 것보다 양질의 강의가 올라왔을 때 전환율도 높아지고 매출의 임팩트가 크기 때문에 콘텐츠에 가장 집중하는 경향이 있어요.프로덕트 중심 회사는 프로덕트를 중심으로 디벨롭하는 회사를 말하는데요. 토스 같은 핀테크 회사도 그 중 하나 일 것 같고, 알라미 등을 만드는 앱 개발 중심 회사들도 그렇게 해석할 수 있을 것 같습니다. 회사에서 프로덕트가 있다고 해서 프로덕트가 완전히 메인으로 힘이 실리는 곳이 아닐 수 있다는 내용과, 회사별, 도메인별 역학관계에 대해서 설명드린 거라고 봐주시면 좋을 것 같아요. 어떤 회사들은 프로덕트가 있지만 세일즈에 훨씬 힘을 싣는 경우도 있고 콘텐츠에 힘을 싣기도 하거든요. 사업의 방향성과 경영진들의 의지에 따라 굉장히 달라지는 부분이기도 합니다. 혹시 추가로 궁금한 점이 있으면 언제든 질문 남겨주세요 😄

영화님! 각 직무별 역할 차이 및 그외 궁금한 점이 있습니다

안녕하세요, 답이 좀 늦었습니다 🙂 여러 질문 남겨주셨어요. 먼저 질문 남겨주셔서 감사합니다! 제가 이해하기로 질문이 세개로 정리되는 것 같네요.PM ↔︎ 서비스 기획자 ↔︎ PD나 UI/UX 디자이너의 역할 구분 이해디자이너 커리어 관점에서 어떤 직무부터 시작하는 게 좋은지, UI 디자인을 실무자가 얼마나 잘 해야하는지PM과 PD의 의견차이가 있을 때 어떻게 조율하는지 하나씩 답변드려볼게요. 1. PM ↔︎ 서비스 기획자 ↔︎ PD나 UI/UX 디자이너의 역할 구분 이해이거는 진짜 많이 궁금해하시는 단골 질문 중 하나예요. 그런데 이 롤에 대한 이해가 실무를 하기 전에는 많이 궁금하시겠지만 실무에서는 그렇게까지 중요한 질문이 아니기도 합니다. 왜냐면 "정해진 구분이 없"기도 하고 "회사 마다 다르"기도 하거든요. 이것을 잘 이해하기 위해서는 결국 두가지 롤에 대해서 잘 이해해야해요. 1) 서비스 기획자 2) 프로덕트 디자이너 이 두 직군이요. 1) 서비스 기획자 = 해외의 PM 역할 먼저 서비스 기획자를 살펴보면 한국의 특이한 형태의 조직구조로 인해 생긴 직무명이지 일반적으로는 해외에서 PM이 하는 역할과 비슷하다고 이해하시면 됩니다. 회사마다 서비스기획자/PM/PO등 다양한 명칭으로 불리지만 조직적 차이는 장르적 차이일 뿐 결국 의미있는 프로덕트를 만들어내기 위한 과정에서 스테이크홀더와 조율하며 개발자, 디자이너와 함께 일한다는 점은 동일하구요. 2) 프로덕트 디자이너 일반적으로 조직에서 만드는 서비스의 디자인과 관련된 모든 의사결정에 관여하는 사람으로 말씀하신 서비스 기획, 문제 발견, 해결을 하는 UX설계를 비롯해, 유저리서치, GUI 디자인, 디자인 시스템, 인터랙션 디자인, 그래픽 디자인, UX 라이팅, 브랜드 디자인까지 어느정도 전반적인 이해도를 바탕으로 관여를 하는 것이죠. 디자이너에 가깝습니다. 이 때 프로덕트 디자이너도 회사에서 준 역할에 따라 1번의 PM롤을 더 많이 하게 되는 경우도 발생할 수 있어요. 반대로 거의 디자인에만 집중하는 경우도 발생하게 돼요. 회사와 상황에 따라 다릅니다. 프로덕트 디자이너가 UX/UI 디자이너의 한단계 업그레이드 버전이라고 말씀해주셨는데 저는 사실상 같은 직무라고 보고 있어요. 하는 일이 거의 같거든요. 다만 프로덕트 디자이너는 조금 더 나은 팀 문화를 택하는 곳에서 부르는 직무명이라 좀 더 업그레이드 된 것으로 보일 수 있으나 실질적으로는 같은 일을 합니다. 3) UX 디자이너그럼 UX 디자이너는 뭐냐? 일반적으로는 1번인 서비스 기획자에서 UX 설계 부분에 집중하는 사람이기도 하고, 2번인 프로덕트 디자이너에서 UX 설계만 떼어서 집중하는 사람이기도 합니다. 그런데 1번과 2번에서 모두 PM롤을 일부 가져간다고 했잖아요. 그리고 1번과 2번 모두 회사마다 제품 상황마다 다르거든요. 그럼 회사 상황과 제품 상황을 보고 서비스 기획의 일부까지 깊게 관여하기도 하고, 아니기도 하겠죠!그래서 강의에서 중간에 있다 라고 표현을 했던 것이고 회사바이 회사 팀바팀이라 정해진 구분 또한 그것에 따라 왔다갔다 한다고 이해하시면 될 것 같아요 ㅎㅎ(사진)제가 이해하기로는 UX 디자이너는 네이버나 카카오 등 좀 대기업에서 채용하는 기획자 직무로 이해하고 있어요. UI 하다가 넘어가신 디자이너 분들을 몇분 알고 있기도 하구요! 이게 실무를 하는 입장에서는 별로 궁금하지 않은 질문인데 실무를 시작하기 전에는 매우 궁금하신 것 같더라고요. 일 자체가 중요하지 직무명이 중요하지는 않았어요. 일하는 방식이나 그런 것들은 자주 바뀌게 되는 게 일반적이라 업의 본질과 소프트스킬 쪽에 집중하시면 더 좋을 것 같다고 말씀드려봅니다 ㅎㅎ 2. 디자이너 커리어 관점에서 1) 어떤 직무부터 시작하는 게 좋은지, 2) UI 디자인을 실무자가 얼마나 잘 해야하는지1) 저는 10년 전에 그래픽 디자이너로 시작해서, UI/UX 디자이너를 거쳤고, 팀에서 프로덕트 디자이너로 직무명이 바뀌면서 그 뒤로는 쭉 프로덕트 디자이너로 업무를 진행했어요. 그런데 사실 처음 실무를 시작해야하는 지금 상황에서는 어떤 일이든 실무를 시작하는 것을 추천드려요. 요새 취업이 너무 힘들기도 하고 업무를 시작해서 배워가다보면 얻는 것들이 생기게 되거든요. 경력을 만들어가시면서 조금씩 jump up 하실 수 있는 방법이 충분히 많기 때문에 일단 어느 직무든 시작부터 하시는 것을 더 추천드려요.자세한 제 커리어에 대한 내용은 인프런 밋업 강의와 디자이너의 소프트스킬 관련 강의에서 다루고 있으니 참고 부탁드릴게요 🙂 2) UI 디자인을 실무자가 얼마나 잘 해야하는지는, 회사마다 굉장히 다른 것 같아요. 어떤 회사는 시스템이 굉장히 잘 갖춰져 있어 그렇게까지 엄청나게 중요하지 않은 경우도 분명 있고요. 어떤 회사는 프로덕트 디자이너에게 굉장히 높은 수준의 UI 디자인 실력을 요구하기도 합니다. 요구되는 역량은 채용 공고나 해당 회사에서 발행하는 콘텐츠들을 확인해보면 어느정도 감이 잡히실 수 있으니, 해당 회사에서 발행하는 다양한 자료들을 분석해보시길 추천드릴게요. 3. PM과 PD의 의견차이가 있을 때 어떻게 조율하는지사실 이런 경우는 의견차이의 내용이나 방식에 따라서도 매우 달라지기 때문에 답변하기 쉬운 질문은 아니긴 합니다. 롤이 겹치기는 하지만 공동의 목표는 제품의 성공인 경우가 많기 때문에 그것을 주지시키면서 조율하기도 하고, 1:1 커피챗 등을 통해서 라포를 형성하는식으로 해결하기도 하고 다양한 방식의 스킬들을 활용하곤 해요.개인적으로 가장 추천하는 책은 당당한 디자인 결정을 위한 9가지 방법이라는 책이에요. 이해관계자와 어떻게 조율하는지에 대한 손에 잡히는 팁들이 나와있어요.추가적인 내용은 디자이너의 소프트스킬 관련 강의에서도 일부 확인하실 수 있고요. 2019년에 진행한 토스, 디자인, 시스템 밋업에서 김소현 님이 자세히 풀어드린 예시도 참고하실 수 있을 것 같습니다. 토스의 다양한 컨퍼런스 등에서도 어떻게 조율하는지 소프트 스킬 등을 확인하실 수 있을 것 같아 한번 찾아보시는 걸 추천드릴게요 🙂 답변이 되셨으면 좋겠습니다.추가로 궁금한 내용이 있으시면 언제든 편하게 질문 남겨주세요 😄 감사합니다.

개발자가 PO역할을 하는 경우는 없나요?

안녕하세요, 박하탕 님! 질문 남겨주셔서 감사합니다.답이 좀 늦었습니다. 밑에 AI 인턴이 제법 잘 설명해줬네요 😅 두가지 질문이신 것 같아요. 디자이너나 개발자가 PO를 하는 경우가 없는지PO의 역량을 기르기 위해서는 미술적인 공부가 필수적인지두 질문에 대해서 하나씩 답변드릴게요. 1. 디자이너나 개발자가 PO를 하는 경우가 없는지디자이너나 개발자가 PO를 하는 경우가 있습니다. 실제로 저도 PO나 PM롤을 했었고, 지금 일하는 회사에서는 개발자 분이 PO 역할을 해주고 계세요.그렇지만 제 경험 상 이런 롤을 넘나들며 일하는 일은 초기 스타트업인 경우에 더 자주 일어나는 일 같아요. 시리즈 A 이상의 스타트업이나 그 이상의 대기업의 경우 이미 정해진 시스템과 방식이 있다보니 롤을 넘나들면서 일하기는 조금 어려운 것 같아요. 만약 직접 PO나 PM롤로 일하고 싶은 경우에는 회사와 이야기 해서 아주 작은 프로젝트를 수행해보시는 걸 추천드려요. 회사에서는 내 니즈와 욕구를 말하지 않으면 잘 모르기 때문에 이야기를 나누면서 조율하는 방식을 시도해보시길 추천드려요. 그러면서 많이 배우게 됩니다. 2. PO의 역량을 기르기 위해서는 미술적인 공부가 필수적인지미술적인 공부보다도 앱을 많이 써보고 분석하는 공부가 더 유용하다고 생각해요. 실제로 섹션 1 강의 중 나의 역할 - PO / PM / 서비스 기획자 / PD를 보시면 아래와 같은 이미지가 나와요.(사진)이 중에서 미술적인 공부로 보이는 UI 디자인은 2번인 고객 인사이트와 밀접할 것 같아요. 앱을 보고 어떤 사용자에게 어떻게 적용되기를 원하면서 만들었는지 분석하게 되면 이런 역량을 기르실 수 있게 될 것 같은데요. 아마도 UX 리서치와 UI/UX 디자인 영역의 다양한 인풋을 바탕으로 공부하실 수 있을 것 같아요. 이게 미술적 공부와는 살짝 거리가 있게 느껴집니다.제가 말씀드리고 싶은 말의 요지는 "결국 내가 가지고 있는 강점과 경험을 이해하고 어떻게 발전시킬지 더 적극적으로 탐색하고 알아가는 게 필요하다" 라는 건데요. 제가 박하탕님의 백그라운드는 모르지만 이렇게 한번 분석해보시면서 적어보셔도 큰 공부가 될 것 같습니다 🙂 답변이 되셨을지요?추가로 궁금한 점이 있다면 언제든 편하게 남겨주세요 😄 고맙습니다.

문제 정의 관련

안녕하세요! 답이 좀 늦었습니다 😀 아래와 같이 남겨볼게요! 먼저, 사용자, 비즈니스, 이즈니스에 대한 문제 정의는 팀에서 백로그를 만들 때 유용하게 활용되는 부분이라 세부 디자인 문제를 솔루션으로 낼 때에 대한 것을 설명하는 것은 아니라는 점을 짚고가면 좋을 것 같아요.팀이 어떤 문제를 풀 것인가 WHAT 에 대한 부분이고 이 부분은 PM이나 PO가 책임을 지고 디자이너는 참여를 하게 됩니다. 백로그를 만든다는 것을 쉽게 설명하기 위해서, 우리는 백로그를 '할 일 목록'이라고 생각할 수 있습니다. 프로젝트나 제품 개발에 필요한 모든 작업, 기능, 개선 사항, 버그 수정 등등의 이슈 티켓이 될수도 있고, 큰 범위의 어떤 사업을 선택할지 등을 생각하는 그런 작업이 될 수도 있어요. 이 전제를 하고 다시 궁금한 질문에 대해서 답변 드리면요.1번 질문B 관점에 있어서 저는 사용자가 아니지만, 사용자가 느낄 수 있는 문제를 많이 만났는데 이러한 방식으로 문제를 찾으면 안되는 것인지 궁금합니다.또는 이러한 방식으로 찾되 정량적, 정성적 검증을 하고 문제 정의가 된 후에만 솔루션을 만들어야 하는지도 궁금합니다.당연히 그런 방식으로 문제를 찾고 풀어도 됩니다.그리고 정량적, 정성적 검증을 하기 전에 솔루션을 만들어가도 됩니다. 다만 강의에서는 두가지 관점의 이야기를 하고 싶었어요. 첫번째는 제공자 관점에서 출발한 문제 정의와 솔루션 도출이 실제 사용자의 요구와 경험을 완전히 반영하지 못할 수 있다는 점을 인식하는 것이 중요하다는 점이에요. 제품 개발 및 개선 과정에서 사용자 리서치를 통해 실제 사용자의 목소리를 듣고, 이를 기반으로 문제를 정의하고 솔루션을 도출하는 것이 매우 중요함에도 불구하고 그런 접근 방식보다는 숫자를 보고 결정하기도 해요. 제품을 만들면서 우리는 너무 쉽게 비즈니스 중심, 혹은 쉽게 만들 수 있는지 등으로 의사결정을 하곤 하는데요. 그만큼 사용자의 문제를 수명 위로 끌어올리거나 하는 결정은 적게 하는 것 같아요. 그 임팩트가 큰 것임에도 말이에요. 두번째는 문제 검증을 먼저 하고 가야하는 부분인가에 대한 부분일 것 같은데요. 이게 먼저 잘 정의 된 상태에서 업무를 진행하게 된다면 훨씬 업무를 쉽고 빠르게 처리할 수 있게 되어요. 그래서 정석적인 방법을 알려드린거구요! 회사 업무를 더 오래 진행해서 경험이 쌓이게 되면 자기만의 일하는 방식이 생기기 때문에 굳이 정의 안해도 물 흐르듯이 일하게 됩니다. 2번 질문내 문제가 무엇인지부터 시작하는 것이 아니라 사용자 문제에서부터 시작하라는 말씀을 주셨는데요. 강의에서 예시로 주신 내용은 제공자 관점에서 출발한 문제, 정보수집, 솔루션 도출이라고 느껴지는데요. 이에 대해서 영화님 생각은 어떠신지 궁금합니다. 맞아요 ㅎㅎ 제공자 관점에서 시작한 문제 정의였어요! 회사 생활을 하다보면 거의 80%는 제공자 입장에서 문제를 해결하고, 그 솔루션에 대해서 검증하는데 재료로 디자이너가 사용자의 피드백을 많이 쓰게 되는 것 같아요. 만들고 UT를 하는 식으로 사용자 관점을 부어 해결하곤 했던 것 같아요. 한가지 더 짚고 넘어가고 싶은 부분이 있어요.사실 우리가 일하는 방식이 언제나 딱 정량화 되어서 필요한 검증을 거친 다음에 진행 할 수 있는 건 당연히 아니겠죠. 현실에서는 특히 회사 업무 중에서는 회사가 성장하고 생존 해야 되는 게 가장 우선순위가 높다 보니까 사용자의 문제 보다는 사업부에 문제를 해결하거나 회사가 생존 하는 걸 먼저 가져 가야 하는 게 옳게 느껴지는 거 같고 저도 거기에 공감 하는 것 같아요.다만 우리가 기억해야 할 것은 만약에 프로덕트 디자이너라면 사용자 관점에서 적극적인 의견을 부어주는 게 팀이 잘 될 수 있는 방법이라는 점이에요. 한가지 관점으로만 팀이 구성이 되어 있다면 견제 할 수 있거나 다른 의견을 줄 수 있는 사람이 없다 보니까 다양성 차원에서 조금 별로인 결정을 하게 되는 거 같아요. 그렇기 때문에 사실 디자이너는 외로울 수 밖에 없다 라는 생각도 들기도 하네요 😂 질문 남겨주셔서 저도 생각 정리해서 전달드릴 수 있어서 기뻐요. 스스로 생각도 해보셨을 거 같아요! 이렇게 고민 되는 것들 계속 남겨주시면 좋을 것 같아요. 감사합니다.

가설 검증 시, 실현가능한 성공 지표 설정 방법

안녕하세요, 학영 님 🙂 일단 질문 남겨주셔서 넘 감사합니다! 많은 분들한테도 도움이 되실 것 같아요.꼭 필요한 개선임에도 불구하고 우선순위가 자꾸 밀려서 답답한 마음이시군요...저도 비슷한 경험이 있어서 이 마음에 공감이 되기도 해요. 인트로에서 설명했다시피 저는 워터폴로 일해본 적이 더 적어요. 그리고 일의 맥락이 충분하지 않으면 답변하기 어려운 질문이라 짧게 답변을 하기엔 쉽지 않네요. 그래도 생각나는대로 조금 길게 적어보면요, 만약 저라면 다음과 같은 방법을 활용해볼 것 같아요.업계 벤치마킹 지표 알아보기: 비슷한 도메인의 회사들, 비슷한 패턴을 가진 UX에서 UX를 어떻게 개선해봤는지 살펴봐요. 이런 사례들을 보면, 그들의 변화가 얼마나 효과가 있었는지, 특히 사람들이 더 많이 사용하게 되었는지, 새로 가입한 사람들이 많아졌는지 알 수 있어요. 이 정보를 우리 제안에 어떻게 적용할 수 있을지 생각해보면 도움이 돼요. 실제 다른 회사 실험등의 지표를 공개한 자료들을 통해 실험의 구체적인 임팩트를 측정할 수 있으면 좋겠죠. 비슷한 실험을 했는데 이 컴포넌트 개선, 혹은 이 플로우 개선은 NN%올랐어 등의 자료를 모을 수 있는 방법이 아예 없진 않을 거 같아요. 커뮤니티가 도움이 될 수도 있겠죠.프로토타입으로 UT: 가능하다면, 우리가 생각한 개선안을 실제로 만들어볼 수 있는 간단한 버전, 즉 프로토타입을 만들어서 사람들이 직접 써보게 해보세요. 이렇게 해서 받은 피드백으로 우리 아이디어가 실제로 얼마나 좋은지, 어떤 부분을 더 개선해야 하는지 알 수 있어요.전문가 의견: UX나 디자인 분야에서 꽤 경험이 많은 사람들한테 우리 아이디어에 대해 의견을 구해보세요. 이런 사람들은 비슷한 상황에서 어떤 것들이 잘 통했는지, 우리 아이디어가 실제로 얼마나 효과가 있을지에 대한 좋은 조언을 줄 수 있어요.리스크 대비: 아무리 잘 계획해도 예상치 못한 일이 생길 수 있어요. 그래서 우리 제안을 할 때, 이게 잘 될 거라고 생각하는 근거를 명확히 하면서도, 만약 잘 안 되면 어떻게 할지에 대한 계획도 같이 세워두는 게 좋아요. 이렇게 하면 뭔가 잘못되더라도 당황하지 않고 대처할 수 있어요. 이러한 부분은 혼자 고민하기 보다는 리더나, 아젠다를 끌고갔던 실무자 분께 여쭤보면 조금 더 팁을 얻을 수 있어요. 이런 부분을 잘 알고 있으면 설득하기 쉬울 것 같아요. 회사의 비즈니스 방향성에 대한 이해: UX 개선안을 제안할 때는 이게 우리 회사의 비즈니스 골과 방향성과 얼마나 잘 맞는지를 확실히 보여줘야 해요. 예를 들어, 우리가 원하는 건 더 많은 사람들이 우리 서비스를 쓰게 하거나, 이미 쓰고 있는 사람들이 더 만족하게 만드는 거잖아요. 그래서 우리가 바꾸려는 부분이 이런 목표에 어떻게 도움이 될지를 세세하게 설명해야 해요.회사 안의 이해관계자와 대화: 회사 안에서 다른 팀과도 잘 얘기해봐야 해요. 비즈니스나 마케팅 팀, 개발 팀처럼 여러 팀이 있잖아요. 이런 대화를 통해 우리 회사가 정말 중요하게 생각하는 게 뭔지, 그리고 우리가 제안하는 UX 개선안이 왜 중요한지, 어떤 문제를 해결할 수 있는지에 대한 더 넓은 시각을 가질 수 있어요. 이렇게 하면 우리 제안이 회사에 정말 필요한 거라는 걸 더 잘 보여줄 수 있을 거예요. 그리고 대화 하는 과정 자체를 통해서도 학영 님께서 많이 배우는 부분이 생길 수 있고요. 추가로 고민해볼 수 있는 건 다음과 같은 내용들이 있을 것 같아요.꼭 필요한 개선이 맞을까? 그 근거는 무엇일까? 누구의 도움을 받으면 이걸 정확하게 인지할 수 있을까? → 우선순위를 올리는데 있어서 이 개선안에 대해서 설득할 수 있으려면 이 개선안과 다른 업무들 간의 우선순위를 버드뷰로 인지하고 있으면 좋아요. 제 강의의 메타인지와 구조화 섹션에서 자세히 볼 수 있으니 그 섹션을 참고해보셔도 좋을 것 같아요.만약 꼭 필요한 개선이 맞다면 팀을 잘 설득하기 위해 필요한 재료는 무엇일까? → 다른 팀원일수도 있고 설득하는 근거나 숫자일수도 있겠죠. 이 부분에 대해서 어떻게 설득할 수 있을지 한번 고민해보셔도 좋을 것 같아요!섹션 2. 메타 인지와 구조화, 섹션 4. 프로덕트 스테이지별, 기능별, 도메인별, 유저 져니별 문제해결 사례를 보시고 셀프 체크리스트를 풀어보신 다음에 질문에 대해서 셀프로 답변해보셔도 학영 님께 도움이 되실 것 같습니다! 궁금한 점 있으면 지금처럼 계속 질문 남겨주세요 😄