전체 아카이브

https://abr.ge/zwa9px

[프로덕트 & 데이터 분석]

프로덕트 분석

비즈니스 전략

Product-Led Growth와 No-Code는 확실히 2020년과 2021년의 핫 트렌드였습니다. 다음 2022년 및 그 이후의 다음 제품 트렌드에 대한 5가지 소개합니다. 구매 잊기 이 키워드는 스토리지, 모니터링 및 백업의 기능을 제공하는 제품에 알맞습니다. 고객이 데이터를 어딘가에 저장해야 하는 기능적 요구 사항 을 찾고 있다면 더 중요한 것은 데이터가 안전하다는 것을 알고 마음의 평화를 얻는 감정적인 요소가 있습니다. - 참여도가 낮은 제품은 핵심 기능에만 집중하면 되기 때문에 일반적으로 유지 관리가 더 쉽습니다. 즉, 고객은 문제가 발생했을 때만 제품을 찾아오면 됩니다. - 반복 가치 는 고객이 1년 이상 서비스를 사용하지 않은 경우에도 제품을 유지하고 신용 카드 정보를 계속 업데이트하도록 유도하는것이 좋습니다. ROI 리포팅 B2B 기업에 해당 되는 키워드입니다. 가치와 수익이 매치되는 프로덕트는 쉽게 고객에서 설득할 수 있습니다. 구매자는 제품 비용, 설치 비용, 이 새 앱을 유지 관리하는 비용, 교육하는 비용, 제대로 작동하지 않는 비용은 얼마인지 궁금해 합니다. 이러한 경우 가장 좋은 방법은 ROI에 대해 보고하는 것입니다. 특정 방식으로 가치를 추가하겠다고 구매자에게 약속하고 이를 증명하세요. Tip #1: 집착은 하지 마세요. 항상 가능한 것은 아닐 수도 있습니다. Tip #2: 경쟁업체에서 배우고 복사해보세요. 유료 활성화 사용자는 완전히 활성화되기 전에 마지막 고비를 넘기 위해 약간의 넛지가 필요할 수 있습니다. 이러한 경우 활성화하기 위해 "지불"하는 것을 두려워하지 마세요. SaaS를 먹는 SaaS 일반적인 SaaS 제품이라면 Twilio, Stripe, Algolia 같은 기술 스택의 일부로 사용하는 것이 가속화 될것입니다. 이러한 앱은 많은 소프트웨어 제품의 중추를 형성했지만 부차적인 경험에 대해서 유효합니다. 또한 이런 경향은 메인 SaaS는 경험에도 영향을 미칠것입니다. Ed-Tech 탐구 Ed-Tech은 콘텐츠 마케팅의 확장이라고 생각할 수도 있지만 그 이상입니다. 일반 대중에게 자신의 프로덕트 이점에 대해 교육해야 합니다. 현재 Ed-tech 비즈니스 모델은 다음과 같습니다. (a) 무료, 무작위 광고로 수익 창출(Youtube) (b) 무료, 팬으로부터 후원 또는 기부금 모으기(Patreon) (c) 과정당 유료(Udemy) (d) 월별 유료(Treehouse)

마켓플레이스에서 공급자를 늘리는 28가지 방법 by AirB&B Supply Growth Leader

https://abr.ge/u0r1az

[그로스 전략]

스타트업

마케팅

비즈니스 전략

※ 자세한 설명과 예시는 원문에서 확인 가능합니다. 1. 공급자에게 제공할 수 있는 가치를 제공할 수 있는 가치를 내걸어라 2. 가치를 노출시킬 엔트리 포인트를 만들어라 3. 추천인 프로그램을 만들어라 4. 다이렉트 세일즈(직접 영업) 5. 기존의 네트워크에 편승해라 6. 모임을 주최해라 7. 각종 이벤트와 PR을 활용해라 8. 퍼포먼스 마케팅 9. 수요를 공급으로 전환시켜라 Ex. 로블록스 플라이휠 10. SEO 최적화 11. 공급자 인수 12. 공급업체와 제휴하기 13. 당신만의 공급채널을 만들어라 14. 광고 실행 15. 제휴 마케팅 실행하기 16. 우편물 보내기 17. 전환을 최적화하고 전환율을 올려라 18. 재참여 유도를 위해 푸시 이메일을 보내라 19. 재참여 유도를 위해 전화해라 20. 활성화(아하 모먼트) 최적화 21. 리텐션 최적화 22. 기존 공급채널 확대 23. 이윤 증대, 비용 절감 24. 수요가 없어도 공급자에게 가치를 제공할 수 있게 하라 25. 충분한 양의 공급자가 확보되는 임계치를 달성해라 26. 신뢰를 획득해라 27. 해외진출을 염두에 둬라 28. 세그먼트 공급자를 확대해라

UX writing 매거진 (by 브런치 작가 Joo Jun님)

https://abr.ge/nmonwi

[디자인]

UX Writing

사실 한국어 UX writing의 역사는 짧지 않습니다. 적어도 13년 전부터 초창기 네이버의 훌륭한 테크니컬 라이터 분들이 네이버의 스타일을 정리하셨고, 삼성과 LG휴대폰의 UX 조직에 규모 있는 UX writing팀이 있어 왔습니다. UX writer, Contents designer들의 고요한 성정 때문인지 몰라도 UX, UI, CX에 대한 글에 비해 한국어 UX writing에 대한 글이나 책도 많지 않았습니다. 책 역시 참고할만한 것이 무척 적은 상황인데, 『웹 기획자가 알아야할 서비스 글쓰기의 모든 것』 (2016) 외에는 한국어 UX writing에 대한 레퍼런스가 될만한 책은 사실 없었어요. Facebook, Instagram, Google 같은 글로벌 서비스를 매일 쓰지만 묘하게 그들의 텍스트가 우리의 언어 감각과는 안 맞는 것 같은 불편한 느낌, 느끼신 적 있나요? 또한 해외 사례를 한국에 도입하려해도 언어 특성상 어려운 지점이 분명 있습니다. 이런 한국어 UX writing 상황에 대해 하고 싶은 말, 나누고 싶은 경험들을 일단 글로 써서 지식을 나누며, 나름의 의견을 내고자 이 시리즈를 작성합니다. 매거진의 목차는 대략 이렇습니다. 일단 UX writing의 주요 원칙에 대해서 살펴보고, UI 텍스트와 각 컴포넌트별 레이블 작성법에 대해서도 간단히 이야기합니다. 실무에서 designer와 writer가 뭘로 투닥투닥하는지, 어떤 이슈가 우리들을 힘들게 하는지도 알아봅시다. 우리에겐 한국어 writing 사례가 필요하므로 마지막에는 제가 이용하고 있는 서비스들의 UI 텍스트들도 중간중간 분석하는 가벼운 챕터도 준비하고 있습니다. ----------------------- 매거진 본문 중 특히 흥미로운 글을 B2B 디자이너 커뮤니티에 소개합니다. UI 텍스트 쓸 때 종종 등장하는 '-하기' 어미에 대해 어떻게 생각하시나요? 글쓴이는 먼저 '-하기'를 자제하자는 요지의 글을 올렸었는데, 일부 특정한 환경에서는 필요에 따라 '-하기'를 써도 좋겠다는 후속 글을 올렸습니다. 잘 정리된 글이지만 작성자 개인의 의견이므로, 이 글을 읽으시는 분들께서 여러 의견을 표출한다면 한국어 UX writing 발전에 도움이 되지 않을까 싶습니다. '-하기'를 그만하기 https://brunch.co.kr/@joojun/101 '-하기'형, 버튼이 왜 이래 (서비스의 욕망이 살그머니 드러나는 지점) https://brunch.co.kr/@joojun/113 [통합 요약] - 서술형 명사 2음절만으로도 충분한데도 '-하기'를 붙여서 억지로 명사를 만들어 쓸 필요가 없다. '-하기'를 반복해서 쓰면 텍스트 간결성, 가독성, 의미변별성이 모두 나빠진다. - 4음절 선호는 그저 익숙함 때문이다. 긴 버튼에서의 양쪽 여백이 신경쓰인다면 톤 앤 보이스를 살려서 문장형 버튼을 적용하는게 차라리 낫다. - 필요한 순간, 쓰고 싶은 순간에는 '-하기'를 써라. 다만 모든 버튼을 '-하기', '-기'로 끝내려 하지는 말자. - '-하기'는 '-음'이나 서술형 명사보다 사용자 스스로가 해당 액션을 다짐하는 듯한 인상을 주기 때문에 앱 제작자는 CTA에 적용하고 싶어지는 느낌이 들 수도 있다. - 마켓컬리 앱은 1) 컨트롤러로써 동작하는 기능적인 버튼에서는 명사 형태로 쓰고, 2) 사용자의 액션을 강력하게 끌어와야 하는 버튼에 '-하기'를 쓴다. - '-하기'는 워낙 은근한 장치이기 때문에 사용자의 선택에 결정적인 영향을 미치는 일은 없다고 본다. - 다만 가능하면 구매, 구독, 결제와 같이 서비스 입장에서 중요한 버튼에만 드물게 '-하기'를 붙이면 좋겠다.

제품 로드맵에 대한 궁극적인 가이드

https://abr.ge/tftk8k

[워크 프로세스]

프로덕트 전략

제품 로드맵에 대한 궁극적인 가이드 제품 로드맵이란 무엇입니까? - 제품 전략을 실행하기 위한 계획과 지침이 되는 전략 문서 제품 로드맵이 중요한 이유는 무엇입니까? - 제품 로드맵은 제품 전략이 어떻게 현실화되는지 요약 - 제품과 제품의 성공에 대한 영감, 동기 부여 및 공유 소유권의 원천 - 조직이 혼란을 피하고, 소규모 프로젝트가 구현 대기열에 들어가지 않고, 덜 중요한 작업에 리소스를 낭비하는 것을 방지 <제품 로드맵 구축> 제품이 성숙해짐에 따라 로드맵이 발전함. 새로 만든 MVP와 성숙한 제품은 다르다. - 지평(Horizon): 스타트업은 미래 요구사항과 기회를 예측하기 어렵고, 로드맵이 멀지 않음. 기존 제품은 고객과 시장을 더 잘 이해하고, 확고한 장기 계획을 세움. - 빈도(Frequency): 미숙할 때는 "항상 배포"해야합니다. 성숙한 제품은 덜 긴급하게 릴리즈할 수 있다. - 종속성(Dependencies): 스타트업은 빠르게 움직이고 부술 수 있다. 성숙한 제품은 레거시, 써드파티 통합, 역행 이슈 등이 있다. - 목표(Goals): 스타트업은 생존 가능성을 증명하고, 견인력(traction)을 얻고, 성장하려고 노력해야함. 엔터프라이즈는 미묘한 전략적 목표와 다양한 타겟을 가진다. 제품 로드맵을 어떻게 계획합니까? 몇가지 필터가 있음. - 사용자에게 실제 가치가 있는가? - 그 가치에 대한 증거가 있는가? - 소유자(owner)가 있는가? (챔피언 역할) - (기존 로드맵에) 어울리는가? 제품 로드맵에서 기능의 우선 순위를 어떻게 정합니까? - OKR, MoSCow , RICE Scoring Model 등 선택할 수 있는 프레임워크가 다양함. - 궁극적으로 어떤 접근 방식을 선택하든지 가치, 노력 수준 및 기회 비용에 대해 각 항목을 평가해야함. - 팀은 또한 단기 승리와 장기 목표를 향한 진전의 이점을 비교해야 함. <추가 로드맵 팁> 로드맵에 여러 제품을 추가하는 방법 - 일관성은 이 문제를 해결하는 열쇠 - 로드맵 스타일, 범례, 색상 코딩, 시간대 및 세분성 수준에 대한 정렬은 필수 - 버전 관리 문제도 잊지 마세요! 애자일 로드맵은 무엇입니까? - 훨씬 더 짧은 기간을 가지며 변화하는 우선순위와 시장 기회를 수용하기 위해 더 자주 조정 - 로드맵을 최신 상태로 유지하는 것이 성공의 가장 큰 비결 중 하나 다양한 유형의 제품 로드맵은 무엇입니까? - 경영진을 위한 내부 로드맵: 계획된 작업이 제품(및 회사)의 가치를 어떻게 높일 것인지에 중점 - 엔지니어를 위한 내부 로드맵: 기능, 릴리스, 스프린트 및 이정표에 중점 - 판매를 위한 내부 로드맵: 기능과 고객 이점의 조합에 중점 - 고객 및 잠재 고객을 위한 외부 로드맵: 릴리스 또는 출시 날짜를 포함하지 않는 것이 가장 좋습니다. <로드맵 발표 및 사용> 5단계로 로드맵을 제시하는 방법 1. 로드맵을 누구와 공유해야 합니까? 2. 청중을 파악하십시오. 3. 내러티브에 집중하세요. 4. 높은 수준을 유지하십시오. 5. 메시지에 몇 가지 메트릭을 추가합니다. 로드맵 실행이란 무엇입니까? - 제품 로드맵과 그 목표를 실현하는 임무를 맡은 팀이 명확하게 이해하도록 해야함 - 프로세스의 설계, 개발, 테스트 및 배포 단계 전반에 걸쳐 계속 참여해야함 - 새로운 기능이 예상대로 작동하고 요구 사항을 충족하는 동시에 기존 기능도 계속 작동하는지 확인해야함

접근성은 디자이너의 책임이다

https://abr.ge/vhvzb3

[디자인]

접근성

접근성은 디자이너의 책임이다 시력과 청력에 지장이 없고 쉽게 읽고 쓸 수 있는 사람이 인구의 약 50% 정도 밖에 안된다는 걸 알고 있었나요? 디자인 단계에서 몇 가지 간단한 원칙을 지키는 것 만으로도 전반적인 UX를 개선할 수 있습니다. 이것을 '인클루시브 디자인(Inclusivie Design)' 이라고 합니다. 인클루시브 디자인이란? - 가능한 한 많은 사람들의 니즈와 능력을 고려하는 디자인. 문제가 생기기 전 해결하여 좋은 프로덕트의 기준을 높이고 바꾸는걸 목표로함 - POUR (Percivable Operable Understandable Robust)을 참조 -- Percivable: 디지털 콘텐츠를 쉽게 다양한 방식으로 해석하거나 처리할 수 있는지? -- Operable: 프로덕트를 복잡하지 않게 쉽게 작동하고 제어할 수 있는지? -- Understandable: UI의 기능과 정보를 이해할 수 있는지? -- Robust: 프로덕트가 다양한 보조 기술과 장치와 호환이 되는지? 디자이너가 어떻게 접근성을 향상 시킬 수 있을까? (원문 링크에 각 항목에 대한 적절한 예시와 설명이 자세히 나와있으니 꼭 한번 확인해보세요!) 1, 시각적 경험: 모양, 컬러, 대비, 텍스트 스타일 등의 모든 그래픽 요소 - 명암비: AAA (접근성 최고 수준)을 달성하려면 7:1의 명암비가 필요함 - 명도: 밝은 색상일 수록 빛을 반사하여 정보를 읽고 처리하는 능력을 방해함. Yellow 가 50% 이상 표함된 색상은 더많은 빛을 반사함. - 색맹: coolors.co (지정한 팔레트가 색맹에게 어떻게 보이는지 보여주는 사이트) * 색상을 중요한 메세지를 전달하는 유일한 방법으로 쓰지 말 것. - 타이포 그라피: 14px 아래로 사용하지 않을 것. 줄 간격은 2.0을 초과하지 말 것. 2. 청각적 경험: 제품 인터렉션 시 생기는 소리, 볼륨 및 선명도 3. 인지적 경험: 인터페이스를 해석하는데 소비하는 시간 - 인식: 사람들의 인식은 연령, 접근성, 멘탈모델, 문화에 따라 다를 수 있으므로 실제 사용자와 함께 효율성을 테스트 하여 디자인을 결정하는 것이 중요함. - 시각적 계층 구조: 사용자가 쉽게 콘텐츠를 탐색하고 발견할 수 있도록 배열 - 상호작용: 너무 많은 옵션을 제공하지 않고 (최대 5개) 의사 결정 속도를 줄이기. 애니메이션 및 gif는 꼭 필요한 경우에만 사용하기. 피드백을 통해 사용자에게 확실성과 통제감을 주기. 4. 모터 경험 향상: 프로덕트와 상호작용하는 데 필요한 모든 동작과 움직임 - 피츠의 법칙: 사용자와 대상 사이의 거리를 줄이고 크기를 늘리기 - 공백: 사용자와 UI간의 명확한 인터렉션에 도움이됨.

알림 디자인을 위한 가이드라인

https://abr.ge/ghnidm

[디자인]

프로덕트 전략

더 나은 알림 디자인을 통한 더 나은 사용성 알림은 제품 사용성에 주요한 기능입니다. '시스템 상태의 가시성' 은 Nielsen Norman Group의 "사용자 인터페이스 디자인을 위한 10가지 사용성 휴리스틱" 목록에서 첫번째 항목 입니다. 이 규칙은 "시스템은 적절한 시간 내에 적절한 피드백을 통해 사용자에게 무슨 일이 일어나고 있는지에 대한 정보를 항상 제공해야 한다."라고 말합니다. 알림 시스템은 디지털 제품 UX의 많은 부분을 차지하므로, 알림 시스템이 없으면 제품은 마치 무언가가 빠진 것처럼 느껴질 것입니다. '시스템 상태의 가시성'과 피드백이 없다면 대시보드 없이 자동차를 운전하는 것과 같습니다. 모든 유형의 알림은 디지털 제품에서 없어서는 안될 부분입니다. 유용한 알림 프레임워크 구축하기 알림 디자인을 나중에 생각하지 마세요 우리는 작지만 중요한 UX개선사항을 마지막으로 생각하는 경향이 있습니다. 경고, 오류메시지, 확인, 공지 등의 알림 디자인은 나중에 생각하는 경우가 많습니다. 이러한 접근방식은 UX를 손상시키는 조잡한 프랑켄슈타인과 같은 결과물을 만들기도 합니다. 이러한 상황을 피하려면 알림 디자인에 대한 통합 접근 방식을 사용해 제품 디자인 프로세스의 초기에서 부터 사용자 경험을 향상시켜야합니다. '주의 수준'으로 알림을 분류하세요 알림 프레임워크를 잘 설계하려면 알림을 '주의 수준' 측면에서 생각하는 것이 도움이 될 수 있습니다. 예를 들어 테스크를 수행하는데에 큰 방해가되는 문제에는 "강력한 알림"이 필요하고, 그렇지 않은 경우에는 "조용한 알림"이 필요합니다. 알림 디자인에 대한 초기 접근 방식은 [높음, 중간, 낮음]의 세가지 수준으로 분류해보세요. 그 다음 경고, 확인, 오류, 성공메시지 등 특정 속성 내에서 추가로 유형을 정의할 수 있습니다. 높은 주의 Alerts 즉각적인 주의 필요 Errors 즉시 조치 필요 Exceptions 시스템 이상으로 무언가 작동하지 않음 Confirmations 진행하려면 사용자 확인이 필요해 잠재적인 주의요인 중간 주의 Warnings 즉각적인 조치가 필요하지 않음 Acknowledgments 사용자 작업에 대한 피드백 Success messages 성공 메시지 낮은 주의 Informational messages 볼 수 있게 준비된 항목 Badges 일반적으로 아이콘 위에 노출되며 마지막 상호작용 이후 새로운 것을 표시함 Status indicators 시스템 피드백 알림 유형에 맞는 디자인 시스템을 설계하세요 알림 목록이 준비되면 다음 단계는 원하는 주의 수준과 속성에 따라 알림을 분류하는 것입니다. 알림은 방해가 되어서는 안 되므로 신중하게 수행해야 합니다. 아래 질문에 따라 알림을 유형화하고 이에 맞는 색상코드, 아이콘, 위치, 동작 등 상세한 UX와 알림 디자인 시스템을 설계하세요. 이 과정에서 디자이너는 알림이 표시되는 모든 상황과 예외케이스들을 고려할 수 있어야합니다. 알림을 트리거하는 것은 무엇입니까? 어떤 유형의 피드백이 전달되고 있습니까? 알림은 어디에 어떻게 표시됩니까? 즉각적인 상호 작용이 필요한 알림은 무엇입니까? 알림이 지속적입니까 아니면 비지속적입니까? 사람들에게 적절한 양의 알림을 보내는것은 균형을 유지하는 작업이며, 이를 과도하게 사용되면 위험이 따릅니다. 과도한 알림이 사용되는 경우 제품에 대해 부정적인 피드백을 받을 수도 있고 최악의 경우 제품을 포기하는데에도 영향을 미칠 수 있습니다. 알림을 사용하는 시기와 방법을 이해하는 것은 뛰어난 사용성을 제공하고 제품 메시지의 일관성을 구축하는 데 필수적입니다. 적절한 순간에 표시되어야 하는 주변 메시지를 신중하게 평가함으로써 디자이너는 제품의 효율성을 높이고 UX를 향상시킬 수 있습니다.

문제 해결을 위해 솔루션으로 달려가지 마세요

https://abr.ge/yiunnl

[워크 프로세스]

PM/PO

마인드셋

가이드

우리의 인지적 편향과 제한된 의사결정 능력 사이에서, 문제를 생각하기 위한 정신적인 연료가 부족할 때, 우리는 고민중인 문제를 완전히 이해할 기회를 갖기 전에 결정을 피하거나 서둘러 해결책을 찾아 정신적 에너지를 절약하려는 경향이 있습니다. 우리가 이렇게 솔루션으로 바로 넘어가는 건 당연한 일입니다. 할 일 목록을 넘기고 문제를 해결하면 도파민이 급증합니다. 특히 우리 주변의 세계가 불안정하고 무언가 임박했다고 느낄 때 더 그렇습니다. 하지만 일시적인 솔루션은 상황을 악화시킬 수 있으며, 장기적으로 봤을 때 본래의 문제 만큼이나 해를 끼치는 요소가 될 수 있습니다. 서둘러 해결책을 내버리려는 충동을 극복하기 위해, 간단한 4단계 프로세스를 따라보세요. 1. 문제를 직접 관찰하세요. 문제의 사실(*Facts, 본질로 이해해도 됨)에 대한 이해가 없을 때 형편없는 솔루션으로 건너뛰기 쉽습니다. 문제의 사실을 수집하는 것은 면밀한 관찰로부터 시작됩니다. 우리가 종종 의지하는 스프레드시트와 보고서는 2차원으로 표현한 데이터에 불과합니다. 사실이 없는 데이터는 2차원의 시야는 제공하지만 인사이트를 제공하지 못합니다. 의미있는 결론에 도달하기 위해서는 [데이터]와 [사실 수집] 두가지를 모두 고려해야 합니다. 예시1 - 데이터가 얘기하는 것 : 조립 라인에서 기계가 얼마나 자주 고장났는가. - 관찰로 알 수 있는 사실 : 기계가 더럽고 기름으로 덮혀있으며, 오랫동안 청소 및 관리되지 않았다. 예시2 - 데이터가 얘기하는 것 : 작업자가 Zoom 회의에 제시간에 맞춰 오지 않았다. - 관찰로 알 수 있는 사실 : 부모가 자녀의 온라인 스쿨 적응을 도와주어야 하기 때문에 오전 9시 미팅을 하기가 어렵다. 또한 아이들 점심을 준비해야 하기 때문에 12:30 회의가 어렵다. 2. 문제의 프레임을 적절하게 정의하세요. 문제를 정의하는 것은 어렵습니다. 무엇보다도, 문제의 증상을 근본적 문제로 오인하기 쉽습니다. 잘 짜여진 문제 정의는 토론과 선택의 길을 열어주지만, 나쁜 문제 정의는 대안에 대한 생각을 막아버리고 쉽게 생각하게끔 막다른 골목으로 보내버립니다. (A) 우리 병원에는 인공호흡기가 더 필요합니다. (B) 우리 병원의 인공호흡 가용성이 더 높아져야 합니다. 첫 번째 문장(A)은 바로 결론을 내버립니다. 이 경우 유일한 해결책은 인공호흡기를 더 구입하는 것입니다. 두 번째 문장(B)은 암묵적인 판단(= 더 많은 인공호흡기가 필요함)을 피하고 있습니다. 이것은 더 나은 솔루션을 개발하는데 도움이 되는 질문으로 이어질 수 있습니다. ∙ 현재 수리중인 기계의 수는 얼마인가? ∙ 모든 장비가 작동 가능하도록 관리되고 있는가? ∙ 모든 인공호흡기가 어디에 있는지 간호사가 알고있는가? ∙ 한 환자에서 다음 환자로 인공호흡기를 옮기는데 소요되는 시간은 얼마인가? 3. 거꾸로 생각해보세요. 문제에 직면했을 때, 솔루션으로 바로 달려가기 보다는 뒤로 돌아서 어떻게 이 문제까지 오게 되었는지 ‘이유’를 정리해보세요. 문제의 ‘이유'에는 기본적으로 아래 6가지 범주가 있습니다. 예시와 함께 살펴보겠습니다. 문제 : 팬데믹 기간 동안 직원들의 사기가 저하됨 ∙ 환경적 이유 e.g. 재택근무 환경이 갖춰지지 않아서 집중하기 어려움 ∙ 심리학적 이유 e.g. 고립되었다고 느낌, 일상적인 대화를 할 수 없음 ∙ 기술적 이유 e.g. 줌 사용이 어려움, 미팅중에 자주 끊김 ∙ 규범적 이유 e.g. 업무시간이 명확하지 않음 ∙ 커뮤니케이션 이유 e.g. 전사 미팅이 없음, 리더십의 메시지가 잘 전달되지 못함 4. 왜? 를 반복하세요. 답을 내리기 전에 반복적으로 “왜?”를 묻는 것은 성급한 결론을 내리거나 불충분한 솔루션을 구현하지 않도록 하는 강력한 방법입니다. 5번, 많게는 11번 "왜"를 물어보면 결국 근본 원인에 도달하게 될 것 입니다. 각 질문은 우리가 실제 문제에 대해 더 깊게 이해하도록 유도하기 때문입니다. 모든 복잡한 문제에는 명확하고 간단하며 잘못된 솔루션이 있습니다. 근본 원인을 찾으면 증상을 단순히 치료하는 반창고가 아닌 지속 가능한 솔루션을 갖게 됩니다.

PM겸 디자이너가 전략에 더 많은 영향력을 만드는 방법

https://abr.ge/oawzai

[성장의 피땀눈물]

일하는 방법

마인드셋

이 글은 프로덕트 디자이너인 저자가 Tally의 그로쓰 팀 PM으로 250일 동안 업무하면서 얻은 4가지 레슨 런에 대한 글입니다. 저도 현재 회사에서 프로덕트 디자이너와 PM 역할을 동시에 수행하고 있어 공감하며 읽을 수 있었습니다. 1. 목표를 우선순위화 하고, 결과물을 최적화 하는데 사용하기 프로덕트 디자이너와 PM으로서 함께 일할 때, 두 역할을 동시에 해야하는 날들이 많았고, 업무를 분배하는데 고민인 생겼습니다. SMART[^1] 방법으로 목표를 설정하고, 내 시간을 투자할 방법으로 사용했습니다. 어떤 목표에 시간을 더 많이 사용할 지는 다음과 같이 결정합니다. • 주 별, 분기 별 목표를 설정하자 • 목표 간 상충 관계를 파악하고 덜 중요한 요청엔 잘 거절하자 • 도중에 문제가 생겼을 때 어떤 것이 더 임팩트가 큰 지를 파악하자 [^1]: Specific, Measureable, Actionable, Relavant, Time-bound 2. 변화가 있을 때(혹은 문제가 있을 때) 적절한 태도를 취하기 지난 가을, 그로쓰 로드맵을 마무리 하고 새로운 업무를 시작하려 할 때 앱의 크리티컬 패쓰의 경험에 문제가 있는걸 발견했습니다. 이런 복잡한 상황에서 사람들은 무엇을 해야하는지에 대한 답을 찾으려고 하는게 아니라, 안정되고 긍정적인 환경을 원했습니다. 디자이너로서도 여러 사람들과 문제를 facilitating 하게 됩니다. 팀이 더 일을 잘 하도록 도우면서 리더십 스킬을 성장시키고 더 탄탄한 솔루션을 만들 수 있게 됩니다. • 인간적인 모습을 취하고, 변화의 중심에 있는 사람들의 이야기를 듣자 • 솔직한 모습을 취하지만 도움이 되지 않는 피드백이나 문제로부터 팀을 보호하자 • 답을 모르는건 괜찮다. 함께 일을 굴릴 사람들을 불러들이자. 3. 데이터를 문제 발견, 우선순위화, 평가하는데 사용하기 PM으로서 다른 사람들이 성과 지표, 상태, 사용자 행동에 대해 물어보는 일이 많았는데, 데이터 분석 코스를 수강하고 이런 질문들에 스스로 답변할 수 있게 되었습니다. 또, 내 디자인 결과에 이벤트를 추가하고 이벤트 간 비주얼 맵을 그려 여러 팀이 목표를 얼라인하고 이해하는데 도움이 되었습니다. • 프로덕트 분석과 분석 툴을 공부하는데 시간을 쓰자 • 데이터를 확인할 때 기준선(베이스라인)을 지정해, 어디에 시간을 더 써야 하는지 확인하자 • 디자인 결과물에 수집될/되는 이벤트를명시해 디자인 의사결정에 참고하고, 엔지니어들과 더 원할하게 대화할 수 있다 4. 나 혼자 뿐 만 아니라 다른 모든 사람들이 장기 계획을 바라보고 있도록 하기 현재 진행중인 일에만 집중하면, 한 Phase가 끝나고 다음 Phase로 넘어갈 때 팀원들이 예상치 못한 목표를 발견하고 놀라는 일이 생기게 됩니다. • 눈 앞만 바라보지 말고 장기적 관점을 생각하는데 시간을 쓰자 • 계속해서 팀이 나아가야 할 방향을 리마인드 하고 목표를 이해시키자 • 파트너와 이해관계자들에게 장기 계획을 이해하고 참여할 수 있도록 내 계획을 지도 삼아 이야기하자 디자이너로서 만드는 결과물들은 목표 얼라인, 협업, 영감에 도움을 줄 수 있습니다. 무언가를 만들 때 청중들이 어떻게 사용하게될 지를 고려해 만들어야 합니다.

McKinsey가 경력 발전에 대해 가르쳐준 7가지 교훈

https://abr.ge/jszowj

[성장의 피땀눈물]

일하는 방법

마인드셋

경험 공유

엑셀로 데이터 쟁탈전, 파워포인트로 스토리텔링을 얼마나 잘했는지에 대한 글이 아닙니다. 모든 직업, 어떤 경우에는 삶에 적용할 수 있는 중요한 것들을 공유하고 싶습니다. 전문가가 아닌, 항상 학생으로서 문제에 접근하기. 신선하고 호기심 많은 마음으로 문제에 접근해야 합니다. 질문을 하고, 메모를 하고,더 깊이 파고들고 계속 압박하여 가설을 수정하십시오. 학생의 사고방식은 당신의 두뇌를 객관적인 환경에 놓이게 합니다. 문제를 합리적으로 분석하고, 팀원과 효과적으로 협업하고, 적절한 솔루션을 만들 수 있는 보다 개방적인 형식으로 아이디어에 접근합니다. 이 모든 것이 "모든 것을 알고" 있어야 하는 스스로 유발하는 압력을 완화하는 것입니다. ’사기꾼 증후군'의 사기꾼은 조직이 아닌, 나 자신입니다. 동료들이 나보다 더 많이 알고 더 잘 실행한다고 가정하지만, 현실은 대부분의 사람들이 진행하면서 알아가는 실행착오를 격습니다. 다른 사람들이 전문적으로 나보다 우월하다는 선입견을 가질 때, 그들(그리고 자신)을 그렇게 대하기 시작하며, 이는 큰 착각입니다. 모두가 당신과 같은 학생이라는 것을 인식해야 합니다. 실패는 일어날 수 있는 가장 좋은 일입니다. 거의 해고당할 뻔했습니다. 높은 스트레스 상황에서 까다로운 고객을 관리하면서 내 기술을 넘어 도전적인 프로젝트에 참여했지만, 비참하게 실패했습니다. 이때 스스로의 약점을 알고 실패의 핑계가 아닌 성장의 원동력이 되었습니다. 실패는 앞으로 나아갈 방향을 결정해 줍니다. 조직은 개인이 그만둘 때까지 영역에 맞춰 넣을 것입니다. 경영진은 배를 조종하는 방법에 대한 비전을 가지고 있으며, 그 비전은 더 작은 조각으로 쪼개지고, 개인은 만들어진 조작 내에서만 실행할 수 있습니다. 조직은 궁극적으로 배를 조종할 것이기 때문에 개인을 그 영역 안에 두도록 장려합니다. 하지만 조직의 방향과 영역이 배움, 흥미가 있지 않다면 스스로를 가두지 말고 다른 다른 곳을 찾는 것은 우리의 몫입니다. 마음가짐, 동기 부여, 회복력이 있다면 실행해 보세요. 모든 것에 대한 해결책이 있습니다. 침착하세요. 패닉은 해결책이 아닙니다. 한 발 물러서서 논리에서 감정을 풀고 가능한 최선의 계획에 착수하십시오. 휴식도 답이 될 수 있습니다. 좋은 의도가 사람을 움직입니다. 정치가 아닙니다. 리더가 개인적인 이득을 위해 팀원들 인형극 부리듯 조종하는 것은 단기적으로 승리할 수 있지만 장기적인 성공은 관계를 기반해서 움직입니다. 조직의 성공은 맞는 팀원들과 함께해야만 도달할 수 있습니다. 그리고 적합한 팀원이 합류되기 위해서는 리더가 팀원의 성취에 진정한 관심과 케어가 동반되어야 합니다. 만들어진 관계는 조직의 운영보다 더 깊습니다. 관계는 사건보다 오래 지속됩니다. 비록 당장 이익관계에서 틀어진다 하더라도, 함께 좋은 일을 할 수 있는 기회가 올 수도 있다는 것을 명심하세요. 긍정적인 관점에서 서로를 기억하는 것은 항상 승리할 것입니다. 그리고 서로에게 훌륭하지 않고서는 함께 위대한 일을 할 수 없습니다.

디자인 시스템 101 - 닐슨 노먼 그룹

https://abr.ge/uenabm

[워크 프로세스]

디자인 시스템

가이드

<디자인 시스템이란?> - 중복성을 줄이고 - 다양한 페이지와 채널에서 공유된 언어와 시각적 일관성을 만들어 - 대규모로 디자인을 관리하기 위한 일련의 표준 UI 디자인 - UI 화면을 생성해야 하는 규모와 속도가 높아져 - 각 앱과 웹 사이트에는 수백 또는 수천 개의 페이지(또는 화면)가 필요 - 조직에서는 설계 작업을 간소화해야 할 절박한 필요성이 대두 디자인 시스템을 사용하는 이유 - 설계(및 개발) 작업을 신속하게 대규모로 생성하고 복제할 수 있다. - 더 크고 복잡한 문제에 집중하기 위해 설계 리소스의 부담을 덜어준다. - 교차 기능 팀 내에서 그리고 팀 간에 통합된 언어를 만든다. - 제품, 채널 및 (잠재적으로 고립된) 부서 전반에 걸쳐 시각적 일관성을 만든다. - 주니어 레벨 디자이너와 콘텐츠 기고가를 위한 교육 도구 및 참고 자료로 사용할 수 있다. 디자인 시스템을 사용하지 않는 이유는 무엇입니까? (잠재적인 장애물과 제한사항) - 디자인 시스템을 만들고 유지 관리하는 것은 전담 팀이 필요한 시간 집약적인 활동이다. - 디자인 시스템을 사용하는 방법을 다른 사람에게 가르치는 데는 시간이 걸린다. - 프로젝트는 일반적으로 재사용 가능한 구성 요소가 필요하지 않은 정적인 일회성 생성이라는 인식이 있을 수 있다. <디자인 시스템의 요소> 1. 디자인 저장소(repository) 2. 그것을 관리 하는 사람들 1. 디자인 저장소 - 스타일 가이드 - 일반적인 스타일 가이드는 브랜딩(색상, 타이포그래피, 상표, 로고 및 인쇄 매체)에 초점을 맞춤 - 콘텐츠( 목소리 및 언어 권장 사항 등)와 시각적 및 상호 작용 디자인 에 대한 지침도 제공 - 컴포넌트 라이브러리 - 구성 요소 이름 - 설명 - 속성 - 상태 - 코드 조각 - 프론트엔드 및 백엔드 프레임워크 (필요 시) - 패턴 라이브러리 - 컴포넌트 라이브러리는 개별 UI 요소를 지정하는 반면, 패턴 라이브러리는 UI 요소 그룹화 또는 레이아웃 컬렉션을 제공 2. 디자인 시스템 팀 - 오래되거나 쓸모없거나 중복된 항목이나 제출로 인해 과밀화되지 않도록 지속적인 유지 관리와 감독이 필요 - 팀에는 최소한 1명의 인터랙션 디자이너, 1명의 비주얼 디자이너 및 1명의 개발자가 포함되어야 함 - 인터랙션 디자인 가이드라인을 만들고, 시각적 예제를 만들고, 각 요소에 대한 코드 스니펫과 구현 사양을 각각 제공 설계 시스템 노력을 조율하기 위해 경영진 후원자를 확보하는 것을 고려해야함 스폰서는 자금과 자원을 확보하는 동시에 나머지 조직에 디자인 시스템의 전략적 중요성을 전달할 수 있음 <디자인 시스템 채택에 접근하는 방법> - 기존 디자인 시스템 채택 - 기존 디자인 시스템 적용 - 나만의 독점 또는 맞춤형 디자인 시스템 만들기 디자인 시스템 솔루션이 맞춤화될수록 구현하는 데 더 많은 시간과 비용이 소요 기존 설계 시스템을 사용하는 것이 가장 비용이 적게 드는 접근 방식 개념 증명(PoC)이나 변경될 가능성이 있는 초기 프로토타입의 경우 본격적인 설계 시스템을 만드는 것은 단기간에 원하는 ROI가 안 나옴 미래에 있을 디자인의 복제 가능성에 도움이 됨 디자인 시스템은 작업 포트폴리오로 생각해서는 안됨 디자이너와 개발자가 보다 빠르게 작업할 수 있는 기능적 툴킷 또는 리소스로 간주해야 함 디자인 시스템을 만들 때 고려해야 할 주요 요소 - 프로젝트의 규모와 복제 가능성 - 사용 가능한 리소스와 시간 제대로 구현 및 유지 관리하지 않으면 디자인 시스템이 구성 요소와 코드의 다루기 힘든 모음이 될 수 있음 그러나 잘 구현되면 팀 구성원을 교육하고 작업을 간소화하며 디자이너가 복잡한 UX 문제를 해결할 수 있음

B2B 앱 참여 및 마케팅 심리학

https://abr.ge/r8atsa

[디자인]

마케팅

심리학

B2B 앱이 해결하려는 문제가 복잡할 수는 있지만 솔루션이 복잡할 필요는 없습니다. 사용자는 프로덕트 팀이 마주하는 문제에 관심이 없습니다. 단지 앱이 단순한지, 그것이 문제 해결을 더 쉽게 만들어주는지를 알고자 합니다. B2C 앱 디자인에 널리 사용되는 행동 경제학 및 마케팅 심리학을 사용하여 앱을 간소화하고 관여도를 높일 수 있습니다. default 값 정의를 신중하게 하자 '넛지'라는 책은 사람들이 비합리적이라고 이야기합니다. B2B 앱 제작자는 사용자가 풍부한 복잡성을 뚫고 모든 일을 처리할 거라 가정하지만, '넛지'는 너무 많은 선택이 장애가 될 수 있다고 합니다. 책 저자들의 연구에 따르면 너무 많은 옵션이 제시되면 사람들은 선택을 시스템에게 맡깁니다. 프로덕트 팀은 기본 옵션을 변경하여 원하는 방향으로 "넛지"할 수 있습니다. 이것을 "선택 아키텍처"라고 합니다. 사용자 선택을 줄이며 결정하기까지 길을 안내하도록 인터페이스를 설계합니다. 게임 메커니즘 사용하기. Gamification 사람들이 비용을 지불하고 쌓아둔 마일리지의 대부분은 사용되지 않습니다. 기업은 사람들이 마일리지를 쌓는 성취 자체를 보상으로 여기고 이 게임을 좋아한다는걸 알고 있습니다. 행동경제학에서는 목표 달성에 가까워졌을 때 더 열심히 일할 동기가 생긴다는 말이 있습니다. 이는 결과가 사용자에게 특히 흥미롭지 않거나 사용자가 생산성 혁신을 달성하기까지 몇 달이 걸릴 수 있는 B2B 앱에서 특히 두드러집니다. 그 효과를 극대화하기 위해 프로덕트 팀은 '게임' 결과만 공개하면 됩니다. B2B에서 이것은 인증과 같은 보상을 제공하고 받는 사람에게 명성을 주는 것을 의미합니다. 이는 고급 사용자에게 상을 제공하고 컨퍼런스에서 연설하도록 초대하는 것을 의미합니다. 사회적 증거가 있는 가이드 나이트클럽에는 왜 항상 줄이 있는 것 같습니까? 꽤 의도적입니다. 클럽이 붐비는 것처럼 보이려고 경비원은 줄을 세웁니다. 버지니아 주 전기세 고지서에 이웃 주민들이 절약한 전력량을 표시하기 시작한 이후 30억 kw/h의 에너지가 절약되었습니다. B2B 제품 팀은 이러한 경향을 사용하여 사용자를 넛지할 수 있습니다. 예를 들어, 사용자에게 새로운 기능을 알릴 때 제품 팀은 다른 사람들이 그것을 시도하고 좋아했음을 알려야 합니다. 사회적 증거 예시 몇 가지: - 총 고객 수 또는 비율 - 인식 가능한 브랜드의 이름 또는 로고 - 고객 만족도 또는 업계 전문가의 후기 - 인증 기관의 승인 마크 - 신뢰할 수 있는 출처의 연구 또는 통계 긍정적인 인상을 극대화하는 UX 디자인 많은 호텔이 최근들어 결제 절차를 바꾸고 있습니다. 마지막에 결제를 받는 대신 체크인 시 결제를 사전 승인합니다. 왜일까? 나쁜 느낌이 오래 지속된다는 '최신성 원칙'을 호텔이 배웠기 때문입니다. 행동 심리학자의 연구를 인용한 McKinsey는 "고객은 제품이나 서비스를 사용한 후 며칠, 몇 주, 몇 달이 지나면 고객 여정의 모든 개별적인 측면이 아니라 높은 지점과 낮은 지점을 불균형적으로 기억하는 경향이 있다"라고 썼습니다. B2B 앱 디자이너에게 사용자 여정 순서를 변경할 수 있는 기회는 무한합니다. 제품 분석과 사용자 인터뷰를 혼합하여 사용자 여정에서 낮은 지점을 식별할 수 있습니다. 디자이너가 문제를 해결할 수 없다면 최소한 낮은 지점이 경험 중간에 발생하거나 고르게 퍼지도록 해야 합니다.

스타트업이 데이터를 활용하기 위한 4단계 접근법

https://abr.ge/elm0yl

[프로덕트 & 데이터 분석]

프로덕트 분석

스타트업

마인드셋

JTBD 프레임워크 제대로 이해하기

https://abr.ge/tvzkti

[프로덕트 & 데이터 분석]

프레임워크

PM/PO

사용자의 업무상 발생하는 워크플로우 내 문제를 해결하기 위해 존재하는 것이 B2B SaaS의 존재 의의입니다. 과업을 수행하기 위해 제품이나 서비스를 구매한다는 JTBD(Jobs to be Done) 프레임워크는 B2B 프로덕트를 만들고 있는 사람들이 필수적인 프레임워크입니다. 고객이 수행하고자 하는 과업을 명확하게 정의하지 않고 제품 개발에만 몰두하는 것은 방향 없이 속력만 내는 것입니다. 원문에서는 JTBD 프레임워크의 9가지 원칙에 대해 상세한 설명과 함께 소개하지만, 일부만 옮기겠습니다. 궁금하신 분들은 원문 링크를 참조하세요. 3. 고객의 과업(JTBD)는 오랜 시간에 걸쳐 안정적이게 되었다 • '부모가 자녀에게 삶의 교훈 물려주기' 과업은 인류만큼 오래된 과업입니다 • '출근길의 무료함 달래기'는 지역과 관계 없이 동일하게 적용되는 과업입니다 • Amazon은 '고객에게 가장 좋은 것을, 가장 저렴하게, 가장 편리하게 제공하는 것'을 과업으로 정의했기 때문에 이커머스 플랫폼 뿐 만 아니라 다양하게 비즈니스를 운영할 수 있습니다 4. 고객의 과업은 솔루션이나 기술과 무관하다 • 자신의 제품이 최적의 솔루션이 될 수 있도록 고객의 불편함과 니즈를 입맛대로 정의하고 싶은 욕구에 매몰되어서는 안됩니다 • 킥보드 대여 서비스가 해결하고자 하는 과업은 킥보드를 더 쉽게 빌리는 것이 아니라, 도심 속 이동을 더 편리하게 하는 것입니다 • 이미 고객은 현존하는 기술이나 자신만의 솔루션으로 해당 과업을 수행하고 있다는 것을 잊어서는 안됩니다 5. 제품의 성공은 제품이나 고객에 대한 분석이 아닌 고객 과업의 단위 분석(Unit Analysis)에서 창출된다 • 고객은 자신의 과업에 대해서는 알고 있지만, 그 과업의 최적 솔루션에 대해서는 모르기 때문입니다 • 헨리 포드가 '고객에게 무엇이 필요한지 묻는다면, 그들은 더 빠르고 지치지 않는 말이 필요하다고 답할 뿐이다'고 한 말과 일맥 상통합니다 • 고객의 과업은 시작과 끝이 존재하는 프로세스 형태로, 대여섯 가지에서 많게는 20~30개의 단위 과업으로 이루어져 있습니다 • 각 단위 과업 중 어떤 부분이 병목이며, 예측이 불가능 하고 비효율이 발생하는지에 대해 학습 해야합니다 7. 과업을 정의함으로서 니즈 해결의 성공을 측정할 수 있는 측정 지표로 활용 가능하다 1) 고객이 과업 수행에서 진정으로 원하는 Desired Outcome을 정의합니다 2) 이를 달성하기 위한 측정 지표와 기준값을 정의합니다 3) 이 기준값을 달성할 수 있도록 제품을 개발하고 마케팅을 수행합니다 • Desired Outcome: '중고 아이폰을 제 값에 빠르게 판매하기' • 측정 지표와 기준값: 제 값 = 60만원+, 빠르게 = 7일- • 달성 방법: 물건을 먼저 수령해 위탁 판매하고, 판매 고객에게는 최소 가격을 보증한다 8. 사람들은 과업을 더 잘 수행하거나, 더 저렴하게 수행할 수 있는 제품이나 서비스를 원한다 • 과업을 더 잘 / 덜 잘 수행한다, 가격을 더 많이 / 더 저렴하게 제공한다 두 축으로 2x2 매트릭스를 그릴 수 있습니다 • 고객이 과업을 해결하기 위해 사용중인 솔루션의 기능이 과다하다면 덜 제공하는 것도 하나의 방법이될 수 있습니다

A/B테스트는 죽었다

https://abr.ge/7jyaa5

[프로덕트 & 데이터 분석]

프로덕트 전략

지표

A/B테스팅

A/B 그들은 작동하는 것과 작동하지 않는 것을 빠르게 시도하고, 실패하고, 구현합니다.그리고 마치 C급의 의사결정인 것처럼 믿고 따릅니다. 하지만 성공적인 A/B 테스트가 결과적으로 실패한 이유를 살펴보겠습니다. 참신 효과 고객을 대면하는 새로운 기능에는 자연스럽게 관심이 있고 경쟁자 반응 효과가 있을 수 있습니다. 하지만 참신함은 클릭을 생성한 다음 사라집니다. 결국 새 기능은 "표준”이 되고 영향은 줄어들 것입니다. 일부 시스템에서는 최종 결과만 중요합니다 너무많은 A/B 테스트 실행 중 실험은 대부분 상호 배타적으로 간주되므로 모집단이 겹칩니다. 실제로 대부분의 트래픽 분할은 일부 상호 배제와 함께 인구의 일부에서 수행되며, 불행히도 실험은 가장 충성도가 높은 사용자에서 훨씬 더 나은 성능을 보였습니다. 부정확한 측정항목 A/B 실험을 통해 그룹의 주문 수를 $5.5로 성공적으로 증가시켰습니다. 하지만 동시에 낮은 그룹에 대한 유지율은 48%로 떨어졌지만 이를 모니터링하지 않았습니다…이처럼 리텐션은 복합적인 지표입니다. 이처럼 장기 트래킹이 필요한 항목에 대한 A/B 테스팅은 관찰하기 어렵습니다. 범용적 결과 A/B 테스팅은 모든 방법론이 승자입니다. 프로덕트 특징에 맞춰 평가 되지 않습니다. 결과 대해 어떤 동작으로 이뤄졌는지 제공하지 않습니다. 인사이트 부족 버전 A가 B보다 전환율이 더 좋다는 것을 알게 되었습니다. 하지만 이것은 핵심 학습이 아닙니다! 개별적인 사용자, 실험한 버전에 대한 인사이트를 주지 않습니다. A/B 테스트는 개별 인과 관계 알고리즘이 아닙니다. 단지 현재 상황을 감안할 때 변이가 모집단에서 평균적으로 더 낫다는 것을 알려줍니다. 즉, 개인 X_i와 X_j를 고려하면 한 사람이 다른 사람보다 더 높은 지표를 가질 가능성이 더 높은지 여부를 알 수 없습니다.

많은 SaaS 회사가 미디어를 자체적으로 운영 하고있는 이유

https://abr.ge/mokhjn

[프로덕트 & 데이터 분석]

마케팅

실 사례

콘텐츠가 비즈니스와 마케팅 분야에도 엄청난 잠재력을 가지고 있다는 점이 증명되고 있습니다. 특히 지난 몇 년간 Salesforce, Hubspot, Shopify와 같은 SaaS 기업들이 미디어 회사처럼 움직이기 시작하면서 콘텐츠 마케팅은 한 단계 도약하고 있습니다. Salesforce 지난 해 세일즈 포스는 대규모의 콘텐츠 투자를 발표하면서 할리우드 스타일의 콘텐츠 스튜디오를 만들었습니다. B2B 고객 유치라는 궁극적인 목표를 가지고 고품질의 콘텐츠를 말들기 위함이었죠. Hubspot 다양한 마케팅 솔루션을 제공하는 Hubspot은 뉴스레터, 팟캐스트 등을 운영하는 미디어 The Hustle을 330억에 인수했습니다. Shopify 디스커버리 채널과 함께 Shopify's Studio라는 미디어 회사를 설립하여 I Quit라는 프로그램을 제작했습니다. 회사를 시작하기 위해 직장을 그만둔 기업가들에게 초점을 맞춘 예능 프로그램이었습니다. 위와 같은 테크 기반의 B2B SaaS 회사들이 콘텐츠에 투자하는 이유는, 하이엔드 테크놀로지의 가치를 고객에게 제대로 전달하기 위해서입니다. 기술이 충분히 발전했고 훌륭한 프로덕트도 넘치는 상황에서 그 가치를 제대로 전달할 양질의 콘텐츠는 턱없이 부족한 상황입니다. 제품과 서비스를 제대로 알리기 위해선, 그리고 고객의 재방문을 위해선 콘텐츠에 대한 투자가 필요합니다. 또한 테크 회사들은 이미 훌륭한 제품과 서비스를 통해 충분한 고객을 확보하고 있기 때문에, 양질의 콘텐츠에 투자할 여력까지 가지고 있습니다. 이러한 콘텐츠의 유형으로는 회사의 제품과 기술에 대한 교육자료나 회사의 흥미로운 이야기에 초점을 맞춘 다큐멘터리 형식의 프로그램 등이 있습니다. 다만 콘텐츠 마케팅을 구축 및 그 이점을 확인하는데에는 시간이 걸리고 콘텐츠의 지속적인 생산 역시 필요하다는 점을 염두에 두어야 합니다.

디자이너에서 매니저로 성장하기

https://abr.ge/e1ffil

[성장의 피땀눈물]

PM/PO

마인드셋

직무 분석

이 아티클은 디자인 관리라는 커리어가 적절한 선택인지에 대한 판단을 돕고, 그 여정을 시작하겠다면 성공적인 길이 무엇일지를 설명합니다. 성공을 위한 방법 결정에 도움이 되는 핵심 프레임워크와 질문을 참고해보세요. 훌륭한 매니저의 자질 전략가로서 디자인 리딩하기 팀의 목표 및 핵심 결과(OKR)을 개발하고 추적하는 일을 담당합니다. 디자인팀 OKR은 팀 내부로만 한정짓지 않고 타 팀, 회사 전체의 성과를 바라보도록 설계할 수도 있습니다. 운영자로서 팀을 원활하게 운영하고 만족스러운지 확인하기 운영자의 역할은 효과적인 프로세스를 구현하여 팀 문화와 참여를 구축하고, 우수한 디자이너를 모집 및 고용하고, 팀 성과를 관리하는 것입니다. 또한 팀에 별일이 없게끔 하고, 안정감을 느끼도록 하며 긍정적인 환경을 만들 책임이 있습니다. 코치로서 팀원을 성장시키기 마지막으로 매니저는 팀원들에게 성장과 개발 기회를 제공해야 합니다. 1 on 1은 매니저에게 가장 중요한 무기입니다. 팀원과의 관계를 구축하고, 만족하는지 확인하고, 장애물을 제거할 수 있는지 알아보고, 경력 개발을 도웁니다. 그러한 자질을 개발하기 위해 연마할 기술 매니저가 되는데 가장 큰 어려움 중 하나는 위의 3가지 역할에 적절한 비중을 두고 유연하게 대처하는 것입니다. 순간순간 회사가 무엇을 필요로 하는지에 따라 주요 책임이 달라집니다. 스킬 측면에서는 아래와 같은 기술을 익혀야 합니다. 커뮤니케이션: 팀원에게는 탑다운, 동료 매니저와는 수평적으로, 임원과는 바텀업 식으로 하는 등 실무자일 때 경험하지 못한 다양한 커뮤니케이션 전략이 필요 팀원 코칭 및 성장 지도 위임 및 기대치 설정 인재 평가, 채용 자율적으로 프로젝트를 주도: 비즈니스의 핵심 요구 사항을 해결하는 자체 프로젝트를 관리하거나 생성하여 주도권을 잡습니다. 디자이너에서 매니저로의 커리어 전환에 대한 잘못된 통념과 반박 ① 예전 직무로 되돌아갈 수 없다? 매우 일반적인 통념인데 사실이 아니며 역효과를 낳는 이야기입니다. Tech Managing 분야에는 충분한 교육, 지원에 대한 수요와 공급이 넘쳐납니다. 글쓴이는 커리어상에서 매니저와 실무 디자이너 직무를 오갔습니다. ② 매니저는 인적 자원을 서포트하는 역할이다? 다른 사람들을 지원하는 것은 매니저 업무 범위에서 빙산의 일각에 불과합니다. 운영, 관리 책임도 있습니다. 코칭이 매니저의 유일한 업무가 아닙니다. ③ 경력을 쌓으려면 매니저가 되어야 한다? 일부 회사에 해당될 수는 있지만 전부는 아닙니다. 많은 회사가 실무 디자이너의 연차가 쌓여도 개인으로서 활약하는 기여도를 유지하면서 매니저와 같은 수준에서 보상을 받고 영향력을 갖는 방법을 마련합니다. 예를 들어 Webflow라는 회사에서 수석 디자이너와 시니어 매니저는 동일한 등급이며 유사한 보상 및 영향력을 부여받습니다. ④ 디자인 매니저는 팀에서 최고의 디자이너다? 이것은 사실이 아닐 뿐더러 그렇게 되어서도 안됩니다. 직원의 작업을 평가하고 비판하기 위해 디자이너로서의 핵심 기술을 끌어내야 하지만, 그렇다고 해서 팀에서 최고의 디자이너가 되어야 하는 것은 아닙니다. NBA 역사상 최고의 코치 중 일부는 명예의 전당 선수가 아니었습니다. ⑤ 디자인 매니저는 더 이상 디자인 실무에 신경쓰지 않는다? 매니저로서 픽셀 하나하나에 덜 관여하는 것이 사실일 수도 있지만 결국 팀이 만드는 모든 산출물에 대한 책임은 매니저에게 있습니다. 디자인 매니저가 하는 일에는 팀원을 지도하고 디자이너로서 성장하도록 돕는 것입니다. 제품 설계 및 디자인에 쓰이는 프레임워크는 팀원들에게 모델 역할을 합니다.

PM의 시간 다루기 : 로드맵, 타임라인, 릴리즈 플랜

https://abr.ge/8ogxwa

[성장의 피땀눈물]

PM/PO

마인드셋

직무 분석

PM의 능력은 시간을 얼마나 잘 다루느냐에 달려있습니다. PM은 단순히 시작과 끝을 지정하고 관리하는 것이 아닌 ① 시간 단위를 연결해야 하고 ② 사용자의 시간에 맞추어서 프로덕트 동작이 다채로워야 하며 ③ 고객이 원하는 시간에 딜러버리를 해야 하고 ④ 로드맵이란 큰 마일스톤에 따라 잘 분배해야 합니다. PM의 시간 - 정의 1) 로드맵 - 기업, 조직 또는 제품이 달성하고자 하는 전략을 기본으로 그 목표를 설명하는 문서입니다.(≠딜리버리 플랜) - 로드맵은 타임라인이 정해져 있지 않은, 목표를 주관적이고 정성적으로 적어놓은 것입니다. - 로드맵은 프로덕트의 성공의 기회를 만드는 시간에 생성됩니다. 2) 타임라인(≠타이밍_무언가를 결정하는 전략적 순간) - 시작 날짜와 종료 날짜가 포함된 시간순으로 정렬된 이벤트의 시각적/물리적 순서입니다. 3) 프로덕트 사이클(=프로덕트 라이프 사이클, 프로덕트 개발 사이클) - 아이디어를 내는 순간에서 릴리즈, 유지보수를 하고, 다시 새 버전을 위해 새로운 루프가 시작되는 것을 의미합니다. - 프로젝트가 끝나더라도 프로덕트 라이프 사이클이 계속되는 한 프로덕트는 존속할 수 있습니다. 4) 데드라인(=Due Date) - 프로젝트 또는 이벤트의 마감일입니다. PM의 시간 - 로드맵과 타임라인의 조화 - 로드맵은 프로덕트 전략을 기반으로 달성해야 할 목표를 우선순위를 나누어 작성한 것이며, 타임라인을 기반으로 하지 않습니다. - 하지만 사용자, 고객, 회사의 경영진은 목표의 달성 시점(시간)이 들어가야 비로소 관심을 보입니다. - 따라서 로드맵은 방향, 의도 및 의사소통의 역할을 하는 동시에 전략적 목적을 위해 충족되어야 하는 타임라인과 데드라인을 포함해야 합니다. 로드맵, 타임라인, 릴리즈 플랜의 관계 - 아무리 훌륭한 로드맵이더라도 타임 팩터가 들어가 있지 않다면, 생명력이나 전달력이 부족해집니다. - PM은 훌륭한 커뮤니케이터로써 지속적으로 투명성을 공유하는 것이 성공의 핵심입니다. - 타임라인은 그 자체로는 어떤 의미도 없습니다. - 타임라인은 우선순위 그룹과 만나야 하고 우선 순위를 정의한 로드맵은 시작일과 종료일을 제시한 타임라인과 만나야 합니다. - 로드맵에 따른 기능을 정리하고 그 우선순위를 그룹화한 후 타임라인으로 나누면, 릴리즈 플랜을 만들어 출시 계획을 경영진, 고객 또는 사용자들과 소통할 수 있습니다.

UX 설계 문서 작성이 필요한 이유

https://abr.ge/6oasd9

[워크 프로세스]

문서 작성법

많은 팀에서 "지금은 UX 설계 문서를 작성할 시간이 없다. 디자인과 개발에 집중하자"며 문서 작성을 연기합니다. 문서화의 부족은 설계의 구현 단계에서 혼란을 야기합니다. 이 아티클은 UX 디자인의 문서화의 개념을 알아보고 이것이 왜 중요한지, 어떻게 하면 올바르게 수행할 수 있는지 유용한 팁들을 알려줍니다. UX 설계 문서란? - 프로덕트의 설계의 모든 측면을 다루는 문서 및 리소스의 모음이다. 문서에는 사용자, 프로덕트 기능, 팀원과 이해관계자들이 합의한 디자인 결정 사항 및 필수 구현 정보 등이 포함되어야한다. 문서화에 시간 투자를 해야하는 이유는? 1. UX 설계 문서는 프로젝트 요구 사항을 명확히 한다. - 이해관계자들은 설계 문서를 통해 디자인 결정 사항들이 회사의 비지니스 목표와 사용자 요구를 동시에 충족시키는 방법을 이해할 수 있다. 2. 구현 간소화 - 프로덕트 설계 시 다양한 사람들과 협업 하는데, 이때 설계 문서는 특정 목표 중심으로 팀을 결집 시키고 모든 사람에게 동일한 형태로 전달 되는 단일 정보 역할을 한다. 문서에 포함되어야 할 필수 사항 1. 프로젝트 개요 (UX팀이 달성 하고자하는 목표, 누구나 이해할 수 있어야함) 3. 팀 동기 부여 - 잘 설계된 문서는 프로덕트에 대한 높은 수준의 이야기를 전달하고 팀원들에게 프로덕트 비전을 심어주는 역할을 한다. "프로덕트를 어떻게 구축하고 싶은가?" "왜 이걸 만들고 싶은가"와 같은 질문에 대답할 수 있게 된다. 문서에 포함되어야하는 필수 항목 1. 프로젝트 개요 (UX 팀이 달성하고자하는 목표) 2. 제품 요구 사항 (설계 비지니스 및 기술적인 요구사항) 3. 프로젝트 결과물 (구현이 완료되면 결과물로 제공되는 정보) 4. 타겟 사용자 정보 (페르소나, 유저 리서치 데이터 등은 디자인 결정에 대한 근거 참고 자료가 됨) 5. 사용자 여정 (사용자의 프로덕트 사용 플로우 설명) 6. 디자인 가이드 라인 및 스타일 가이드 7. 프로젝트 범위 및 구현 계획 (ex. 프로젝트 타임라인) 8. 디자인 검증 및 사용자테스트 (제품 주기동안 수행해야하는 것들) 9. 운영 지침 (ex. 새 버전의 앱을 출시하는 방법에 대한 가이드) 적절하게 문서화하는 팁 1, 문서를 볼 타켓 유저 고려해서 작성 2. 최신 문서 제공 3. 점진적인 업데이트 작업 4. 문서 테스트 하기 5. 전문적인 용어 피하기 6. 쉬운 접근성 제공 (온라인으로 제공) 7. 시각적 예시 혹은 코드 샘플 제공 8. 문서를 최신으로 유지 9. 기존 문서의 패턴을 찾아서 템플릿화 하기

PM수첩: 꼭 알아야 할 4가지 우선 순위 정하기 기법

https://abr.ge/cspvo3

[성장의 피땀눈물]

PM/PO

일하는 방법

프레임워크

상황에 맞게 논리적으로 우선순위를 정하는 기술은 누구에게나 필요합니다. 이 글에서 언급되는 PM은 소프트웨어 서비스 기억의 프로덕트 매니저, 프로덕트 오너 등을 지칭하고 있으나 응용하여 해석하면 타 직군에도 대부분 적용될 수 있을것입니다. 빠르고 합리적인 "우선순위 정하기"는 모든 현대인의 생존 기술 현업의 PM에게 업무 중 가장 어려운 부분이 무엇이냐고 물으면 압도적으로 차지하는 대답은 "실제 시장의 피드백이 부족한 상태에서 로드맵에 따른 백로그의 우선순위를 지정" 하는 것이라고 합니다. 백로그 작업의 우선순위를 정하는 것은 PM의 가장 중요한 업무 책임 중의 하나입니다. 가장 단순하면서 명료한 원칙은 "첫번째로 중요한 일을 가장 먼저 하는것" 입니다. 하지만 이 일을 어렵게 만드는 잠재적 변수들이 있고, 아이디어들의 우선순위를 위한 미팅과 토론은 결정에 대한 영향력과 성공가능성의 극대화라는 목적때문에 늘 치열하게 이루어집니다. 그 덕에 많은 IT기업이 우선순위를 정하기 위한 여러가지 "우선순위 지정 기법"을 사용합니다. 모스코우(MoSCoW) MoSCoW는 애자일 프로덕트 관리 방법에서 중요한 것과 그렇지 않은 것을 구별하고 이해하기 위해 일반적으로 사용되는 방법입니다. 🄼 Must Have : 이 기능을 빼고 제품 딜리버리/서비스 론칭을 생각할 수 없는 것 🅂 Should have : 높은 우선순위를 지니는 기능이 분명하지만, 그것이 없어도 프로덕트에 재앙이 닥칠 운명까지는 아닐 때 🄲 Could have : 많이 이야기하는 'Nice to have'에 해당하는 것. 충분한 자원이 있다면 할 수 있었을 것이지만 성공을 위해 꼭 필요한 것은 아닐 때 🅆 Will not have : 많은 PM들이 "다음 버전에 포함하도록 신중히 검토하겠습니다."라고 말하는 것. 주로 개발자원 부족의 이유로 이번 버전에는 포함되지 않을 것이라는 의미로 사용 워킹 스켈레톤 (Walking Skeleton) 워킹 스켈레톤은 최소화된 프로덕트의 엔드 투 엔드를 구현한 것입니다. 최소 실행 가능 제품(MVP) 기능의 우선순위를 정하는데 사용되며, 그중 어떤 것이 제품이 작동하는데 절대적으로 중요한지 정의합니다. 이 방법은 특정 카테고리에 속하는 요구사항을 뜻하는 것이 아니라 사용자 스토리에 초점을 맞추어 우선순위를 정합니다. ① 먼저 필요한 사용자 스토리에 순위를 매깁니다. ② 필수 기능의 구현에 중점을 두기 때문에 주요 기능이 완전하게 동작하는 제품의 형태를 갖고 있어야합니다. ③ 비즈니스 가치를 충분히 보여주는 형태를 갖고 있어야합니다. 여러가지 기술 제한이 있는 상태에서도 핵심 시스템 요소를 표시하기 위해 스토리맵을 잘 정리해야합니다. 워킹 스켈레톤은 딜리버리와 배포까지의 모든 과정을 포함하기 때문에 제품 기능 테스트도 과정에 포함됩니다. 라이스 (RICE: Reach, Impact, Confidence, Effort) 라이스 방법은 우선 순위를 설정하기 위해 등급점수 모델이라는 방법을 사용합니다. 🅁 Reach : 특정 기간에 이 기능을 사용할 수 있는 사용자 수. DAU, MAU 등의 실제 프로덕트 지표로 평가 🄸 Impact : 이 기능을 사용함으러써 어떤 영할을 받을지에 대한 것. 상태적인 값으로 매우 큰 임팩트의 경우 3점, 높은 경우 2점, 낮을 수록 1점, 0.5점, 0.25점을 사용해 평가 🄲 Confidence : 신뢰도 값. 이 기능이 사용자에게 얼마만큼의 혜택을 주는지에 대한 추정값. 높은 경우 100%, 중간 80%, 낮음 50% 등 객관식 척도를 사용하는 것이 좋음 🄴 Effort : 제품, 디자인 및 엔지니어링 팀이 소요한 시간. 소요 일 수나 시간 등으로 계산 ➥ RICE = (Reach*Impact*Confidence)/Effort R, I, C의 곱을 E(시간)으로 나누어 계산. RICE의 값이 클수록 우선순위가 높다는 뜻이 됨 카노 모델 (Kano) 카노 기법은 고객 기반의 우선 순위 지정 방법입니다. 프로덕트의 기능에 대해 사용자의 만족도와 행동이 다르다는 사실에서 시작합니다. Must-be : 고객이 이 기능이 포함된 경우에만 제품의 의미를 두는 반드시 구현해야하는 기능 Performance : 프로덕트가 동작하기 위해 반드시 필요한 것은 아니지만, 고객은 이 기능을 매우 갖고 싶어 하는 경우 Attractive : 만족감을 더해주는 것들. 이 기능이 없다고 해서 특별히 불만족스러워하지는 않지만 가지고 있으면 좋은 기능 Indifferent : 고객 만족에 미치는 영향이 거의 없는 것 프로덕트 백로그에서 작업의 우선 순위를 정하는것은 PM의 중요한 책임 중 하나입니다. 직감에 의존할 수도 있지만 이러한 접근방식은 대개 해당 프로젝트와 제품/서비스를 위험에 빠뜨립니다. 원글에서는 위의 각 방법의 장단점과 이를 비교해놓은 표로 글을 마무리하고 있습니다. 어떤 상황에 어떤 우선순위 지정기법을 사용하는 것이 효율적인지 파악하실 수 있으니 관심이 가신다면 아래의 원글 링크에서 자세한 내용을 확인해보세요.

주니어 PM에게 바라는 10가지

https://abr.ge/w3jbks

[성장의 피땀눈물]

마인드셋

PM/PO

직무 분석

PM은 IT분야에서 많은 사람들이 원하는 직무이면서, 경험이 없으면 매우 어려운 직무입니다. 이 아티클에서는 처음 PM이 되어 IT 매니징에 아무런 경험이 없던 작가가 지난 몇 년간 경험하며 배웠던 10가지 교훈을 얘기합니다. 1. 다음달에 유니콘을 제공하겠다고 고객과 약속하지 마세요. 첫째로 유니콘은 존재하지 않으며, 둘째로 유니콘이 존재한다 하더라도 그 가능성을 팀과 확인해야 합니다. 고객은 항상 아이디어를 가지고 있고, 그 요구사항은 사실 어제 원했던 것입니다.* 하지만 성급히 약속하지 마세요. 고객의 레거시 코드를 확인하고, 실행 가능성을 평가하는 회의를 반복하세요. (*어제 원했다 = 아주 새로운 아이디어가 아니라, 이미 여러번 요구되었던 기능일 수 있습니다. - 역자 주) 2. 데모가 필요합니다. 프로젝트 시작 단계에서 고객에게 제품/디자인의 전체 데모를 요청하고 질문하세요. 데모 중에 질문하고 내용을 녹음하세요. 질문에는 옳고 그름이 없습니다. “전문적으로 보이기 위해" 질문을 하지 않으면, 플랫폼과 요구사항을 제대로 이해하지 못한 채로 잘못된 기능을 만드는 데 몇 주를 소비하게 됩니다. 3. 고객의 언어로 이야기하세요. 고객이 가장 선호하는 커뮤니케이션 방법이 무엇인지 이해하기 위해 회의를 몇 번 해보세요. 어떤 사람은 전화를 싫어하고 다른 사람은 문자를 싫어하고 어떤 사람은 보고서를 선호하는데 다른 사람은 전혀 보고서를 원하지 않을 수 있습니다. 그리고 특히 데모를 할 때 “Lorem ipsum and etc” 대신 그들이 쓰는 데이터와 사진을 사용하세요. 4. 팀이 잘 가고 있는지 확인하세요. Covid-19 시대에 번아웃은 현실적인 문제입니다. '웰빙'은 팀원의 일과 삶, 정서적이고 육체적인 측면을 모두 의미합니다. 관리자는 업무 및 작업속도를 저해하는 요소가 있는지 알아야 합니다. 5. 고객이 디자인에 참여하게 하세요. 물론, 우리가 스스로 디자인 요소와 플로우를 결정할 수 있습니다. 하지만 3개월 뒤에 고객이 “저희가 언제 이걸 하기로 했었죠? 기억이 안나네요...” 라고 말하고, 작업을 다시 해야 하는 상황에 빠질 수 있습니다. 고객을 관리자로 두지 말고, 함께 만들어가는 참여자로 만드세요. 6. To-do list를 만드세요. 회의 중에 바로 항목을 작성하세요. 우리의 단기 기억 체계*는 간단한 액션들을 잊을 수 있습니다. 작성하고, 고객에게 확인하세요. 세심한 배려는 항상 높게 평가됩니다. (*단기 기억 체계 = 사람의 자각 시스템에서 수초에서 수분 사이의 일시적인 정보의 보유를 담당하는 기억 체계입니다. - 역자 주) 7. PM은 첫번째 방어선입니다. 어떤 일이 발생할 때 당신이 팀을 보호할 수 있는지 확인하세요. 매니저는 항상 책임을 요구받지만, 팀을 하나로 모으는 것도 당신입니다. 8. 표정도 소통의 도구입니다. 원격 회의때 카메라를 켜는게 중요합니다. 팀원들이 논의된 내용에 동의했다는 것을 PM이 이해할 수 있는 방법 중 하나이기 때문입니다. 다른 방법으로는 예/아니오로 이해를 확인하거나, 미팅 콜이 끝날 때 팀원에게 책임을 인지하도록 반복하는 것입니다. 9. 먼저 팀을 구성한 후, 프로젝트를 구성하세요. 진부하게 들릴 수 있지만 잘 구성된 팀, 그리고 팀 내 합의 없이는 아무것도 되지 않습니다. 팀은 하나의 ‘몸'처럼 느껴져야 합니다. 10. 너무 많은 책임을 한번에 지지 마세요. 경력 초기에는 모든 PM이 야망덩어리이며, 모든 것을 처리할 수 있다고 생각합니다. 동시에 3-4개의 프로젝트를 수행합니다. 하지만 경험상 너무 많은 책임을 진다면 데드라인을 놓치거나 실수할 수 있습니다. P.S. 11번째로, 과로하지마세요! 점심을 먹고, 휴가를 가세요. PM은 어메이징한* 직무이기 때문에 경력 초기에는 번아웃이 올 수 있습니다. 당신이 앞으로 배울 것들과 그 여정에 행운을 빕니다! (*느낌을 살리기 위해 그대로 썼습니다. - 역자 주)

야근하지 않는 디자이너, 디자인 기반 PO의 첫걸음

https://abr.ge/f3chbb

[성장의 피땀눈물]

PM/PO

마인드셋

경험 공유

일하는 방법

[성장을 위한 데일리 아티클] '야근하지 않는 디자이너' 디자이너에게 요구되는 직무적 역할이 늘어나고 있는 요즘, 나를 포함한 많은 디자이너들은 처리해야 할 업무들에 둘러쌓여 있는 상태다. 나의 일을 효율적으로 처리하기 위해서는 똑똑하게 일하는 방법을 알아야 한다. 내가 야근을 했다는 것은 내가 효율적으로 일을 처리하고 있지 못하다는 뜻이다. 구조적으로 업무량에 비해 디자이너 리소스가 부족한 경우를 제외하고, 내가 가진 리소스로 내가 맡은 업무를 처리할 수 있다면 내가 야근하게 되는 이유는 아래와 같은 이유들로 발생하게 된다(이외에도 여러 이유가 있을 수 있지만 원 글의 내용을 기반으로 합니다). 1. 내가 가진 업무에 대해 제대로 파악하지 못했다 2. 일의 우선순위를 제대로 세우지 못했다 3. 작업 방향을 잘못 잡았거나 완성도에 집착하다 마감 기한을 놓친다 4. 물리적인 업무 시간 중 이미 시간을 배정해둔 협업 시간들을 유의미하게 보내지 못했다 이 중 1, 2, 3은 업무 효율성을 높이기 위한 순서이자 방법이다. [1. 내가 가진 업무에 대해 제대로 파악하지 못했다] 나의 시간을 효율적으로 배분하고 어떤 일을 먼저 집중해서 처리해야 하는지 아는 것은 내가 가진 업무가 무엇인지, 왜 그 일을 해야하는지를 파악하는 것으로부터 시작한다. 업무를 완료하면 어떤것이 더 나아지는가? 누구를 위한 작업인가? 작업을 완료하기 위해서는 어떤 리소스가 필요한가? 작업을 완료하기 위해서는 어떤 일들을 해야 하는가? [2. 일의 우선순위를 제대로 세우지 못했다] 각 업무를 왜 해야하는지를 알면 우선순위를 세울 수 있다. 다른 팀 지원 업무, 쉽게 끝낼 수 있는 일이지만 중요하진 않은 업무, 내부 회의에서만 쓰고 실제 프로덕트로 개발되지 않을 장표들의 경우 우선순위를 낮게 가져갸야 한다. 내 업무시간은 나의 팀의 목표에 맞고, 고객에게 더 중요한 일이며, 시간이 많이 필요하더라도 꼭 달성해야하는 어떤 것이다. [3. 작업 방향을 잘못 잡았거나 완성도에 집착하다 마감 기한을 놓친다] 주로 주니어에게서 많이 발견되기도 하는 이 문제는 시간이 오래 걸리는 일이거나 아직 익숙하지 않은 일 일수록 쉽게 발생할 수 있는 문제이다. 내 상관이 원하는 방향은 이미 있는데 그것을 제대로 파악하지 못하고 잘못된 방향으로 일하고 있다거나, 중요하지 않은 디테일을 먼저 신경써서는 안된다. 전체적인 얼개를 그려 드래프트를 자주 공유해 방향을 자주 점검하고, 큰 줄기에서 작은 줄기, 마지막 디테일 순으로 작업해야 진짜 중요한 작업을 놓치지 않을 수 있다. [4. 물리적인 업무 시간 중 이미 시간을 배정해둔 협업 시간들을 유의미하게 보내지 못했다] 스크럼, 회고, 의사결정을 위한 회의 등 다른 사람들과 협업하기 위한 시간은 고정되어있고, 여러 사람의 시간을 동시에 사용하기 때문에 더욱 귀중하게 쓰여야 한다. 회의 어젠다는 참석자에게 전달하고 수렴하고 싶은 내용이 확실하게 정해져야 한다. 이를 위해 주도적으로 회의를 준비해보는 것도 도움이 되겠다.

PM을 위한 API 해설

https://abr.ge/b5gu0a

[성장의 피땀눈물]

마인드셋

직무 분석

커뮤니케이션

PM과 소프트웨어 엔지니어가 레스토랑에 들어갑니다.엔지니어는 PM에게 API가 무엇이며 어떻게 작동하는지 레스토랑 일에 비유하면서 설명하기 시작합니다. 인증 (Authentication) 엔지니어: 회원 전용인 멋진 레스토랑에 간다고 상상해 보세요. 클럽 회원 자격이 있어야 레스토랑에서 식사를 할 수 있습니다. PM: API에서 이것이 의미하는 바는 무엇인가요? 엔지니어: 레스토랑에 입장하려면 요트 클럽 레스토랑에 입장할 수 있는 신분증과 유효한 멤버십 카드가 필요합니다. 기술 용어로 API 사용 인증을 받으려면 ‘API 키 또는 토큰’ 이 필요합니다. 엔드포인트/목적지(Endpoint) PM: 식당으로 가는 주소와 길을 알려주시겠습니까? 엔지니어: 주소는 '엔드포인트(http://xxx.com)'라고 부릅니다! 메소드, 요청과 응답 (Method, Request and Response) PM: 이제 레스토랑에 도착했으니 음식을 주문하죠! 엔지니어: 여기 있습니다, Method = Get GET method 는 지정된 리소스의 서버에서 데이터를 검색하는 데 사용됩니다. (‘Method’ 는 API에 수행하도록 요청하는 '동사' 또는 '동작'일 뿐입니다.) 이 시나리오에서는 웨이터에게 레스토랑에서 제공되는 메뉴를 요청했습니다. Request: 레스토랑에서 제공되는 항목 목록을 보도록 요청했습니다. Response: 응답의 결과는 레스토랑에서 제공되는 항목 목록을 보여주는 메뉴를 얻는 것입니다. Method = Post 상상의 요트 클럽 레스토랑에서는 원하는 음식을 찾지 못해 레스토랑의 주방장에게 전화를 걸어 맞춤형 “비건 버거” 새로운 요리를 요청합니다. 그리고 요리사는 이 새로운 항목을 메뉴에 추가하기로 결정했습니다! 이 시나리오에서 메뉴에 새 항목을 넣는 행위를 'Post‘ 라고 합니다. Request: 셰프가 새로운 “비건 버거” 메뉴를 추가합니다. 요청에는 메뉴에 게시할 설명 및 가격과 함께 항목 이름이 포함되어야 합니다. Response: 이 결과 '설명' 및 '가격'과 함께 “비건 버거”가 게시되고 메뉴에 표시됩니다. Method = Put “비건 버거”는 레스토랑에서 큰 인기를 얻었지만 터무니없는 가격에 요리사는 가격을 몇 달러 인하하기로 결정합니다. 이 시나리오에서 메뉴의 기존 항목을 업데이트하는 작업을 'Put'이라고 합니다. Request: 셰프가 “비건 버거” 항목의 새 가격을 입력합니다. 요청 페이로드에는 업데이트 중인 항목의 참조 및 값과 함께 업데이트가 필요한 매개변수가 포함되어야 합니다. Response: 이 결과 메뉴에서 “비건 버거”가격이 업데이트됩니다. Method = Delete “비건 버거”에 대한 수요가 급증하자 요리사는 메뉴에서 인기없는 다른 메뉴를 제거하기로 결정합니다. 아이템을 제거하는 행위를. API 용어로 ’Delete’ 라고 합니다. Request: 셰프가 메뉴에서 '캐비아'를 제거해 달라고 요청할 것입니다. 요청 페이로드에는 메뉴에서 제거할 다른 세부 정보 중에서 항목 이름이 포함되어야 합니다. Response: 이 결과 메뉴에서 '캐비아'가 더 이상 표시되지 않습니다. 상태 코드와 오류 메세지 (API Status Codes and Error Messages) PM: 와우! API가 원하는 모든 작업을 수행한다는 사실이 마음에 드는군요. 엔지니어: API가 항상 잘 작동하는 것은 아닙니다. 종종 오류도 발생합니다. 아래 '응답 코드'를 통해 API의 동작 상태를 확인할 수 있습니다. 2xx : 요청이 성공했음을 의미합니다. 3xx : 운전을 해서 상상의 요트 클럽 레스토랑으로 가서 새 주소로 이사했다는 안내판과 호텔 직원이 새 위치 방향을 알려주는 안내판을 찾았다고 상상해 보세요. API 용어로 요청이 다른 URL로 리디렉션됨을 의미합니다. 4xx: 레스토랑으로 차를 몰고 가 '캐비아'를 주문했는데 더 이상 레스토랑에서 제공되지 않는다는 사실을 알게 되었습니다! 이는 클라이언트 오류(승인되지 않음, 금지됨, 페이지를 찾을 수 없음)와 동일합니다. 5xx: 이 경우에는 레스토랑의 문제입니다! 비건 버거를 주문했지만 대기열이 길고 항목을 만드는 데 시간이 오래 걸렸습니다. API 용어로 그것은 서비스를 사용할 수 없거나 게이트웨이 시간 초과를 의미합니다.

디자인 시스템 구축 경험을 인터뷰하다

https://abr.ge/e7qdqe

[디자인]

디자인 시스템

경험 공유

SaaS 기업을 위한 고객 여정 지도

https://abr.ge/7k7yau

[디자인]

프레임워크

리서치

Getfeedback 이라는 서비스에서 SaaS 기업이 고객 여정 지도를 그려야하는 이유와 이점 등을 작성한 내용입니다. 물론 SaaS 기업이 아니더라도 참고할 만한 내용이 많습니다. 1. 고객 여정 지도를 만드는 방법 - 고객 여정 라이프사이클 그리기 - 잠재 고객 → 충성고객이 되기까지 일반적인 단계 - 1. 발견 - 2. 탐구 - 3. 구입 - 4. 사용 - 5. 물어보기 - 6. 관여 - 회사 및 고객 접점(touch point: 터치포인트) 식별 - 각 단계에서 무슨 일이 일어나고 있는지 확인 - 고객의 조치 - 동기 - 질문 - 장벽 - 각 접점에서 고객의 경험과 감정을 이해하는데 도움 - 기존 전략과 기대 사이의 격차 분석 2. SaaS 기업을 위한 고객 여정 지도 - SaaS 회사는 복잡한 고객 여정을 가짐 - 고객은 여정의 단 하나의 접점에도 불만을 품는 경우, 다른 옵션을 많이 선택할 수 있음 - 대부분의 SaaS 회사는 구독 모델에 의존 - 높은 이탈률을 피하기 위해 고객 경험을 지속적으로 개선하고 향상시켜야. 3. SaaS에서 여정 지도의 관련성 - SaaS 구매 프로세스에만 평균 6.8명이 포함 - SaaS 제품은 단 한 사람으로 인해 조직 전체가 경쟁업체로 전환되어 상당한 수익 손실을 입을 수도 있음. - 고객 여정은 처음부터 끝까지 최고 수준이어야 이탈 감소. 4. SaaS 고객 여정 지도의 이점 - 조직 전체에서 효과적으로 의사 소통하는데 중요 - 현재 상태와 최적의 상태에 대한 이해를 공유하기 쉬움 - 모든 도구에서 추적, 기여 및 동기화하는데 필요한 데이터를 정의 - 1:1 개인화된 경험을 대규모로 확장할 수 있는 방법을 간략하게 설명 5. 다뤄야할 질문 - 내 사용자는 누구인가? - 소프트웨어에는 다양한 종류의 사용자가 있을 수 있음 - 각 사용자는 제품이 충족해야 하는 특정 요구 사항을 가지고 있음 - 도구와 "실제" 세계 사이의 인터페이스는 무엇입니까? - 소프트웨어가 어떤 맥락에서, 어떻게 사용되는지 이해하는데 중요한 질문 - 사람들과 기업이 소프트웨어를 구매하고 운영하는 방법과 관련된 조건들은 무엇입니까? - 사용자의 소프트웨어 온보딩을 어떻게 지원할 수 있습니까? - 온보딩은 SaaS 고객 여정에서 특히 중요한 부분 - 도구를 사용할 사람들에게 도구를 소개하고 효과적으로 사용할 수 있도록 교육

UX의 확증 편향

https://abr.ge/dkiipd

[디자인]

마인드셋

심리학

UX의 확증 편향 사람들은 자신의 생각이 옳다는 것을 확인하고 싶어하고 반대되는 의견을 과소 평가하려는 경향이 있습니다. UX 디자인 시, 적절한 리서치 방법론을 활용한다면 확증 편향을 사전에 인지하고 피할 수 있습니다. 우리가 맞다고 생각하는 것들을 선호하고 사실과 증거를 무시하는 건 사용자에 대한 공감과 진정한 것을 찾는데에 방해가 됩니다. UX 분야 종사자들이 확증 편향에 대해 주의해야하는 이유 디자인과 사용자에 대해 '가정'을 하기 때문에 더욱 경계해야한다. 디자인을 만들기 위해 몇달 동안 노력했다면 자신의 디자인이 괜찮다는 증거를 믿을 가능성이 높고, 문제가 있다는 결과에 대해서는 회의적일 것이다. 확증 편향은 사용자와 공감하는 능력에 부정적인 영향을 미치고, 잘못된 설계 및 연구로 이어져 피드백 및 결과에 대해 잘못된 해석을 유발할 수 있다. 예를 들어, 전자 상거래 사이트에서 매출이 낮은 이유가 '결제하기 버튼의 잘못된 설계' 때문이라고 가정함. 다음과 같은 질문을 실행하기로 함. "빨간색의 결제하기 버튼이 찾기 어려웠나요?" 이 질문에는 몇가지 문제점이 내포되어있다. 1. 결제하기 버튼에 초점을 맞추면 이것에 대한 증거만 수집하도록 편향된다. 결제 프로세스에서 '버튼'이 진짜 문제가 아닐 수 있다. 2. 질문에서 부정적인 언어('찾기 어렵다')는 사용자가 이 버튼이 정말 효과적인지 아닌지 보다 '문제'에 대해 생각해보게 한다. 3. 폐쇄형 질문 (예/아니오, 혹은 주어진 문항을 선택하는 질문을 뜻함. 반대되는 개념은 어떤 방식으로도 대답할 수 있는'개방형 질문'임)은 사용자의 실제 경험과 발생한 문제에 대해 컨텍스트를 제공할 여지를 주지 않는다. 그렇다면 적절한 질문은 무엇일까? "결제 과정은 어땠나요? 그 과정에서 좋았던 점 혹은 나빴던 점을 설명해주세요." UX 확증 편향을 방지하는 팁 1. 검증 보다 연구 - 가설을 '검증' 하려기 보다 '테스트'를 목표로 하기. 연구의 목표는 내 가정이 맞다는 걸 확인하는게 아니라 미리 알지 못했던 걸 아는 것이다. 디자이너는 민첩해야한다. 잘못된 길을 가고 있다면 이를 빠르게 인식할 수 있어야함. 2. 초기 데이터 수집 - 가능한 한 타겟 사용자로부터 실증적인 데이터를 빨리 얻으면 얻을 수록 데이터를 분석하고 결과에 따라 행동 했을 때 편향되지 않을 수 있다. 3. 편견없는 질문 하기 - 사용자에게 피드백을 수집할 때 결정적이고 중요한 질문을 하지 말 것. 그 질문을 함으로써 사용자가 해당 이슈 대해 민감하게 느끼는 역효과가 나타난다. 사용자가 질문을 받았을 때 내 가설이 무엇인지 예측 가능할 경우 질문을 바꾸는 것이 좋다. 4. 삼각 측량 기법을 사용 - 하나의 연구 결과만 본다면 자신의 가설과 일치 시키기 위해 결과를 쉽게 바꿀 수 있다. 여러 연구를 통해 얻은 데이터를 사용하면 훨씬 어렵다. 다양한 연구를 통해 신뢰성을 높이고 확증 편향을 방지하기. 5. 연구 계획 및 분석에 대해 새로운 시각을 가진 사람들을 참여 시킬 것. - 프로젝트와 관련없는 동료에게 연구 계획 검토 요청을 하고 결과 발표에 참석하게 할 것. 새롭고 중립적인 관점을 제시해줄 수도 있다.

UX디자이너를 위한 10가지 소프트스킬

https://abr.ge/4d73ll

[성장의 피땀눈물]

마인드셋

UX 디자이너를 위한 커뮤니케이션 꿀팁

https://abr.ge/itwlb6

[워크 프로세스]

마인드셋

가이드

성공적인 디자이너가 되기 위해서는 두가지 유형의 스킬이 필요합니다. 이것을 소프트스킬과 하드스킬이라고 합니다. 소프트스킬은 대인관계 스킬입니다. 하드스킬은 특정 분야에 특화된 전문스킬입니다. 소프트스킬 즉, 커뮤니케이션 스킬은 디자이너의 기본 스킬이자 업무의 핵심입니다. 팀에서 효과적으로 의사소통할 수 있고 좋은 평판을 얻을 수 있는 능력입니다. 좋은 커뮤니케이션을 통해 신뢰를 쌓을 수 있으며, 정직한 피드백을 나누고 작업에 대한 확신을 가질 수 있습니다. 디자이너는 마법사가 아닙니다. 주니어 디자이너는 종종 UX디자인 작업을 오랫동안 공유하지 않고 혼자서 작업하다가 최종 솔루션을 짠! 하고 보여줍니다. 대부분의 경우, 이 주니어 디자이너는 팀원들이 솔루션을 받아들이지 않는다는 사실에 화를 냅니다. 작업 중간중간 팀원들에게 작은 변화들을 공유하세요. 팀원들이 작업 프로세스에 기여하게 되면 솔루션을 더 잘 이해할 수 있으며, 솔루션을 수용할 가능성이 높아집니다. 하지만 모든 것을 전달할 필요는 없습니다. 유저에게 유효하지 않거나, 자신없는 아이디어는 공유하지 않는 것이 좋습니다. 진정한 마법은 경청에서 시작됩니다. 미팅은 디자이너 업무의 많은 비중을 차지합니다. 경청하지 않으면 올바른 솔루션을 설계할 수 없습니다. 다른 팀원의 말을 집중해서 듣고 ‘왜?’를 질문하세요. 개발자들에게 질문하는 것을 두려워하지마세요. 질문을 통해 발화 의도를 확인할 수 있고 새로운 지식을 얻을 수 있습니다. 또한, 다른 팀원의 말을 경청하면 그들의 상황과 고군분투에 공감하여 문제를 더 쉽게 해결할 수 있습니다. 회의를 적극적으로 활용하세요. 모든 회의에 참석할 필요는 없습니다. 그러나 중요한 회의에 참석하고 있다면, 질문을 통해 적극적으로 참여하세요. 다양한 주제를 이해할 수 있는 기회가 되며, 크리티컬할 수 있는 이슈를 사전에 논의할 수 있습니다. 특히 주니어 디자이너에게 중요한 것은 질문을 부끄러워하지 않는 것입니다. 많은 경우, 혼자만 이해하지 못하는 게 아닐 수 있습니다. Flow Chart와 프로토타입을 사용하세요. 말로만 설명하기 힘든 경우들도 많습니다. 다양한 시각 자료를 활용하면 원활하게 커뮤니케이션을 할 수 있습니다. 팀원들에게 흐름을 설명하기 위해 플로우차트를 사용하면 요점을 설명하는데 도움이 될 수 있습니다. 또한 프로토타입을 활용하면 팀원들이 제품을 더 구체적으로 이해하고 피드백을 줄 수 있습니다. 논의하기 전에 주제를 공부하세요. 디자이너가 제품을 잘 모르거나 사용자 조사를 하지 않으면 잘못된 정보를 가지고 결정하게 되고, 비효율적인 논의를 반복하게 됩니다. 사람들이 전문가의 의견을 듣는 이유는 그들이 제시하는 정보를 신뢰할 수 있기 때문입니다. 사람들이 당신을 신뢰하기 시작하면 설득하기도 훨씬 쉬워지며 갈등과 오해가 줄어들 것입니다. 건설적인 피드백을 수용하여 전문성을 키우세요. 피드백은 가끔 가혹할 수도 있습니다. 하지만 팀원이 당신의 업무에 대해 어떻게 느끼는지 모르고 나쁜 습관을 유지하는 것보다는 건설적 비평을 듣는게 낫습니다. 사람들은 부정적 피드백을 주는 것을 꺼려하기 때문에, 피드백을 요청하기 전에 “정확한 의견이 더 나은 UX디자인을 만드는데 도움이 된다”는 것을 언급하는 것도 좋습니다. 프레젠테이션 스킬은 필수입니다. 오늘날의 디자이너는 디자인 작업 그 자체 보다 ‘작업에 대해 설명'하는 시간이 더 많은 것 같습니다. 회의에서, 개발자에게 디자인을 공유할 때, 디자인 크리틱 시간 등에서 디자인 작업을 시연해야 합니다. 팀이 이해하고 수용할 수 있도록 명확하고 간결한 메시지로 디자인을 전달하고, 의도를 묻는 질문에 대답할 수 있어야 합니다. 연습하면 더 나아집니다! 협상 능력은 사용자 경험 디자이너의 핵심 스킬입니다. 최종 제품의 성공 여부는 팀이 얼마나 잘 협력하고 타협점을 찾을 수 있을지에 달려있습니다. 개발자, PM 관점을 이해하고 작업 범위를 협상할 수 있어야 합니다. 예를 들어 복잡한 UX디자인을 개발해야 하는 경우, 개발팀이 현재 얼마나 개발해야 하는지, 개발할 수 있는 여력이 얼마나 있는지를 이해하고 협상해야 하는 경우가 많습니다.

팀이 사랑하게 될 백로그 만들기

https://abr.ge/eu53nn

[워크 프로세스]

스타트업

PM/PO

문서 작성법

가이드

[성장을 위한 데일리 아티클] '팀이 사랑하게 될 백로그 만들기' 스타트업 씬에서 빠르게 프로덕트를 개발하다보면 백로그에 남아있는 이슈들이 점점 많아지게 되는 경험을 많이 해보셨을 것 같아요. 백로그에 등록된 이슈들은 우선순위를 관리해주지 않으면 이슈가 쌓이기만 하고, 스프린트로 올라와서 해결되는 이슈는 점점 적어지고, 그 크기나 중요도와 관계 없이 아이디어들만 중구난방으로 흩어져있는 창고가 되기 쉽습니다. 저도 B2B SaaS 프로덕트를 만들 때는 고객의 요구사항에 의해 짧은 기간에 해결해야 할 로드맵이 구성되기 쉽고, UX 개선이나 내부적으로 의미있는 기능들은 뒷단으로 밀리는것을 경험하고 있습니다. 백로그를 아이디어의 무덤이 되지 않게 활용할 수 있도록 소개하는 방법을 시도해보세요! 1. 들어오는 업무를 기록하기 쉽게 하기 새로 들어오는 업무 요청사항들은 여러 이해 관계자로부터 발생할 수 있습니다. 백로그는 앞으로 해야 할 업무가 쌓이기 시작하는 Source of Truth로 활용될 수 있어야 합니다. 이 Source of Truth에 쌓인 업무들으로 우선순위를 파악하는 작업이 이어집니다. 기록되어야 할 것: 모든 새로운 할 일 2. 그루밍이 필요한 할 일이 무엇인지 알기 쉽게 하기 백로그에 등록된 이슈들 모두가 업무할 수 있도록 정리될 필요는 없습니다. 한 백로그에서 장기, 중기, 단기 할일들이 쌓이게 될 것입니다. 백로그 그루밍을 시간 효율적으로 하려면 단기 할일들을 우선해서 그루밍 할 수 있도록 해야합니다. 기록되어야 할 것: 일이 처리되어야 하는 due 고객사 임팩트가 적거나, 실행 가능하지 않은 아이디어들에는 그루밍을 할 필요가 없습니다. 그런 이슈들은 Not Doing 로 태깅하고 다음 이슈로 넘어갈 수 있어야 합니다. 기록되어야 할 것: Status - Not Doing 장기적으로 미래 로드맵에서 가져가면 좋은 이슈들은 지금 내용을 정리할 필요는 없지만, 나중에 다시 와서 쉽게 확인할 수 있어야 합니다. 기록되어야 할 것: Status - Future Nice to Have 3. 우선순위가 높은 할 일을 찾기 쉽도록 하기 우선순위를 결정하는 것은 어려운 일입니다. 실행 하기로 결정되어 그루밍 된 이슈들 중 우선순위가 낮거나 아직 우선순위가 판단되지 않은 이슈와, 우선순위가 높은 이슈들을 구분해서 더 중요한 일을 쉽게 확인하도록 할 수 있습니다. 기록되어야 할 것: Status - 우선순위 낮거나 지정되지 않음 기록되어야 할 것: Status - 우선순위 높음 다음 스프린트에 할 일 / 이전 스프린트에서 못 한 일 백로그에 처음 등록된 할 일은 최종적으로 '다음 스프린트에 할 일'으로 이동하게 됩니다. 그리고 이번 스프린트 할 일은 새로 등록된 할 일과 지난 스프린트에서 끝내지 못한 일을 하게 됩니다. 기록되어야 할 것: Status - 이번 스프린트에서 할 일 기록되어야 할 것: Status - 지난 스프린트에서 못 한 일 4. 불필요한 일은 숨기기 보통 진행하지 않기로 한 업무는 히스토리 관리를 위해 삭제하지는 않습니다. 진행하지 않기로 한 업무들을 Archive하여 보이지 않도록 정리할 필요가 있습니다. 기록되어야 할 것: Status - Archive

🧐 문의 채널을 설계하는 방법

https://abr.ge/e7gswh

[프로덕트 & 데이터 분석]

문서 작성법

경험 공유

프로덕트 전략

지속적인 가능성을 생각하세요. 사용자는 항상 어디서든 도움을 받을 수 있어야 합니다. 일관된 사용자 인터페이스 사용하세요. 도움말 정보에 대한 접근 및 표시는 시스템 전체에서 동일해야 합니다. 짧고 정확해야 합니다. 모든 세부 사항의 모든 내용이 다루어져야 합니다. 사용자는 필요한 것을 얻은 다음 나가기 위해 고객 센터에 옵니다. 도움말 기사는 제품을 판매하거나 마케팅 연설을 사용하는 장소가 아닙니다. 사용자 입장을 공감하세요. 레이아웃을 단순하게 유지하고 불필요한 일러스트레이션을 피하며 사용자를 "겁먹게" 할 수 있는 색상에 대해 주의를 기울이는 것을 피하세요. 솔직하게 말하고 추측하지 마십시오. 얻는 도움말 정보는 사용자의 특정 상황을 대상으로 해야 합니다. 사용자에게 알아야 할 사항을 말하되 얕잡아 보지 마십시오. 더미 데이터를 활용하세요. 가짜 사용자 페르소나로 데모 계정을 만들어 문제사항을 시험해 보세요. 문의 채널의 상담원 입장에서 생각해 보세요. 문의 내용이 ‘해결됨’ 으로 결론 내려질 때 까지, 상담원이 온라인 혹은 오프라인에서 문제를 해결하는 데 사용하는 시간, 채널, 방법을 측정하여 회사 내부의 영향도를 체크하세요. 검색 가능성 및 카테고리 최고의 고객센터는 검색 창을 주요 초점으로 만들고 동의어에 초점을 맞춘 스마트 인덱싱 시스템을 갖추고 있습니다. 그러나, 모든 사람들이 동일한 방식으로 사용하는 것은 아닙니다. 탐색을 좋아하는 사람들에게는 카테고리를 제공할 필요가 있습니다. 기본적으로 각 카테고리의 처음 몇개의 내용만 표시함과 동시에 기사 제목을 한눈에 보여주는 레이아웃을 선택하십시오. 고객센터에만 집중하지 마세요 유용한 정보를 제공하는 가장 빠른 방법은 제품 내 설명을 사용하는 것입니다. 길이를 제한하여 적절한 서브 설명 텍스트, 툴팁을 활용하세요. 하지만, 아무데나 툴팁을 추가 하지는 마세요. 그렇게 하면 UX 문제에 대한 반창고 솔루션처럼 느껴질 것입니다. 해당 요약본은 2개의 아티클을 참고하여 작성되었습니다. - To help a Helpdesk application : a UX Case Study (https://abr.ge/e7gswh) - Help me help you: How we design help documentation at Envoy (https://abr.ge/8objut)

Meta에서 일하는 것이 프로덕트 디자이너에 대한 이해를 어떻게 변화시켰는가?

https://abr.ge/qalkts

[디자인]

마인드셋

워크플로우

경험 공유

[성장을 위한 데일리 아티클] '워크 프로세스' Meta에서 일하는 것이 프로덕트 디자이너에 대한 이해를 어떻게 변화시켰는가? Meta에서 1년 동안 일하면서 저는 여전히 디자이너들이 직면한 도전에 대해 큰 감사를 표하지만 디자인이 어떻게 작동할 것인지에 대한 생각을 넘어 목적을 이해하게 되었습니다. 1. 당신이 디자인하는 것이 이미 있다면 그것은 새로운 것이 아닙니다. 저는 직전 회사에서 Meta보다 훨씬 더 넓은 범위의 업무를 수행했습니다. 그러나 그곳에서 진행한 디자인은 새로운 것은 아니었습니다. 물론 엔지니어링 한계, 기능 등의 약간의 차별점은 있었지만 이미 그 디자인은 무엇을 위한 것인지 차별점이 없어도 알 수 있었습니다. 즉, 제품 디자이너가 되기 위해서는 일반적으로 인정받는 구성 요소가 무엇인지, 어떤 역할을 하는지 알아야 합니다. 그래야 사용자가 제품을 사용할 때 쉽게 사용할 수 있습니다. 인지하고 있는 프로덕트 표준에서 벗어나지 않고 익숙한 사용성을 설계하는 것을 의미합니다. 그리고 항상 훌륭한 프로덕트 디자이너의 디자인이 집단적으로 어떻게 작용하는지 이해해야 한다고 느꼈습니다. 2. 가장 어려운 부분은 사람들이 입증하지 않은 개념에 동의하도록 하는 것입니다. 세계 기술 제품을 선도하고 있는 Meta에서는 항상 새로운 디자인을 하고 있습니다. 저는 개인 정보 보호 규정을 준수하는 새로운 비즈니스 솔루션 설계뿐만 아니라 책임감 있고 개인 정보 보호 중심적인 경험을 우선시하는 솔루션을 설계해야 했습니다. 또한 사용자와 비즈니스 모두에 가치를 제공해야 했습니다. 어떻게 하면 많은 단어 없이 새로운 기능을 사람들에게 이해시킬 수 있을까요? 여러분은 그들에게 이야기를 들려줄때, 비주얼이 뒷받침하는 설득력이 있는 이야기를 해야 합니다. 그러고 나서야, 그들은 어떻게 작동하는 것인지 질문을 하게 될 것입니다. 3. 정확한 작동 방식을 알지 못하고 설계하는 것은 일부입니다. 누군가가 텍스트 링크를 누르면 어떤 내용이 표시되는지 물어보면, 저는 시각적으로 보여주지 않고 "링크를 클릭하면 허브로 이동하여 관련 세부 정보를 볼 수 있습니다."라고 개념적으로 설명할 수 있습니다. 즉, 중요하지 않다면 모든 화면을 디자인할 필요는 없습니다. 전에 보지 못한 제품을 전달하고 디자인할 수 있는 능력은 제품 디자이너를 성공으로 이끄는 것입니다. 대부분의 경우, 컨셉 보드를 만들어야 했지만, 사실 일반적으로 컨셉작업은 최종결과물이 아니라 단순히 아이디어를 보여주는 방법입니다. 그 후에 독특한 엔지니어링 문제를 팀원들과 함께 최선의 방법을 찾습니다. Conclusion 저는 운 좋게도 Meta에 있게 되었습니다. 이곳에선 새롭고 이름없는 컨셉들을 연구할 기회가 있습니다. 성공적인 프로덕트 디자이너가 되러면 모든 것을 처음부터 끝까지 봐야 한다고 생각했습니다. 이름이 없는 새로운 제품의 경우, 아직 작업할 팀조차 없을 수 있기 때문에 모든 구성요소를 알 수 없습니다. 또한 컨셉 설계의 목표는 이해관계자들이 시간과 노력을 투자하는 데 관심을 가질 만한 것인지 확인하는 것입니다. 그리하여 저는 Meta에서 스토리텔링 컨셉 작업이 UI/UX디자이너와 역할을 차별화하고 제품을 제품 디자이너로 만드는 요소라는 것을 배웠습니다.

박주현

사람들이 착각하는 MVP에 대한 오해

https://abr.ge/fbn8dx

[프로덕트 & 데이터 분석]

프로덕트 분석

프로덕트 전략

실 사례

MVP(Minmum Viable Product)는 무엇을 위한 것인가. - MVP는 최소 비용으로 고객에 대해 학습하는 수단이다. 제품 생산 전에 비즈니스 아이디어를 저렴한 비용에 잠재 고객에게 전달하고, 그들의 관심 여부를 평가하는 행위를 반복하여 시장과 고객에 대한 인사이트를 높여가는 프로세스를 의미한다. 이를 통해 고객이 원하는 제품 가설을 구체화하는 것이 MVP의 목적이다. - 따라서 MVP를 통해서는 제품을 출시하고 나서야 알 수 있는 '시장에서 성공할 수 있을지', '사람들이 구매할지', '이 기능을 좋아할지', '이렇게 설계하면 될지' 등을 알 수 없다. MVP는 어떻게 활용해야 할까 - 예시) 드랍박스는 '사람들이 더욱 편리한 파일 공유 방식에 관심이 있'다는 가설을 증명하기 위해 제품의 사용 방식을 거의 동일하게 구사한 데모 비디오를 배포했다. 비디오에 대한 사람들의 관심을 수치화하여 그것에 투자할 만한 가치를 증명할 수 있었다. MVP는 제품의 성공을 보장하지 않는다 - 제품의 만들어지는 과정은 '제품 발견'과 '제품 실행'으로 나뉜다. 특히 실행 과정에 있어 고객과 끊임없이 소통하고 제품을 개선해가야 한다. - 결국, MVP에 과도하게 기대하지 말고, 고객의 니즈와 그것을 해결하기 위한 실행에 집중해야 한다.

PM을 설득하려면 어떻게 해야할까?

https://abr.ge/ksqumu

[워크 프로세스]

가이드

마인드셋

협업

커뮤니케이션

이 글을 읽고 있는 디자이너분들께서는 제품이 잘못된 방향으로 가고 있다고 PM(Product Manager)에게 의견을 말해본 적이 있나요? 제품이 정말 의미없이 산으로 갈 것만 같아서 꼭 PM에게 말해야 하는 상황이라면 어떻게 할까요? 아래에서 PM이 의사결정 및 우선순위 지정에 활용하는 툴을 알아보고 이를 효과적인 커뮤니케이션의 발판으로 삼아보시기 바랍니다. [간단하고 사용이 쉬운 툴] 순서도(Flow Chart) 논리적으로 파고들 수 있습니다. ex. 타겟 고객층이 누구인지 아시나요? -> 현재 제품 상태가 그들의 문제를 해결해주나요? -> .......(계속되는 검증, 질문) -> 대안으로 이건 어떤가요? -> (우선순위 추려서) 이 솔루션으로 해봅시다. [더 나은 툴 제안] 제품 두뇌(The Product Brain) 노드 해킹하기 아이디어를 명확하게 표현할 방법을 찾고 있다면, 가장 좋은 길은 PM이 어떤 방식으로 생각하고 무엇을 두려워하는지 이해하는 것입니다. ///노드로 표현되는 제품 두뇌 (본문에 그림 있습니다)/// 리서치 -> 영감 획득 -> 아이디어 발전 -> 검증 -> 가치 따지기 -> 영향도 따지기 -> 기획 -> 구현 -> 측정 -> 학습 제품 두뇌는 일련의 '노드'를 통해 작동하는데, 노드 일부는 해킹할 가치가 있습니다. 다음은 커뮤니케이션에 임하기 위한 노력과 그 결과에 따르는 영향입니다. 처한 상황에 맞게 접근하면 좋을 것입니다. - 리서치: 노력 중간, 영향 중간 - 영감과 아이디어: 노력 중간, 영향 낮음 - 검증 및 가치 따지기: 노력 높음, 영향 높음 초점은 정성적 평가입니다. 대상 사용자를 만나고, 설문 조사를 실행하고, 종이 프로토타입을 보여주고, 이벤트에 참석하고, 조사를 수행하십시오. 한 사람의 삶에 의미 있는 영향을 미칠 무언가를 만들고 있는지 확인하십시오. 그 과정에서 미래에 새로운 아이디어를 더 쉽게 검증할 수 있는 프레임워크를 개발하게 될 것입니다. - 영향도 따지기: 노력 높음, 영향 높음 진정으로 가치 있는 문제를 찾아 검증한 경우에도 고려할 가치가 있는 적절한 사용자 집단를 충분히 배려해야 한다는 것이 요점입니다. 이 단계에서는 설문조사, a/b 테스트, Fake dore test 등 정량적 평가에 중점을 둡니다. - 기획 및 구현: 노력 중간, 영향 낮음

효과적인 제품 비전을 작성하고 전달하는 방법

https://abr.ge/eysohv

[워크 프로세스]

문서 작성법

프로덕트 전략

비즈니스 전략

협업

UX 디자인 검수란?

https://abr.ge/j11cpc

[디자인]

가이드

문서 작성법

UX 디자이너들은 사용자에게 긍정적인 경험을 주기 위해 다양한 부서와 이해관계자들과 협업하며 자신의 디자인과 비지니스 전략이 일치하는지 확인합니다. 협업은 좋은 디자인으로 이어질 수 있지만 디자인의 일관성 문제, 접근성의 격차 등의 어려움을 겪을 수 있습니다. 이런 이유로 정기적인 디자인 검수를 계획하여 제거해야할 차이들을 찾고 측정하고 해결하는 것이 중요합니다. 디자인 검수란? - 디자인 검수란 품질 보증 (Quality Assurance, 많이들 알고 있는 'QA')을 의미함. UX 관점에서 프로덕트가 접근성, UI 컴포넌트의 일관성 및 디자인 통합 요구사항을 충족하는지 평가함. 이 과정을 통해 디자이너들은 이전에 발견하지 못했던 이슈나 다음 디자인 스프린트에서 해결되어야할 이슈를 찾을 수 있다. 디자인 검수 과정에서 발견되는 흔한 이슈들 - 스크린 리더 사용자에게 필요한 이미지 대체 텍스트 누락 - 일관성 없는 폰트 타입 및 사이즈 사용 - 네비게이션 링크 누락 - 업데이트가 안된 구 콘텐츠 - 적절하지 않은 컴포넌트 사용 패턴 - 접근성 요건을 충족하지 않는 브랜드 컬러와 동떨어진 컬러 사용 - 레이아웃의 기준이 없어 컴포넌트 배치가 어수선하고 삐딱함 디자인 검수는 언제 해야 할까? - 최대한 자주, 정기적으로 할 것. - 디자인 검수를 미루면 미룰수록 이슈가 문제를 만들 가능성이 높아져 디자인 과정에서 해결하기 어려워짐. 웹사이트 디자인 검수 시 사용되는 방법들 10가지 사용성 휴리스틱 1) 시스템의 가시성 2) 현실세계와 부합 하도록 설계 3) 사용자에게 적절한 통제권을 부여 4) 일관성과 표준성 높이기 5) 사용자 실수 방지 6) 적은 인지적 노력 7) 유연하고 효과적인 사용성 8) 심미적이고 미니멀한 디자인 9) 사용자 스스로 오류를 인지하고 벗어날 수 있도록 설계 10) 충분한 도움말 제공 ( 각 항목에 대한 더 자세한 내용 아래 아티클들 참고해보시면 좋아요. - 닐슨&노먼 그룹 아티클 참고: http://abit.ly/0v8cec - 국문은 이 브런치 추천 드립니다: https://brunch.co.kr/@hyoi0303/53 ) 접근성 가이드라인 - 모든 사람들이 디자인을 사용할 수 있도록 설계되는 건 중요하다. - 회사 내부에 접근성 지침이 없다면 'W3C 접근성 표준'을 참고 하는 것도 방법이다. (https://abit.ly/4njwod) 프로토 타이핑 도구를 활용해 UI 컴포넌트의 연속성과 일관성 유지하기 - 프로토타이핑 도구를 활용한 사용성 테스트를 통해 UI 구성 요소 패턴을 테스트 하기 스타일 가이드 라인 준수 - 프로덕트의 look&feel 과 Tone&Manner 에 대한 지침을 제공하는 문서를 잘 지키면 일관된 사용자 경험을 제공할 수 있다. UX 검수 템플릿 - UX 검수 템플릿을 구축하여 팀에게 인사이트를 제공하는 것이 중요하다. 아래 항목들을 스프레드 시트의 열 제목 사용해서 각 문제들을 평가해보기. 1) 문제 설명: 무엇이 문제인지 2) 문제 위치: 문제가 어디서 발생하는지 3) 사용성 휴리스틱: 어떤 휴리스틱 요건이 충족되지 않는지? 4) 접근성: 접근성 문제인가? 예/아니오 5) 사용자에게 미치는 영향도: 얼마나 심각한 영향인지? 높음/중간/낮음 6) 디자인 수정 규모: 수정하는데 노력은 얼마나 드는지? 높음/중간/낮음 7) 개발 규모: 디자인 수정을 위해 개발 리소스는 얼마나 드는지? 높음/중간/낮음 8) 우선 순위: 위의 항목들 결과를 토대로 전체 우선 순위 설정하기 UX 검수로 얻는 인사이트 - UX 검수에서 가장 가치 있는 부분은 팀에서 다양한 관점으로 논의하고 합의한 UX 평가 기준으로 프로덕트을 평가 할 때 이루어 진다. 문제에 대한 계획을 좀 더 수월하게 할 수 있다.

엔터프라이즈 UX리서치를 진행할 때 고려할 점

https://abr.ge/ajt14t

[워크 프로세스]

마인드셋

리서치

UX리서치는 풍부하고 가치있는 사용자 경험을 만드는데에 있어 가장 중요합니다. 올바른 UX 리서치는 UX품질은 물론 사용성과 비즈니스 수익 측면에서 완성도 높은 제품을 만듭니다. 엔터프라이즈 서비스의 컨텍스트에는 수 많은 이해관계자와 레거시, 사용자와 구매자의 경험 차이 등의 과제가 있습니다. 따라서 엔터프라이즈 서비스의 UX리서치를 수행하기 위해서는 아래와 같은 키 포인트를 염두해 두어야합니다. 1. 서비스 구매자는 실제 사용자가 아니다 엔터프라이즈 서비스는 고객이 실제 사용자가 아니라는 점에서 일반 B2C앱과 차이가 있습니다. 엔터프라이즈 서비스는 실제 사용자의 요구사항을 이해하는 것이 중요합니다. 엔터프라이즈 프로젝트의 성공은 사용자의 요구가 얼마나 충족되었는지에 달려있으며, 이는 사용자의 생산성 향상으로 이어집니다. 따라서 제품 기획 초기에 사용자리서치를 진행하고 사용자의 요구를 파악하는데에서 부터 시작해야합니다. 2. UX 리서치를 통해 도메인에 대해 기본적인 이해하기 엔터프라이즈 서비스는 복잡한 인터페이스와 인터랙션으로 구성되어있어 워크플로우를 깊이있게 이해하는 것은 모든 리서치팀에게 필수적입니다. 엔터프라이즈 프로젝트를 진행하기 위해서는 도메인에 대한 철저한 이해가 바탕이 되어야합니다. UX리서치의 장점은 서비스 사용에 대한 실제 전문가인 사용자를 찾고 도메인 관련한 내부 정보를 알 수 있다는 점입니다. 기본적인 도메인 지식을 쌓으면 의미있는 방식으로 결과를 매핑하고 분석할 수 있습니다. 3. 사용자의 행동은 레거시 시스템만큼 복잡합니다. 대부분의 사용자는 자신의 임무를 수행하기 위해서 작업을 수행합니다. 많은 사례에서 사용자는 본인이 필요한 작업을 완료하기 위해 선택적인 기능에 대해서만 공부한다는 것을 알 수 있습니다. 따라서 워크플로우를 조금만 변경해도 시스템 전체의 기능을 이해하지 못하는 사용자들은 업무 효율성이 저하될 수 있습니다. 따라서 리서처와 디자이너는 현재의 행동패턴과 새로운 시스템에서의 기대치를 이해하는 것 외에도 시스템의 역사, 변화, 사용자의 반응을 주의 깊게 조사해야합니다. 4. 사용자가 말하는 것과 실제로 하는것에는 차이가 있습니다. UX리서치에서는 어떤 것도 표면 그대로 받아들여서는 안됩니다. 리서처로서 사람들의 인터뷰와 피드백 내용을 신뢰하고 싶겠지만 본질적인 인사이트를 얻기 위해서는 직감에 의존해야합니다. 이런 상황에서는 얻은 데이터를 교차 확인 및 분석하고 여러 시나리오에 대해 검증하는 것이 중요합니다. 또한 계층구조, 문화적 요인 등 의사결정에 영향을 줄 수 있는 다른 요인도 확인해야합니다. 5. 엔터프라이즈 시스템에서도 사용자는 즐거울 수 있습니다. 사용자는 오랜 세월 따분하고 복잡한 엔터프라이즈 서비스를 쓰고있습니다. 현재 서비스의 좋지 않은 경험을 쉽게 무시할 수도 있지만 워크플로우를 개선하는 사소한 변화에도 크게 기뻐할 수 있습니다. 제품 테스트 단계에서 이런 사용자의 사례를 자주 볼 수 있고, 이런 변경은 사용자의 작업을 더욱 쉽게 만듭니다. 모든 유저는 인간이며, 실제 경험에 맞추어 쾌적한 시스템으로 작업하고 싶어하는 공통의 욕구를 가지고 있습니다. 디자이너에게 엔터프라이즈 서비스를 만드는 것은 지뢰가 난무하는 들판을 걷는 것과 같은 느낌일 수 있습니다. 그러나 이러한 프로젝트를 수행함으로써 얻은 성공 또한 그만큼 더 달콤합니다. 엔터프라이즈 서비스의 성공은 리서치팀이 도출한 결과와 관찰의 질에 크게 좌우됩니다. 결국 UX리서치가 EUX(Enterprise UX)의 혁신이 실제로 시작되는 단계라고 할 수 있습니다.

8가지 통계 법칙

https://abr.ge/i74cju

[프로덕트 & 데이터 분석]

마인드셋

데이터 분석

프레임워크

가이드

통계 연구 결과는 어떤 내러티브로 전달하는지가 아주 중요합니다. 통계학 졸업반 학생들을 대상으로 하는 Statistics as Principled Argument 라는 책의 저자인 Abelson의 법칙 8가지를 소개합니다. 전달을 위해 의역을 많이 했으니 원문이 궁금하신 분들은 원문을 확인해주세요. 1. 확률은 생각만큼 매끄럽게 발생하지 않는다 - 동전 던지기가 50% 확률이라고 해서 앞면 다음에 반드시 뒷면이 나오진 않습니다 - 실제 랜덤 함수의 결과는 결과들이 생각보다 뭉쳐있습니다 2. 사람들은 표본 간 차이를 무시하려는 경향이 있다 - 표본마다 측정치는 다를 수 있는데, 이를 무시하고 잘못된 확신을 가지려 하는 경우가 많습니다 - 특히 표본 크기가 작을 때 추정된 값을 중심으로 신뢰 구간을 계산하는 것이 중요합니다 3. 통계적 관행은 한 번만 다시 생각하라 - 오랜 시간동안 유의성 실험에 p < 0.05를 사용하는건 관행이었습니다 - 하지만 현대 UX 분석에서 p < 0.10이라는 덜 엄격한 기준을 적용했을 때 더 높은 통계적 힘을 낼 수 있었습니다 - 마음에 드는 결과를 찾기 위해 p < 0.05와 p < 0.10 사이를 왔다갔다 하면 안됩니다 4. 복잡한 분석 방식으로 뭘 분석해야할 지 모름을 덮으려 하지 마라 - 다변량 분석 방식은 유의미할 수 있는 종속 변수를 결합할 수 있는 어떤 방법이 있음을 나타낼 뿐, 그 조합이 어떤 실제적 의미를 갖는지는 고려되지 않았습니다 - 각각 단일 분석 결과는 상관 관계가 있지만 UX 관점에서 다르게 해석되는 경우가 있습니다. 이런 분석 결과를 맹목적으로 조합 해 그 조합을 이해하려는 노력보다는 각각을 별도로 분석하는것이 더 옳습니다 (예: 성공률, 용이성 등급, 완료 시간) 5. 아무 할 말이 없을 땐 아무 말도 하지 마라 - 종종 분석 결과가 어떤 유의성도 보이지 않는 경우가 있을 수 있습니다 - 여기서 어떤 의미를 뽑아내기 위해 데이터를 이리 저리 쥐어짜기 보다는 다음 연구로 넘어가는게 맞습니다 - 거짓으로 결과를 뽑아내는것 보다는 아무 말도 하지 않는 것이 낫습니다 6. 공짜 점심은 없다 - 단일 실험 결과는 실험 맥락을 벗어나는 일반적인 경우까지 일반화되어 적용될 순 없습니다 7. 소파를 움직이지 않으면 먼지를 볼 수 없다 - 한 분석 결과가 컨텍스트가 다른 상황에 적용 가능할 지 확인하는 방법은 그 컨텍스트를 변수화 하는 것입니다 8. 비판은 방법론의 어머니다 - 모든 답을 내려주는 한 가지 실험은 있을 수 없고, 한 실험은 어떤 종류든 비판에 노출될 것입니다 - 적절한 비판을 받았다면 연구자들은 그러한 비판을 극복할 수 있는 추가적인 연구를 수행하게 될 것입니다 - 이런 결과로 기존 일반론이 지지되거나, 수정되거나, 파기되기도 하며, 새로운 일반론이 등장하기도 합니다

프로덕트를 어떻게 측정할 것인가 (How to Measure Your Product)

https://abr.ge/h3opcv

[프로덕트 & 데이터 분석]

프로덕트 분석

중니어 프로덕트 디자이너를 위한 조언

https://abr.ge/unquap

[워크 프로세스]

마인드셋

직무 분석

변경될 내용에 시간을 낭비하지 마세요. 이해 관계자를 설득 시키기위한 몇분을 위하여, 완벽한 디자인을 만들기 위해 몇 시간을 보낸 적이 있나요? 시안 중 하나만 선택되고 나머지는 폐기됩니다. 이 경우 각 시안의 개념을 전달할 수 있을 만큼만 디자인하고 명확한 피드백을 받은 후 디자인을 완성하는 데 시간을 투자해야 합니다. 따라서 작업에 투자하는 노력의 수준은 해당 위험의 양(즉, 크게 변경될 가능성)과 일치해야 합니다. 모든 회의의 아젠다를 설정하세요. 1. 우리가 이 회의를 하는 이유 2. 회의에서 논의될 내용 3. 이 회의에서 달성하고자 하는 것 해당 내용을 명확히 하면 4가지 주요 베네핏 있습니다. - 회의중 논의하고 싶은 명확한 요점을 가지는데 도움이 됩니다. - 구성원 모두 회의 목적에 대한 명확한 이해와 가시성을 이해할수 있습니다. - 구성원 모두 같은 공동의 목표를 위해 일할 수 있습니다. - 모든 논의를 체크하고 대화가 탈선하지 않도록 돕습니다. 주요 이해 관계자와 1:1로 인터뷰하세요. 새 제품에 합류할 때, 주요 이해 관계자 및 팀 구성원(PM, 엔지니어...)과 대화할 시간을 설정해 잠재적인 문제를 판별하는 데 도움이 되는 질문을 해보세요. - 과거에는 무엇이 잘 되었습니까? - 과거에 잘 되지 않은 것은 무엇입니까? - 사람들이 제품을 사용하는 데 어떤 이의가 있습니까? - 제품을 사용하기 어려운 이유는 무엇입니까? - 기술적인 제약이 있습니까? 프레임워크 구축하세요. 프레임워크의 사용은 아마도 새로운 기능, 특히 매우 빠른 실행이 필요한 프로젝트에서 작업할 때 가장 좋아하는 것 중 하나입니다. 시간을 절약할 뿐만 아니라 설계자(심지어 이해 관계자)가 제공해야 하는 것을 진정으로 이해하도록 돕습니다. 다른 디자이너들과의 협력하세요. 디자인 페어링은 두 명의 디자이너가 문제, 제품 또는 프로젝트에 대해 함께 작업하는 경우입니다. 페어링은 협업을 통한 학습을 장려하고 팀에 많은 베네핏 제공합니다. - 작업의 더 나은 목표설정과 우선 순위 지정 - 신선한 관점과 실시간 피드백 - 강화된 책임의식 - 빠른 지식 공유 - 빠른 피드백을 통한 더 나은 디자인 - 설계 결정에 대한 자신감 증가 - 미래 설계 부채 감소 작업한 디자인을 다시 리뷰하세요. 스스로에게 완성된 디자인에 다시 질문하세요. 화면에서 이 요소를 제거할 수 할수 있을까? 제거하면 어떻게 될까? 이는 불필요한 정보로 디자인을 깔끔하게 정리하는 데 도움이 될 뿐만 아니라 디자인 근거에 대한 확신을 얻는 데 도움이 됩니다. 증거로 결정 뒷받침하세요. 디자인 근거를 명확히 설명하고 뒷받침할 수 있다는 것은 제품 디자이너로 역할중 큰 부분입니다. 제품과 모범 사례를 수집하여 하나의 파일로 조합하고 특정 사용 사례에서 작동하거나 작동하지 않을 수 있는 항목을 강조 하세요. 이 사고 과정은 이해 관계자에게 2가지 모습을 보여줄 수 있습니다. - 다른 대안을 시각화하고 그것이 효과가 있거나 없는 이유를 볼 수 있도록 돕습니다. - 여러 옵션을 고려하고 있으며 정보에 입각한 결정을 내리고 있음을 보여주고 있습니다. 여러분은 디자이너입니다. 이 학습은 여러분이 디자이너로 고용된 이유가 있다는 것을 상기시켜줍니다. 디자인 관련 항목을 논의할 때 디자인에 대한 책임과 소유권이 부여되었음을 기억하세요. 주도권을 잡고 항상 더 선임 팀 구성원(특히 비디자이너)의 의견에 의존하지 마세요. 주도하는 것이 편하지 않다면 다음과 같은 것들이 도움이 될 수 있습니다. - 다른 디자이너와 확신이 서지 않을 수 있는 부분을 논의하세요. - 설계 프로세스를 최적화하기 위한 프레임워크 구축 시작하세요. 특정 문제나 기능의 중요성을 과대평가하고 마세요. 어려운 문제를 다룰 때 사용자와 완전히 공감할 수 있도록 몰입해야 합니다. 이러한 몰입은 우리가 이 문제의 중요성을 너무 많이 확대하는 결과를 초래할 수 있는 "집중 착시"로 이어질 수 있습니다. 이를 피하는 몇 가지 방법은 다음과 같습니다. - 사용자 경험 맵 : 전체 경험에 대한 전체적 관점을 얻기 위해 살펴보세요. - 사용자 조사 : 사용 상황 및 수행할 여러 작업에 대한 다양한 정보를 얻습니다. - 디자인 페이링 : 집중 착시가 일어날 문제에 대해 다른 디자이너로부터 새로운 관점을 얻으세요.

UI/UX 디자인에서 프레젠테이션 스킬을 마스터 하는 법

https://abr.ge/uckcqx

[워크 프로세스]

마인드셋

프로덕트 전략

PM/PO

워크플로우

UI/UX 디자인에서 프레젠테이션 스킬을 마스터 하는 법 UI/UX 분야에서 첫 커리어를 시작할 때 대부분의 사람들은 디자인, 문제, 해결책, 분석, 연구, 프로토타이핑 또는 UX writing과 같은 어려운 기술을 생각합니다. UX디자이너로서 성공하기 위한 기본적인 역량이지만, 프레젠테이션 및 커뮤니케이션 스킬의 중요성을 쉽게 생각하지 않는 것이 중요합니다. 프레젠테이션 기술은 아이디어, 개념 및 디자인 정보를 효과적으로 구현하는 데 사용되며, 프레젠테이션 기술이 UX/UI 디자이너로서의 커리어에 도움이 될 수 있는 방법이 있습니다. 왜 프레젠테이션 스킬은 UI/UX 역할에 중요한가? 디자인 프로세스는 커리어의 핵심일 수 있지만 모든 프로젝트에서 함께 일하는 사람들과 협력하고 설득해야 합니다. 1 : 포트폴리오 프레젠테이션 눈에 띄는 디자인 포트폴리오를 만드는 데 많은 시간과 에너지를 쏟아 부은 후에는 경쟁에서 눈에 띄는 데 도움이 될 것입니다. 자신의 작업을 명확하고 자신 있게 표현할 수 있는 것도 중요합니다. 2 : 반복적인 디자인 공유 (리뷰) 연구와 데이터를 기반으로 특정 디자인이나 목업을 어떻게 생각해 냈습니까? 전체적인 관점을 간결하게 제시하는 방법을 알면 팀이 훨씬 더 빨리 좋은 솔루션에 도달하는 데 도움이 될 수 있습니다. 3 : 최종 디자인 발표 자신감 있고 명확한 프레젠테이션은 최종 승인을 위한 강력한 스킬입니다. 긴장, 신뢰 부족 등으로 부적절한 소통을 하게되면 문제가 될 수 있으나, 강력하고 합리적인 프레젠테이션은 청중이 디자인 솔루션을 새롭고 긍정적인 관점에서 보도록 설득하는 데 도움이 될 수 있습니다. UI/UX 프레젠테이션 스킬 향상을 위한 10가지 팁! 전략적 목표를 설정하고 청중의 참여를 유도하는 것부터 긍정적인 사고 방식을 위한 준비 및 계획에 이르기까지 프레젠테이션 기술을 향상시키는 데 도움이 될 수 있는 10가지 방법이 있습니다. 1 : 프레젠테이션의 명확한 목표 결정 - 프레젠테이션을 통해 달성하고자 하는 바를 파악하는 시간을 가지세요. - 잠재적 고용주에게 포트폴리오를 보여주고 있는 지, 새로운 아이디어를 시도하도록 설득하려는 지 생각하세요. - 프레젠테이션의 전체적인 구조와 전달하려는 요점을 계획하세요. 2 : 간결하고 명확한 주제 설정 - 간결하고 하나의 핵심 주제에 집중하세요. - 글머리 기호를 사용하거나 시각적 그래프를 만드세요. - 이해하기 쉬운 콘텐츠로 청중을 더 몰입하게 하세요. 3 : 프레젠테이션에 유머 가미 - 유머는 청중이 긴장을 풀고 친밀감을 형성하도록 도움되는 스킬입니다. - 요점을 설명하기 위해 자신에 대한 재밌는 일화를 포함해보세요. - 대규모 그룹에 전달하기 전에 신뢰할 수 있는 동료나 친구에게 유머를 시도해보세요. 4 : 프레젠테이션에 유머 가미 - 유머는 청중이 긴장을 풀고 친밀감을 형성하도록 도움되는 스킬입니다. - 요점을 설명하기 위해 자신에 대한 재밌는 일화를 포함해보세요. - 대규모 그룹에 전달하기 전에 신뢰할 수 있는 동료나 친구에게 유머를 시도해보세요. 5 : 청중 참여 유도 - 직접적인 질문을 사용하여 의견을 구하세요 - 손을 들어달라는 요청을 하여 청취자가 자신의 의견이 가치 있게 느끼도록 도와줄 수 있습니다. 6 : 프레젠테이션 마지막 요약 포함 - 프레젠테이션 길이가 아주 긴 경우, '마무리' 슬라이드를 넣어주세요. - 이 페이지에서는 목표를 다시 확인하여 1~3가지 주요 요점으로 골라주세요. 7 : 열정 나누기 - 열정적인 대화를 나누기 위해 청중이 어떤것에 관심이 있는지 미리 생각해보세요. - 청중과 소통하는 방법을 찾으세요. 8 : 내용 숙지 - 프레젠테이션의 전체적인 내용을 숙지하는 시간을 가지세요. 9 : 연습, 연습, 또 연습 - 집에 있는 거울이나 몇 명의 신뢰할 수 있는 동료나 친구 앞에서 수행해보세요. 10 : 긍정적인 마이드 유지 - 프레젠테이션 전에 숙면을 취하세요. - 명상, 호흡운동, 아침 러닝 등 긍정적인 감정을 느끼는 데 도움되는 일을 해보세요. - 발표에 대한 두려움이 있다면 마음속으로 아래 내용처럼 읊어보세요. - 나는 잘 준비되어 있습니다. 나는 발표할 준비가 되어있다, 나는 사람들과 연결하는 것을 즐긴다, 이 정보를 공유하게 되어 기쁩니다 Conclusion UX디자이너로서 커리어에 있어서는 프레젠테이션도 중요합니다. 효율성을 높이고 면접관, 이해 관계자 및 팀 구성원이 작업을 이해하도록 하려면 의사 소통 및 프레젠테이션 기술을 예리하게 유지하는 것도 똑같이 중요합니다. 이는 많은 연습과 경험을 통해 얻을 수 있는 기술이며, 해당 분야의 경험 많은 전문가로부터 피드백을 구할 때 향상될 수 있습니다.

박주현

2021년 B2B 마케팅 트렌드 15가지

https://abr.ge/rja4r0

[성장의 피땀눈물]

마케팅

마인드셋

일반 이론

2021년 B2B 디지털 마케팅 트렌드 9가지 2021년은 B2B 마케팅에서 디지털 전환이 가속화된 해였습니다. 이러한 흐름은 2022년에도 가속화될 것이기에 2021년에 일어난 주목할 만한 B2B 마케팅 15가지를 정리해보고자 합니다. (국내에서 적용하기 용이한 9개 사례만 요약했습니다. 전문은 링크에서 확인 부탁드립니다.) 1. AI의 지배력 증가 AI는 조직이 데이터 잠재력을 실현하고 다재다능한 홍보 전략을 위해 콘텐츠를 스케일업하며 고객에게 더 나은 시각과 서비스를 제시할 수 있도록 지원합니다. Ex. 챗봇은 고객들에게 더 빠른 반응성, 더 나은 서비스는 물론 24시간 대응을 제공할 수 있는 연중무휴의 에이전트입니다. 2. 진실하고 독창적인 콘텐츠 파워 진정한 콘텐츠를 홍보하는데 집중하면 높은 성과를 얻을 수 있습니다. 아래 5가지 팁을 참고하세요. (1) 키워드 리서치 기반의 콘텐츠 게재 (2) 긴 포맷과 짧은 포맷의 혼합 콘텐츠 (3) 고객, 임원, 파트너에게 콘텐츠 판매 (4) 비즈니스를 위한 구독자, 팔로워 구축 (5) 콘텐츠 상위 노출을 위한 유료 광고 집행 3. 고객 유지를 위한 타깃 마케팅(리텐션 & CRM) 하버드 비즈니스 리뷰에 따르면 고객 유지율이 5% 증가할 때 수익은 25~95% 증가합니다. 또한 새로운 고객 확보 대비 5~25배 저렴한 비용이 사용됩니다. 고객 유지 전략은 B2C, B2B 모두에게 필수입니다. 4. 옴니채널 마케팅 전략 고객이 어느 채널에서나 브랜드를 찾을 수 있게 하는 옴니 채널 마케팅은 고객과의 상호작용 촉진은 물론, 고객 유지율을 91% 상승시킵니다. 다만, 모든 채널을 사용하지만 통합되지 않는 멀티 채널 마케팅과는 구분되어야 합니다. 5. SEO & SEM 음성 검색, 검색 의도와 시맨틱 검색의 증가로 인해 기존과 같은 짧은 키워드는 물론 롱테일 키워드 및 인포그래픽 콘텐츠의 적극 활용이 필요합니다. 6. 영상 마케팅과 VR B2B 고객의 90% 이상이 온라인에서 영상을 시철할 뿐만 아리아 절반 이상이 제품 및 서비스 검색의 목적으로 영상을 이용합니다. VR이 중요성 역시 점차 증가하고 있습니다. 7. Paid 마케팅에 대한 투자 Organic과 Paid는 동전의 앙면과 같습니다. Organic이 브랜드 평판, 신뢰 등을 정의한다면 Paid는 보다 빠른 도약을 가능하게 합니다. 특히 대부분의 브랜드가 Paid 광고를 이용한다는 점에서 경쟁사의 마케팅을 고려하지 않을 수 없습니다. 8. 웹 혹은 블로그 콘텐츠 재최적화 새로운 콘텐츠는 최적화에 시간이 걸리기 때문에 보다 효율적인 운영을 위해서는 기존에 웹 혹은 블로그에 업로드된 콘텐츠를 업데이트 하는 재최적화를 통해 검색 엔진에서 높은 위치에 위치할 수 있습니다. 9. 인플루언서 마케팅 B2C 마케팅에 한정되있던 인플루언서 마케팅은 B2B 영역에도 확장되고 있습니다. 인플루언서를 통해 세분화된 고객 니즈 공략은 물론 개인화된 구매 경험을 제공할 수 있습니다. 특히 B2B 인플루언서 마케팅은 콘텐츠를 재생산하는 인플루언서 유형에 보다 초점을 맞춰야 합니다.

SaaS 스타트업에서 디자인 프로세스 실행하기

https://abr.ge/ojc5es

[워크 프로세스]

경험 공유

실 사례

프레임워크

2019년 약 3년 전 센드버드 디자인팀에서 작성한 글입니다. 알아보니 당시 센드버드는 시리즈 B 투자(약 586억원)를 받았네요. 실제 스타트업 팀의 경험에서 나온 이야기라 좋은 글이라고 생각합니다. - 프로세스를 만들기 전 센드버드 디자인(UX)팀은 크게 3가지 문제를 발견 - 문제 1. 프로젝트 우선순위와 배경 공유 - 기존에는 프로젝트에 참여하는 디자이너, 개발자 모두 다수의 일을 동시에 진행하는 시스템 - 즉흥적 판단으로 우선순위를 정하고 의논 - 히스토리가 기록되지 않아 다른 사람이 배경을 이해하기 어려움 - 문제 2. 디자인 결정사항에 대한 기준과 자료 분석 - 벤치마킹, 고객의견, 페르소나, 시장조사 등이 개인적 차원에서만 이루어짐 - 결국 적절한 참고자료인지 재확인 필요 - 문제 3. 제품 전체에 대한 디자인 목표 정의 - 슬랙이나 구두로 급하게 오고간 경우가 많고 제품에 대한 균일한 목표가 없었음 - 이해하고 있는 정의와 목표도 멤버마다 다름 해결점: 우리에게 맞는 디자인 프로세스 만들기 - 작업과정 시각화 하기 - 전체 UX 설계 과정을 하나의 문서로 시각화 - 결과의 공유보다는 각 프로세스별 과정을 공유하는 것에 집중 - 프로젝트 배경과 요구사항 이해하기 - 현재의 UX 플로우 분석 - 고객이 제품을 쓰고 있는 상태를 파악하고 문제 찾기 - UX 관련 정량적, 정성적 데이터 사용하기 - 고도화된 비슷한 서비스 참고하고 표로 제작 - UX 문제 확인과 우선순위 정하기 - 기능 추가는 페이지 추가를 겸함 - 발생할 수 있는 문제를 미리 점검 - UX 플로우를 그려 변경되야하는 부분 파악 - 와이어프레임 - 문제의 본질에 집중하기 위해 일반적인 형태로 그리고 논의와 수정을 반복 디자인 프로세스의 결과 - 다른 팀과 협업 시, 공유 요소 전반을 파악하기 용이 - 제품에 대한 각기 다른 관점과 불확실성으로 인한 피로도 해소 - 투명한 소통으로 UX 개선에 대한 이해도 높임 - 개진 의견에 설득력이 높아짐 - 프로젝트 요구사항과 제한영역은 명료해짐 - 다른 팀과 협의가 편리해짐 배우게 된 것 - 처음에는 디자인 과정이 정방향일거라 예상 - 실제로는 전 단계로 돌아가 재검토와 개선을 거듭 - 이슈를 확인하고 UX 플로우가 맞는 방향으로 흐르는지 점검의 연속 - 아쉽게도 해야할 일은 더 늘어남 - 프로세스는 디자인 팀이 타 팀과 협의 시 도움이 됨 - 유동적으로 피드백이 반영된, 정보에 기반한 결정을 할 수 있게 됨 다음 단계는 - 잘 알려진 방법론이나 프로세스를 그대로 차용하지 않음 - 센드버드에 맞는 업무 방식과 부족한 부분이 무엇인지 생각하면서 실험

UX 디스커버리 단계에서의 문제 설명

https://abr.ge/nled9u

[워크 프로세스]

일반 이론

UX 디스커버리 단계에서의 문제 설명 요약: 문제 설명은 해결해야할 문제에 대한 간략한 설명이다. UX 디자인 프로세스의 초기단계인 ‘디스커버리’ 에서 문제 설명을 작성하면 문제에 대한 동의 및 추후 프로세스에 대한 방향을 제시할 수 있다. 문제 설명을 구성하려면 문제가 누구에게, 어떻게 영향을 미치는지, 문제를 해결하는 것이 왜 중요한지 중점을 둔다. 문제 설명에는 아래 사항들이 포함되어야 한다. 1. 문제의 배경 * 어떤 부서/조직이 문제를 겪고 있는가? 어떻게 대두 되었는가? 문제의 근본 원인 파해치기 2. 문제의 영향을 받는 사람들 3. 문제가 조직에 미치는 영향 * 문제가 해결되지 않았을 때 조직에 어떤 결과를 가져올지? 비용이 얼마나 드는지? 문제 설명에 도움을 주는 5Ws (다섯개의 W) * 아래 질문들에 대한 답을 한번에 답하지 않아도 된다. ‘디스커버리' 단계에서 해결해야할 문제이며 언제든지 돌아가서 문장에 대한 답을 추가할 수 있다. * 누가 문제의 영향을 받는지? (Who is affected by the problem) * 문제가 무엇인지? (What is the problem?) * 어디서 문제가 발생하는지? (Where does this problem occur?) * 언제 문제가 발생하는지? (When does the problem occur?) * 왜 문제가 발생한는지? 왜 이 문제가 중요한지? (Why does the problem occur? Why is the problem important?) 문제 설명은 목적에 맞게 잘 작성되어야한다. * 하나의 문제에 초점을 맞출 것 * 관련 없는 문제를 나열하는 건 너무 많은 문제를 해결하려고 있다는 신호다. * 솔루션을 포함하지 않는다. * 디스커버리 단계는 최적의 솔루션이 뚜렷하게 그려지지 않는다. * 간략하게 할 것. * 문제 설명을 간단한 문장으로 표현할 수 있으면 그 문제에 집중하는 이유를 사람들이 빠르게 이해할 것이다. 문제는 항상 부정적이여야 한다? 오히려 기회를 포착할 수 있다! * 우리의 현재 상태와 미래에 원하는 모습의 차이를 강조해야한다. 우리가 목표하는 것은 무엇인지? 문제 설명을 활용하는 법 * 문제를 설명하는 것은 디스커버리 단계를 구조화 하기 위한 출발점으로 활용할 수 있다. 문제에 대해 알고 싶은 여러 질문들을 통해 문제를 더욱 구체화 하며 ‘진짜' 문제가 무엇인지 파악할 수 있다

SaaS 서비스 온보딩 잘하는 법

https://abr.ge/dvttqb

[디자인]

온보딩

가이드

온보딩에 왜 신경써야 할까? - 신규 유저 40~60% 이상이 2일차에 서비스를 이탈합니다. - 유저가 유료 고객이 되어 다른 사람들과도 제품을 공유할 가능성이 높아집니다. - 신규 유저를 대상으로 한 개선이 많을수록 모든 KPI(유료 전환율, 구독 유지율, 투자회수 등)가 나아집니다. → 흔히 나오는 7가지 실수와 개선 방향 가이드 (4번부터는 간략히 적었어요. 더 자세한 내용은 링크를 눌러보세요) ① 기존 유료 유저들이 익숙하게 사용하던 서비스를 판매 전략상 무료로 제공할 수도 있습니다. 이 때, 온보딩이 부족한 상태에서 신규 유저는 갈피를 잡기 힘듭니다. 당연한 컨텍스트는 사실 당연하지 않습니다. 새로 입사한 동료직원에게 프로그램을 사용하게 해보고 어떻게 쓰는지 화면을 관찰해보자. ② 빈 칸이 너무 많으면 유저가 그 화면에서 요구되는 작업을 완료할 동기 부여에 악영향을 줍니다. 템플릿, 더미 데이터 등으로 default값을 넣어주어 작업 완료 시 나타날 결과를 시각적으로 보여주세요. ③ 그것이 유저에게 어떤 의미가 있는지 충분히 설명해주지 않으면 서비스에 신뢰를 주기 어렵고, 프로세스를 충실히 마치기가 어렵습니다. 유저에게 무엇인가를 요구하는 주요 항목을 찾습니다. 그리고 유저의 관점에서 그것을 왜 입력해야 하는지 1~2문장으로 설명을 넣어봅니다. ④ '둘러보기' 기능에 의존하지 마세요. 제품은 그 자체로 직관적이어야 합니다. '둘러보기' 외에도 다른 장치를 준비해야 합니다. ⑤ 가이드 장치가 너무 빨리 사라지기도 합니다. '둘러보기'가 끝난 후 신규 유저가 수행할 작업을 안내해봅니다. 체크리스트, 진행률 표시바 등이 유용한 도구입니다. ⑥ 가입 절차 단순화는 수익화에 직접적인 도움이 되지 않습니다. 마케팅 KPI를 '가입'에서 '활성화된 가입'으로 대체하고, 온보딩 과정에서 이탈해버린 유저 시점이 되어 온보딩을 강화할 지점이 어디인지 찾아보세요. ⑦ 불필요한 알림이 과하면 중요한 일에 집중하기 어렵습니다. 효과가 적은 알림은 제거하고 유저에게 커스텀된 알림을 제공하여 알림의 효용을 높여보자.

회사 내 단일 UXer로 살아남는 법

https://abr.ge/iehvjp

[성장의 피땀눈물]

마인드셋

협업

조직 내 단일 UXer로 살아남는 법 조직 내 단일 UXer거나 소규모의 UX팀에서 일한다는 것은 디자이너에게 큰 기회입니다. 하지만 UX조직의 규모가 작을 수록 UXer의 목소리는 작고, 사용자 경험에 포커스된 업무 문화가 조성되기 어렵습니다. 어떻게 하면 성공적으로 사용자 경험을 위한 조직 문화를 만들고, 단일 UXer로서 성공적으로 일할 수 있을까요? 먼저 프로세스 수립하세요 첫번째 단계는 명확한 UX 프로세스를 수립하는 것입니다. UX 디자인 프로세스가 없다면 디자이너는 어둠속에서 길을 걸어가는 것과 같습니다. 명확하고 간결한 UX 프로세스가 있다면 이를 통해 사용자에게 놀라운 경험을 제공할 수 있습니다. 다만, 프로세스는 조직과 제품의 환경을 고려해 만들어야합니다. 어떤 것도 완벽하게 맞을 수 없기 때문에 어떤 프로세스를 선택하든 초기 프로세스를 수립한 후 필요에 따라 문제를 해결해가며 조직에 맞는 프로세스를 만들어야합니다. 이해관계자과 UX의 이점에 대해 공유하세요 좋은 사용자 경험은 비즈니스에 분명히 좋습니다. UX의 이점은 분명하지만 UX프로세스가 왜 이해관계자들에게 중요한지도 설명할 수 있어야합니다. UXer는 비즈니스의 중심에 앉아있습니다. 우리는 비즈니스팀과 프로젝트의 요구사항에 대해 이야기하고, 기술팀과 협력해 무엇이 가능한지 파악하고 개발 작업을 지원합니다. 또한 우리는 고객의 요구와 기대를 이해하기 위해 고객과 대화합니다. 이처럼 UXer는 프로젝트의 모든 파이프라인 사이에 있기때문에 UX프로세스를 통해 각 이해관계자에게 어떤 영향을 미치는지 말할 수 있습니다. UX의 성공은 비즈니스 조직 전체의 협력과 참여에 달려 있습니다. 조직 내 이해관계자들에게 우리의 역할과 프로세스가 어떤 이점이 있는지 명확하게 설명하고, 사용자 경험 중심의 문화를 수용할 수 있도록 설득하세요. 어디서 어떻게 이야기해야할까요? 개발 싱크업 미팅 블로커가 되는 이슈에 대해 듣고 향후 개발 전후 과정에서 UX의 역할이 이를 해결해줄 수 있는 부분을 설명하세요. 비즈니스팀 미팅 비즈니스 목표 달성을 위해 고객 이해가 필요하지 않나요? UX프로세스를 통해 어떻게 고객을 이해할 수 있고, 비즈니스 목표 달성에 영향을 줄 수 있는지 이야기하세요. 스프린트 회고 이전 릴리즈의 문제를 논의하고 UX프로세스가 이 문제에 어떤 영향을 미칠지 이야기하세요. 고객과의 만남 고객은 훌륭한 UX가 시작되고 끝나는 곳입니다. 개발 중인 프로젝트에 대해 고객과 이야기하고, 고객의 요구사항과 니즈, 패인포인트를 비즈니스팀 미팅에 이를 가져가 더 좋은 제품을 만드세요. 앞으로의 긴 여정에 대비하세요 UX를 하나의 팀으로 만들어가는 과정은 힘들고 외로울 수 있습니다. 함께 일할 사람이 없는 상태에서 무리하지 않는 것이 중요합니다. 합리적인 목표 설정을 위한 상급자와의 논의 상급자와 프로세스를 수립할 시기와 방법에 대해 이야기하고, 진행상태와 블로커에 대해 정기적으로 공유하세요. 더 큰 규모의 UX커뮤니티에 참여 단일 디자이너로 고립된다면 창의적인 해결책을 내거나 전문적으로 성장하는데에 방해가 됩니다. 우리에게는 회사조직보다 더 큰 팀에서 피드백을 줄 수 있는 동료가 있습니다. UX커뮤니티나 모임, SNS에서의 업계 리더와 UX/기술 블로그 팔로우 등 적극적으로 UX업계에 참여하세요.

UX 관점에서 기업용 서비스 필터링 기능 개선방법

https://abr.ge/xxjouf

[디자인]

프로덕트 전략

UI 컴포넌트

필터링이 중요한 이유 많은 양의 데이터를 다루는 서비스는 체계적이고 포괄적인 방법으로 데이터를 보여주어, 사용자가 몇 번의 클릭만으로 필요한 것을 쉽게 찾을 수 있도록 해야합니다. 엔터프라이즈 서비스는 항상 많은 양의 정보를 가지고 있기 때문에, 데이터를 필터링하는 것이 필수입니다. 필터링은 다양한 데이터에 대한 다양한 옵션을 제공하여, 특정 태스크를 수행하는 사용자의 시간을 단축하고 UX를 개선하는 훌륭한 방법입니다. 참고 : 이 아티클은 엔터프라이즈 솔루션을 위한 데스크탑 필터링에 중점을 두었습니다. 데스크탑 필터링과 모바일 필터링은 완전히 다르며 모바일 필터링은 다른 관점으로 별도 연구가 필요합니다. 데이터를 체계적이고 포괄적으로 보여주는 방법에는 크게 3가지가 있습니다. ∙필터 Filter ∙패싯 네비게이션 Faceted Navigation ∙데이터 테이블 Data Table 필터와 패싯 네비게이션은 둘 다 데이터를 더 작은 하위 집합으로 좁히는 데 사용하는 컴포넌트라는 점에서 동일한 기본작업을 수행하지만, 필터는 고정된 범주를 다루는 반면 패싯 네비게이션은 훨씬 유연하고 콘텐츠의 다양한 차원을 다룰 수 있습니다. 필터 Filter 필터는 미리 정의된 범주를 기반으로 검색 범위를 좁히는 프로세스입니다. 필터를 사용하여 사용자가 확인하는 정보의 수를 제한하세요. 두가지 주요 이점이 있습니다. 1. 서버 로딩 시간을 대폭 단축할 수 있음 2. 사용자가 데이터를 이해하기 쉬워짐 패싯 네비게이션 Faceted Navigation 패싯 네비게이션을 사용하면 사용자가 동시에 여러 차원으로 검색을 구체화할 수 있습니다. 획일적인 필터로는 표현하기 어려운 구체적으로 타게팅된 제품결과를 제공하려고 할 때 패싯 네비게이션을 사용합니다. ∙예시 : 쇼핑몰에서 여성용 신발을 탐색할 때, 컬러-블랙 / 사이즈-240 / 카테고리-캐주얼 과 같이 여러 필터를 한번에 선택하여 구체적인 제품 유형으로 범위를 대폭 좁힐 수 있습니다. 데이터 테이블 Data Table 필터의 기능을 대폭 향상시키는 3번째 방법은 ‘결과가 표시되는 방식을 사용자가 정의하게 하는 것' 입니다. 사용자가 데이터 열의 순서와 위치를 직접 커스터마이징하여, 니즈에 맞게 데이터를 확인할 수 있습니다. 엔터프라이즈 솔루션의 사용자는 여전히 ‘사람'이기 때문에, 솔루션 사용방법을 숙지하기보다는 타 서비스 사용경험과 본인의 직관에 의존하여 솔루션을 사용합니다. 잘 설계된 필터링은 사용자가 원하는 것을 찾고 작업을 쉽게 만드는 가장 빠른 방법입니다.

헤밍웨이로부터 배우는 UX Writing

https://abr.ge/6lengc

[디자인]

UX Writing

헤밍웨이는 짧고 쉬운 문장으로 많은 독자들에게 큰 감동을 선사하는 것으로 유명합니다. 여러 지식 레벨을 가진 다양한 사용자가 사용해야 할 복잡한 B2B 프로덕트에 헤밍웨이의 이런 작문 방식이 도움이 될 수 있습니다. 먼저 프로덕트에 사용될 UX Writing(마이크로 카피)는 다음 기본적인 원칙을 준수해야 합니다. • 명확해야 함 • 간결해야 함 • 유용해야 함 사람들이 생각하는것과 다르게 헤밍웨이는 짧은 문장만을 사용하지는 않았습니다. 그는 무조건 짧은 문장을 만드는 것 보다는 1. 충분하게, 2. 간단하게, 3. 효과적으로 문장을 썼습니다. 헤밍웨이의 방식과 같이 UX Writing을 충분하고, 간단하고, 효과적으로 만들기 위해 다음과 같은 방식을 시도해볼 수 있습니다. • 사전이 필요할 만큼 어려운 단어는 피하기 • 표현적이면서도 명확한 문장 사용하기 • 충분한 만큼만 정보 전달하기 (많다면 빼기, 적다면 추가하기) • '그리고'와 같은 접속사로 문장을 연결하지 않고, 각 문장을 분리하여 독립적으로 문장 구성하기 • 의식적으로 다시 편집해보기 잊지 말아야 할 점 헤밍웨이는 소설가였지만 우리는 프로덕트의 UX Writing을 만들어야 합니다. 소설에나 필요한 플롯, 서스펜스, 감동 등을 포함하지 않아야 합니다. UX Writing은 사용자를 다음 단계로 이동시키는 역할을 수행해야 한다는 점을 잊어서는 안됩니다.

스타트업이 블로그 글을 게시해야하는 3가지 이유

https://abr.ge/oafotz

[성장의 피땀눈물]

스타트업

프로덕트 전략

비즈니스 전략

모든 사람들은 잘 만들어진 사용자 경험을 좋아합니다. 그러나 문제는 아무도 제품의 존재를 알지 못한다면 사용할 기회조차 갖지 못한다는 것입니다. 이때, 블로그는 제품을 홍보하는 유용한 도구입니다. 블로그는 SEO(검색 엔진 최적화)에 도움을 줍니다. 여러분이 집을 산다고 상상해 보세요. TV 광고, 유튜브 광고 다음, 인터넷에 “집을 사는 법” “대출받는 법”을 찾아봅니다. 이때 우리는 수많은 블로그 글을 봅니다. 그리고 원하는 정보를 알아내기 전에 모든 신뢰할 수 있는 블로그 소스를 클릭했을 것입니다. 블로그는 회사에 목소리를 줍니다. 블로그는 사람들이 제품이 무엇인지 알기도 전에 해당 UX를 소개할 수 있는 좋은 방법입니다. 잘 된 블로그들을 보면 UX, UX Writing,블로그가 완벽히 하나의 패키지로 매끄럽게 묶여 있습니다. 플랫폼 전체 색상은 통합되어 있으며 내가 어떤 페이지에 있느냐에 따라 제품과 상호 작용하는 것처럼 느껴지게 합니다. 이런 블로그가 있는 회사는 제품을 판매할 시도할 필요 없이 소비자가 스스로 구매할 겁니다. 블로그는 가치를 제공합니다. 가치는 제품, 사용자 경험, 제품의 문제 해결 가능성 모든 것입니다. 그중 가장 중요한 것은 가치가 신뢰를 구축한다는 것입니다. 블로그를 통해 여러분이 어떤 주제에 대한 전문가로 소개할 수 있다면, 고객들은 이 주제에 대한 신뢰할 수 있는 정보원으로 보고 답을 얻기 위해 찾아올 겁니다. 대부분 회사는 Instagram에 매일 10개의 사진을 게시하고, 매시간 트윗을 게시하고, 30분마다 새로운 Facebook 게시물을 게시하면서 성과를 내고 있다고 생각합니다. 하지만 이것은 가치를 제공하는 것이 아니라 자랑입니다. 고객과 친구가 되지 마세요. 블로그는 고객을 이해하고, 고객과 관계를 맺고, 고객의 문제를 해결하는 데 도움을 주는 방법입니다.

B2B 영업 가이드 by A16Z

https://abr.ge/yzitdn

[그로스 전략]

마케팅

세일즈

PM/PO

A16Z의 반복/재현 가능한 B2B 영업 프로세스의 기본 - GTM(Go-To-Market) 모델 설계하기 1. 우리 기업에 맞는 영업 및 판매 채널 찾기 : 채널은 공급자와 수요자를 이어주는 다리로, 크게 3가지로 나뉜다. 스타트업은 이 중 하나를 선택해서 집중해야 한다. ① 직접 영업 - 고객과 1:1로 직접 관계를 쌓고 거래하는 채널이다. B2B 고객이 선호하는 방식이다. ② 채널 파트너(유통/중개업자) - 작게 시작(ex. Frito Lay & Taco Bell - Doritos Locos Taco)하여 파트너 포털로 확장(ex. 삼성 파트너 센터)하세요. ③ OEM ex. Amazon, Hp, 삼성, .... 3가지 채널을 활성화하게 되면 충돌이 발생하는데, 영업조직을 만들고 스케일하면서 이를 지양해야 한다. 2. 마케팅 vs. 영업 : B2C에서 B2B로, High Touch 모델이 될 수록 마케팅보다 영업의 비중이 높아져야 한다. SaaS는 B2B의 극대화 모델로 마케팅 비용은 무료 혹은 낮은 가격에 제공하는 기능이 된다. 이를 Freemium이라고 한다. (그림 1 참고) 3. GTM을 위한 시장 세분화 세그먼트는 3가지로 나뉘며 ③으로 갈수록 사용자 수는 많아지고 판매 비용이 적어진다. ① Enterprise - 직접 판매가 필요하다. ② Mid-market - 채널 파트너 또는 비대면으로 판매한다. ③ 중소기업/B2C - Freemium 제공 또는 비대면 판매한다. (그림 2 참고)