[0311 TIL] 프로덕트 매니지먼트 개론 Chapter 3 + Figma 기초

실전 PM의 커뮤니케이션

• 사용자들에게 좋은 피드백을 얻을 수 있지만 매번 그렇지는 않음. 서비스가 종료되고 오히려 사용자들에게 안좋은 반응을 얻을 수도 있음을 알아야함
• 아이디어를 내고 기획안을 잘 쓰는 것도 중요하지만 현실적인 상황 (주어진 리소스. 주변 팀의 요구사항, 일정 등)을 고려해야함
• 현실적인 제약에서 불구하고 실제로 구현해내는 사람이 기획자에 가깝다 
• 아이디어에 장애물이 되는 일부 사용자의 불편함도 고민해야함 
• 문제 정의와 해결안을 포함한 방향을 제시하는 것은 PM의 역할, but 대부분 정답이 없는 상황이기 때문에 개발자 말도 맞고, 디자이너 말도 맞고 PM도 확신이 없는 경우가 있음 → 설득과 조율을 통해 자연스럽게 영향력을 확보해야함 
• 설득을 위해서는 논리적인 기획, 팀원들의 신뢰, 데이터 등이 필요함
• PM이 되기 위해 팀이 혼란스러울 때 무엇이 문제이고 어디로 가야하는지 명확하게 방향을 제시할 수 있어야함
• 개발자,디자이너,마케터 등 자유롭게 소통하며 제품을 만들어감 → but 이해관계가 엇갈릴 때 갈등을 조율하는 과정이 쉽지 않음. 

종합하자면,, PM의 역할은
- 사용자와 비즈니스를 위해 팀원들과 함께 제품을 세상에 내놓는 사람
- 문제 정의, 방향 제시, 커뮤니케이션, 실행 리더, 성과 책임

 

PM의 현실적인 어려움

• 내가 사용자가 아닌 제품을 담당하더라도 누구보다 사용자를 깊이 이해할 수 있어야함 
  • 제품이 속한 산업과 고객군에 대한 이해도가 매우 중요한데, 정작 PM은 그 대상에 대해 전혀 경험이 없거나 관심이 없는 경우가 있음 → 내가 겪어보지 않은 사용자의 니즈를 상상하기 어려움 

[해결방안]

• 직접 사용자가 되어 많이 써보기
• UX 리서치 (현장에 나가서 사용자 직접 만나기)
• 고객과 자주 만나는 회사 내부 전문가
• 온라인 SNS (커뮤니티) 분석

 

• PM 역할의 범위가 회사마다, 팀마다 조금씩 다름
  • 우리 회사에서 나에게 원하는 역할이 무엇인지 잘 파악해야함 

 

• 수시로 바뀌는 시장 상황과 회사 상황에 빠르게 적응해야함
  • 시장 상황이 바뀌면서 최상위 목표가 계속 변하기도 함 
  • 심리적으로 '계속 바뀌는 것이 당연하다' 는 것을 인지하기 

커뮤니케이션

• 팀 활동에서 주도적인 리딩 경험을 쌓고 회사에 입사하고나서는 체계적인 협업을 경험하기 
• 커뮤니케이션이 왜 오류가 날까? : 각자 알고 있는 정보, 목표가 다르기 때문이다 (내가 안다고 남들도 안다고 생각하지 말기) 

 

커뮤니케이션 원칙

1. 상대방의 니즈 파악

• 상대방이 원하는 것이 무엇인지 파악하기 (역지사지)
• 내가 원하는 것만 이야기하면 상대방은 공감하지 못하기 때문에 협업이 어려워짐 → 원하는 결과를 얻기 어려움 
• 상대가 중요하게 생각하는 기준을 파악하기, 상대방이 듣고 싶은 방식으로 이야기하기, 상대방의 언어로 말하기

2. 빌드업

• 결정을 통보하는게 아니라 사전에 정보를 공유하고 논리를 쌓아가며 자연스럽게 동의하게 만드는 과정
• 갑작스러운 통보로 인한 거부감 완화, 준비시간 확보, 피드백 반영, 참여 유도

3. 크로스체크 

• 내가 전달한 정보가 그대로 받아들여졌는지 확인하는 과정

 

 

 

 

Figma

마스터 컴포넌트

• 파운데이션을 결합해서 UI를 만듦
• 어떤 걸 만들기 위해 필요한 구성 재료들 → 컴포넌트
• 피그마에서 만든 UI 블록
• 마스터 컴포넌트 : 피그마에서 컴포넌트를 만들었을 때 기능의 핵심임
  • 복사한 디자인을 한 번에 수정하거나 편집할 수 있도록 해주는 중요한 기능
• 마스터 컴포넌트는 원본임 (내가 변경시키지 않는 이상 변하지 않음)
• 마스터 컴포넌트를 복제하면 복제본인 인스턴스가 생김 (인스턴스는 피그마 내에서 컴포넌트라고 부름)

 

인스턴스

• 마스터 컴포넌트의 복제본 → 마스터 컴포넌트의 속성을 그대로 받음

[마스터 컴포넌트와 인스턴스의 관계]

• 컴포넌트를 수정하면 인스턴스도 수정됨
• 인스턴스를 먼저 수정하면 컴포넌트를 수정해도 반영되지 않음
  • e.g. 인스턴스의 색상을 초록색으로 변경, 이후 마스터 컴포넌트의 색상을 보라색으로 변경했다면 인스턴스의 색상은 초록색으로 유지 (변경되지 않음)
• 컴포넌트를 지운다고 해도 인스턴스가 같이 지워지진 않음

 

디자인 시스템 이해

• 디자인 시스템 왜 필요하지? : 있으면 효율적임 , UI는 다른 디자이너도 똑같은 방법으로 만들고 쓸 수 있어야하고 개발자도 같은 생각이어야한다
• 효율성과 일관성
• 목적 : 반복적인 UI를 효율적으로 관리 / 팀 전체가 같은 정도로 이해
• UI 키트가 디자인 시스템인가? 틀린건 아니지만 정확한 건 아님. 규모에 따라서 UI 키트가 될 수도 있고..
• UI 키트는 단어만 있는 셈, 대신 문법이 하나도 없는 상태. → UI를 디자이너가 본인이 이해한대로 쓰게 됨
• UI 키트는 방법과 규칙은 없고 그냥 단순히 UI를 모아둔 것, 레시피
• 디자인 시스템 : 문서의 형태를 갖추고 있어야 함, 재료 목록, 레시피, 다른 메뉴들과의 궁합 등등
• 정리하자면,, 디자인 시스템은 UI 자체 뿐만 아니라 UI의 규격과 스펙, 사용 사례, 주의 사항 등이 총망라된 종합적인 제품 가이드라인
• 팀의 규모와 프로덕트의 사이즈에 따라 디자인 시스템 UI 키트 어떤게 더 좋은지 모름 반드시 뭐가 정답이다 할 수는 없음

⭐ 디자인 시스템은 효율적인 제품 설계를 할 수 있도록 하는 강력한 방법이지만 그만큼 준비하는 과정이 힘들고 어려움, 따라서 디자인 시스템을 만든다면 어디까지 만들지 팀원들과 매우 신중하게 의논하는 과정이 필요함

 

 

UI 디자인 기본

[UI의 분류]

• 액션 : 버튼
• 인풋 : 텍스트필드
• 인포메이션 : 토스트 메세지, 스낵바, 라벨
• 컨테이너 : 컴포넌트 여러 개가 결합되어 하나의 덩어리를 이루는 컴포넌트
• 내비게이션 : 네비게이션 바, 앱 바, 하단 바
• 컨트롤 : 라디오, 체크박스, 스위치

💡 중요한건 UI 분류를 정확히 아는 것보다 어떤 상황에서 어떤 기능을 하는지를 잘 알아채는게 더 중요함

• 의사상태 (가짜 상태) : 컴포넌트의 가상의 상태 → 버튼에 마우스를 올렸을 때 색깔이 바뀌는 건, 실제 버튼이 다른 버튼으로 바뀐게 아니라 버튼이 가진 가상의 상태를 말함
• 컴포넌트마다 쓸 수 있는 것과 없는 것이 있다~