문제 정의 관련

24.02.22 12:56 작성 조회수 199

2

영화님 안녕하세요. 강의 정말 잘듣고 있습니다 !

3강 내용 중 사용자, 비즈니스, 이즈니스에 대한 문제 정의에 대해 궁금하여 2개의 질문드리게 되었어요.

  1. <나는 사용자가 아니다>라는 점을 인지하면서 문제를 풀어야 한다고 강의해주신 점에 대해 조금 더 구체적으로 보강 설명을 해주실 수 있으실까요?

     

    • (질문의 배경)실제로 저는 아래와 같은 2개의 관점을 둘다 이용하는데요.

      • A 관점

         

        • 이 경우 프로덕트 디자인을 제작하는 입장에서의 문제를 찾는 관점임

        • 전문가 입장에서 사용성 문제를 찾는 관점 때문에 일반 사용자가 못느끼는 문제를 해결하는 시도인 경우가 많았음 - 휴리스틱 평가와 비슷하게 문제를 찾는 형태

           

      • B 관점

        • 제품을 이용해보면서 느낀 사용자 관점

        • 이 관점에서 문제는 팀원들도 쉽게 설득시킬 수 있었고 사용자에게 어떤 가치를 주느냐에 대한 임팩트가 큰 문제라고 느낌

      • 결론적으로 궁금한 점

        • B 관점에 있어서 저는 사용자가 아니지만, 사용자가 느낄 수 있는 문제를 많이 만났는데 이러한 방식으로 문제를 찾으면 안되는 것인지 궁금합니다.

        • 또는 이러한 방식으로 찾되 정량적, 정성적 검증을 하고 문제 정의가 된 후에만 솔루션을 만들어야 하는지도 궁금합니다.

  2. 이론 내용에서는 내 문제가 무엇인지부터 시작하는 것이 아니라 사용자 문제에서부터 시작하라는 말씀을 주셨는데요.

    • 강의에서 예시로 주신 내용은 제공자 관점에서 출발한 문제, 정보수집, 솔루션 도출이라고 느껴지는데요. 이에 대해서 영화님 생각은 어떠신지 궁금합니다.

       

 

제가 아직 3강까지 밖에 못들어서 드리는 질문일 수도 있는 점 양해 부탁드립니다 !

감사합니다.

답변 1

답변을 작성해보세요.

2

안녕하세요!

답이 좀 늦었습니다 😀 아래와 같이 남겨볼게요!

 

먼저, 사용자, 비즈니스, 이즈니스에 대한 문제 정의는 팀에서 백로그를 만들 때 유용하게 활용되는 부분이라 세부 디자인 문제를 솔루션으로 낼 때에 대한 것을 설명하는 것은 아니라는 점을 짚고가면 좋을 것 같아요.
팀이 어떤 문제를 풀 것인가 WHAT 에 대한 부분이고 이 부분은 PM이나 PO가 책임을 지고 디자이너는 참여를 하게 됩니다. 백로그를 만든다는 것을 쉽게 설명하기 위해서, 우리는 백로그를 '할 일 목록'이라고 생각할 수 있습니다. 프로젝트나 제품 개발에 필요한 모든 작업, 기능, 개선 사항, 버그 수정 등등의 이슈 티켓이 될수도 있고, 큰 범위의 어떤 사업을 선택할지 등을 생각하는 그런 작업이 될 수도 있어요.

 

이 전제를 하고 다시 궁금한 질문에 대해서 답변 드리면요.

1번 질문

B 관점에 있어서 저는 사용자가 아니지만, 사용자가 느낄 수 있는 문제를 많이 만났는데 이러한 방식으로 문제를 찾으면 안되는 것인지 궁금합니다.

또는 이러한 방식으로 찾되 정량적, 정성적 검증을 하고 문제 정의가 된 후에만 솔루션을 만들어야 하는지도 궁금합니다.

당연히 그런 방식으로 문제를 찾고 풀어도 됩니다.

그리고 정량적, 정성적 검증을 하기 전에 솔루션을 만들어가도 됩니다.

 

다만 강의에서는 두가지 관점의 이야기를 하고 싶었어요.

첫번째는 제공자 관점에서 출발한 문제 정의와 솔루션 도출이 실제 사용자의 요구와 경험을 완전히 반영하지 못할 수 있다는 점을 인식하는 것이 중요하다는 점이에요. 제품 개발 및 개선 과정에서 사용자 리서치를 통해 실제 사용자의 목소리를 듣고, 이를 기반으로 문제를 정의하고 솔루션을 도출하는 것이 매우 중요함에도 불구하고 그런 접근 방식보다는 숫자를 보고 결정하기도 해요.
제품을 만들면서 우리는 너무 쉽게 비즈니스 중심, 혹은 쉽게 만들 수 있는지 등으로 의사결정을 하곤 하는데요. 그만큼 사용자의 문제를 수명 위로 끌어올리거나 하는 결정은 적게 하는 것 같아요. 그 임팩트가 큰 것임에도 말이에요.

 

두번째는 문제 검증을 먼저 하고 가야하는 부분인가에 대한 부분일 것 같은데요.
이게 먼저 잘 정의 된 상태에서 업무를 진행하게 된다면 훨씬 업무를 쉽고 빠르게 처리할 수 있게 되어요. 그래서 정석적인 방법을 알려드린거구요! 회사 업무를 더 오래 진행해서 경험이 쌓이게 되면 자기만의 일하는 방식이 생기기 때문에 굳이 정의 안해도 물 흐르듯이 일하게 됩니다.

 

 

2번 질문

내 문제가 무엇인지부터 시작하는 것이 아니라 사용자 문제에서부터 시작하라는 말씀을 주셨는데요. 강의에서 예시로 주신 내용은 제공자 관점에서 출발한 문제, 정보수집, 솔루션 도출이라고 느껴지는데요. 이에 대해서 영화님 생각은 어떠신지 궁금합니다.

맞아요 ㅎㅎ 제공자 관점에서 시작한 문제 정의였어요! 회사 생활을 하다보면 거의 80%는 제공자 입장에서 문제를 해결하고, 그 솔루션에 대해서 검증하는데 재료로 디자이너가 사용자의 피드백을 많이 쓰게 되는 것 같아요. 만들고 UT를 하는 식으로 사용자 관점을 부어 해결하곤 했던 것 같아요.

 


한가지 더 짚고 넘어가고 싶은 부분이 있어요.

사실 우리가 일하는 방식이 언제나 딱 정량화 되어서 필요한 검증을 거친 다음에 진행 할 수 있는 건 당연히 아니겠죠. 현실에서는 특히 회사 업무 중에서는 회사가 성장하고 생존 해야 되는 게 가장 우선순위가 높다 보니까 사용자의 문제 보다는 사업부에 문제를 해결하거나 회사가 생존 하는 걸 먼저 가져 가야 하는 게 옳게 느껴지는 거 같고 저도 거기에 공감 하는 것 같아요.

다만 우리가 기억해야 할 것은 만약에 프로덕트 디자이너라면 사용자 관점에서 적극적인 의견을 부어주는 게 팀이 잘 될 수 있는 방법이라는 점이에요. 한가지 관점으로만 팀이 구성이 되어 있다면 견제 할 수 있거나 다른 의견을 줄 수 있는 사람이 없다 보니까 다양성 차원에서 조금 별로인 결정을 하게 되는 거 같아요. 그렇기 때문에 사실 디자이너는 외로울 수 밖에 없다 라는 생각도 들기도 하네요 😂

 

질문 남겨주셔서 저도 생각 정리해서 전달드릴 수 있어서 기뻐요. 스스로 생각도 해보셨을 거 같아요! 이렇게 고민 되는 것들 계속 남겨주시면 좋을 것 같아요.

감사합니다.