오늘 기획이론을 공부하는데 헷갈리는 부분들이 꽤 있었고, 열심히 질문하여 이해된 부분을 정리해보고자 한다. 질문하다가 인터뷰 처럼 되었는데 아주 유익한 시간이었다. 나도 진짜 제품을 내놓아 사용자한테 피드백을 받아보고 싶어 진다.
1. 성공지표와 VS 가드레일 우선 이 두 요소가 비례와 반비례 관계가 아니다, 데이터를 분석할 때 이 둘의 상관관계는 확인되어야 한다.
2. 유저 시나리오 VS 유저 스토리 차이
답변 주신 분들 마다 개념 두 개의 명칭이 서로 엇갈리는 것 같다. 일단 개념 챙기고, 다니는 회사가 사용하는 명칭을 쓰면 될 것 같다.
📌 유저 시나리오 User Scenario #스토리텔링 #감성적 이해 #경험적인 것
- 특정 상황보다 백그라운드, 유저의 이야기를 나열하는 식, 전반적인 이야기 (유저 스토리는 기능적인 거)
- 살인자라면, 그 준비를 하는 과정 그 씬이 될 거고, 살인현장 장면일 수 있고.. 씬 바탕, 장치도 들어가고, 장소도 들어가고, 실내야 실외야? 혼자 집에서 쓰는 앱이야? 같이 쓰는 앱이야? 커뮤니티 바탕이야? 여러 가지 기능 구체화 할 때 많이 쓴다.
- 전체 플로우(전반적 서비스 흐름)를 유저테스트 할 때 유저 시나리오를 쓴다. 유저 스토리 보다 큰 범위.
📌 유저 스토리 User Story #개발 구현 가능 단위 #합의 도출 #걸킨 문법 #테스트 케이스
- 기능명세서와 비슷 (가장 구체적으로 - 이 화면에 어떤 기능이 들어가는데 이 기능이.. 어떤 요소가 있고.. 어떤 정보가 있는지, 명확하게 정리를.. 기능에 대한 요구사항)
- 캐릭터를 만들기 위한 스토리가 뭐지? 이 스토리가 더 유저에 더 가깝다!(고 정함) 스토리 바탕으로 페르소나가 만들어진다. 캐릭터 성격 중심, 기능 테스트 할 때도 참여자에게 스토링 텔링을 한다.
- 여러 기능 중, 일부 기능 테스트 할 때 유저 스토리를 쓴다. (유저테스트 할 때, 유저 시나리오 보다 유저 스토리를 실무에서 더 많이 씀)
3. 여러 페르소나를 중심으로 유저저니를 만들기도 한다는데, 그럼 그다음 단계에는 어떻게 되는 건지?
- 장 보는 앱을 예를 들어보자. 사용자는 주부가 있을 거고 자취생도 있을 수 있다. 주부랑 자취생은 저니가 조금씩 다를 수 있다. 지취생은 육아하는 주부가 가는 육아용품 쪽을 가지는 않을 것이다. 마켓컬리 경우, 젊은 주부들이 많이 사용. 그들이 메인 페르소나, 그들이 많이 쓰는 섹션을 앞단에 배치한다던지. 주요 페르소나 또는 다른 페르소나들은 어떻게 이 앱에 들어갈지, 뭘 중요하게 생각해서 어디로 들어갈지를 알아야 한다. 그들의 저니에 따라서 같은 앱을 쓰더라도 하나의 서비스에도 여러 가지의 플로우가 생길 수 있다. 서로 다른 저니에서 접점지도 있을 거다. 그걸 서비스에서 어떻게 구현하는지는 다음 문제. 타깃인 코어 페르소나 를 계속 업데이트해하고 숙지하고 있어야 프로덕트의 청사진처럼 사용할 수 있다.
4. 어떻게 페르소나를 업데이트하는지?
1st 파티 도메인 - 모니터링 가능, 가입회원 데이터로, 쌓이기 전에는 마켓 조사 통해서 페르소나를 만들기는 한다.
5. 시장조사 하고 유저 조사하고 분석해서 제품을 만들어 시장에 내놓아도 맞지 않는 경우가 많다던데?
틀린 것도 정답이다. 가설이 맞지 않으면 다시 애자일 하게 빨리 변화하는 시장에 맞춰 개선하고 다시 내놓는 일을 반복한다. 어쨌든 마켓은 예측불가다. 알아볼 수 있는 방법은 내 새끼를 시장에 내놓는 것 밖에 없다. 그리고 자리 잡을 수 있도록 현실감각을 키워주는 것이다.
6. 프로덕트 디자인 실력 향상의 가장 빠른 길은 시장에 내놓은 프로덕트 사용자들한테 두들겨 맞는 것이라는 말이 떠오른다.
진짜 맞는 말이다. 사용자는 냉정하다. 거기다 익명이니까. 내주머니에서 돈이 나간다 생각하면 100원 쓰는 것에도 내가 왕인 것처럼 행동한다. 보통 주니어 때는 사용자와 맞닥뜨리는 일이 별로 없다. 나 같은 경우는 시장이랑 전면대결을 3-4년 차 때부터 했다. 하도 단련되어서 이제는 '이것밖에 안 하나? 좀 더 세게 나와도 될 것 같은데?'라는 여유도 생겼다. (쓴배님..멋져요...😍)
강의 내용 중, '유저 페르소나의 가장 중요한 목적은 팀원들과 공감대를 형성하고 문제의식을 공유하는 것임을 잊으면 안 된다.'라고 하는데 페르소나를 '유저에게 공감하기 위해'라고만 알고 있는 터라 이해가 잘 가지 않았다. 그래서 튜터님을 찾아뵙고 그에 대한 설명과 알찬 조언을 얻었다.
페르소나를 만드는 경우
페르소나를 만드는 경우는 보통데이터가 없는새 제품을 만들고, 새로운 기능을 만들 때다. 사용자 데이터가 없는 상태에서는 페르소나가 중요한 데이터가 된다. 만약 메디컬 의사들만 또는 마라토너들만 쓰는 제품을 만들게 되었다고 해보자. 그렇다면 그들의 특수성을 알아야 하고, 사용할 이 유저들이 어떤 사람인지에 대한 이해도가 제품을 만드는 사람들끼리 함께 얼라인 되어야 한다.
페르소나의 쓰임새
페르소나 없이 팀회의를 하면 의견이 다를 때가 많다. 사용자입장에서 생각한다고 하지만 결국 주관적인 생각일 수 있기 때문.근데 여기서 페르소나를 정의하게 되면 팀원이 모두 페르소나의 입장에서 얘기하고 유대감 공감대가 생긴다.
페르소나가 여럿일 수 있다. 사용자가 하나의 스타일은 아닐 테니 2,3명은 될 수 있음. 하지만 회의할 때 1명의 페르소나 기준으로 얘기하자. 2번째면 2번째 기준으로 얘기하고, 그다음 페르소나 기준으로도 얘기하고 이런 식으로.
피그마에 컴포넌트 만들 때 불리언 on/off 될 수 있는 요소들, 불리언 적용하고 모두 다 on인 상태로 하나만 남겨라. 불리언 적용된 요소들이 각자 on/off된 경우의 수를 나열할 필요없다. 그런 부분은 개발과 운영조직이 협의하여 UI 문서를 따로 만든다. 이 문서를 피그마로 만드는 회사도 있지만 보통 다른 툴을 써서 만듦.
3. 프로덕트 역량 키우는 방법
가장 빠르게 성장하는 방법: 사수, 선배, 팀장 말고 사용자에게 많이 깨져보는 것. 진짜 성장은 내 디자인이 세상에 나갔을 때 시작이다.
기획력은 글쓰기에 달렸다 : 애매하거나 명확하지 않은 부분이 글에 드러나는 것 처럼 기획에도 선명하게 보인다 (어느 시점에는 꼭 질문하는 내용이 된다. 그 부분을 없애거나 보충하면 더욱 탄탄한 기획이 된다.)
누구보다 많이 찾아보기: 이미 출시한 프로덕트, 새로 출시한 프로덕트도 가리지 말고 전부 살펴보기. 업데이트 내용도 꾸준히 보기. 그림만 슬쩍 살펴보지 말고 가입도 하고, 꼼꼼하게 버튼 하나하나 눌러보고, 데이터도 넣어보며 이 제품이 어떻게 동작하는지 살펴보기.
연차 많이 쌓인 디자이너 분들이라도 따로 공부하시고 개인작업을 하시길래 한 튜터님께 따로 개인적으로 프로젝트 진행하시거나 컨퍼런스 가시는 등의 활동을 하시는지 여쭈어봤는데 '돈 주는 프로젝트만 작업하신다고' 하신다는 말씀에 빵터졌다. 디자인에 대한 고민에 대해서도 '연차가 쌓이고 나면 디자인, 기획 보다는 제품이 성공했는지가 제일 중요하다(사업 성공하기가 쉽지 않다)'고 하셨다. 정말 실무자만이 할 수 있는 이 현실적인 찐 조언에 감탄했다.
그리고 리서치 관련 숙제를 하다가 UX/UI 디자이너에게 추천하고 싶은 문구를 발견했다. 보자마자 'TIL에 무조건 넣을 각이다!'라고 외쳤다.
Since you are creating a product for someone else and not for yourself, any time is good to start UX research. The beginning doesn't have to be sophisticated. It can start simple and evolve, adapting to the amount/complexity of the questions about the users and the resources of your business. You only need curiosity, some time, and a willingness to base your product on facts and not assumptions. 제품을 (내가 아닌) 다른 사람을 위해 만들고 있는 것이기 때문에 (유저를 알기 위해서) UX 리서치는 어느 때 라도 할 수 있습니다(프로덕트 프로세스 중 어느 단계라도!). 시작은 복잡할 필요가 없습니다. 간단하게 시작하고, 사용자에 대한 질문의 양과 복잡성, 그리고 비즈니스 자원에 따라 진화하고 적응할 수 있습니다.
필요한 것은 호기심, 약간의 시간, 그리고 제품을 추측이 아닌 사실에 기반하려는 의지뿐입니다.
Replacing guesswork with data-driven insights: 문제정의를 할 때 데이터 기반보다 얼마나 많은 추측을 했던가. 그럼에도 신뢰할 수 있는 데이터를 모으고, 유저를 더 알고자 노력한다면 문제해결에 더 가까워질 수 있겠지. 거기다 나는 호기심이 많은 사람이니 좋은 UX/UI 디자이너가 될 수 있는 기반이 있다고 믿어본다. 😁
팀 프로젝트를 지난주에 하고 난 뒤, 회고를 했다. 우리 팀뿐만 아니라 본캠프에서 처음 만나 합이 잘 맞았던 첫 번째 팀 멤버들과 따로 만나서 한 시간 정도 서로의 팀 프로젝트가 어땠으며 무엇을 배웠는지 공유했다. 일단 희민님과 나는 이번에 같은 팀이었고 팀장님 잘 만나서 잘 이끌어주셔서 무탈하게 프로젝트가 진행되었다고 한 반면, 다른 두 분은 성향이 맞지 않은 팀원들과 마음고생을 많이 한 모양이다. 새삼스럽게 팀으로 일할 때 중요한 점을 다시 되새겨보았다.
WHY의 근거를 찾기가 쉽지 않았다. 즉, 리서치의 방향성을 제대로 잡아서 문제정의하기가 쉽지 않았다. 팀원들이 각자 열심히 자료를 조사했지만 결국 실제로 사용하는 유저들의 피드백이 제일 중요하다는 교훈을 얻었다. 그리고 이외로 유저들이 사용 서비스에 대해 가감없이 잘 말한다는 사실도 알 수 있었다. 몇 살이고 직업이 무엇인지 등의 단편적인 유저 페르소나 정의가 아닌 좀 더 깊이 있게 유저의 문제점을 파고들어야 문제정의가 탄탄해지고 솔루션에 의미가 있다는 것을 배울 수 있는 귀한 시간이었다. 팀과 함께 작업하며 협업의 재미가 있었고 모르고 있던 기능이나 꿀팁들을 알 수 있었다.
우리 팀 발표에 대한 튜터님 피드백 :
AS IS, TO BE 프로토타입으로 비교해서 보여준 거 잘 했다. (그외 칭찬이 더 있었는데 기억이..@_@) 설문조사에 대해 말할 때, 어떤 연령층이 있었고 조사 외에 블로그나 유튜브 댓글 등의 의견은 어땠는지 언급이 없어 아쉽다. 유기적으로 연결되는 결제설정 페이지 부분 까지 작업이 되었으면 좋았을 텐데 주어진 시간이 많지 않았으니 이해한다.
발표시간에 노트한 내용 :
디자인씽킹은 '아에이오우'만 말하는 것이 아닌 '공감, 문제정의, 솔루션 도출, 구현' 모든 과정을 의미한다.
경쟁사 분석 : 각 서비스의 차이점을 분석하는데, 목적 없이 분석하면 무의미.
유저 이탈을 강조하고 싶으면 이탈 주제에 대해 한 번 더 짚어주어야 한다. 경쟁사로 이탈이유 등등.
타겟 분석&정의는 굉장히 중요하다. 단편적으로 하면 XX, 왜, 어느 순간에, 어떤 고민을 하다가 이 앱을 쓰게 되었는지?
맥락있고 짜임새 있어야 한다.
문제정의가 탄탄해야 솔루션의 의미가 있다.
AS IS to TO BE 구성으로 어떻게 바꾸었는지가 나와야 한다.
장표구성 잘 하기! 근거 있는 자료로 신뢰를 주고, 여기서 어떤 결론이 났는지 잘 보여주어야 한다.
필터를 세분화하여 개선을 했는데 그게 미미해 보이지만 그렇지 않다. 큰 아이디어도 중요하지만 사소한 것 놓치지 않고, 작은 부분을 조금씩 개선하고 진짜 개선 되었는지 (사용자 관점, 비지니스 관점에서) 확인하는 작업을 하는 것이 프로덕트 디자이너의 역할.
받은 피드백으로 이 솔루션이 정말 최선이었는지, 더 나은 아이디어는 없었는지 회고하기
도메인 마다 다양하게 리서치하고 솔루션이 나오는데 여기서 그런 공부를 할 수 있으면 좋겠다. 분석해보고, 어떤 데이터가 있는지, 이 서비스에서는 어떤 플로우가 있는지 등등.
데드라인이 얼마 남지 않은 관계로 모두들 고군분투하는 하루였다. 드디어 유저리서치 질문지를 작성하고 배포했고, 개선의 근거를 확보했다. 주어진 가이드라인과 양식에 따라 지금까지 작업한 것을 정리하는 단계이고, 더 나아가서 선택한 서비스의 디자인시스템을 분석한 뒤 개선한 스크린 작업을 내일까지 마무리하고 제출하면 될 것 같다.
