문제 정의 관련

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

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

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