Search
Name
oopy
카테고리
태그
요약
🧑🏻⚕️ 요약자
타겟 오디언스
UX 결과가 비즈니스 결과보다 더 나은 목표를 만드는 이유
Open
[디자인]
프로덕트 전략
비즈니스 전략
UX
“이번 분기에 구독 갱신율을 15% 늘립시다.”
비즈니스가 생존하려면 이과 같은 비즈니스 목표가 필요합니다. 그러면 디자인 팀은 "우리가 갱신을 위한 디자인을 변경하여 기존 보험 계약자의 갱신이 15% 증가했습니다.” 라고 보고할 수 있습니다. 그러나 디자이너로서 이것을 목표로 보아야 할까요?
비즈니스 결과는 훌륭한 성과를 가져오지만 훌륭한 목표는 아닙니다.
디자인 리더가 범하는 실수는 비즈니스 결과를 디자인 목표로 세우는 것입니다. 비즈니스 결과를 얻는 가장 쉬운 방법은 비즈니스 결과에 영향을 미치는 직접적인 요소에 집중하는 것입니다.
“더 많은 구독자를 갱신하기 위해 리마인더 알림을 개선합시다.”
이것은 효과적이지만 사용자의 진정한 목표를 놓치고 있습니다. 오늘 아침에 아무도 구독을 갱신할 수 있게 되어 기뻐하지 않았습니다. 또한, 팀이 이러한 목표에 집중하면 의도치 않게 사용자 경험이 악화할 수 있습니다. 조직은 다크 패턴을 사용하여 사용자가 의도하지 않게 가입하거나 구독을 갱신 하도록 속이는 방법을 찾기도 합니다. 이처럼 갱신율 증가는 서비스를 더 좋게 만들었는지 나쁘게 만들었는지 알 수 없습니다.
UX 결과 는 비즈니스 결과와 다릅니다.
UX 결과에 도달하기 위해 디자인 리더는 다음 질문에 답해야 합니다.
“우리의 제품 갱신을 통해 고객의 삶을 어떻게 개선할 수 있습니까?“
이러한 방식으로 갱신에 관해 묻는 것은 단순히 거래를 완료하는 행위를 넘어섭니다. 거래를 완료하는 데 초점을 맞추면서도 고객에게 타사 제품과 다른 긍정적인 차이를 만드는 방식입니다.
예를 들어 자동차 보험 회사라면, 부모 보험 계약자들의 삶을 개선 할 수 있습니다. 사용자 조사로 자녀가 초보 운전자가 되면 부모는 자녀의 안전에 대해 걱정하는 것을 알아냅니다. 이 인사이트를 통해 디자인팀은 앱으로 자녀 운전자가 타이어 펑크와 같은 일이 발생했을 때 부모에게 도움을 요청할 수 있도록 개선합니다. 또한 긴급출동 지원 요청의 상태를 부모에게 알릴 수 있는 기능을 만듭니다. 이런 방향은 부모인 고객이 앱이 있을 때 자녀가 안전하다고 느낄 것입니다. 그리고 갱신 시점에 부모 보험 계약자에게 자녀 운전자를 보호하는 데 앱이 어떻게 도움이 되었는지 요약하여 보여줍니다.
결과적으로 디자인팀은 목표를 비즈니스 결과(청소년 운전자에 대한 갱신율 증가) 대신 UX 결과(청소년 운전자의 부모에게 보안 의식 향상)로 명시할 수 있습니다.
비즈니스 결과를 위해 거꾸로 작업해야 합니다.
비즈니스 결과는 여전히 도움이 되지만 팀이 UX 결과를 달성한 후에만 가능합니다. 디자인 팀이 일을 잘하면 갱신율이 높아집니다. 또한 부모가 다른 부모에게 입에서 입으로 추천해 새로운 보험 가입이 증가할 수도 있습니다.
디자인 팀은 사용자 리서치 데이터와 밀접하게 일하기 때문에, 특정 비즈니스 결과가 UX 결과와 밀접한 연관이 있다는 것을 쉽게 찾아낼 수 있습니다. 이는 디자인 팀 리더가 고위 경영진에게 보고할 때 개선된 사용자 경험과 중요한 비즈니스 결과 달성 사이의 점을 연결할수 있습니다. 결과적으로 UX 결과는 잘 설계된 제품과 서비스를 제공하는 비즈니스 가치를 보여주는 필수 도구입니다.주니어
중니어
CS팀과 프로덕트팀의 협업을 최대로 이끄는 10가지 방법
Open
[성장의 피땀눈물]
워크플로우
일하는 방법
업무 공유하기
CS팀의 업무를 쉐도잉해서 팀 사이의 공감과 신뢰를 이끌어내기
- CS팀 업무를 쉐도잉한다면 다음과 같은 장점이 있다. 고객의 피드백과 이슈를 직접 확인하고 고객에 대한 직감을 기를 수 있다. 또 팀 간의 공감대 및 CS와 PM 간의 대화를 형성할 수 있다. 마지막으로는 다른 업무 흐름에 대한 가시성을 전달할 수 있을 것이다. 실제로 위잔트라는 미국의 과외 플랫폼은 모든 프로덕트팀이 CS팀의 업무를 하는 시간이 있기도 하다고 한다.
사용자 리서치의 연장선에 CS팀 포함시키기
- CS팀이 고객 응대를 마칠 때, 특정 이슈 한 가지에 대해 고객에게 질문하게끔 요청하자. CS팀은 보통 프로덕트나 리서치팀보다 규모가 크고 고객과 가장 맞닿아 있다는 것을 활용하는 것이다.
피드백 시스템에 대해 공동의 오너십 형성하기
- 기능 관련 요청을 정량적으로 트래킹하는 툴을 CS팀과 함께 활용하자. 이를 통해 PM은 일부 업무를 CS팀에게 일부 위임할 수 있고 CS팀은 프로덕트와 비즈니스에 대한 감각을 키울 수 있을 것이다.
CS팀에게 QA와 베타테스트 관련 도움 받기
- CS팀원들이 프로덕트의 기능에 대해 가장 능숙할 가능성이 많다. 실제로 릴리즈 전에 CS팀원에게 테스팅을 부탁하는 팀도 있다. 이를 통해 제품팀은 프로덕트의 오류를 줄이고 CS팀은 개발 과정에 참여하게 되기에 완성도 높은 경험을 할 수 있게 된다.
공통의 언어 만들기
함께 이슈의 분류 체계 만들기
- 보통 CS팀은 생산성을 측정할 때 이슈 하나당 사용되는 시간과 비용을 예상한다. 반면 프로덕트팀은 특정 고객과 케이스, 그리고 라이프사이클 단계를 기반으로 구조화되어 있다. 그렇기에 CS팀과 프로덕트팀은 함께 체계를 만들어 나가야 한다.
미리 제품의 로드맵 공유하기
- 작은 기능을 개선하거나 버그 픽스를 요청하기에 가장 좋은 타이밍은 프로덕트팀이 해당 내용에 대해 이미 집중하고 있을 때이다. PM팀은 CS팀, 세일즈팀 등 대화의 자리를 만들도 제품에 대한 인사이트를 보강해야 한다. 이때 기존에 있던 기능 결함을 확인하고 디자인의 방향성에 대한 인사이트를 제공하고 불필요한 제품 개선 사이클의 시간을 줄일 수 있다.
소통의 루프를 만들고 이를 종료하기
- CS팀과 프로덕트팀 간의 협업의 루프를 종료하는 것이 필요할까 싶지만 이 단계가 중요한 단계이다. 실수를 돌아보는 것도 중요하지만 잘 해낸 것과 직원들의 영향력과 가치에 대해 얘기하여 CS팀이 해당 이슈를 종료하면, 결과를 만든 팀은 이 소통 루프를 계속 만들려고 할 것이기 때문이다.
공동의 목표를 세우는 문화 만들기
우선순위가 높은 로드맵은 어떤 이유로 만들어졌는지 공유하기
- 프로덕트팀이 로드맵과 업무의 근원이 되는 이유를 CS팀과 소통하게 되면, CS팀은 프로덕트팀이 가장 우선시하는 이슈의 유형과 맥락을 이해할 수 있게 되면, 이는 CS팀이 제품팀에게 인사이트를 더 효과적으로 공유할 수 있도록 한다.
CS팀의 목표치 설정하기
- CS팀 리더에게 회사의 전략과 맞는 팀 목표를 설정해 주는 것도 하나의 방법이다. 만약 회사가 데이터 기반이라면, CS팀 또한 데이터 기반의 목표를 설정해야 한다.
주요 컨택 포인트를 만들어서 소통하기
- PM이 많은 사람들과 소통할 만한 시간이 있는 것은 아니다. 따라서 하나의 컨택 포인트를 만들 필요가 있다. 퀴즐렛(Quizlet)에서는 각각의 제품 스쿼드가 CS와 프로덕트팀을 잇는 제품 서포트 전문가(PSS)와 소통했다고 한다. 내부에서는 특정 기능을 없애고자 하는 확신이 있었지만 일부 고객에게 영향을 줄 수 있다는 생각이 들어 PSS와 협업하여 내부에서 고객에게 미리 이슈를 트래킹 할 방법을 만들어 미리 예측하혔다고 한다. 미리 예측한 덕분에 영향을 받은 고객들에 대해 대응할 수 있었고 CS팀의 걱정도 줄었다고 한다.주니어
'블리츠스케일링' 제대로 읽기
Open
[그로스 전략]
프로덕트 전략
마인드셋
블리츠 스케일링의 정의 :
블리츠스케일링은 불확실한 상황에서도 효율보다는 속도를 중시하여 업계에서의 '퍼스트-스케일러'가 되고자 하는 사업 접근 방식을 의미합니다.
블리츠 스케일링의 3가지 특징
블리츠 스케일링은 '공격이자 방어'전략이다. 급속한 성장은 반격할만한 시간과 여지를 없앤다.
블리츠 스케일링은 '시장 선점자가 경쟁 우위를 갖는' 선순환을 통해 성장한다.
블리츠 스케일링은 기회와 동시에 위험을 수반한다.
블리츠 스케일링을 하기 위한 3가지 핵심 기법
비즈니스 모델 혁신 : 돈을 버는 방법 자체를 혁신하여 진정한 성장을 가능하도록 한다.
※ 블리츠 스케일링의 대상 기업은 4가지 성장인자 중 일부를 가지고 있어야 하며, 2가지 성장 제약 인자를 이겨내야 한다.
4가지 성장 인자
① 시장 규모
② 유통 : 기존 네트워크를 레버리지할 수 있거나 바이럴이 용이해야 한다.
③ 매출 총이익 : 매출에서 원가가 차지하는 비용이 낮을수록 좋다. ex. 소프트웨어 기업
④ 네트워크 효과 : 바이럴과 달리 네트워크는 유지/방어의 역할을 한다.
2가지 성장 제약 인자
① PMF의 부족
② 확장에 대한 대응 부족
전략 혁신 : 단순 공격적 성장전략을 넘어 불확실·위험성을 감수하는 초고속 성장 추구 전략이다.
Checklist: 지금 블리츠 스케일링을 할 수 있는가?
① 새롭고 큰 기회가 있는가
② 퍼스트 스케일러 우위를 만들 수 있는가
③ 가파른 학습 곡선을 가질 수 있는가
④ 빠른 성장으로 경쟁 위험을 줄 수 있는가
Checklist: 언제 블리츠 스케일링을 멈춰야 하는가?
① 성장률의 저하
② 유닛 이코노믹스 악화
③ 직원 생산성 악화
④ 경영 간접비 증가
⑤ 내분
경영 관리 혁신 : 임직원의 극도 긴장, 인사 부분의 문제를 일으킬 여지가 높아 일반적인 경영과 확연히 다른 접근법이 필요하다.
블리츠 스케일링에 대응하기 위한 8가지 전환
① 조직의 규모 확장에 따른 인적관리의 변화
② 제너럴리스트에서 스페셜리스트로
③ 실무자에서 관리자/경영자로
④ 일대일 > 일대다 커뮤니케이션 방식으로
⑤ 영감에서 데이터로
⑥ 한가지에 집중에서 동시다발적인 대응으로
⑦ 해적에서 해군으로의 태세 전환
⑧ 설립자에서 리더로
블리츠 스케일링에 대응하기 위한 9가지 반직관적인 규칙
① 혼란을 수용하라
② 가장 적합하기보다 바로 지금 필요한 사람을 영입하라
③ 잘못된 관리도 때론 용인하라
④ 부끄러운 수준에서 제품을 론칭해라
⑤ 불길이 타오르게 내버려 둔다
⑥ 규모가 나오지 않는 일을 해라
⑦ 고객을 무시하라
⑧ 너무 많다 싶을 정도의 자금을 모아라
⑨ 문화를 진화시켜라주니어
디자인 산출물을 개발자에게 완벽하게 전달(Hand-off)하는 방법
Open
[워크 프로세스]
커뮤니케이션
일하는 방법
협업
핸드오프 용어 짚고가기
- 누가: 디자이너가
- 무엇을: 디자인 완료 후 취해야 하는 모든 작업
- 목표: 개발자가 구현을 시작하는데 필요한 모든 정보를 전달
디자인 스케치를 개발팀에 넘겨주고 디자이너가 구상한 대로 잘 돌아가게끔 하는 게 왜 그렇게 어려운 일일까요? 몇 가지 이유가 있습니다.
1) 커뮤니케이션 부족
협업을 시작하기까지 딜레이가 길어지는 실수가 흔합니다. 완벽한 디자인 결과물을 개발팀에 전하려고들 하지만, 개발자가 처음부터 참여했더라면 좀 더 시행착오를 줄일 수 있었을 것입니다.
모든 관련 당사자가 초대된 Slack 전용 채널을 만드세요.
이들과 하는 정기적인 회의를 계획하세요.
2) 불충분한 정보
사실 단순한 Figma UI 이미지가 제공하는 것보다 훨씬 더 많은 정보가 있어야 사물의 흐름, 움직임, 사용자 여정 단계 등을 알 수 있습니다.
트리거 및 사용자 여정의 여러 단계에 대한 추가 정보를 공유하세요.
디자인 도구의 상태 업데이트를 사용하여 디자인의 어떤 부분이 진행 중, 일시 중지 또는 완료되었는지 보여줍니다.
3) 불명확한 스펙 설명
Zeplin, Sketch, Figma 등의 툴로 최신 디자인 산출물과 목업을 온라인에 업로드함으로써 개발자는 UI에 쉽게 접근할 수 있습니다.
Photoshop이나 Illustrator와 같은 툴을 쓰고 있다면 적절한 클라우드 기반 UI 소프트웨어로 전환하십시오.
설계 시스템이 구현되고 선택한 플랫폼에서 쉽게 사용할 수 있는지 확인하십시오.
4) 디자인 시스템 부재
적절한 디자인 시스템이 없는 경우, 불필요한 잦은 반복이 발생할 수 있습니다. 제약이 없어 너무 창의적인 결과물이 나올 수 있고, 시각적으로 일관되는 최종 제품을 만들기가 어려워집니다. 디자인 시스템을 사용하면 일관성을 유지하면서 규모에 맞게 공동으로 디자인할 수 있습니다.
개발자를 위한 스타일 가이드를 구축하고 디자인 시스템으로 전환하십시오.
디자이너가 항상 어떤 요소를 만들어야 하고 누락된 항목이 없는지 알 수 있도록 체크리스트를 만드십시오.
5) 팀 간의 지식 격차
단순히 디자이너와 개발자가 서로가 말하는 내용을 모르는 경우가 종종 있습니다. 정기적인 지식 공유를 위한 시간과 공간을 만드는 것은 더 나은 제품과 더 행복한 동료의 관점에서 성과를 거둘 수 있는 투자입니다. 다른 팀의 답변과 행동 뒤에 숨겨진 "이유"를 이해하면 마찰과 좌절을 줄이고 더 나은 솔루션을 위한 길을 열 수 있습니다.
"학습" 또는 이와 유사한 이름의 Slack 채널을 만들고 모든 사람이 흥미로운 읽기, 비디오 및 팟캐스트를 공유하도록 권장합니다.
프로젝트가 완료된 후 피드백 및 후속 조치를 위한 프로세스를 만들어 모든 사람이 잘 된 부분과 개선할 수 있는 부분에서 모두 배울 수 있도록 합니다.
6) 사일로 현상과 팀스피릿 부족
모든 사람이 모든 아이디어를 환영하고 경청한다고 느끼는 심리적 안전의 견고한 기반을 만들도록 하십시오.
7) UX Writing 최종 결정이 프로세스 상에서 너무 뒤에 있음
디자인 구축을 시작하기 훨씬 전에 항상 카피라이터를 프로젝트에 참여시키십시오.
8) 디자인한 애니메이션이 제대로 수행되지 않음
필요한 경우 대화형 프로토타입을 만들어 사물의 흐름과 이동 방식을 정확히 보여줍니다.
* 이 글은 핸드오프를 어렵게 하는 8가지 원인과 총 40가지(8×5) 솔루션을 담고 있습니다. 짧은 요약글이라 일부만 소개드렸습니다만 원문을 살펴보시기를 추천드립니다! 이해하기 쉬우며 현실적인 해결책을 다수 제시하고 있습니다.
디자인 스케치를 개발팀에 넘겨주고 디자이너가 구상한 대로 잘 돌아가게끔 하는 게 왜 그렇게 어려운 일일까요? 몇 가지 이유가 있습니다.
1) 커뮤니케이션 부족
협업을 시작하기까지 딜레이가 길어지는 실수가 흔합니다. 완벽한 디자인 결과물을 개발팀에 전하려고들 하지만, 개발자가 처음부터 참여했더라면 좀 더 시행착오를 줄일 수 있었을 것입니다.
모든 관련 당사자가 초대된 Slack 전용 채널을 만드세요.
이들과 하는 정기적인 회의를 계획하세요.
2) 불충분한 정보
사실 단순한 Figma UI 이미지가 제공하는 것보다 훨씬 더 많은 정보가 있어야 사물의 흐름, 움직임, 사용자 여정 단계 등을 알 수 있습니다.
트리거 및 사용자 여정의 여러 단계에 대한 추가 정보를 공유하세요.
디자인 도구의 상태 업데이트를 사용하여 디자인의 어떤 부분이 진행 중, 일시 중지 또는 완료되었는지 보여줍니다.
3) 불명확한 스펙 설명
Zeplin, Sketch, Figma 등의 툴로 최신 디자인 산출물과 목업을 온라인에 업로드함으로써 개발자는 UI에 쉽게 접근할 수 있습니다.
Photoshop이나 Illustrator와 같은 툴을 쓰고 있다면 적절한 클라우드 기반 UI 소프트웨어로 전환하십시오.
설계 시스템이 구현되고 선택한 플랫폼에서 쉽게 사용할 수 있는지 확인하십시오.
4) 디자인 시스템 부재
적절한 디자인 시스템이 없는 경우, 불필요한 잦은 반복이 발생할 수 있습니다. 제약이 없어 너무 창의적인 결과물이 나올 수 있고, 시각적으로 일관되는 최종 제품을 만들기가 어려워집니다. 디자인 시스템을 사용하면 일관성을 유지하면서 규모에 맞게 공동으로 디자인할 수 있습니다.
개발자를 위한 스타일 가이드를 구축하고 디자인 시스템으로 전환하십시오.
디자이너가 항상 어떤 요소를 만들어야 하고 누락된 항목이 없는지 알 수 있도록 체크리스트를 만드십시오.
5) 팀 간의 지식 격차
단순히 디자이너와 개발자가 서로가 말하는 내용을 모르는 경우가 종종 있습니다. 정기적인 지식 공유를 위한 시간과 공간을 만드는 것은 더 나은 제품과 더 행복한 동료의 관점에서 성과를 거둘 수 있는 투자입니다. 다른 팀의 답변과 행동 뒤에 숨겨진 "이유"를 이해하면 마찰과 좌절을 줄이고 더 나은 솔루션을 위한 길을 열 수 있습니다.
"학습" 또는 이와 유사한 이름의 Slack 채널을 만들고 모든 사람이 흥미로운 읽기, 비디오 및 팟캐스트를 공유하도록 권장합니다.
프로젝트가 완료된 후 피드백 및 후속 조치를 위한 프로세스를 만들어 모든 사람이 잘 된 부분과 개선할 수 있는 부분에서 모두 배울 수 있도록 합니다.
6) 사일로 현상과 팀스피릿 부족
모든 사람이 모든 아이디어를 환영하고 경청한다고 느끼는 심리적 안전의 견고한 기반을 만들도록 하십시오.
7) UX Writing 최종 결정이 프로세스 상에서 너무 뒤에 있음
디자인 구축을 시작하기 훨씬 전에 항상 카피라이터를 프로젝트에 참여시키십시오.
8) 디자인한 애니메이션이 제대로 수행되지 않음
필요한 경우 대화형 프로토타입을 만들어 사물의 흐름과 이동 방식을 정확히 보여줍니다.
* 이 글은 핸드오프를 어렵게 하는 8가지 원인과 총 40가지(8×5) 솔루션을 담고 있습니다. 짧은 요약글이라 일부만 소개드렸습니다만 원문을 살펴보시기를 추천드립니다! 이해하기 쉬우며 현실적인 해결책을 다수 제시하고 있습니다.신입
주니어
B2B UX - 장애물과 솔루션
Open
[디자인]
마인드셋
UX
<B2B UX가 불편한 이유>
UX나 UI디자인을 모르는 엔지니어들로만 구성된 팀이 구축한 경우
- 그들의 주요 관심사는 사용성이나 모범사례가 아닌 많은 기능
- 범위가 크고 전면적인 재설계하는건 높은 위험
특정 앱 동작에 익숙해진 고객을 화나게 할 가능성도 있음
- 변경 사항에 대해 불평할 가능성이 큼
- Twitter, Gmail도 조정할 때마다 항상 난리가 남
구매자가 최종 사용자가 아닌 것도 큰 이유
- 일반적으로 IT 및 조달 부서가 대신 소프트웨어를 구매함
- IT스코어카드로 평가하는데 '사용성'은 직접적인 영향을 주는 요소가 아니라서 제외됨
<더 나은 B2B 애플리케이션 설계>
앱을 구축하고 설계하는 회사의 관점에서 접근
- UI를 한번에 교체하는건 매우 위험
- 경영진 입장에서 대규모 투자에 비해 매력도가 낮음
- "시간에 따라 구축"하는 접근이 필요
- UX팀은 UX로드맵을 구성해야함
- 일반적으로 컴포넌트 라이브러리와 디자인 시스템은 일관된 작업을 위한 첫번째 단계.
- B2B 조직에는 사용자 인터페이스에 대해 강한 의견을 가진 이해관계자가 많다.
- 최종 사용자에 다가가는건 어렵지만, 이런 사용자와 개방형 인터뷰를 수행해야함.
- 선호도 맵과 고객 여정지도, 사용자가 불편을 겪고있는 것을 데이터로 보여주는 등의 과정을 거쳐 설득 필요.
UI를 개선하는 가장 좋은 방법은 오늘날의 공통 표준을 따르는것
- 머터리얼 디자인인은 훌륭한 시작
- 그 외에 기타 인기 소프트웨어를 연구하고, 가능한 경우 유사한 요소를 통합하세요
<엔터프라이즈 UX의 성공 측정하기>
- A/B테스트로 설계 작업이 원하는 지표를 개선하고 ROI를 제공하는지 증명 가능
- 두 세그먼트를 비교할 메트릭을 설정
- 작업 완료 시간, 성공적으로 작업한 사용자의 비율 또는 작업 포기율의 감소 등이 대표적.
사용자와 B2B 소프트웨어 테스트
- 베타 프로그램도 좋은 방법
- UX팀은 사용자와 직접 상호작용하여 구두 피드백을 얻을 수도 있음
<B2B 소프트웨어 구매를 위한 사용성 스코어카드>
구매자의 입장
- "기술의 혜택을 받는 사람이 작업을 수행하는 사람이 아닐 때 기술은 실패하거나 전복될 가능성이 높습니다."
- 회사가 구매할 때, 최종 사용자 직원도 스코어 카드에 표시되야함
- 최종 사용자는 해당 소프트웨어가 잘 쓰일지 견해를 줄 수 있음.
<B2B ux의 더 밝은 미래>
- 구매자 측의 솔루션은 간단. 구매 결정에 실제 최종 사용자를 포함하면 됨.
- 공급자 측은 점진적 접근 방식이 더 안전하고 현실적. 고객 조사를 기반으로 단계별 로드맵을 마련해야함.
- 신생 기업이 기존 플레이어를 방해하고 매끄러운 UI를 가져오고 있음.
- 세일즈포스와 같이 오래된 회사들도 UX에 상당한 노력을 기울이기 시작함.
- 페이스북, 구글, 애플 기기 사용자가 많아짐에 따라, 향상된 경험에 대한 수요가 증가함.
기획자
SaaS 제품 담당자
VoC로는 충분하지 않은 이유
Open
[프로덕트 & 데이터 분석]
PM/PO
프로덕트 전략
프로덕트 분석
고객의 소리에 귀를 기울이는 아이디어는 비즈니스 자체 만큼이나 오래됐습니다. 시간이 지나면서 "VoC"로 공식화된 이 관행에는 인터뷰, 설문조사 및 포커스그룹이 포함되었습니다. 그리고 최근에는 구매후 설문, 피드백 양식, 후속 이메일을 통해 이러한 방식을 온라인으로 가져오려는 노력이 있었습니다.
고객 경험을 이해하고 개선하는데 있어 피드백이 중요하다는 것에는 의심의 여지가 없습니다. 그러나 점점 더 경쟁이 치열해지는 오늘날의 디지털 환경에서 VoC 데이터만으로 충분할까요?
불완전한 스냅샷
VoC라는 용어가 처음 1993년에 만들어졌을 때 설문조사 및 포커스그룹과 같은 방법은 기억이 고객을 이해할 수 있는 유일한 방법이었습니다. 그후로 많은 것이 바뀌었고, 점점 더 많은 디지털 중심의 비즈니스가 생겨왔습니다.
물론 VoC는 온라인에서 고객과 연결할 수 있는 신기술로 계속해서 확산되고 있습니다. 하지만 수집된 피드백은 종종 고객이 실제로 제품이나 서비스를 어떻게 사용하고 있는지, 이탈의 원인이 있다면 무엇인지에 대해서는 거의 언급하지 않습니다.
이것이 바로 중요한 문제입니다. 의미있는 컨텍스트에 대한 이해없이 작은 시점 단위의 샘플을 사용하는 경우가 많습니다. 그 결과 고객 경험을 연결하는 복잡한 행동을 놓칩니다.
예를 들자면, 고객에게 식사경험을 평가하도록 요청하는 레스트랑의 피드백 카드에서 고객들이 첫방문인지, 10번째 방문인지, 무엇을 주문했는지, 식당이 얼마나 바빴는지와 같은 정보에 비추어 볼 때 그 대답은 얼마나 달라질까요? 아니면 카드가 더 전략적으로 처음 식사하는 사람들에게만 배포되었다면 어떨까요?
VoC는 UX방법론의 단일 도구
VoC가 제공하는 일반화된 데이터는 고객 경험을 개선하는 데 크게 도움이 되지 않습니다. 특히 필터링, 요약 및 행동 컨텍스트에서 벗어난 데이터가 제품팀의 책상에 도착하는 경우에는 더욱 그렇습니다.
VoC가 하지 않는 것은 솔루션이 무엇인지 알려주는 것입니다. 이를 위해서는 문제와 솔루션이 잘 맞는지 테스트하기 위해 실험을 실행해야합니다.
VoC는 훌륭한 UX방법론 중의 하나일 뿐이고 고객 경험에 대한 보다 포괄적인 관점을 가져야합니다.
정성적, 정량적 데이터의 한쪽에만 치우친다면 어떻게될까요?
· 정성 데이터에만 집중한다면?
"고객에 대한 이해는 깊지만 우리가 하는 일이 실제로 도움이되는지 효과가 있는지 모르겠어요."
· 정량 데이터에만 집중한다면?
"우리는 데이터 중심이지만 누구를 위해 만드는걸까요? 일은 잘 되는것 같지만 왜 그런지 모르겠어요. 일부에 대한 최적화만을 쫓고있어요."
· 정성+정량 데이터를 잘 활용하고 있다면?
"고객을 이해하고 고객이 제품을 사용하는 방식을 잘 이해하는 균형을 지키고 있어요"
훌륭한 팀들을 어떻게 하나요?
고객 여정 전반에 걸친 복잡한 관계를 설명하는 세분화된 행동 데이터 캡쳐
심도있는 정성적, 정량적 연구 및 분석방법을 모두 수용
개별 및 연결된 행동이 주요 지표에 어떤 영향을 미치는지 이해하고, 이를 활용해 추적하고 영향을 미치는 올바른 측정 기준을 결정
해당 데이터를 사용해 특정 사용자 그룹의 요구사항에 맞게 제품 경험을 개인화하고 맞춤화
변경사항을 빠르게 구현하고 그 영향을 측정하여 피드백 루프 닫기
VoC와 제품 분석을 혼합함으로써 기업은 고객과 자신을 위한 가치를 창출할 수 있는 진정한 기회를 얻게 됩니다. 다양한 VoC 메트릭과 접근방식의 장점에 대해서는 논쟁의 여지가 있지만 조직이 개발자와 디자이너를 고객과 거리를 두게한 채 VoC에만 의존한다면 문제가 됩니다.
빠르게 디지털화되는 세상에서 경쟁력을 유지하고자 하는 기업은 고객 경험에 대한 보다 포괄적인 관점이 필요합니다.
불완전한 스냅샷
VoC라는 용어가 처음 1993년에 만들어졌을 때 설문조사 및 포커스그룹과 같은 방법은 기억이 고객을 이해할 수 있는 유일한 방법이었습니다. 그후로 많은 것이 바뀌었고, 점점 더 많은 디지털 중심의 비즈니스가 생겨왔습니다.
물론 VoC는 온라인에서 고객과 연결할 수 있는 신기술로 계속해서 확산되고 있습니다. 하지만 수집된 피드백은 종종 고객이 실제로 제품이나 서비스를 어떻게 사용하고 있는지, 이탈의 원인이 있다면 무엇인지에 대해서는 거의 언급하지 않습니다.
이것이 바로 중요한 문제입니다. 의미있는 컨텍스트에 대한 이해없이 작은 시점 단위의 샘플을 사용하는 경우가 많습니다. 그 결과 고객 경험을 연결하는 복잡한 행동을 놓칩니다.
예를 들자면, 고객에게 식사경험을 평가하도록 요청하는 레스트랑의 피드백 카드에서 고객들이 첫방문인지, 10번째 방문인지, 무엇을 주문했는지, 식당이 얼마나 바빴는지와 같은 정보에 비추어 볼 때 그 대답은 얼마나 달라질까요? 아니면 카드가 더 전략적으로 처음 식사하는 사람들에게만 배포되었다면 어떨까요?
VoC는 UX방법론의 단일 도구
VoC가 제공하는 일반화된 데이터는 고객 경험을 개선하는 데 크게 도움이 되지 않습니다. 특히 필터링, 요약 및 행동 컨텍스트에서 벗어난 데이터가 제품팀의 책상에 도착하는 경우에는 더욱 그렇습니다.
VoC가 하지 않는 것은 솔루션이 무엇인지 알려주는 것입니다. 이를 위해서는 문제와 솔루션이 잘 맞는지 테스트하기 위해 실험을 실행해야합니다.
VoC는 훌륭한 UX방법론 중의 하나일 뿐이고 고객 경험에 대한 보다 포괄적인 관점을 가져야합니다.
정성적, 정량적 데이터의 한쪽에만 치우친다면 어떻게될까요?
· 정성 데이터에만 집중한다면?
"고객에 대한 이해는 깊지만 우리가 하는 일이 실제로 도움이되는지 효과가 있는지 모르겠어요."
· 정량 데이터에만 집중한다면?
"우리는 데이터 중심이지만 누구를 위해 만드는걸까요? 일은 잘 되는것 같지만 왜 그런지 모르겠어요. 일부에 대한 최적화만을 쫓고있어요."
· 정성+정량 데이터를 잘 활용하고 있다면?
"고객을 이해하고 고객이 제품을 사용하는 방식을 잘 이해하는 균형을 지키고 있어요"
훌륭한 팀들을 어떻게 하나요?
고객 여정 전반에 걸친 복잡한 관계를 설명하는 세분화된 행동 데이터 캡쳐
심도있는 정성적, 정량적 연구 및 분석방법을 모두 수용
개별 및 연결된 행동이 주요 지표에 어떤 영향을 미치는지 이해하고, 이를 활용해 추적하고 영향을 미치는 올바른 측정 기준을 결정
해당 데이터를 사용해 특정 사용자 그룹의 요구사항에 맞게 제품 경험을 개인화하고 맞춤화
변경사항을 빠르게 구현하고 그 영향을 측정하여 피드백 루프 닫기
VoC와 제품 분석을 혼합함으로써 기업은 고객과 자신을 위한 가치를 창출할 수 있는 진정한 기회를 얻게 됩니다. 다양한 VoC 메트릭과 접근방식의 장점에 대해서는 논쟁의 여지가 있지만 조직이 개발자와 디자이너를 고객과 거리를 두게한 채 VoC에만 의존한다면 문제가 됩니다.
빠르게 디지털화되는 세상에서 경쟁력을 유지하고자 하는 기업은 고객 경험에 대한 보다 포괄적인 관점이 필요합니다.주니어
중니어
기획자
디자인 리드가 해야할 일은 무엇일까요?
Open
[성장의 피땀눈물]
일하는 방법
마인드셋
디자이너 성장
협업
필자는 시니어 디자이너 생활을 하면서 디자인 리더는 기술에 초점을 맞추는 것보다 사람과 비지니스에 맞추는 것이 더 가깝다고 느꼈습니다. 아래 6가지의 비유를 통해 리더의 책임을 설명합니다.
1. 훌륭한 리더는 중매인이다. 전문 지식을 비지니스 요구 사항과 일치 시킬 수 있다.
- 사람과 기업을 연결하여 최상의 결과를 얻는 것이 리더의 임무다.
2. 좋은 리더는 주장이다. 더 큰 그림을 보며 팀의 방향성을 제시한다.
- 훌륭한 리더는 팀에게 영감을 주고 참여하고 결집 시키는 비전을 구축한다.
- 리더는 팀원 한명 한명을 세세히 관리 하는게 않는 대신 방향성을 제시한다.
- 리더는 팀원들이 자신만의 방식으로 솔루션을 탐색할 수 있게 여유를 제공해야 한다.
3. 훌륭한 리더는 외교관이다. 팀의 요구를 대변하고 클라이언트의 요구를 이해하며 그들의 기대치를 관리한다.
- 리더는 모든 것이 실현 가능한 척 하지 않는게 좋다.
- 문제에 대해 클라이언트와 신뢰를 구축해라.
4. 좋은 리더는 치어리더다. 동료의 노력을 인정하고 참여하게 한다
- 디자이너에게 자유와 소유권을 제공하고 참여를 유지해라.
- 사람들은 칭찬 받기를 좋아한다. 긍정적인 피드백은 긍정적인 행동을 강화하고 장점을 발휘 시켜준다.
5. 좋은 리더는 정원사다. 디자이너가 성장할 수 있도록 안전한 환경을 조성한다.
안전한 환경이 중요한 이유
- 디자이너는 신뢰감을 느꼈을 때 위험을 감수하고 건설적인 피드백을 제공하는게 안전하다고 느낀다.
- 개인이 결정을 내리는 것이 위험하다고 느끼면 리더가 결정을 내려야한다.
- 사람들은 안전하다고 느낄 때 피드백을 위한 디자인을 공유하는 경향이 있다.
안전한 환경을 구축하려면?
- 리더 자신이 취약하다는 걸 보여줄 때 팀원들의 필요성을 보여줄 수 있다. 리더가 항상 옳다면 실패를 두려워 하게 된다.
- 팀과 함께 정기적인 확인을 한다.
- 실패를 통해 학습해라.
- 디자인 비평 문화를 장려해라.
6. 때로는 훌륭한 리더가 코치다.
- 팀원이 예상과 상반된 결과를 제공할 경우, 문제를 개선할 수 있도록 도와준다.
안전한 환경이 중요한 이유
- 디자이너는 신뢰감을 느꼈을 때 위험을 감수하고 건설적인 피드백을 제공하는게 안전하다고 느낀다.
- 개인이 결정을 내리는 것이 위험하다고 느끼면 리더가 결정을 내려야한다.
- 사람들은 안전하다고 느낄 때 피드백을 위한 디자인을 공유하는 경향이 있다.
안전한 환경을 구축하려면?
- 리더 자신이 취약하다는 걸 보여줄 때 팀원들의 필요성을 보여줄 수 있다. 리더가 항상 옳다면 실패를 두려워 하게 된다.
- 팀과 함께 정기적인 확인을 한다.
- 실패를 통해 학습해라.
- 디자인 비평 문화를 장려해라.
6. 때로는 훌륭한 리더가 코치다.
- 팀원이 예상과 상반된 결과를 제공할 경우, 문제를 개선할 수 있도록 도와준다.주니어
중니어
사용자의 자율성을 높이는 3가지 UX
Open
[디자인]
UX
리서치
디자이너는 사람들이 개인의 선호도와 우선순위에 맞는 방식으로 인터페이스를 사용하도록 도와야 합니다.
사용자에게 선택의 자율성을 보장하는 것은 매우 중요합니다. 여기서 자율성은 개인의 선호도 및 우선순위에 맞게 인터페이스, 제품을 사용할 수 있는 것을 의미합니다.
커스터마이징
커스터마이징 기능을 제공하여 사용자에게 자율성을 부여할 수 있습니다. 커스터마이징을 적용한 사용자는 프로덕트에 애정을 갖게 됩니다. 한가지 주의해야 할 점은 브랜드 일관성과 표준을 유지하는 것입니다.
∙Facebook Messenger 는 사용자가 원한다면 각 대화의 테마를 변경할 수 있습니다.
∙Google Drive 는 파일 표시 옵션을 변경할 수 있습니다(목록으로 보기와 아이콘으로 보기). 이 옵션은 각각 다른 유형의 파일을 볼 때 최적의 방식을 선택할 수 있기 때문에 유용하게 사용되며, 옵션간 전환도 쉽게 가능하기 때문에 편리합니다.
∙Chrome 에서는 페이지의 콘텐츠 배율을 Zoom in/out 으로 조정할 수 있습니다.
∙Apple Mac의 Shortcuts 기능을 사용하면 사용자가 단축키를 지정할 수 있습니다. 많은 사용자가 사용하는 기능은 아니지만, 기능을 사용하는 사용자의 업무 속도를 매우 높일 수 있습니다.
스캐닝
사용자는 웹에서 콘텐츠를 꼼꼼히 읽지 않습니다. 다양한 Eyetracking 연구를 보면 사용자는 ‘읽을만한 가치가 있는 콘텐츠인지'를 확인하기 위해 쓱 훑어보는 경향이 있습니다. 사용자의 정보 스캐닝을 어렵게 만드는 것은 사용자에게 ‘꼼꼼히 읽기'를 강요하는 것이기 때문에 자율성을 제한합니다.
∙제목과 부제목을 적절히 사용하여 사용자가 자세히 읽기 원하는 콘텐츠를 빠르게 파악하는데 도움을 줄 수 있습니다.
∙또한 적절한 이모지를 사용하여 추가적인 Visual Signal을 제공할 수 있습니다.
타이밍과 순서
사용자는 콘텐츠를 확인할 시기와 순서를 선택하고싶어합니다. 어떤 사용자는 인터페이스에 이미 익숙하고 바로 사용하기 원하지만, 다른 사용자는 초반에 제공되는 가이드를 선호합니다. 한가지 방법이나 순서가 모든 선호와 우선순위를 충족시킬 수 없기 때문에 다양한 Support 방법을 제공하는 것이 중요합니다.
∙Grammarly.com 에서는 사용자가 개인화 선택을 연기할 수 있습니다. Grammarly 가 각 사용자의 정보를 수집해서 사용자의 경험을 향상시킬 수 있지만, 이 단계를 완료하도록 강요하지 않음으로써 사용자의 자율성을 존중합니다.
∙Khan Academy(게임 형식으로 제공되는 교육 앱) 은 사용자가 수강 코스와 코스 내 주제의 순서를 선택하여 구성할 수 있습니다. 이정도의 자율성은 사용자가 주도적으로 강의를 듣는 경험을 제공하게 됩니다.
Tips
자율성이 너무 과도해져서 사용자를 압도하지 않도록, 균형을 찾는데 도움이 되는 두가지 팁을 제안합니다.
∙옵션의 개수를 결정할 때 작업기억을 고려하세요. 선택지가 없으면 자율성이 제한되고, 의미 있는 몇 가지 옵션을 제공하면 사용자가 통제할 수 있지만, 너무 많은 선택지를 제공하면 사용자가 압도됩니다.
∙사용자에게 도움이 되는 기본값을 제공하세요. 모든 값을 사용자가 정의하도록 맡겨버리면 사용자의 작업 속도가 현저하게 떨어집니다.
커스터마이징
커스터마이징 기능을 제공하여 사용자에게 자율성을 부여할 수 있습니다. 커스터마이징을 적용한 사용자는 프로덕트에 애정을 갖게 됩니다. 한가지 주의해야 할 점은 브랜드 일관성과 표준을 유지하는 것입니다.
∙Facebook Messenger 는 사용자가 원한다면 각 대화의 테마를 변경할 수 있습니다.
∙Google Drive 는 파일 표시 옵션을 변경할 수 있습니다(목록으로 보기와 아이콘으로 보기). 이 옵션은 각각 다른 유형의 파일을 볼 때 최적의 방식을 선택할 수 있기 때문에 유용하게 사용되며, 옵션간 전환도 쉽게 가능하기 때문에 편리합니다.
∙Chrome 에서는 페이지의 콘텐츠 배율을 Zoom in/out 으로 조정할 수 있습니다.
∙Apple Mac의 Shortcuts 기능을 사용하면 사용자가 단축키를 지정할 수 있습니다. 많은 사용자가 사용하는 기능은 아니지만, 기능을 사용하는 사용자의 업무 속도를 매우 높일 수 있습니다.
스캐닝
사용자는 웹에서 콘텐츠를 꼼꼼히 읽지 않습니다. 다양한 Eyetracking 연구를 보면 사용자는 ‘읽을만한 가치가 있는 콘텐츠인지'를 확인하기 위해 쓱 훑어보는 경향이 있습니다. 사용자의 정보 스캐닝을 어렵게 만드는 것은 사용자에게 ‘꼼꼼히 읽기'를 강요하는 것이기 때문에 자율성을 제한합니다.
∙제목과 부제목을 적절히 사용하여 사용자가 자세히 읽기 원하는 콘텐츠를 빠르게 파악하는데 도움을 줄 수 있습니다.
∙또한 적절한 이모지를 사용하여 추가적인 Visual Signal을 제공할 수 있습니다.
타이밍과 순서
사용자는 콘텐츠를 확인할 시기와 순서를 선택하고싶어합니다. 어떤 사용자는 인터페이스에 이미 익숙하고 바로 사용하기 원하지만, 다른 사용자는 초반에 제공되는 가이드를 선호합니다. 한가지 방법이나 순서가 모든 선호와 우선순위를 충족시킬 수 없기 때문에 다양한 Support 방법을 제공하는 것이 중요합니다.
∙Grammarly.com 에서는 사용자가 개인화 선택을 연기할 수 있습니다. Grammarly 가 각 사용자의 정보를 수집해서 사용자의 경험을 향상시킬 수 있지만, 이 단계를 완료하도록 강요하지 않음으로써 사용자의 자율성을 존중합니다.
∙Khan Academy(게임 형식으로 제공되는 교육 앱) 은 사용자가 수강 코스와 코스 내 주제의 순서를 선택하여 구성할 수 있습니다. 이정도의 자율성은 사용자가 주도적으로 강의를 듣는 경험을 제공하게 됩니다.
Tips
자율성이 너무 과도해져서 사용자를 압도하지 않도록, 균형을 찾는데 도움이 되는 두가지 팁을 제안합니다.
∙옵션의 개수를 결정할 때 작업기억을 고려하세요. 선택지가 없으면 자율성이 제한되고, 의미 있는 몇 가지 옵션을 제공하면 사용자가 통제할 수 있지만, 너무 많은 선택지를 제공하면 사용자가 압도됩니다.
∙사용자에게 도움이 되는 기본값을 제공하세요. 모든 값을 사용자가 정의하도록 맡겨버리면 사용자의 작업 속도가 현저하게 떨어집니다.주니어
중니어
데이터 테이블: 4가지 핵심 사용자 태스크
Open
[디자인]
UI 컴포넌트
B2B 프로덕트는 많은 양의 데이터를 한 번에 보여주기 위해 테이블을 사용하는 경우가 많습니다. 테이블을 사용할 때 어떤 점을 고려해서 디자인 해야할까요?
테이블의 특징과 장점 (특히 카드 UI와 비교했을 때)
1. 확장성
• 데이터가 변경되었을 때 행 방향, 열 방향으로 쉽게 확장할 수 있습니다
2. 비교 용이성
• 두 인접한 데이터들을 눈을 많이 움직이거나 머릿속에 정보를 기억해둘 필요가 없이 편리하게 비교할 수 있습니다
테이블에서 수행되는 4가지 핵심 사용자 태스크
• 특정 레코드 검색
• 데이터 비교
• 한 행의 데이터를 확인하고, 편집하고, 추가하기
• 레코드 관리 작업
1) 특정 레코드 검색
사용자의 검색 행동은 이미 알고있는 특정 항목을 찾거나, 어떤 기준을 충족하는 여러 항목을 찾는 행동입니다.
이를 위해 필터링, 정렬, 검색, 눈으로 스캔할 수 있습니다. 하지만 어떤 방식을 취할지 예측하기 어렵고, 사용자가 생각하는 가장 쉬운 방법에 대한 기대를 바탕으로 결정하게 됩니다.
Key Point
• 첫 번째 열은 읽을 수 있는 식별자를 제공해야 합니다
• 각 열은 데이터의 중요성과 각 열 간의 관련성에 따라 배치해야 합니다
• 필터는 발견하기 쉽고 빠르게 사용할 수 있어야 합니다. 또한 데이터를 확인할 때 필터링된 데이터를 보고있다는 것을 쉽게 인지할 수 있어야 합니다.
2) 데이터 비교
복잡하고 큰 테이블에서 비교 작업할 때 아래 문제들을 경험할 수 있습니다.
• 많은 양의 데이터 중 각 셀이 무엇을 나타내며, 어떤 레코드에 속하는지 알기 어렵습니다
• 비교하려는 열 혹은 행이 서로 멀리 떨어진 경우 비교하기 쉽지 않습니다
이를 해결하기 위해 아래 방법을 사용할 수 있습니다.
2-1) 찾는 정보를 쉽게 확인할 수 있게 하기
• 화면보다 큰 테이블일 경우 헤더 행과 헤더 열을 고정하기
• 행과 열 사이로 움직일 때 위치를 유지할 수 있도록 보더, 지브라 스타일, 호버 스타일을 제공하기
2-2) 비교할 정보를 가까이 위치할 수 있게 하기
• 행, 열을 숨기거나 행, 열 순서를 변경할 수 있도록 하기 (숨긴 경우 숨겨져있는 표시가 있어야 합니다!)
3) 한 행의 데이터를 확인하고, 편집하고, 추가하기
한 레코드에 대한 위 세가지 액션을 하기에는 테이블 형식이 적절하지 않을 수 있습니다
• 테이블에서 직접 수정 : 좁은 테이블에서 가능한 방식입니다. 읽기 모드와 수정 모드는 시각적으로 구분해 실수로 편집되는 경우를 방지해야 합니다.
• 모달 팝업 : 하나의 레코드만 확인할 수 있기 때문에 인접하거나 유사한 레코드의 데이터를 참조하거나 복사할 수 없는 단점이 있습니다.
• 비모달 팝업, 개별 윈도우 : 테이블의 일부에 접근할 수 있도록 하는 옵션입니다.
• 아코디언으로 행 확장 : 편집 중인 경우 인접 레코드를 참조하는데 어려울 수 있고, 시각적으로 어수선하게 될 수 있습니다.
4) 레코드 관리 작업
레코드 내용을 편집하는것 외에도 하나 혹은 그 이상의 레코드에 대한 관리 작업이 있을 수 있습니다.
4-1) 단일 액션
액션이 1개, 2개인 경우 행 내 인라인으로 배치할 수 있습니다. 그 이상인 경우엔 보통
• 공간이 없어 레이블을 생략하게 되면서 버튼을 식별하고 클릭하기 어렵게 됩니다
• 액션 버튼이 호버 혹은 Action 메뉴 아래에 숨겨져 발견하기 어렵게됩니다.
4-2) 배치 액션
여러 레코드에 대한 동시 액션을 위해서는 보통 레코드를 선택하는 과정이나 메뉴가 포함됩니다. 공간 효율적으로 옵션을 배치할 수 있습니다.
테이블의 특징과 장점 (특히 카드 UI와 비교했을 때)
1. 확장성
• 데이터가 변경되었을 때 행 방향, 열 방향으로 쉽게 확장할 수 있습니다
2. 비교 용이성
• 두 인접한 데이터들을 눈을 많이 움직이거나 머릿속에 정보를 기억해둘 필요가 없이 편리하게 비교할 수 있습니다
테이블에서 수행되는 4가지 핵심 사용자 태스크
• 특정 레코드 검색
• 데이터 비교
• 한 행의 데이터를 확인하고, 편집하고, 추가하기
• 레코드 관리 작업
1) 특정 레코드 검색
사용자의 검색 행동은 이미 알고있는 특정 항목을 찾거나, 어떤 기준을 충족하는 여러 항목을 찾는 행동입니다.
이를 위해 필터링, 정렬, 검색, 눈으로 스캔할 수 있습니다. 하지만 어떤 방식을 취할지 예측하기 어렵고, 사용자가 생각하는 가장 쉬운 방법에 대한 기대를 바탕으로 결정하게 됩니다.
Key Point
• 첫 번째 열은 읽을 수 있는 식별자를 제공해야 합니다
• 각 열은 데이터의 중요성과 각 열 간의 관련성에 따라 배치해야 합니다
• 필터는 발견하기 쉽고 빠르게 사용할 수 있어야 합니다. 또한 데이터를 확인할 때 필터링된 데이터를 보고있다는 것을 쉽게 인지할 수 있어야 합니다.
2) 데이터 비교
복잡하고 큰 테이블에서 비교 작업할 때 아래 문제들을 경험할 수 있습니다.
• 많은 양의 데이터 중 각 셀이 무엇을 나타내며, 어떤 레코드에 속하는지 알기 어렵습니다
• 비교하려는 열 혹은 행이 서로 멀리 떨어진 경우 비교하기 쉽지 않습니다
이를 해결하기 위해 아래 방법을 사용할 수 있습니다.
2-1) 찾는 정보를 쉽게 확인할 수 있게 하기
• 화면보다 큰 테이블일 경우 헤더 행과 헤더 열을 고정하기
• 행과 열 사이로 움직일 때 위치를 유지할 수 있도록 보더, 지브라 스타일, 호버 스타일을 제공하기
2-2) 비교할 정보를 가까이 위치할 수 있게 하기
• 행, 열을 숨기거나 행, 열 순서를 변경할 수 있도록 하기 (숨긴 경우 숨겨져있는 표시가 있어야 합니다!)
3) 한 행의 데이터를 확인하고, 편집하고, 추가하기
한 레코드에 대한 위 세가지 액션을 하기에는 테이블 형식이 적절하지 않을 수 있습니다
• 테이블에서 직접 수정 : 좁은 테이블에서 가능한 방식입니다. 읽기 모드와 수정 모드는 시각적으로 구분해 실수로 편집되는 경우를 방지해야 합니다.
• 모달 팝업 : 하나의 레코드만 확인할 수 있기 때문에 인접하거나 유사한 레코드의 데이터를 참조하거나 복사할 수 없는 단점이 있습니다.
• 비모달 팝업, 개별 윈도우 : 테이블의 일부에 접근할 수 있도록 하는 옵션입니다.
• 아코디언으로 행 확장 : 편집 중인 경우 인접 레코드를 참조하는데 어려울 수 있고, 시각적으로 어수선하게 될 수 있습니다.
4) 레코드 관리 작업
레코드 내용을 편집하는것 외에도 하나 혹은 그 이상의 레코드에 대한 관리 작업이 있을 수 있습니다.
4-1) 단일 액션
액션이 1개, 2개인 경우 행 내 인라인으로 배치할 수 있습니다. 그 이상인 경우엔 보통
• 공간이 없어 레이블을 생략하게 되면서 버튼을 식별하고 클릭하기 어렵게 됩니다
• 액션 버튼이 호버 혹은 Action 메뉴 아래에 숨겨져 발견하기 어렵게됩니다.
4-2) 배치 액션
여러 레코드에 대한 동시 액션을 위해서는 보통 레코드를 선택하는 과정이나 메뉴가 포함됩니다. 공간 효율적으로 옵션을 배치할 수 있습니다.중니어
시니어
B2B UX의 통념과 4가지의 핵심 가치
Open
[프로덕트 & 데이터 분석]
UX
프로덕트 전략
Cimpress의 프러덕트 매니저로 활동하고 있는 Tanulekha Roy는 B2B UX에 대해 흔히 가지고 있는 통념과 B2B 프로덕션이 가지고 있어야 할 4가지 핵심 가치에 대해 아와 같이 소개하고 있다.
통념1. B2B 프로덕션의 고객은 비즈니스 파트너/비즈니스 SPOC(단일화된 고객 접점)이라는 통념
B2B 프로덕션의 고객은 직원이다. 하지만 이 직원들은 공식적인 온보딩 없이 프로덕션을 마주하게 되는 일이 빈번하다. 그렇기에 Self-learning을 유도하는 UX를 가진 프로덕션을 만들 수 있도록 해야 한다.
통념2. 사용자가 우리의 B2B 프로덕션을 사용할 필요가 있다는 통념
B2B 프로덕션을 사용하는 유저들은 그들이 오랜 시간 동안 유지해 온 시스템(legacy)가 있기에 B2B 프로덕션에 적응하는 것이 힘들 수 있다. 또 우리 제품에 적응하는 것이 중요한 것이 아니라, 업무 목표를 완수할 수 있도록 하는 것에 집중해야 한다는 것을 명심해야 한다.
그렇다면 B2B 프로덕션이 가지고 있어야 할 핵심 가치 4가지는 무엇일까?
일관성 : 한 번 배워서 모든 곳에 적용할 수 있어야 한다
- 동일한 색상과 폰트뿐만 아니라 정보의 접근성에도 신경을 써야 한다. 링크와 버튼의 위치, 네비게이션과 인터랙션, 필터를 포함한 여러 요소가 일관된 동작을 할 수 있어야 한다.
모듈화 : 필요한 것만 표시한다
- 복잡할 수 있는 B2B 시장에서는 정보를 구분하여 제공하는 것이 중요하다. 모든 리포트, 대시보드를 한 화면에 보여주는 것은 사용자가 제품을 이해하는 시간만 늦출 뿐이다.
접근 제어 : 유저에 따른 기능 맵핑이 되어야 한다
- 한 기능 안에서도 여러 level로 나뉠 수 있다. 관리자로서의 접근 권한을 가진 유저는 모든 기능에 접근할 수 있겠지만 뷰어로서의 접근 권한을 가진 유저는 같은 기능이어도 제한적으로 기능에 접근할 수 있도록 제어된다. 이러한 상황과 유저의 페르소나를 기억하고 있다면 용도에 따라 기능을 논리적으로 분리할 수 있을 것이다.
Product Nudge : 자연스럽게 유저를 온보딩하는 가이드
- 프로덕션의 관련 메뉴 안에서 도움말, 말풍선, FAQ, 짧은 온보딩 영상을 삽입한다면 유저가 자연스럽고 빠르게 프로덕트에 적응할 수 있을 것이다.
마지막 팁: B2C 프로덕션처럼 View와 Click 이벤트를 심어서 User experience journey를 파악해보자
B2B, B2C와 상관 없이 사람을 위해 제품을 만든다는 것은 변하지 않는다. 그렇기에 유저에게 프로덕션을 사용하도록 강요하는 것보다 유저가 사용하고 싶어하는 프로덕션을 만드는 것이 중요하다.
통념1. B2B 프로덕션의 고객은 비즈니스 파트너/비즈니스 SPOC(단일화된 고객 접점)이라는 통념
B2B 프로덕션의 고객은 직원이다. 하지만 이 직원들은 공식적인 온보딩 없이 프로덕션을 마주하게 되는 일이 빈번하다. 그렇기에 Self-learning을 유도하는 UX를 가진 프로덕션을 만들 수 있도록 해야 한다.
통념2. 사용자가 우리의 B2B 프로덕션을 사용할 필요가 있다는 통념
B2B 프로덕션을 사용하는 유저들은 그들이 오랜 시간 동안 유지해 온 시스템(legacy)가 있기에 B2B 프로덕션에 적응하는 것이 힘들 수 있다. 또 우리 제품에 적응하는 것이 중요한 것이 아니라, 업무 목표를 완수할 수 있도록 하는 것에 집중해야 한다는 것을 명심해야 한다.
그렇다면 B2B 프로덕션이 가지고 있어야 할 핵심 가치 4가지는 무엇일까?
일관성 : 한 번 배워서 모든 곳에 적용할 수 있어야 한다
- 동일한 색상과 폰트뿐만 아니라 정보의 접근성에도 신경을 써야 한다. 링크와 버튼의 위치, 네비게이션과 인터랙션, 필터를 포함한 여러 요소가 일관된 동작을 할 수 있어야 한다.
모듈화 : 필요한 것만 표시한다
- 복잡할 수 있는 B2B 시장에서는 정보를 구분하여 제공하는 것이 중요하다. 모든 리포트, 대시보드를 한 화면에 보여주는 것은 사용자가 제품을 이해하는 시간만 늦출 뿐이다.
접근 제어 : 유저에 따른 기능 맵핑이 되어야 한다
- 한 기능 안에서도 여러 level로 나뉠 수 있다. 관리자로서의 접근 권한을 가진 유저는 모든 기능에 접근할 수 있겠지만 뷰어로서의 접근 권한을 가진 유저는 같은 기능이어도 제한적으로 기능에 접근할 수 있도록 제어된다. 이러한 상황과 유저의 페르소나를 기억하고 있다면 용도에 따라 기능을 논리적으로 분리할 수 있을 것이다.
Product Nudge : 자연스럽게 유저를 온보딩하는 가이드
- 프로덕션의 관련 메뉴 안에서 도움말, 말풍선, FAQ, 짧은 온보딩 영상을 삽입한다면 유저가 자연스럽고 빠르게 프로덕트에 적응할 수 있을 것이다.
마지막 팁: B2C 프로덕션처럼 View와 Click 이벤트를 심어서 User experience journey를 파악해보자
B2B, B2C와 상관 없이 사람을 위해 제품을 만든다는 것은 변하지 않는다. 그렇기에 유저에게 프로덕션을 사용하도록 강요하는 것보다 유저가 사용하고 싶어하는 프로덕션을 만드는 것이 중요하다.주니어
회사의 디자인 프로세스가 모호하다고, 내 디자인 포트폴리오가 망했을까?
Open
[성장의 피땀눈물]
마인드셋
UX
일하는 방법
“더 이상 시간을 낭비할 여유가 없어요. 저는 이곳에 온 지 2년이 조금 넘었고 제안 할 때마다 벽에 부딪혔습니다. 디자인 과정은 없고 앞으로도 없을 것이 분명해요.”
디자이너로서 받아들여야 했던 가장 어려운 진실은 “어떤 기업들은 디자인에 대해 신경을 쓰지 않는다.” 는 것 입니다.
디자이너, 특히 주니어 디자이너는 디자이너가 된다는 것이 무엇인지에 대해 이상주의적인 견해를 가지고 있습니다. 우리는 사용자 중심의 기대치를 가지고 있지만, 때로는 그 기대치를 충족시킬 수 없습니다. 아마도 비즈니스에 다른 우선 순위가 있을 수 있습니다. 혹은 자금이나 자원이 부족할 것입니다. 아니면, 정말 회사가 연구에 관심이 없고 고객과 이야기하지 않을 수도 있습니다.
경험에 비추어 볼 때, 대규모 글로벌 회사조차도 기본 디자인 전략을 구현하기 매우 어렵습니다. 혹은 회사안 누군가의 자아가 가장 큰 장애물이 될 수 있습니다. 그럼에도 불구하고상황에 관계없이 최선을 다하는 사람들이 있고, 자신의 노력이 다른 곳에서 가장 적합하다고 느끼는 사람들이 있습니다. 두 가지 결정 모두 존중받아야합니다. 그리고 만약 이직으로 결정을 내렸다면, 이번 직장 경험을 기반으로 이직하는 것에 대해 걱정하지 마세요.
실제 경험이 중요!
디자인 프로세스가 없는 회사에서 시간을 보내는 것은 낭비라는 일반적인 오해입니다. 경험이 없는 대학을 갓 졸업한 사람들보다 앞서게 되므로 절대 그렇지 않습니다. 실제 경험이 현업에서 매우 중요 합니다. 여러분의 기대에 부응하지 못하지만, 엔지니어링 팀, 이해 관계자, 다른 디자이너와 협력하여 실제 솔루션을 제공했던 프로세스가 있었음을 잊지 마세요. 평등한 회사는 없으며, 디자인 프로세스가 다른 회사와 다르다고 해서 경쟁에서 벗어난 것은 아닙니다.
조사를 한 적이 있습니까?
다른 팀원들이 리서치를 할 때 협력 했습니까?
디자인 워크숍을 주최한 적이 있습니까?
연구/워크샵이 디자인 작업이나 최종 제품에 어떻게 반영되었습니까?
그것이 회사의 디자인 문화에 영향을 미쳤습니까?
와이어프레임, 프로토타입 또는 최종 디자인을 제작했습니까?
그렇다면 이를 엔지니어링 팀에 어떻게 넘겼습니까?
엔지니어링 팀을 반복적으로 참여시키셨습니까?
프로세스가 더 좋았더라면 어떻게 했는지 설명하십시오.
팀 내 마찰의 순간에 어떻게 대처했습니까?
포트폴리오를 검토할 때 어떤 면접관도 완벽을 기대하지 않습니다. 리서치 방법에 대한 경험이 없는 것은 전적으로 허용되지만, 열망을 보여주는 것이 중요합니다. 관심과 열정을 보여주세요! 면접관은 여러 분야의 팀과 어떻게 지냈는지, 사무실의 문제점과 역경이 유일한 선택일 것 같았을 때 어떻게 조언 했는지 알고 싶어할 것입니다. 역경을 이겨낸 방법을 설명할 수 있다면, 당신은 훌륭한 사람이 되기 위해 필요한 기술을 보여주고 있는 것입니다.
”
디자이너로서 받아들여야 했던 가장 어려운 진실은 “어떤 기업들은 디자인에 대해 신경을 쓰지 않는다.” 는 것 입니다.
디자이너, 특히 주니어 디자이너는 디자이너가 된다는 것이 무엇인지에 대해 이상주의적인 견해를 가지고 있습니다. 우리는 사용자 중심의 기대치를 가지고 있지만, 때로는 그 기대치를 충족시킬 수 없습니다. 아마도 비즈니스에 다른 우선 순위가 있을 수 있습니다. 혹은 자금이나 자원이 부족할 것입니다. 아니면, 정말 회사가 연구에 관심이 없고 고객과 이야기하지 않을 수도 있습니다.
경험에 비추어 볼 때, 대규모 글로벌 회사조차도 기본 디자인 전략을 구현하기 매우 어렵습니다. 혹은 회사안 누군가의 자아가 가장 큰 장애물이 될 수 있습니다. 그럼에도 불구하고상황에 관계없이 최선을 다하는 사람들이 있고, 자신의 노력이 다른 곳에서 가장 적합하다고 느끼는 사람들이 있습니다. 두 가지 결정 모두 존중받아야합니다. 그리고 만약 이직으로 결정을 내렸다면, 이번 직장 경험을 기반으로 이직하는 것에 대해 걱정하지 마세요.
실제 경험이 중요!
디자인 프로세스가 없는 회사에서 시간을 보내는 것은 낭비라는 일반적인 오해입니다. 경험이 없는 대학을 갓 졸업한 사람들보다 앞서게 되므로 절대 그렇지 않습니다. 실제 경험이 현업에서 매우 중요 합니다. 여러분의 기대에 부응하지 못하지만, 엔지니어링 팀, 이해 관계자, 다른 디자이너와 협력하여 실제 솔루션을 제공했던 프로세스가 있었음을 잊지 마세요. 평등한 회사는 없으며, 디자인 프로세스가 다른 회사와 다르다고 해서 경쟁에서 벗어난 것은 아닙니다.
조사를 한 적이 있습니까?
다른 팀원들이 리서치를 할 때 협력 했습니까?
디자인 워크숍을 주최한 적이 있습니까?
연구/워크샵이 디자인 작업이나 최종 제품에 어떻게 반영되었습니까?
그것이 회사의 디자인 문화에 영향을 미쳤습니까?
와이어프레임, 프로토타입 또는 최종 디자인을 제작했습니까?
그렇다면 이를 엔지니어링 팀에 어떻게 넘겼습니까?
엔지니어링 팀을 반복적으로 참여시키셨습니까?
프로세스가 더 좋았더라면 어떻게 했는지 설명하십시오.
팀 내 마찰의 순간에 어떻게 대처했습니까?
포트폴리오를 검토할 때 어떤 면접관도 완벽을 기대하지 않습니다. 리서치 방법에 대한 경험이 없는 것은 전적으로 허용되지만, 열망을 보여주는 것이 중요합니다. 관심과 열정을 보여주세요! 면접관은 여러 분야의 팀과 어떻게 지냈는지, 사무실의 문제점과 역경이 유일한 선택일 것 같았을 때 어떻게 조언 했는지 알고 싶어할 것입니다. 역경을 이겨낸 방법을 설명할 수 있다면, 당신은 훌륭한 사람이 되기 위해 필요한 기술을 보여주고 있는 것입니다.주니어
중니어
쉽게 설명한 ABM 마케팅과 적용 사례
Open
[그로스 전략]
마케팅
실 사례
마인드셋
ABM(Account Based Marketing)이란?
- B2B 모델을 가진 기업이 다른 기업을 상대/기반으로Account Based) 제품과 서비스를 판매하는 마케팅 활동입니다.
ABM의 퍼널 (cf. Lead Generation 모델)
- Lead Gen 모델 : 일반적인 마케팅 퍼널으로, 잠재고객이 브랜드를 인지하기 시작하는 퍼널의 최상단부터 아래로 내려갈수록 정보탐색, 고려 등을 거쳐 전환(ex. 구매)로 이어지는 거꾸로 된 깔대기 모양의 모델입니다.
- Lead Gen 모델이 B2B 마케팅에 적합하지 않은 이유 : B2B 마케팅의 타겟은 개인이 아닌 기업이기 때문에, Lead Gen 모델과 같이 개인을 모수로 무조건 많은 Lead를 생성하는 것을 목적으로 한다면 지나치게 많은 허수가 발생합니다. (해당 기업의 임직원, 특히 결정권이 없는 사람에게도 마케팅 비용이 사용되므로)
- ABM 마케팅은 먼저 기업을, 그리고 그 안에서 의사결정권이 있는 직원을 대상으로 타겟팅을 좁혀가야 합니다. (똑바로 선 깔대기 모양의 퍼널을 거슬러 올라갑니다.)
ABM의 채널 종류
- ABM 역시 디지털 마케팅 채널을 이용하며, 디스플레이/소셜/이메일/챗봇/팝업 등을 통한 웹사이트 개인화가 적합합니다.
- 잠재고객에 춤화된 콘텐츠, 페이지, 팝업, 배너를 보여주는 기능을 활용하여 최대한 개인화하는 것이 핵심입니다.
ABM 캠페인 사례
ex. Uber라는 기업을 대상으로 ABM을 한다면,
(1) Uber를 위해 맞춤 제작된 디스플레이 광고를 전세계 또는 특정 국가의 Uber 회사 직원에게 노출합니다.
(2) 광고 클릭 시 Uber가 언급되고 연관성이 높은 정보로 구성된, 또는 개인화된 랜딩페이지로 이동시킵니다. (ABM or CRM 플랫폼과 연동하면 영업팀이 이를 확인할 수 있습니다.)
(2-1) 영업팀이 Uber 직원에게 이메일을 보낼 때 (2)와 같은 랜딩페이지를 발송하면 응답·전환율을 높일 수 있습니다.
ABM의 관건 : 영업 & 마케팅 부서 간의 협력
- 대상의 선정부터 광고 소재와 랜딩 페이지, 콘텐츠 제작의 과정에 있어
대상 기업의 잠재고객을 대면하는 영업 부서와 캠페인을 집행하는 마케팅 부서 간의 긴밀한 협업이 필요합니다.
성공적인 ABM을 위한 Tip : Lead Gen과 병행하세요.
- ABM은 최종 구매로 이어질 가능성이 높지만, 도달률이 제한적이고 캠페인의 비용 효율이 낮습니다. (리소스 높음)
- 이를 상쇄하기 위해 전통적인 Lead Gen을 통해 도달 범위와 Lead 생성의 양을 확보하면서 ABM을 통한 집중 홍보를 병행한다면 기업의 목표에 더 빨리 도달할 수 있습니다.주니어
디자이너와 엔지니어가 보다 긴밀하게 협업할 수 있는 방법
Open
[성장의 피땀눈물]
경험 공유
실 사례
커뮤니케이션
일하는 방법
최고의 비즈니스 아이디어를 연마하고 이를 실행할 제품을 구축할 때 디자이너와 개발자 간의 건전한 협업이 특히 중요하다. 서로 생각하는 스타일이 다른 두 직군이 모이려면 무엇이 필요할까?
이 글은 4개 테크 기업의 시니어급에게 이 두 핵심 직군간 협업을 어떻게 개선했는지 묻고 답변을 기록한 글이다. 그 중 인터뷰 2세트를 번역 및 요약했다.
① Chime - 핀테크 회사
디자이너에게 질문)
개발자와 함께 작업할 때 가장 큰 어려움은 무엇이며, 어떻게 극복했는가?
답변)
...(중략) 개발 협업을 언제, 어떻게 하는지 정확히 알기 어렵다. 이러한 잠재적 마찰 지점에 앞서 대응하기 위해 개발 파트를 포함한 다른 유관 분야 담당자들과 함께 디자인 프로세스의 각 단계에서 검토를 수행한다. 이를 통해 우리는 타 팀의 관점을 디자인 의사결정에 통합하며, 개발 시작에 필요한 방향을 제시할 수 있다.
디자이너에게 질문)
디자이너와 개발자는 작업에 대해 매우 다른 관점을 제시한다. 디자이너로서 서로를 더 잘 이해하기 위해 무엇을 했는가?
답변)
나는 항상 디자인 솔루션이 디자이너에게서 나올 필요는 없으며 디자이너는 최고의 솔루션을 촉진해야 한다고 말한다. 디자인 프로세스 초기에 회의할 때 개발자와 같이 있으면 최종 제품을 염두에 두고 다른 관점에서 디자인 솔루션을 고안할 수 있다. 이런 일을 조기에 하면 제약 조건 하에서 창의적으로 생각할 여지가 생긴다.
디자이너에게 질문)
여러 팀이 같은 목표를 바라보게(Align) 할 때 효과적이었던 전략은 무엇인가?
답변)
스프린트 기간 내내 동료 개발자와 협력할 의도를 가지고 작업에 임한다. 최근에 기업용 제품에 필요한 디자인 시스템을 만들었다. 우리는 해당 제품을 프론트엔드 측에서 복제 가능한 방식으로 컴포넌트 등 디자인 요소를 구성하고, 용어 및 구현 방법을 정리하는데 스프린트 일부분을 할애했다.
② Granular - 농장 관리 소프트웨어 제작사
개발자에게 질문)
디자이너와 함께 작업할 때 가장 큰 어려움은 무엇이며, 어떻게 극복했는가?
답변)
신뢰다. 개발자와 디자이너는 신뢰가 없다면 서로의 동기와 능력에 의문을 제기하기 쉽다.
신뢰가 부족한 시기에 디자이너와 협업할 때, 우리는 개발팀 스크럼에 디자이너를 초대해 관계와 상호 존중을 구축했다. 결과적으로 더 긴밀하게 작업하게 되었다. 최근에는 반대로 디자인 쪽에서 먼저 작업을 미리 살펴보고 새로운 기능을 구현하는 방법을 생각해보기 위해 우리에게 연락을 해왔다.
개발자에게 질문)
디자이너와 개발자는 작업에 대해 매우 다른 관점을 제시한다. 개발자로서 서로를 더 잘 이해하기 위해 무엇을 했는가?
답변)
다시 말하지만 신뢰다. 함께 일한 적이 없는 두 팀은 서로를 알아가는 시간을 보내야 한다. 이런 일이 발생하면 엔지니어와 디자이너는 서로를 팀원으로 보기 시작한다.
이 과정이 부족하면 "이 디자인의 의도가 뭔가요?" 라든지, "그게 왜 구현하기 어렵죠?"와 같은 단순한 질문이 비난에 가깝게 느껴지게 된다. ...(중략)... 우리는 종종 다른 팀의 구성원이 하는 일과 일하는 방식에 대한 대화를 제공한다.
개발자에게 질문)
여러 팀이 같은 목표를 바라보게(Align) 할 때 효과적이었던 전략은 무엇인가?
답변)
준비하고, 고려하고, 공유하고, 피드백을 받고, 조정하고, 공개적으로 의사 소통하고, 모든 단계에서 동의를 얻으라. 공유가 중요하며, 피드백을 들은 다음에 그것을 처리하라. 팀원을 존중하는 이 일련의 과정은 매우 중요하다.
프로젝트를 실제로 시작하기 전에 조정의 모든 당사자가 참여하고 있는지 확인하라. 팀을 Align하려면(모두가 같은 수준으로 지식을 공유하고 같은 목표를 바라보는 상태) 많은 노력이 필요하지만 이것은 동시에 프로젝트의 추진력이 된다.
디자이너에게 질문)
개발자와 함께 작업할 때 가장 큰 어려움은 무엇이며, 어떻게 극복했는가?
답변)
...(중략) 개발 협업을 언제, 어떻게 하는지 정확히 알기 어렵다. 이러한 잠재적 마찰 지점에 앞서 대응하기 위해 개발 파트를 포함한 다른 유관 분야 담당자들과 함께 디자인 프로세스의 각 단계에서 검토를 수행한다. 이를 통해 우리는 타 팀의 관점을 디자인 의사결정에 통합하며, 개발 시작에 필요한 방향을 제시할 수 있다.
디자이너에게 질문)
디자이너와 개발자는 작업에 대해 매우 다른 관점을 제시한다. 디자이너로서 서로를 더 잘 이해하기 위해 무엇을 했는가?
답변)
나는 항상 디자인 솔루션이 디자이너에게서 나올 필요는 없으며 디자이너는 최고의 솔루션을 촉진해야 한다고 말한다. 디자인 프로세스 초기에 회의할 때 개발자와 같이 있으면 최종 제품을 염두에 두고 다른 관점에서 디자인 솔루션을 고안할 수 있다. 이런 일을 조기에 하면 제약 조건 하에서 창의적으로 생각할 여지가 생긴다.
디자이너에게 질문)
여러 팀이 같은 목표를 바라보게(Align) 할 때 효과적이었던 전략은 무엇인가?
답변)
스프린트 기간 내내 동료 개발자와 협력할 의도를 가지고 작업에 임한다. 최근에 기업용 제품에 필요한 디자인 시스템을 만들었다. 우리는 해당 제품을 프론트엔드 측에서 복제 가능한 방식으로 컴포넌트 등 디자인 요소를 구성하고, 용어 및 구현 방법을 정리하는데 스프린트 일부분을 할애했다.
② Granular - 농장 관리 소프트웨어 제작사
개발자에게 질문)
디자이너와 함께 작업할 때 가장 큰 어려움은 무엇이며, 어떻게 극복했는가?
답변)
신뢰다. 개발자와 디자이너는 신뢰가 없다면 서로의 동기와 능력에 의문을 제기하기 쉽다.
신뢰가 부족한 시기에 디자이너와 협업할 때, 우리는 개발팀 스크럼에 디자이너를 초대해 관계와 상호 존중을 구축했다. 결과적으로 더 긴밀하게 작업하게 되었다. 최근에는 반대로 디자인 쪽에서 먼저 작업을 미리 살펴보고 새로운 기능을 구현하는 방법을 생각해보기 위해 우리에게 연락을 해왔다.
개발자에게 질문)
디자이너와 개발자는 작업에 대해 매우 다른 관점을 제시한다. 개발자로서 서로를 더 잘 이해하기 위해 무엇을 했는가?
답변)
다시 말하지만 신뢰다. 함께 일한 적이 없는 두 팀은 서로를 알아가는 시간을 보내야 한다. 이런 일이 발생하면 엔지니어와 디자이너는 서로를 팀원으로 보기 시작한다.
이 과정이 부족하면 "이 디자인의 의도가 뭔가요?" 라든지, "그게 왜 구현하기 어렵죠?"와 같은 단순한 질문이 비난에 가깝게 느껴지게 된다. ...(중략)... 우리는 종종 다른 팀의 구성원이 하는 일과 일하는 방식에 대한 대화를 제공한다.
개발자에게 질문)
여러 팀이 같은 목표를 바라보게(Align) 할 때 효과적이었던 전략은 무엇인가?
답변)
준비하고, 고려하고, 공유하고, 피드백을 받고, 조정하고, 공개적으로 의사 소통하고, 모든 단계에서 동의를 얻으라. 공유가 중요하며, 피드백을 들은 다음에 그것을 처리하라. 팀원을 존중하는 이 일련의 과정은 매우 중요하다.
프로젝트를 실제로 시작하기 전에 조정의 모든 당사자가 참여하고 있는지 확인하라. 팀을 Align하려면(모두가 같은 수준으로 지식을 공유하고 같은 목표를 바라보는 상태) 많은 노력이 필요하지만 이것은 동시에 프로젝트의 추진력이 된다. 신입
주니어
고객 프로필을 만드는 10가지 쉬운 단계
Open
[워크 프로세스]
PM/PO
GTM
고객에게 효과적으로 서비스를 제공하고 고객의 요구 사항을 충족하려면 고객 프로파일링이 필수적
고객 프로파일링이란?
- 인구/심리 통계, 구매 패턴 등 요소로 고객을 설명하는 행위
- 제품이나 서비스를 구매할 가능성이 가장 높은 사람들을 식별
고객 프로파일링이 왜 중요한가요?
- 과거에 누가 제품을 구매했는지에 따라 미래에 누가 구매할 가능성이 높은지 알 수 있음
- 고객 프로필이 너무 광범위하면 제품의 가치가 희석됨
고객 프로파일링 장점
- 더 적합한 잠재 고객을 식별
- 고객 확보 비용(CAC)을 낮춤
- 고객에게 더 나은 서비스 제공
- 고객 이탈을 줄임
고객 프로필 데이터
- 인구 통계 (나이, 성별, 직위, 소득, 교육 수준, 가족 상태, 소속 회사 규모, 산업 속성)
- 심리 통계 (생활 양식, 목표, 고통, 버릇, 가치, 흥미)
- 행동 (관여도, 구매 준비, 구매 내역, 제품 사용정보, 만족도, 충성도, 주의 요망)
- 지리 (도시, 지역, 국가)
고객 프로필 만드는 방법 10단계
1. 고객 프로필 템플릿을 사용합니다. (원글에서 제공)
2. 고객 프로파일링 소프트웨어를 선택하십시오.
- CRM, 피드백 관리, 분석 툴
3. 인구 통계를 파헤쳐 보세요.
4. 고객 피드백을 수집합니다.
- 고객이 기꺼이 전화를 예약할 의사가 있다면 충성도가 높은 사용자
5. 고객 여정 지도를 검토하세요.
- 고객 여정 지도는 고객이 회사의 목표를 달성하기 위해 거쳐야 하는 모든 접점을 설명하는 문서
- 고객의 요구 사항, 과제 및 목표를 이해함으로써 고객이 비즈니스에서 원하는 것이 무엇인지 더 잘 이해
- 지도의 각 정류장에 대해 고객을 인터뷰하여 이 단계를 한 단계 더 발전 가능
6. 우리 비즈니스가 해결하려는 문제에 집중하세요.
- 데이터가 너무 많으면 길을 잃기 쉽습니다.
- 현재 사용자와 그들의 행동을 자세히 살펴보세요.
7. 상황에 맞는 세부 정보를 검토합니다.
- 올해 목표는 무엇입니까?
- 그들에게 완벽한 세상은 어떤 모습일까요?
- 그들은 오늘날 어떻게 문제를 해결하려고 합니까?
8. 산업을 이해하세요.
- 업계를 이해하면 브랜드 아이덴티티를 정의하는 데도 도움이 됩니다.
- 눈에 띄려면 제품과 서비스를 차별화할 방법을 찾아야 합니다.
9. 페르소나를 구축합니다.
10. 고객 페르소나를 분석하고 반복합니다.
기획자
SaaS 제품 담당자
엔터프라이즈 모바일 앱의 올바른 UX를 위한 6가지 조언
Open
[워크 프로세스]
마인드셋
UX
프로덕트 전략
모바일 앱은 데스크탑 앱의 축소 버전이 아니다.
- 모바일 앱은 독립적인 프로세스로 진행되어야 함. 모바일 사용자의 요구를 파악하고 적절한 기능을 충족 시켜야함.
모바일 앱 사용자는 데스크탑 사용자는 동일 하면서도 다르다.
- 모바일 사용자는 작업 지향성 (task oriented)이 매우 높음. 즉 특정 작업을 신속하게 수행하려함.
- 여러 작업을 탐색, 학습 혹은 수행하려는 데스크탑 앱과 달리 모바일 앱은 달성하고자하는 명확한 목표가 있음.
- 목표가 분산되지 않도록 스텝, 클릭, 탭 수를 최소로 유지.
기능이 가치를 제공하는지 확인하기.
- 데스크탑 버전의 엔터프라이즈 앱은 매우 복잡하거나 사용 가능한 기능과 사용되지 않는 기능을 모두 갖추고 있음.
- 모든 기능을 항상 제공하는 것이 아니라 중요한 가치만 제공할 것.
엔터프라이즈 모바일 앱은 MVP 과정이 적합하다.
- 기본적이고 가장 중요한 기능을 갖춘 간단한 앱을 설계해 출시하고 사용성을 테스트해서 실행 가능성을 측정할 것.
- 범위를 단순하게 유지하면서 사용자의 반응을 보며 아이디어를 검증할 수 있음.
UX가 먼저, 그리고 UI
- 엔터프라이즈 앱 사용 환경 구축 시 적절한 백엔드 접속, 오프라인 지원 등 전체적인 신뢰성과 더불어 UI를 고려해야함
- 사용자의 불만을 방지하기 위해 UI보다 앱 퍼포먼스를 먼저 고려해야할 수도 있음.
- 모바일 앱은 항상 사용 가능해야하며 오프라인에서는 중요한 기능을 수행해야할 수도 있음.
성능을 측정할 수 있는 매개 변수 설정
- 비지니스 특성에 따라 측정이 가능하며 엔터프라이즈 앱으로 달성하고자 하는 목표와 관련된 KPI를 설정할 것.
- 사용자의 앱 체류 시간 및 로그인 횟수는 관련이 없을 수 있음.
- 응답 시간 단축 및 작업 완료 시간 단축을 KPI와 비교하기 시작하면 더 큰 그림에서 파악 가능함.주니어
중니어
UX디자인을 애자일 방법론에 적용하는 방법
Open
[성장의 피땀눈물]
UX
일하는 방법
프레임워크
UX 디자인 프로세스는 애자일 방법론보다 Waterfall 방법론과 더 유사합니다. UX 디자인은 구조화된 단계로 구성되어있고, 각 단계는 연구과정에 중점을 두면서 개별적으로 수행됩니다. 그렇다면 UX디자인을 애자일에 적용하는 동시에 사용자 중심의 디자인을 하는것이 가능할까요?
Agile과 Waterfall 방법론
Waterfall 방법론은 순차대로 구성된 단계를 따르고 각 단계는 이전 단계가 완료될 때까지 시작할 수 없습니다. 이는 매우 엄격하고 신중한 계획을 기반으로 하는 반면, Agile은 보다 유연하고 변화에 적응할 수 있어 훨씬 더 빠르게 앞으로 나아갈 수 있습니다.
UX 디자인 프로세스
UX디자인은 더블 다이아몬드를 기반으로하는 4단계를 통해 로드맵을 만듭니다. 디자인 프로세스는 명확하고 구조화된 워크 플로우가 있고 대부분 Waterfall 방식을 기반으로 합니다.
[리서치 리서치 결론 도출 브레인 스토밍 프로토타이핑 사용성 테스트(UT) 최종 디자인]
이 모든 프로세스를 마친 후 디자인을 개발자에게 넘겨줍니다.
이 과정에서 한 단계가 완료되면 디자이너는 다음 단계를 진행하거나, 일부 변경이 필요한 경우 단계를 반복 한 후 다음 단계로 이동하길 결정할 수도 있습니다.
좋은 것을 취하고 더 좋게 만들고 싶은 것은 지극히 자연스럽고, 이런 경우 효율적이고 유연하게 만드는 동시에 Agile방식과 유사할 수 있습니다. 이것이 Lean UX가 작동하는 방식입니다.
Lean UX
Lean UX는 리서치와 문서작성의 양을 최소로 줄이고, 대신 빠른 가설 검증으로 빠르게 전진하는 것을 목표로 합니다.
디자인 프로세스의 단계를 줄이고, 빠른 솔루션을 만들고, 이를 측정/검증해 피드백을 받고 무엇이 효과가 있는지 확인한 다음 최상의 옵션으로 적용하는 것 입니다.
Agile 과 Lean UX의 공통점
워크 플로우: Lean UX의 솔루션 기반 접근방식은 전통적인 UX프로세스에서 파생되지만 반복되는 워크플로우는 Agile과 같습니다.
원칙: Agile 과 Lean UX 모두 협업, 반복, 지속적인 테스트, 신속한 피드백, 빠른 결정 등 동일한 가치와 원칙을 공유합니다.
Agile 과 Lean UX는 함께 잘 작동할 수 있을까?
디자인 프로세스가 Lean/Agile 할 수 있지만 이 경우 리서치로 부터 도출되었을 몇가지 중요한 인사이트와 결론이 간과될 수 있습니다. 또한 디자이너의 스프린트는 항상 개발자의 스프린트보다 1-2 단계 앞서는 방식으로 진행하는 경우에만 작동할 수 있습니다. 이런식으로만 개발자가 인계받기 전 목업을 디자인하고, 필요한 사양을 준비할 시간을 갖게됩니다.
문제는 애자일에서 아무도 디자이너가 고품질의 사용자 중심의 디자인을 하는데 필요한 시간과 리소스를 고려하지 않는다는 것입니다. 디자이너의 작업시간은 워크플로우를 가능한 효율적으로 만드는데 중점을 두고 최소한으로 축소됩니다.
그렇다면 UX디자인은 어떻게 애자일 방법론에 잘 적응할 수 있을까요?
UX디자인은 다음과 같은 경우에만 Lean/Agile 방법론에 따라 잘 수행될 수 있습니다.
디자이너, 개발자, 경영진 간에 공유된 이해가 있습니다.
회사 전체가 UX프로세스를 전적으로 지원합니다.
UX디자이너의 요구는 개발 워크플로우에 통합됩니다.
UX디자이너는 개발자와 동등하며 팀의 중요한 부분입니다.
그러나 한 방법론에 의존하기보다는 Waterfall과 Agile의 일부 측면을 결합해 유연하게 적용하는 것이 더 좋습니다.
리서치를 위한 Waterfall: 실제적이고 깊은 인사이트를 발굴한 다음 이러한 내용을 팀과 공유하는 것이 포함되며, 이는 시간이 걸리므로 제품 개발 초기에 완료해야합니다.
디자인을 위한 Agile: 협업, 프로토타이핑, 테스트, 피드백과 지속적인 개선을 프로세스에 통합합니다.
사물은 흑과 백만 있는것이 아닙니다. 우리는 지속적으로 우리가 사용하는 모든 방법을 최대한 활용하도록 교육해야합니다. 이런식으로 우리는 우리와 우리 프로젝트의 특성에 가장 잘 맞는 솔루션을 찾을 수 있습니다.
Agile과 Waterfall 방법론
Waterfall 방법론은 순차대로 구성된 단계를 따르고 각 단계는 이전 단계가 완료될 때까지 시작할 수 없습니다. 이는 매우 엄격하고 신중한 계획을 기반으로 하는 반면, Agile은 보다 유연하고 변화에 적응할 수 있어 훨씬 더 빠르게 앞으로 나아갈 수 있습니다.
UX 디자인 프로세스
UX디자인은 더블 다이아몬드를 기반으로하는 4단계를 통해 로드맵을 만듭니다. 디자인 프로세스는 명확하고 구조화된 워크 플로우가 있고 대부분 Waterfall 방식을 기반으로 합니다.
[리서치 리서치 결론 도출 브레인 스토밍 프로토타이핑 사용성 테스트(UT) 최종 디자인]
이 모든 프로세스를 마친 후 디자인을 개발자에게 넘겨줍니다.
이 과정에서 한 단계가 완료되면 디자이너는 다음 단계를 진행하거나, 일부 변경이 필요한 경우 단계를 반복 한 후 다음 단계로 이동하길 결정할 수도 있습니다.
좋은 것을 취하고 더 좋게 만들고 싶은 것은 지극히 자연스럽고, 이런 경우 효율적이고 유연하게 만드는 동시에 Agile방식과 유사할 수 있습니다. 이것이 Lean UX가 작동하는 방식입니다.
Lean UX
Lean UX는 리서치와 문서작성의 양을 최소로 줄이고, 대신 빠른 가설 검증으로 빠르게 전진하는 것을 목표로 합니다.
디자인 프로세스의 단계를 줄이고, 빠른 솔루션을 만들고, 이를 측정/검증해 피드백을 받고 무엇이 효과가 있는지 확인한 다음 최상의 옵션으로 적용하는 것 입니다.
Agile 과 Lean UX의 공통점
워크 플로우: Lean UX의 솔루션 기반 접근방식은 전통적인 UX프로세스에서 파생되지만 반복되는 워크플로우는 Agile과 같습니다.
원칙: Agile 과 Lean UX 모두 협업, 반복, 지속적인 테스트, 신속한 피드백, 빠른 결정 등 동일한 가치와 원칙을 공유합니다.
Agile 과 Lean UX는 함께 잘 작동할 수 있을까?
디자인 프로세스가 Lean/Agile 할 수 있지만 이 경우 리서치로 부터 도출되었을 몇가지 중요한 인사이트와 결론이 간과될 수 있습니다. 또한 디자이너의 스프린트는 항상 개발자의 스프린트보다 1-2 단계 앞서는 방식으로 진행하는 경우에만 작동할 수 있습니다. 이런식으로만 개발자가 인계받기 전 목업을 디자인하고, 필요한 사양을 준비할 시간을 갖게됩니다.
문제는 애자일에서 아무도 디자이너가 고품질의 사용자 중심의 디자인을 하는데 필요한 시간과 리소스를 고려하지 않는다는 것입니다. 디자이너의 작업시간은 워크플로우를 가능한 효율적으로 만드는데 중점을 두고 최소한으로 축소됩니다.
그렇다면 UX디자인은 어떻게 애자일 방법론에 잘 적응할 수 있을까요?
UX디자인은 다음과 같은 경우에만 Lean/Agile 방법론에 따라 잘 수행될 수 있습니다.
디자이너, 개발자, 경영진 간에 공유된 이해가 있습니다.
회사 전체가 UX프로세스를 전적으로 지원합니다.
UX디자이너의 요구는 개발 워크플로우에 통합됩니다.
UX디자이너는 개발자와 동등하며 팀의 중요한 부분입니다.
그러나 한 방법론에 의존하기보다는 Waterfall과 Agile의 일부 측면을 결합해 유연하게 적용하는 것이 더 좋습니다.
리서치를 위한 Waterfall: 실제적이고 깊은 인사이트를 발굴한 다음 이러한 내용을 팀과 공유하는 것이 포함되며, 이는 시간이 걸리므로 제품 개발 초기에 완료해야합니다.
디자인을 위한 Agile: 협업, 프로토타이핑, 테스트, 피드백과 지속적인 개선을 프로세스에 통합합니다.
사물은 흑과 백만 있는것이 아닙니다. 우리는 지속적으로 우리가 사용하는 모든 방법을 최대한 활용하도록 교육해야합니다. 이런식으로 우리는 우리와 우리 프로젝트의 특성에 가장 잘 맞는 솔루션을 찾을 수 있습니다.주니어
중니어
기획자
‘성장’을 위해 제품의 ‘안전성’을 포기하면 안되는 이유
Open
[프로덕트 & 데이터 분석]
프로덕트 전략
프로덕트 분석
‘안전'의 이슈는 제품의 가치를 떨어뜨리고 비즈니스 비용을 발생시킵니다. 안전 문제를 경험한 고객은 보통 다시 돌아오지 않으며, 부정적 뉴스 혹은 입소문을 통해 수 십 수 백만 명이 브랜드에 대한 부정적 인식을 갖게 됩니다.
따라서, 제품의 안전을 보장하기 위한 계획은 성장을 지원하는 계획이라고 말할 수 있습니다. PM은 제품이 성장할수록 안전 이슈의 중요성과 가능성을 인지하고 대응방안에 대해 알고 있어야 합니다.
제품의 안전성 = 인식 + 현실
결국 안전은 ‘느낌'입니다. 사람들은 인식을 기반으로 ‘리스크’를 판단하며, 이를 기반으로 결정을 내립니다. 따라서 제품의 안전성은 안전하다는 ‘인식'과 실제로 안전한 ‘현실' 모두를 포함해야 합니다.
1) 안전 문제는 발생 빈도에 비해 회사에 보고되지 않는 경우가 많으며 2) 안전 문제를 겪은 사용자는 관련 경험을 주변에 공유합니다. 간접적으로 안전 문제를 인지한 사용자들은 위험을 완전히 회피하기 위해 제품을 사용하지 않기로 결정할 수 있습니다.
안전 문제는 우리가 인지하는 수준보다 숨겨진 문제가 많을 수 있음을 알아야 하며, 그 사건으로 인해 다른 사용자가 받을 영향에 대한 평가도 함께 진행되어야 합니다.
안전 리스크 식별 방법
1단계: 여러 부서가 모여서, 가능성이 있는 위험 목록 작성하세요. 가설을 수립하고 최대한 구체적으로 논의하여 사용자 여정을 따라 리스크와 우려사항을 나열하세요.
2단계: 나열한 리스크를 분류하세요. 다음 리스크 분류방법을 참고하세요.
∙제품 리스크 vs 행동 리스크 - ‘제품 자체’의 동작 실패인가, 혹은 제품을 ‘사용하는 행동'과 관련된 위험인가
∙빈도 vs 심각도 - 자주 발생하는가, 한번 발생해도 치명적인가
∙남용, 오용, 악의적 행동 - 사용자가 제품을 의도적으로 나쁘게 사용하는가(e.g. 스팸)
∙개인정보 보호 - 특히 커뮤니티 제품/서비스의 경우, 사용자의 신원과 개인정보가 불순한 목적으로 사용되지 않도록 주의해야함
∙사용자의 제품 통제 정도 - 사용자가 제품을 사용할 때 안전하다고 느낄 수 있도록 추가적인 설정 기능이나 통제장치가 필요할 수 있음(e.g. 자녀 보호기능)
∙페르소나별 리스크 - 여성, 노인, 특정 인종 그룹, 어린이 등 특정 그룹에 영향을 미칠 수 있는 사회적 사건이나 트렌드를 검토해야 함
리스크 데이터 수집하기
안전 퍼널에서는 나쁜 경험을 가지는 사용자를 최소화해야합니다. 리스크를 선행지표와 후행지표로 분류하세요.
사용자가 어떻게 위험을 알리는지 확인하고, 품질보증(QA)테스트를 통해 리스크를 확인하세요. 이 데이터는 어떤 리스크에 가장 먼저 손을 대야 하는지를 알려줍니다.
안전 로드맵 구축하기
리스크를 식별하고 분류하는 작업을 완료했다면, 리스크의 상대적 중요성을 기반으로 사용자에게 안심을 줄 수 있는 솔루션을 구축하세요.
제품의 안전성 = 인식 + 현실
결국 안전은 ‘느낌'입니다. 사람들은 인식을 기반으로 ‘리스크’를 판단하며, 이를 기반으로 결정을 내립니다. 따라서 제품의 안전성은 안전하다는 ‘인식'과 실제로 안전한 ‘현실' 모두를 포함해야 합니다.
1) 안전 문제는 발생 빈도에 비해 회사에 보고되지 않는 경우가 많으며 2) 안전 문제를 겪은 사용자는 관련 경험을 주변에 공유합니다. 간접적으로 안전 문제를 인지한 사용자들은 위험을 완전히 회피하기 위해 제품을 사용하지 않기로 결정할 수 있습니다.
안전 문제는 우리가 인지하는 수준보다 숨겨진 문제가 많을 수 있음을 알아야 하며, 그 사건으로 인해 다른 사용자가 받을 영향에 대한 평가도 함께 진행되어야 합니다.
안전 리스크 식별 방법
1단계: 여러 부서가 모여서, 가능성이 있는 위험 목록 작성하세요. 가설을 수립하고 최대한 구체적으로 논의하여 사용자 여정을 따라 리스크와 우려사항을 나열하세요.
2단계: 나열한 리스크를 분류하세요. 다음 리스크 분류방법을 참고하세요.
∙제품 리스크 vs 행동 리스크 - ‘제품 자체’의 동작 실패인가, 혹은 제품을 ‘사용하는 행동'과 관련된 위험인가
∙빈도 vs 심각도 - 자주 발생하는가, 한번 발생해도 치명적인가
∙남용, 오용, 악의적 행동 - 사용자가 제품을 의도적으로 나쁘게 사용하는가(e.g. 스팸)
∙개인정보 보호 - 특히 커뮤니티 제품/서비스의 경우, 사용자의 신원과 개인정보가 불순한 목적으로 사용되지 않도록 주의해야함
∙사용자의 제품 통제 정도 - 사용자가 제품을 사용할 때 안전하다고 느낄 수 있도록 추가적인 설정 기능이나 통제장치가 필요할 수 있음(e.g. 자녀 보호기능)
∙페르소나별 리스크 - 여성, 노인, 특정 인종 그룹, 어린이 등 특정 그룹에 영향을 미칠 수 있는 사회적 사건이나 트렌드를 검토해야 함
리스크 데이터 수집하기
안전 퍼널에서는 나쁜 경험을 가지는 사용자를 최소화해야합니다. 리스크를 선행지표와 후행지표로 분류하세요.
사용자가 어떻게 위험을 알리는지 확인하고, 품질보증(QA)테스트를 통해 리스크를 확인하세요. 이 데이터는 어떤 리스크에 가장 먼저 손을 대야 하는지를 알려줍니다.
안전 로드맵 구축하기
리스크를 식별하고 분류하는 작업을 완료했다면, 리스크의 상대적 중요성을 기반으로 사용자에게 안심을 줄 수 있는 솔루션을 구축하세요.
주니어
중니어
[Relate] Shape Up: Relate 팀의 제품 개발 프로세스
Open
[워크 프로세스]
일하는 방법
실 사례
경험 공유
Relate 팀이 업무 문화에서 많이 참고하고 있는 Basecamp의 제품 개발 프로세스를 소개합니다.
요약
• Shape Up 프로세스는 자율성을 기반으로한 프로젝트 개발에 대한 가이드라인이라고 할 수 있습니다.
• 제품 팀에게 프로젝트의 목표를 전달하되, 프로젝트를 성공적으로 개발하기 위한 의사결정과 진행은 제품 팀이 결정합니다.
• 고객에게 유의미한 프로젝트를 전달하기 위해 더 긴 기간의 개발 주기를 가지고, 매 개발 주기마다 할 일에 다한 의사결정을 새로 합니다.
• 개별 제품 개발 관계자들은 높은 자율성으로 일해야 하기 때문에 모두가 고객과 문제에 대해 잘 이해하고 있어야 하고, 실력이 뛰어나거나 빠르게 학습할 수 있어야 합니다.
Shape Up의 특징
6주 개발 + 2주 쿨다운 사이클
• 스크럼에 비해 더 긴 프로젝트 주기로, 유의미한 기능을 만들만큼 긴 기간과 관리할 수 있을만큼 짧은 기간 사이
명세가 아닌 형태를 전달
• 제품 팀에게 구체적인 명세가 아닌 적절히 추상화된 Shape을 전달
제품 팀이 책임지게 함
• 제품 팀에게 Shape이 배정되고 나면, 해당 Shape에 대한 실행과 커뮤니케이션은 제품 팀이 책임을 가져감
Shape Up 딘계
1. Shaping → 2. Betting → 3. Building
Shaping
제품 팀에게 프로젝트의 큰 틀과 완성 기준을 제시하되, 디테일은 제시하지 않습니다.
좋은 Shape은 충분히 추상적이지만(Rough), 문제를 해결할 수 있어야 하고(Solved), 프로젝트가 달성하거나 달성하지 않아야 할 목표가 확실해야 합니다(Bounded)
Betting
주요 의사결정자들이 올라온 Shape 들의 우선순위를 평가하여, 어떤 프로젝트에 리소스를 투자할 지 결정합니다.
Basecamp는 개발 6주, 쿨다운 2주의 8주 주기를 구성하지만, Relate은 초기 스타트업이기 때문에 개발 3주, 쿨다운 1주로 4주 주기를 적용하고 있습니다.
Relate은 100% 리모트 팀이기에 2주보다 더 긴 주기로 개발을 진행하는 것이 더 유리합니다. 불확실성이 높은 초기에 실시간 커뮤니케이션을 몰아서 하고 나면 해야 할 일이 명확해지기 때문에 비동기 커뮤니케이션으로도 충분하기 때문입니다.
Building
제품 팀은 Shape의 범위 안에서 실행을 위한 구체적인 Task 정의부터, 개발을 완료하고 테스트 하여 실제 제품에 반영시키는 지점까지의 모든 과정을 직접 결정하고 책임집니다.
그 과정에서 디자이너, 프론트, 백엔드 개발자들은 핵심 과제를 먼저 이해하고 확인할 수 있도록 노력해야 합니다.
개발을 진행하면서 관계있는 Task끼리 Scope으로 묶고, 더 불확실성이 높은 Scope의 우선순위를 높이면서 진행하는 방식으로 일합니다. 아직 알지 못하는 것들을 인정하고 계획을 세우면서 진행하기 때문에 개발 상황을 더 정확하게 예측할 수 있습니다.
요약
• Shape Up 프로세스는 자율성을 기반으로한 프로젝트 개발에 대한 가이드라인이라고 할 수 있습니다.
• 제품 팀에게 프로젝트의 목표를 전달하되, 프로젝트를 성공적으로 개발하기 위한 의사결정과 진행은 제품 팀이 결정합니다.
• 고객에게 유의미한 프로젝트를 전달하기 위해 더 긴 기간의 개발 주기를 가지고, 매 개발 주기마다 할 일에 다한 의사결정을 새로 합니다.
• 개별 제품 개발 관계자들은 높은 자율성으로 일해야 하기 때문에 모두가 고객과 문제에 대해 잘 이해하고 있어야 하고, 실력이 뛰어나거나 빠르게 학습할 수 있어야 합니다.
Shape Up의 특징
6주 개발 + 2주 쿨다운 사이클
• 스크럼에 비해 더 긴 프로젝트 주기로, 유의미한 기능을 만들만큼 긴 기간과 관리할 수 있을만큼 짧은 기간 사이
명세가 아닌 형태를 전달
• 제품 팀에게 구체적인 명세가 아닌 적절히 추상화된 Shape을 전달
제품 팀이 책임지게 함
• 제품 팀에게 Shape이 배정되고 나면, 해당 Shape에 대한 실행과 커뮤니케이션은 제품 팀이 책임을 가져감
Shape Up 딘계
1. Shaping → 2. Betting → 3. Building
Shaping
제품 팀에게 프로젝트의 큰 틀과 완성 기준을 제시하되, 디테일은 제시하지 않습니다.
좋은 Shape은 충분히 추상적이지만(Rough), 문제를 해결할 수 있어야 하고(Solved), 프로젝트가 달성하거나 달성하지 않아야 할 목표가 확실해야 합니다(Bounded)
Betting
주요 의사결정자들이 올라온 Shape 들의 우선순위를 평가하여, 어떤 프로젝트에 리소스를 투자할 지 결정합니다.
Basecamp는 개발 6주, 쿨다운 2주의 8주 주기를 구성하지만, Relate은 초기 스타트업이기 때문에 개발 3주, 쿨다운 1주로 4주 주기를 적용하고 있습니다.
Relate은 100% 리모트 팀이기에 2주보다 더 긴 주기로 개발을 진행하는 것이 더 유리합니다. 불확실성이 높은 초기에 실시간 커뮤니케이션을 몰아서 하고 나면 해야 할 일이 명확해지기 때문에 비동기 커뮤니케이션으로도 충분하기 때문입니다.
Building
제품 팀은 Shape의 범위 안에서 실행을 위한 구체적인 Task 정의부터, 개발을 완료하고 테스트 하여 실제 제품에 반영시키는 지점까지의 모든 과정을 직접 결정하고 책임집니다.
그 과정에서 디자이너, 프론트, 백엔드 개발자들은 핵심 과제를 먼저 이해하고 확인할 수 있도록 노력해야 합니다.
개발을 진행하면서 관계있는 Task끼리 Scope으로 묶고, 더 불확실성이 높은 Scope의 우선순위를 높이면서 진행하는 방식으로 일합니다. 아직 알지 못하는 것들을 인정하고 계획을 세우면서 진행하기 때문에 개발 상황을 더 정확하게 예측할 수 있습니다.중니어
시니어
바우하우스에서 배울 수 있는 UX적 관점
Open
[성장의 피땀눈물]
UX
커뮤니케이션
일하는 방법
우리는 바우하우스에서 UX적으로 어떤 것을 배울 수 있을까요? 구글의 UX 디렉터인 Jens Riegelsberger는 아티클을 통해 바우하우스에서 받은 여러 영감과 구글에서의 경험을 공유했습니다.
Simplicity
바우하우스는 단순함이라는 유산을 남겼습니다. 디자이너들이 장식적인 것을 비판적으로 바라보고 사용자들에게 실용적인 방법을 제공하기 시작한 것이죠.
우리는 작고 사소한 결정을 내리면서 UI는 점점 밀도가 높아지고 있는 것을 경험합니다. 때문에 단순하고 쉬운 디자인을 유지하는 것은 간단해 보이지만 복잡성에 계속 의문을 제기하고 어떤 것이 단순한 것인지 정의하는 노력이 요구되는 것입니다.
Gesamtkunstwerk: 종합예술
바우하우스의 설립자인 Walter Gropius는 예술을 완전히 경험하려면 예술을 종합적으로 바라보아야 한다고(Gesamtkunstwerk) 믿었습니다.
디지털 프로덕트를 디자인하는 우리에게도 이런 관점이 필요한 때입니다. 우리는 2D 화면에서 시작해 AR, VR을 만나게 됐고 다양한 차원과 감각을 디자인하는 세상을 마주하게 되었습니다. 모든 감각에 영향을 미치는 경험의 모든 측면을 디자인하게 된 우리의 작업은 Gesamtkunstwerk를 가능하게 하는 것으로 생각할 수 있습니다.
Staying connected to practice
바우하우스 선생님들은 각자 스튜디오 안에서 학생들과 협업하며 작업했습니다. UX팀의 리더라면 이처럼 다음 세대의 디자이너를 양성할 책임이 있습니다. 이를 위해 우리는 협업하며 배울 수 있는 조건을 형성해야 합니다. 의도적으로 일상적인 연습과 연결되는 공간을 만들고 그 안에서 유대감을 형성하기 위해 전문 분야와 상관없이 나란히 앉아 일하는 것이 방법이 될 수 있습니다.
구글에서는 좋은 아이디어를 위해 디자인 스프린트를 할 때 위계를 내려놓은 상태에서 문제 해결을 위한 다양하고 과감한 시도들을 한다고 합니다.
Creative collaboration
바우하우스에서는 각기 다른 분야의 전문가가 모여 서로에게 배우고 영감을 줬습니다. 관점과 경험이 다른 사람들에게 배우며 자신의 분야에서 성장하기를 원했던 것이죠.
요즘 UX나 “창의적인” 팀들은 그저 그들끼리 일하고 있는 것을 볼 수 있습니다. 하지만 디자이너와 엔지니어들이(다른 분야의 사람들끼리) 단결되었을 때, 우리는 새로운 기술이 제공하는 기능을 예상 및 활용할 수 있을 것입니다.
실제로 Jens Riegelsberger의 동료 중 가장 성공한 동료는 파트너 엔지니어들과 강한 유대감을 가지고 있으며 예술, 디자인, 인문학뿐만 아니라 과학과 공학의 언어에 능통하다고 합니다.
Personal bonds
전문적인 네트워크를 넘어 재미있는 상호작용을 위한 공간을 만들고 지속적인 유대를 형성하는 것 또한 중요합니다. 바우하우스의 여러 파티들은 전설이 됐고 지속적인 유대를 형성할 수 있는 이유가 되기도 했습니다. 현재 UX 컨퍼런스나 전문 협회를 통해 우리가 같이 모이기도 하지만 이런 모임들이 과연 재미와 실험 정신을 제공하기에 충분할까요?
이런 맥락으로 구글에서도 공부와 놀이를 목표로 하는 팀을 구성하기도 했다고 합니다.
Social good
바우하우스는 기술과 디자인을 통해 인류가 발전할 수 있다는 믿음을 가지고 있었습니다.
이는 Jens Riegelsberger가 동료들과 매일 대화하는 주제이기도 합니다. 우리의 디자인 결정의 장기적인 결과는 무엇일지, 어떻게 하면 사용자를 더 이해하고 인문학적인 내용을 디자인에 적용할 수 있을지 등과 같은 대화는 구글의 자연스러운 디자인 문화라고 합니다. 이렇듯 구글에서는 단일 분야 또는 한 사람이 모든 답을 가지고 있지 않다는 강한 인식이 있기에 직원에게 권한을 부여하고 하향식으로 의사를 결정하기도 하죠. 이를 통해 더 개방적이고 다양한 관점을 위한 토대를 마련한다고 합니다.
Simplicity
바우하우스는 단순함이라는 유산을 남겼습니다. 디자이너들이 장식적인 것을 비판적으로 바라보고 사용자들에게 실용적인 방법을 제공하기 시작한 것이죠.
우리는 작고 사소한 결정을 내리면서 UI는 점점 밀도가 높아지고 있는 것을 경험합니다. 때문에 단순하고 쉬운 디자인을 유지하는 것은 간단해 보이지만 복잡성에 계속 의문을 제기하고 어떤 것이 단순한 것인지 정의하는 노력이 요구되는 것입니다.
Gesamtkunstwerk: 종합예술
바우하우스의 설립자인 Walter Gropius는 예술을 완전히 경험하려면 예술을 종합적으로 바라보아야 한다고(Gesamtkunstwerk) 믿었습니다.
디지털 프로덕트를 디자인하는 우리에게도 이런 관점이 필요한 때입니다. 우리는 2D 화면에서 시작해 AR, VR을 만나게 됐고 다양한 차원과 감각을 디자인하는 세상을 마주하게 되었습니다. 모든 감각에 영향을 미치는 경험의 모든 측면을 디자인하게 된 우리의 작업은 Gesamtkunstwerk를 가능하게 하는 것으로 생각할 수 있습니다.
Staying connected to practice
바우하우스 선생님들은 각자 스튜디오 안에서 학생들과 협업하며 작업했습니다. UX팀의 리더라면 이처럼 다음 세대의 디자이너를 양성할 책임이 있습니다. 이를 위해 우리는 협업하며 배울 수 있는 조건을 형성해야 합니다. 의도적으로 일상적인 연습과 연결되는 공간을 만들고 그 안에서 유대감을 형성하기 위해 전문 분야와 상관없이 나란히 앉아 일하는 것이 방법이 될 수 있습니다.
구글에서는 좋은 아이디어를 위해 디자인 스프린트를 할 때 위계를 내려놓은 상태에서 문제 해결을 위한 다양하고 과감한 시도들을 한다고 합니다.
Creative collaboration
바우하우스에서는 각기 다른 분야의 전문가가 모여 서로에게 배우고 영감을 줬습니다. 관점과 경험이 다른 사람들에게 배우며 자신의 분야에서 성장하기를 원했던 것이죠.
요즘 UX나 “창의적인” 팀들은 그저 그들끼리 일하고 있는 것을 볼 수 있습니다. 하지만 디자이너와 엔지니어들이(다른 분야의 사람들끼리) 단결되었을 때, 우리는 새로운 기술이 제공하는 기능을 예상 및 활용할 수 있을 것입니다.
실제로 Jens Riegelsberger의 동료 중 가장 성공한 동료는 파트너 엔지니어들과 강한 유대감을 가지고 있으며 예술, 디자인, 인문학뿐만 아니라 과학과 공학의 언어에 능통하다고 합니다.
Personal bonds
전문적인 네트워크를 넘어 재미있는 상호작용을 위한 공간을 만들고 지속적인 유대를 형성하는 것 또한 중요합니다. 바우하우스의 여러 파티들은 전설이 됐고 지속적인 유대를 형성할 수 있는 이유가 되기도 했습니다. 현재 UX 컨퍼런스나 전문 협회를 통해 우리가 같이 모이기도 하지만 이런 모임들이 과연 재미와 실험 정신을 제공하기에 충분할까요?
이런 맥락으로 구글에서도 공부와 놀이를 목표로 하는 팀을 구성하기도 했다고 합니다.
Social good
바우하우스는 기술과 디자인을 통해 인류가 발전할 수 있다는 믿음을 가지고 있었습니다.
이는 Jens Riegelsberger가 동료들과 매일 대화하는 주제이기도 합니다. 우리의 디자인 결정의 장기적인 결과는 무엇일지, 어떻게 하면 사용자를 더 이해하고 인문학적인 내용을 디자인에 적용할 수 있을지 등과 같은 대화는 구글의 자연스러운 디자인 문화라고 합니다. 이렇듯 구글에서는 단일 분야 또는 한 사람이 모든 답을 가지고 있지 않다는 강한 인식이 있기에 직원에게 권한을 부여하고 하향식으로 의사를 결정하기도 하죠. 이를 통해 더 개방적이고 다양한 관점을 위한 토대를 마련한다고 합니다.주니어
사용자 채택을 늘리는 방법: SaaS에서 실제로 작동하는 7가지 실행 가능한 전략
Open
[그로스 전략]
프로덕트 전략
SaaS 제품으로 작업할 때 계속 집착하게 되는 작업은 사용자 채택을 늘리는 방법입니다.
사용자 채택: 제품에 등록하고 해당 제품과 관련된 기능을 사용하는 사용자의 수를 나타냅니다.
사용자 채택률 : 비즈니스를 유지하기 위해 지속적인 지불/갱신 구독에 의존하기 때문에 대부분의 SaaS 회사에서 중요한 지표입니다.
사용자 채택 전에 활성화에 집중해야 하는 이유:
잠재 사용자가 제품을 찾은 후 최종적으로 완전히 채택되기 전에 여러 단계를 거칩니다. 이 여정은 새로운 사용자가 귀하의 제품을 문제에 대한 잠재적인 솔루션으로 인식하는 ' 아하 순간 '으로 시작됩니다.
사용자 채택을 늘리기 위한 7가지 실행 가능한 전술 및 전략
사용자의 기본 온보딩 경험을 최적화
온보딩은 사용자를 신제품에 빠르게 활성화하는 방법입니다. 이를 위해 가입 절차는 최대한 빠르고 쉬워야 합니다. 또한 빈 영역의 컨텐츠 상태를 개인화된 콘텐츠로 교체되어야합니다. 툴팁, 체크리스트, 가이드 및 기타 UI 패턴을 사용하여 학습 곡선을 단축하고 사용자를 활성화 지점으로 안내하는것을 잊지마세요. 마지막으로 환영 화면을 사용하여 사용자에 대해 자세히 알아보고 필요에 따라 제품 내에서의 여정을 개인화 해야합니다.
보조 온보딩 체크리스트로 사용자 채택률 증가
보조 온보딩 체크리스트는 사용자에게 제품에서 더 많은 가치를 얻을 수 있는 관련 기능을 소개함으로써 도움이 됩니다. 사용자는 제품을 활용하여 목표를 완료할 수 있을 때 해당 제품을 더 빨리 채택합니다.
인터렉션 가이드로 사용자 안내 및 학습 경로 단축
때로는 사용자가 제품 기능을 빠르게 채택하도록 하는 가장 좋은 방법은 사용 방법을 가르치는 것입니다. 인터렉션 가이드는 사용자가 기능을 처음 사용할 때 단계별로 안내하는 일련의 도구 설명입니다. 이는 학습 경로를 단축하고 가치를 더 빠르게 제공합니다. 이러한 연습을 통해 사용자가 스스로 문제를 파악하는 데 드는 노력과 시간을 줄이고 사용자 참여도를 높일 수 있습니다.
인앱 메시징으로 새로운 기능 알림, 채택 확대
사용자는 일반적으로 새로운 기능을 기대하거나 찾고 제품을 탐색하지 않으므로 일단 새로운 기능이 출시되면 알려야 합니다. 인앱 메시지는 그들과 관련된 새로운 기능을 알릴 수 있는 좋은 방법입니다.
슬라이드아웃은 방해가 되지 않고 사용자가 시작하기에 충분한 세부정보를 제공할 수 있기 때문에 새로운 기능을 발표하는 데 적합합니다.
피드백을 수집하고 해결하기
인앱 마이크로 설문조사 를 사용 하여 고객 피드백을 수집합니다. 얻은 양적 및 질적 데이터에서 제품의 기능과 사용성을 개선, 앱에서 페인 포인트 제거, 사용자가 어려움을 겪는 부분을 이해도를 높힙니다.
사용자 여정의 여러 시기에 다양한 고객 만족도 설문조사 를 사용할 수도 있습니다.
더 나은 고객 경험을 위한 셀프 서비스 지원 제공
고객의 81%가 지원 직원에게 연락하기 전에 스스로 문제를 해결하려고 시도합니다. 이는 셀프 서비스 지원을 제공하는 것이 합리적이라는 증거입니다. 해당 솔류션은 앱 내 셀프 서비스 지원 센터에는 인앱 가이드, 문서 문서 링크, 원클릭 채팅 시작 관리자 등이 포함됩니다.
사용자가 항상 고객 지원 팀에 전화하거나 이메일을 보내는 것보다 셀프 서비스 지원은 고객이 문제 대한 솔루션에 쉽게 액세스할 수 있게 되어 채택률을 높이는 데 도움이 됩니다.
사용자 채택을 지속적인 프로세스로 만들기
사용자가 가입할 때부터 비즈니스를 종료할 때까지 채택 프로세스는 끝나지 않습니다. 신규 고객과 기존 고객은 지속적으로 제품에 참여하고 그로부터 가치를 얻어야 합니다. 이것이 여러 활성화 기준을 충족하고 구독료를 계속 지불하고 제품 채택 에 도달할 수 있는 유일한 방법 입니다.
끊임없이 고객에게 제품을 고집할 이유를 설명하고, 고객 경험이 문제가 없는지 체크하며, 고객의 목소리와 우려 사항에 귀를 기울이고 그에 따라 제품과 경험을 개선해야합니다.
사용자 채택: 제품에 등록하고 해당 제품과 관련된 기능을 사용하는 사용자의 수를 나타냅니다.
사용자 채택률 : 비즈니스를 유지하기 위해 지속적인 지불/갱신 구독에 의존하기 때문에 대부분의 SaaS 회사에서 중요한 지표입니다.
사용자 채택 전에 활성화에 집중해야 하는 이유:
잠재 사용자가 제품을 찾은 후 최종적으로 완전히 채택되기 전에 여러 단계를 거칩니다. 이 여정은 새로운 사용자가 귀하의 제품을 문제에 대한 잠재적인 솔루션으로 인식하는 ' 아하 순간 '으로 시작됩니다.
사용자 채택을 늘리기 위한 7가지 실행 가능한 전술 및 전략
사용자의 기본 온보딩 경험을 최적화
온보딩은 사용자를 신제품에 빠르게 활성화하는 방법입니다. 이를 위해 가입 절차는 최대한 빠르고 쉬워야 합니다. 또한 빈 영역의 컨텐츠 상태를 개인화된 콘텐츠로 교체되어야합니다. 툴팁, 체크리스트, 가이드 및 기타 UI 패턴을 사용하여 학습 곡선을 단축하고 사용자를 활성화 지점으로 안내하는것을 잊지마세요. 마지막으로 환영 화면을 사용하여 사용자에 대해 자세히 알아보고 필요에 따라 제품 내에서의 여정을 개인화 해야합니다.
보조 온보딩 체크리스트로 사용자 채택률 증가
보조 온보딩 체크리스트는 사용자에게 제품에서 더 많은 가치를 얻을 수 있는 관련 기능을 소개함으로써 도움이 됩니다. 사용자는 제품을 활용하여 목표를 완료할 수 있을 때 해당 제품을 더 빨리 채택합니다.
인터렉션 가이드로 사용자 안내 및 학습 경로 단축
때로는 사용자가 제품 기능을 빠르게 채택하도록 하는 가장 좋은 방법은 사용 방법을 가르치는 것입니다. 인터렉션 가이드는 사용자가 기능을 처음 사용할 때 단계별로 안내하는 일련의 도구 설명입니다. 이는 학습 경로를 단축하고 가치를 더 빠르게 제공합니다. 이러한 연습을 통해 사용자가 스스로 문제를 파악하는 데 드는 노력과 시간을 줄이고 사용자 참여도를 높일 수 있습니다.
인앱 메시징으로 새로운 기능 알림, 채택 확대
사용자는 일반적으로 새로운 기능을 기대하거나 찾고 제품을 탐색하지 않으므로 일단 새로운 기능이 출시되면 알려야 합니다. 인앱 메시지는 그들과 관련된 새로운 기능을 알릴 수 있는 좋은 방법입니다.
슬라이드아웃은 방해가 되지 않고 사용자가 시작하기에 충분한 세부정보를 제공할 수 있기 때문에 새로운 기능을 발표하는 데 적합합니다.
피드백을 수집하고 해결하기
인앱 마이크로 설문조사 를 사용 하여 고객 피드백을 수집합니다. 얻은 양적 및 질적 데이터에서 제품의 기능과 사용성을 개선, 앱에서 페인 포인트 제거, 사용자가 어려움을 겪는 부분을 이해도를 높힙니다.
사용자 여정의 여러 시기에 다양한 고객 만족도 설문조사 를 사용할 수도 있습니다.
더 나은 고객 경험을 위한 셀프 서비스 지원 제공
고객의 81%가 지원 직원에게 연락하기 전에 스스로 문제를 해결하려고 시도합니다. 이는 셀프 서비스 지원을 제공하는 것이 합리적이라는 증거입니다. 해당 솔류션은 앱 내 셀프 서비스 지원 센터에는 인앱 가이드, 문서 문서 링크, 원클릭 채팅 시작 관리자 등이 포함됩니다.
사용자가 항상 고객 지원 팀에 전화하거나 이메일을 보내는 것보다 셀프 서비스 지원은 고객이 문제 대한 솔루션에 쉽게 액세스할 수 있게 되어 채택률을 높이는 데 도움이 됩니다.
사용자 채택을 지속적인 프로세스로 만들기
사용자가 가입할 때부터 비즈니스를 종료할 때까지 채택 프로세스는 끝나지 않습니다. 신규 고객과 기존 고객은 지속적으로 제품에 참여하고 그로부터 가치를 얻어야 합니다. 이것이 여러 활성화 기준을 충족하고 구독료를 계속 지불하고 제품 채택 에 도달할 수 있는 유일한 방법 입니다.
끊임없이 고객에게 제품을 고집할 이유를 설명하고, 고객 경험이 문제가 없는지 체크하며, 고객의 목소리와 우려 사항에 귀를 기울이고 그에 따라 제품과 경험을 개선해야합니다.주니어
중니어
사용자에게 뭘 원하는지 그만 물어보세요
Open
[디자인]
리서치
사용자 인터뷰의 질을 높이기 위해 피해야할 4가지 흔한 질문들
이 앱/웹 사이트/제품을 어디에 사용하시겠습니까?
이 질문이 구린 이유 : 인터뷰이의 잘못된 판단으로 인해 제품에 대한 낙관적인 편견에 빠질 수 있습니다. 또한 인터뷰이가 사회적 압력에 의해 본심을 숨기고 있을 수도 있습니다.
이렇게 해보세요 : 인터뷰이에게 가설을 질문하는 대신, (1) 그들의 과거 행동을 분석하거나 (2) 문제 상황의 원인에 대해 물어보세요. 인간은 습관의 동물이기에 이후에도 같은 행동을 보일 가능성이 높습니다.
이 기능이 유용하다고 생각하세요?
이 질문이 구린 이유 : 모든 기능은 '유용'합니다. 다만 그 기능이 당면한 문제를 해결할 수 있는지 따져보는 것이 중요할 뿐이죠.
이렇게 해보세요 : (1) 작업 기반의 사용 적합성 테스트를 통해 사용자가 직접 기능을 찾고 사용하는지 확인하거나, (2) A/B 테스트를 통해 사용자가 새로운 기능에 어떻게 반응하는지 관찰해보세요.
이 디자인이 좋으신가요?
이 질문이 구린 이유 : 대부분의 사람들은 디자인에 전문적인 식견이 없습니다. 브랜드의 일관성이나 시각적 계층 구조 등에 대해 고려될 수 없음은 물론이다.
이렇게 해보세요 : 다른 질문들을 통해 인터뷰이에게서 브랜드나 시각 효과에 대한 피드백을 받을 수 있다. 그리고 그것을 해석하는 통찰력은 전문가가 가지고 있다.
당신의 어머니/자녀/친구가 이것을 사용할까요?
이 질문이 구린 이유 : 이미 에서 사람들이 자기 자신의 행동을 판단하는데도 서툴다고 말한 바 있다. 그들이 타인의 행동에 대해 정확히 판단하리라고 기대할 수 있을까?
이렇게 해보세요 : 인터뷰이 선정에 까다로울 필요가 있다. 정말 '당면 사용자'를 인터뷰이로 섭외해라.
진정한 혁신은 사용자의 의견 경청과 무시 사이의 적절한 배합에서 나옵니다.주니어
UX리서처의 커리어패스
Open
[성장의 피땀눈물]
스타트업
리서치
직무 분석
경험 공유
UX리서처란 어떤 직무인가를 실무 경험과 함께 볼 수 있는 영상을 소개드려 봅니다. 디자이너와 다른 점은 무엇인지, UX리서처가 되거나 역할을 하려면 어떤 역량이 요구되는지, 국내에 아직 널리 퍼지지 않은 직무인데 커리어패스는 어떠한지 등을 알아보는데 도움이 되는 영상입니다. 몇 가지 질문과 답변을 글로 옮겼습니다.
UX리서처는 어떤 일을 하는 직무일까요?
- 사용자의 경험을 조사하는 사람
- 사람이 제품이나 앱을 사용하면서 경험을 하게 되는데, 이 때 불편한 요소가 있는지 관찰을 통해 파악
- 더 편리한 사용성을 제공하려면 솔루션으로 어떻게 해드릴 수 있는지를 프로덕트 제작 담당자에게 리포트하는 조사관 역할
UX디자인도 참여를 하는지?
- 어느 정도는 함
- UX리서처는 무엇을 어떻게 만들면 사용성이 더 좋아질 것 같다고 리포트를 할 수 있다.
- 다만 보통 UX리서처가 디자인 전문가가 아니기 때문에 아주 깊이 있는 디자인까지 참여하지 않는다.
- 디자인 관련 역량이 없더라도 UX리서처가 될 수 있다는 뜻이기도 함
UX리서처 업무 중 어려웠던 점
- 사용자 개개인 의견을 다 수용할 수 없다.
- 개인적으로는 문제 해결 목적에 맞게 인터뷰이들의 의견에서 필요한 부분만 빼고 알맞게 조합해서 솔루션으로 구축하는 과정이 어려웠다.
스타트업에서의 UX 리서치 실무내용
- 에이전시에서나 스타트업에서나 업무 내용은 같다.
- 에이전시에서는 리크루팅(인터뷰이 섭외)을 대신해 주는 부서가 있다거나 데이터 처리를 대신해주고 그걸 테이블화해주는 부서가 따로 존재함.
- 스타트업에서는 리쿠르팅, 응답자와의 컨택, 데이터 분석 등 타 부서 도움이 필요한 부분들을 UX리서처가 거의 담당한다.
- 에이전시와 다르게 리포팅 이후 follow-up을 할 수 있다. 조사 방향이 옳았는지 제품 개발 이후 2차 조사를 하면서 확인해보고 개선해나갈 여지가 있음.
스타트업에서의 진행했던 프로젝트 중 어려웠던 프로젝트는?
- 패션업계 회사에 처음 입사했을 때 필드를 잘 알지 못해서 어려움을 겪었음
- UX리서처는 사용자 조사를 하기 위해서 이 사용자의 모든 것을 알아야 된다고 생각함
- 필드를 알지 못하는 상태에서 조사를 진행하다보니 사장님들이 쓰는 용어도 알아듣기 힘들었다.
- 해당 산업 분야를 아주 깊이있게, 제품에 대해서 모든걸 알 정도가 되어야 하므로 UX리서처가 스타트업에 입사하려면 정말 좋아하는 분야를 택하는 것이 중요할 것 같다.
UX리서처로서 향후 커리어패스는?
- UX리서치 과정에서 내 가설을 가지고 바로바로 테스트를 해보려면 디자인적 역량, 데이터 분석 역량도 필요하다고 생각함
- 사용자 중심적으로 생각을 하는 리서처지만 나중에는 디자인과 분석까지 총괄적으로 일할 수 있는 PM, PO가 되고자 하는 큰 비전을 가지고 있다.
UX리서처가 되기를 희망하는 취준생들이 가장 갖춰야할 역량
- 가장 중시하는 역량은 사람에 대한 관심과 통찰력
- UT를 하거나 사용자와 인터뷰를 하다 보면 사용자가 항상 생각하는 그대로를 인터뷰어에게 말하지는 않는다.
- 특히 인터뷰 상황에서는 인터뷰어-인터뷰이 관계에서 진솔한 응답을 얻기 힘든데, 관찰을 통해서 인사이트를 뽑아내야 하는 역량이 필요하다. 예를 들어 인터뷰이가 말끝을 흐린다든가, 고민하는 모습을 보일 때.
- 불편함을 느끼는 부분에 대해 계속해서 꼬리 질문을 함으로써 어떻게든 통찰해내는 능력이 필요
UX리서처는 어떤 일을 하는 직무일까요?
- 사용자의 경험을 조사하는 사람
- 사람이 제품이나 앱을 사용하면서 경험을 하게 되는데, 이 때 불편한 요소가 있는지 관찰을 통해 파악
- 더 편리한 사용성을 제공하려면 솔루션으로 어떻게 해드릴 수 있는지를 프로덕트 제작 담당자에게 리포트하는 조사관 역할
UX디자인도 참여를 하는지?
- 어느 정도는 함
- UX리서처는 무엇을 어떻게 만들면 사용성이 더 좋아질 것 같다고 리포트를 할 수 있다.
- 다만 보통 UX리서처가 디자인 전문가가 아니기 때문에 아주 깊이 있는 디자인까지 참여하지 않는다.
- 디자인 관련 역량이 없더라도 UX리서처가 될 수 있다는 뜻이기도 함
UX리서처 업무 중 어려웠던 점
- 사용자 개개인 의견을 다 수용할 수 없다.
- 개인적으로는 문제 해결 목적에 맞게 인터뷰이들의 의견에서 필요한 부분만 빼고 알맞게 조합해서 솔루션으로 구축하는 과정이 어려웠다.
스타트업에서의 UX 리서치 실무내용
- 에이전시에서나 스타트업에서나 업무 내용은 같다.
- 에이전시에서는 리크루팅(인터뷰이 섭외)을 대신해 주는 부서가 있다거나 데이터 처리를 대신해주고 그걸 테이블화해주는 부서가 따로 존재함.
- 스타트업에서는 리쿠르팅, 응답자와의 컨택, 데이터 분석 등 타 부서 도움이 필요한 부분들을 UX리서처가 거의 담당한다.
- 에이전시와 다르게 리포팅 이후 follow-up을 할 수 있다. 조사 방향이 옳았는지 제품 개발 이후 2차 조사를 하면서 확인해보고 개선해나갈 여지가 있음.
스타트업에서의 진행했던 프로젝트 중 어려웠던 프로젝트는?
- 패션업계 회사에 처음 입사했을 때 필드를 잘 알지 못해서 어려움을 겪었음
- UX리서처는 사용자 조사를 하기 위해서 이 사용자의 모든 것을 알아야 된다고 생각함
- 필드를 알지 못하는 상태에서 조사를 진행하다보니 사장님들이 쓰는 용어도 알아듣기 힘들었다.
- 해당 산업 분야를 아주 깊이있게, 제품에 대해서 모든걸 알 정도가 되어야 하므로 UX리서처가 스타트업에 입사하려면 정말 좋아하는 분야를 택하는 것이 중요할 것 같다.
UX리서처로서 향후 커리어패스는?
- UX리서치 과정에서 내 가설을 가지고 바로바로 테스트를 해보려면 디자인적 역량, 데이터 분석 역량도 필요하다고 생각함
- 사용자 중심적으로 생각을 하는 리서처지만 나중에는 디자인과 분석까지 총괄적으로 일할 수 있는 PM, PO가 되고자 하는 큰 비전을 가지고 있다.
UX리서처가 되기를 희망하는 취준생들이 가장 갖춰야할 역량
- 가장 중시하는 역량은 사람에 대한 관심과 통찰력
- UT를 하거나 사용자와 인터뷰를 하다 보면 사용자가 항상 생각하는 그대로를 인터뷰어에게 말하지는 않는다.
- 특히 인터뷰 상황에서는 인터뷰어-인터뷰이 관계에서 진솔한 응답을 얻기 힘든데, 관찰을 통해서 인사이트를 뽑아내야 하는 역량이 필요하다. 예를 들어 인터뷰이가 말끝을 흐린다든가, 고민하는 모습을 보일 때.
- 불편함을 느끼는 부분에 대해 계속해서 꼬리 질문을 함으로써 어떻게든 통찰해내는 능력이 필요신입
주니어
엔터프라이즈 스타트업, 애자일 다시 생각하기
Open
[워크 프로세스]
PM/PO
프로덕트 전략
프레임워크
Flatiron Health의 CMO이자 제품전략 SVP인 Ogi Kavazoic가 B2B 제품 조직에 대한 생각을 인터뷰를 통해 나눈 내용입니다. 모든 내용이 정답이고, 모든 상황에 맞는 것은 아니지만, B2B 조직이 제품을 만들 때 참고하기 좋습니다.
<문제>
- 많은 제품 리더들이 B2C앱 플레이북으로 엔터프라이즈 소프트웨어를 개발하려고 함
- 하지만 제품 개발 사이클과 고객 관계가 (B2B와) 근본적으로 다름
주로 2가지 잘못된 방향으로 빠짐
1. 명확한 제품 비전을 희생하면서, 애자일과 사랑에 빠짐
- 스프린트와 단기 계획만을 강조하고, 더 큰 제품 비전이 부족해짐
- 이는 고객팀과 애자일 제품팀의 마찰로 이어짐
- 세일즈 reps: "내년에 뭘 만들지 고객이 물어보는데 어떤가요?"
- PM: "확실하지 않아요. 우리는 애자일해요."
- 제품 중심 팀은 1-3개월 단위로 일처리를 하는데 익숙함.
- 회사에서 긴장(tension)이 빠르게 생김.
2. 시장 역학을 더 잘 이해하는 대신, 사용자 연구에 집중함
- B2B 세상은, 구매 결정을 내릴 때 사용자(users)는 목소리가 그리 크지 않을 수 있다.
- 사용자의 목소리보다, 시장의 목소리에 귀기울여야한다.
- 기존 고객이 만족하는, 사용자 경험 관점에서 최고의 제품이어도, 신규 딜을 놓칠 수 있다.
- 알고보니 놓친 고객은 '시장이 어디로 가는지, 다음 제품은 어때야하는지' 더 큰 비전을 제시하는 다른 제품 쪽으로 넘어감.
<솔루션>
- 오해할 수 있지만, 애자일 개발과 장기 계획은 상호 배타적이지 않다.
- 물론 애자일은 성공적인 사용자 경험을 만드는데 정말 좋다.
- 그러나, 사용자 경험과 전체 제품 로드맵은 서로 분리해야함.
핵심은
1. 장기적인 제품 비전을 분명히 하고
2. 세부 사항에 관해서는 유연성의 문화를 확립하는 것
상위레벨 로드맵의 적당한 타임라인은 18-24개월
- 해당 문서는 비전 로드맵으로 불림
짧은 개발 로드맵도 필요한데, 이는 1-3개월 정도로, 기능 단위로 나뉨
장기 플랜과 로드맵
- 회사 전체가 비전을 이해하고 소유권을 느껴야함.
- 영업사원, 제품 마케팅 팀의 분석 등을 취합해 시장 요구사항 문서를 만듬.
- 이 문서는 제품 리더십으로 이동해서 현재 상태의 기술 스택에서 실행 가능하고 호환 가능한게 무엇인지 결정.
- 이렇게 나온 비전 로드맵은 리더십 팀 → 회사 전체 순서로 검토 및 피드백을 두번 이상 거침.
- 광범위한 네트워크를 구축하고, 체계적인 방식으로 모든 사람의 의견을 얻는 것은, 모두가 이해하고 흥미롭고 동기 부여되는 제품 비전과 전략을 갖게 된다는 것.
개발 로드맵
- 제품 관리자와 엔지니어의 영역
- 다음 빌드에 적합한 기능 세트를 알아냄
- 확정이 되면 특정 기능을 기다릴 수 있는 주요 고객에게 알리고, 마케팅 팀에게 캠페인용 콘텐츠를 제공하거나, 고객 성공 팀에게 예정된 제품 변경 사항을 알리도록 허용함.
<고객을 믿어주세요.>
많은 신생 기업이 앞으로 1-2년의 내용을 공유하는것을 우려함.
- '고객이 목업 기능에 집착하면 어쩌지?'
- '생각이 바뀌면? 아무말도 하지 않는게 안전하지 않을까?'
하지만 대부분의 고객은 상황이 바뀌고 우선순위가 바뀔 수 있다는 점을 이해함.
더 중요한 것은 우리가 더 나은 솔루션을 찾을 수 있다는걸 이해함.
만족스러운 로드맵이 있다면 더 많은 고객과 공유하세요.
- 무엇이 반향을 일으키는지, 그렇지 않은 것을 살펴보세요.
- 만들어지기 전에 고객을 확보할 수도 있어요.
- 스타트업의 현금 흐름에 긍정적.
- 경쟁자의 공간을 미리 없애버릴 수도 있음.
고객 교육은 끝이 없습니다.
- 장기 로드맵을 진행하면서 고객이 기대하는 개발/기능에서 벗어날 수도 있음
- 이럴 때는 반드시 설명하고 새로운 접근 방식이 더 나은 이유를 가르쳐 주세요.
기획자
SaaS 제품 담당자
더 나은 일반적인 사용자 인터뷰를 하는 5가지 방법
Open
[워크 프로세스]
UX
리서치
사용자 조사
가이드
이 아티클은 개인적인 편견을 배제하고 사용자 행동에 대한 통찰력을 발견하는 질문을 하는 방법을 소개합니다. 사용자 인터뷰를 진행할 때 아래 5가지 질문을 하고 있지 않은지, 하고 있다면 필자가 제안하는 더 나은 질문을 하는 방법을 참고해보세요.
1) "어떤 문제가 있나요?"
- 사용자들은 대부분 자신이 갖고 있는 문제를 알지 못한다. 사용자들은 현재 상태에 익숙하기 때문에 자신의 문제가 사소하거나 실수라고 생각할 경우 공유하지 못한다. (실제로 사용성 테스트 중 참가자가 태스크를 완료하기 전에 오류를 겪었음에도 불가하고 서비스가 사용하기 쉽고 UX가 직관적이라고 했다.)
더 나은 방법: 관찰하고 간접적 질문을 해라
- "태스크를 어떻게 수행하는지 보여주세요"
- "마지막으로 X를 수행했을 때 시간이 얼마나 걸렸나요? 결과는 어떘나요? 결과에 만족하나요?"
- "이 태스크를 대신 수행할 수 있는 보조자가 있다면, 무엇을 알려주고 뭘 할 것인가요?"
2) "당신을 __ 라고 생각하나요? 당신은 __ 하는 사람인가요? (자체 평가 질문)"
- 우리의 뇌는 자신을 호의적으로 인식하도록 연결되어 있다. 따라서 자신이 말하는 것과 실제 행동 차이에 괴리가 생긴다.
더 나은 방법: 구체적인 행동에 대해 질문 해라
- "마지막으로 __ 한 경험을 말해 주세요. (ex. 오늘 마지막으로 본 콘텐츠를 생각하세요. 왜 관심이 갔나요? 왜 보기로 결정했나요?)"
- "당신은 (가치의 부합하는 행동)을 어떻게 하고 있나요?"
- "지난주에 몇번 __ (구체적인 행동)를 하셨나요?"
3) "__하시겠습니까?"
- 사람들은 선택을 강요 받을 땐 의견이 바뀔 수 있다.
더 나은 방법: 기존 행동에 대해 질문 해라
- "당신은 무얼 하려고 했나요? 이 문제/태스크를 더 쉽게 하려고 무엇을 하고 있나요?"
- 팁: 사용자한테 특정 태스크를 말하도록 요청하지 말고 자연스럽게 수행하는지 확인해라.
4) "어떤 기능을 원하세요?"
- 안타깝지만 사용자의 제안은 인식 가능 범위에 제한이 있다. 사용자는 아직 존재하지 않는 기능을 상상하는 디자이너나 기술자가 아니다.
더 나은 방법: 이유를 파헤쳐라.
- "무엇을 끝내려 하나요? 왜 중요한가요?"
- "현재 어떻게 하나요?"
- "우리가 제안한 기능을 언제, 어떻게 사용하고싶나요?"
5) "__에 동의하나요?"
- 선행 질문은 질문자의 가정이나 의견이 내제한다.
더 나은 방법: 질문은 간단하게 열린 형대로 유지하기.
- "__에 대해 어떻게 생각하나요?"
더 나은 방법: 관찰하고 간접적 질문을 해라
- "태스크를 어떻게 수행하는지 보여주세요"
- "마지막으로 X를 수행했을 때 시간이 얼마나 걸렸나요? 결과는 어떘나요? 결과에 만족하나요?"
- "이 태스크를 대신 수행할 수 있는 보조자가 있다면, 무엇을 알려주고 뭘 할 것인가요?"
2) "당신을 __ 라고 생각하나요? 당신은 __ 하는 사람인가요? (자체 평가 질문)"
- 우리의 뇌는 자신을 호의적으로 인식하도록 연결되어 있다. 따라서 자신이 말하는 것과 실제 행동 차이에 괴리가 생긴다.
더 나은 방법: 구체적인 행동에 대해 질문 해라
- "마지막으로 __ 한 경험을 말해 주세요. (ex. 오늘 마지막으로 본 콘텐츠를 생각하세요. 왜 관심이 갔나요? 왜 보기로 결정했나요?)"
- "당신은 (가치의 부합하는 행동)을 어떻게 하고 있나요?"
- "지난주에 몇번 __ (구체적인 행동)를 하셨나요?"
3) "__하시겠습니까?"
- 사람들은 선택을 강요 받을 땐 의견이 바뀔 수 있다.
더 나은 방법: 기존 행동에 대해 질문 해라
- "당신은 무얼 하려고 했나요? 이 문제/태스크를 더 쉽게 하려고 무엇을 하고 있나요?"
- 팁: 사용자한테 특정 태스크를 말하도록 요청하지 말고 자연스럽게 수행하는지 확인해라.
4) "어떤 기능을 원하세요?"
- 안타깝지만 사용자의 제안은 인식 가능 범위에 제한이 있다. 사용자는 아직 존재하지 않는 기능을 상상하는 디자이너나 기술자가 아니다.
더 나은 방법: 이유를 파헤쳐라.
- "무엇을 끝내려 하나요? 왜 중요한가요?"
- "현재 어떻게 하나요?"
- "우리가 제안한 기능을 언제, 어떻게 사용하고싶나요?"
5) "__에 동의하나요?"
- 선행 질문은 질문자의 가정이나 의견이 내제한다.
더 나은 방법: 질문은 간단하게 열린 형대로 유지하기.
- "__에 대해 어떻게 생각하나요?"주니어
중니어
모두가 즐길 수 있는 디자인 검토 회의 만들기
Open
[워크 프로세스]
UX
경험 공유
일하는 방법
마인드셋
UX디자인 프로세스에서 건설적인 피드백은 매우 중요합니다. 하지만 이러한 피드백이 서로에게 오히려 스트레스를 주는 경우가 생길 수 있습니다.
이 글은 멋진 프레젠테이션을 하거나 이해 관계자의 마음을 얻는 방법에 대한 팁을 제공하기 위한 글이 아닙니다. 대신, 여기에서는 사전 준비가 필요하지 않고 비판에서 자유로운 새로운 아이디어를 공유 방식을 제안합니다. 만약 여러분이 피드백의 품질을 높이고 보다 유기적인 협업을 장려하며 모두가 즐기는 회의를 원하신다면 이 글이 도움이 될 것입니다.
기존의 디자인 검토 회의와 문제점
목적 : 디자이너가 각자의 작업을 발표하고 개선을 위한 아이디어를 얻는 것
참석자 : 제품 디자이너 외에도 마케팅, 모션 디자이너, 연구원, 카피 전략가 등이 참석
문제점 :
깔끔하고 내용이 충실한 발표 자료를 준비해야 하는 부담
디자이너는 원할 때 동료와 즉석에서 만나 더 나은 피드백을 수집하는 것을 선호
회의 스케줄로 인해 더 빠른 피드백이 필요한 경우가 많음
피드백이 항상 유용한 것은 아니었고, 때로는 프로젝트 전체에 의문을 제기하는 데 초점을 둠
우리의 방식은 협업을 위한 친근한 검토가 아닌, 심사위원 앞에서 무대를 선보이고 비평 받는 자리와 같았습니다.
새로운 검토 방식 - 디자인 오픈 아워
당신이 가진 것을 보여주세요
많은 시간이 걸리는 발표 준비 없이 문서화와 세부 사항이 정해진 프로젝트 막바지라면 가지고 있는 산출물을 그대로 보여줍니다. 포스트잇이나 메모장에 휘갈긴 아이디어의 스케치라도 환영입니다.
내가 필요한 것은?
나에게 도움이 되는 피드백을 얻으려면 회의에 참가한 모든 디자이너에게 어떤 종류의 피드백이 필요한지 알려야 합니다.
보여드리는 프로세스 마지막 단계에 대한 여러분의 참신한 아이디어가 필요합니다.
제시된 고객 진입점이 직관적이고 사용자에게 도움이 된다고 느끼시나요?
가설에 대한 두 가지 아이디어가 있습니다. 그중 여러분은 어느 것을 선호하고 그 이유는 무엇인가요? 제가 생각하지 못하고 있는 더 나은 해결책이 있을까요?
이 솔루션을 개선하는 데 도움이 될 수 있는 데이터나 모범 사례를 찾고 있습니다.
액티브 피드백* 주고받기
*액티브 피드백은 자기 아이디어를 스케치로 표현하고, 다른 디자인 사례를 게시하고, 칭찬 남기기 등 구성원 모두가 프로젝트 개선을 위해 참여하는 활동을 말합니다.
피그마에서 짧은 10분 동안 스케치를 한 후 각 디자이너는 툴킷(toolkit)을 복사하여 자신의 화면에서 작업을 시작합니다. 이 작업의 목표는 잘 디자인된 부분에 대한 피드백을 남기고 개선이 필요한 부분에 대해 각자의 아이디어를 소개하는 것입니다.
다음 단계는 모두가 각자의 아이디어를 설명하는 열린 토론입니다. 이제 우리의 관심사는 특정 디자이너의 작업을 비판하는 것이 아니라 집단 지성을 통해 새로운 디자인을 구축하는 것입니다.
새로운 규칙
피그마는 우리의 화이트보드다
원격 근무 환경에서 원활하게 협업할 수 있는 공간을 찾으세요.
다른 프로젝트도 내 것처럼
이 규칙은 새로운 문화를 정착시키기 위해 가장 중요한 부분입니다. 이는 모든 참가자가 단순히 남의 프로젝트를 판단하는 위치에서, 프로젝트를 공동 소유하는 일원으로 전환해야합니다.
프로젝트 전체에 의문을 제기하지 말 것
때로는 그런 의견도 필요하지만, 디자인 오픈 아워는 그런 비판을 위한 공간이 아닙니다. 누군가가 프로젝트를 소개할 때, 이미 그 정당성에 대한 검증이 있었다고 믿고 해당 디자이너와 협업하여 도움을 주는 데 집중해야 합니다.
최종 결정은 디자이너의 몫이다
누군가는 자기 생각이 옳다고 굳게 믿습니다. 하지만 최선의 결정이 무엇인지 판단하고 어떤 피드백을 수용할 것인지 선택하는 것은 디자인 당사자라는 믿음을 주어야합니다.
기존의 디자인 검토 회의와 문제점
목적 : 디자이너가 각자의 작업을 발표하고 개선을 위한 아이디어를 얻는 것
참석자 : 제품 디자이너 외에도 마케팅, 모션 디자이너, 연구원, 카피 전략가 등이 참석
문제점 :
깔끔하고 내용이 충실한 발표 자료를 준비해야 하는 부담
디자이너는 원할 때 동료와 즉석에서 만나 더 나은 피드백을 수집하는 것을 선호
회의 스케줄로 인해 더 빠른 피드백이 필요한 경우가 많음
피드백이 항상 유용한 것은 아니었고, 때로는 프로젝트 전체에 의문을 제기하는 데 초점을 둠
우리의 방식은 협업을 위한 친근한 검토가 아닌, 심사위원 앞에서 무대를 선보이고 비평 받는 자리와 같았습니다.
새로운 검토 방식 - 디자인 오픈 아워
당신이 가진 것을 보여주세요
많은 시간이 걸리는 발표 준비 없이 문서화와 세부 사항이 정해진 프로젝트 막바지라면 가지고 있는 산출물을 그대로 보여줍니다. 포스트잇이나 메모장에 휘갈긴 아이디어의 스케치라도 환영입니다.
내가 필요한 것은?
나에게 도움이 되는 피드백을 얻으려면 회의에 참가한 모든 디자이너에게 어떤 종류의 피드백이 필요한지 알려야 합니다.
보여드리는 프로세스 마지막 단계에 대한 여러분의 참신한 아이디어가 필요합니다.
제시된 고객 진입점이 직관적이고 사용자에게 도움이 된다고 느끼시나요?
가설에 대한 두 가지 아이디어가 있습니다. 그중 여러분은 어느 것을 선호하고 그 이유는 무엇인가요? 제가 생각하지 못하고 있는 더 나은 해결책이 있을까요?
이 솔루션을 개선하는 데 도움이 될 수 있는 데이터나 모범 사례를 찾고 있습니다.
액티브 피드백* 주고받기
*액티브 피드백은 자기 아이디어를 스케치로 표현하고, 다른 디자인 사례를 게시하고, 칭찬 남기기 등 구성원 모두가 프로젝트 개선을 위해 참여하는 활동을 말합니다.
피그마에서 짧은 10분 동안 스케치를 한 후 각 디자이너는 툴킷(toolkit)을 복사하여 자신의 화면에서 작업을 시작합니다. 이 작업의 목표는 잘 디자인된 부분에 대한 피드백을 남기고 개선이 필요한 부분에 대해 각자의 아이디어를 소개하는 것입니다.
다음 단계는 모두가 각자의 아이디어를 설명하는 열린 토론입니다. 이제 우리의 관심사는 특정 디자이너의 작업을 비판하는 것이 아니라 집단 지성을 통해 새로운 디자인을 구축하는 것입니다.
새로운 규칙
피그마는 우리의 화이트보드다
원격 근무 환경에서 원활하게 협업할 수 있는 공간을 찾으세요.
다른 프로젝트도 내 것처럼
이 규칙은 새로운 문화를 정착시키기 위해 가장 중요한 부분입니다. 이는 모든 참가자가 단순히 남의 프로젝트를 판단하는 위치에서, 프로젝트를 공동 소유하는 일원으로 전환해야합니다.
프로젝트 전체에 의문을 제기하지 말 것
때로는 그런 의견도 필요하지만, 디자인 오픈 아워는 그런 비판을 위한 공간이 아닙니다. 누군가가 프로젝트를 소개할 때, 이미 그 정당성에 대한 검증이 있었다고 믿고 해당 디자이너와 협업하여 도움을 주는 데 집중해야 합니다.
최종 결정은 디자이너의 몫이다
누군가는 자기 생각이 옳다고 굳게 믿습니다. 하지만 최선의 결정이 무엇인지 판단하고 어떤 피드백을 수용할 것인지 선택하는 것은 디자인 당사자라는 믿음을 주어야합니다.주니어
중니어
기획자
PM이 필수로 알아야 하는 7가지 디자인 원칙
Open
[디자인]
PM/PO
UX
프로덕트 전략
디자인은 Product Manager가 결정을 내릴 때 최우선으로 생각해야 할 요소 중 하나입니다.
모든 Product Manager가 숙지해야 하는 7가지 제품 디자인 원칙이 있습니다. 특히 디자이너 출신의 PM이 아니라면, 이 7원칙을 이해하고 내면화 하는 것이 중요합니다.
1. 유저의 생각을 가이드하세요
유저가 어디에 초점을 맞춰야 할지를 알려주세요. 우선순위가 높은 사용자 요구사항에 집중해야 합니다. 다른 기능을 숨기거나 우선순위를 낮춤으로써 사용자가 ‘가장 중요하게 생각할 것'을 보여주세요.
예 : Google Flight는 주요 사용자 요구사항에 집중하기 위해 1) 직항편을 가장 먼저 보여주고 2) 가격 정보를 두드러지게 제공합니다. 여전히 다양한 정보를 제공하지만 주요하지 않은 정보는 회색으로 표시하고, 필터도 두드러지지 않습니다.
2. 유저가 생각하지 않게 하세요
사용자 경험이 단순해야 한다는 것은 가장 기본적인 개념이지만 쉽게 간과될 수 있습니다. 어수선한 것을 잘라내고 인지 부하를 최소화하세요. 유저가 정보에 압도되는 것을 막을 수 있습니다.
3. 핵심 액션이 클릭 3번으로 달성되게 하세요
포인트는 단일 핵심 액션 이 3번의 클릭 안에서 달성할 수 있어야 한다는 것입니다. 3클릭 사고방식이 모든 서비스에 적용되는 것은 아니지만, 이것은 우리의 서비스가 얼마나 고객 친화적인지를 판단할 수 있는 기준이 됩니다.
4. ‘되돌릴 수 있는’ 디자인을 하세요
우리는 모두 실수를 합니다. 그리고 실수를 되돌릴 수 없을 때 화가납니다. 여기서 말하는 리버시블 디자인은 단순히 ‘실행 취소' 버튼만을 말하는 것이 아닙니다.
예 :
- Trello 혹은 Notion의 갤러리 ui에서는 유저가 카드를 A열에서 B열로 옮겼다가 다시 A열의 원래 위치로 끌어올 수 있습니다.
- Intercom의 필터 ui에서는 유저가 필터를 추가했다가 삭제할 수 있는 작은 x 버튼이 있습니다.
- Google Drive ui에서는 유저가 파일을 삭제 했을 때 다시 undo 할 수 있는 토스트팝업을 제공합니다.
5. 액션의 컨텍스트를 알려주세요
모호한 용어는 인지 부하를 증가시킵니다. 유저가 올바른 조치를 취하고 있는지 확신을 주세요. 유저의 판단 소요 시간이 더 줄어듭니다.
- 버튼에 컬러를 사용하여 프로세스의 컨텍스트를 알려주세요. (예 : 메시지 삭제 팝업에서 [네, 이 메시지를 삭제할래요] 버튼에 컬러를 사용하여 강조)
- 컨텍스트에 맞고 모호하지 않은 버튼 문구를 사용하세요. (예 : [삭제] 버튼 대신 [네, 이 메시지를 삭제할래요] 버튼으로 제공)
6. 여백을 잘 사용하세요
여백을 잘 사용하면 투박한 디자인을 매끄럽게 끌어올릴 수 있습니다.
Wordpress의 경우 좌측에서는 세팅에 대한 다양한 메뉴를 제공하고 우측에서는 블로깅 프로세스에 필요한 기능들을 제공합니다. 하지만 실제로 블로그를 작성할 때, 즉 이 서비스의 핵심 액션을 수행할 때 이런 ui 구성은 매우 방해가 됩니다. Wordpresss는 ‘Distraction-free writing mode’를 제공하여 문제를 해결했습니다. 이 ‘방해 없이 쓰기 모드’에서는 모든 사이드바를 숨기고 쓰기 공간을 페이지의 중심 초점으로 제공합니다.
7. MVP 대신 MSP(Minimum Salable Product)
MSP가 MVP와 다른 점은 기능적인 면 뿐 아니라 유저가 느끼는 감정도 제품의 필수적 요소로 생각한다는 것입니다. 제품의 디자인은 사용자의 첫 인상을 결정합니다. Geoffrey Moore는 제품이 성공하려면 ‘얼리어답터'와 ‘대다수의 사람들' 사이에 존재하는 틈(chasm)을 잘 넘어야 제품이 확산된다고 말합니다. 사람들은 디자인이 좋으면 제품의 초기 결함을 슬쩍 넘겨버립니다.
디자인은 PM의 비밀무기입니다. 디자인을 디자이너에게만 맡겨두지 마세요. 제품 전략의 최전선에 디자인을 두고 시간을 내어 사용자가 서비스를 어떻게 느끼는지 확인하세요.
주니어
중니어
토스의 프로덕트 매니저가 하는 일
Open
[워크 프로세스]
실 사례
직무 분석
PM/PO
국내에서는 서비스 기획자, PO와 PM 직무가 많이 혼용되어 사용되고 있습니다. 도그냥님이 브런치에서 역사적으로 각 직무가 왜 생기게 되었는지, 어떻게 발전하고 있는지를 고찰한 K-Product ownder의 탄생론이란 글도 있습니다.
쿠팡에 이어 대한민국 스타트업계를 리딩하고 있는 또 하나의 기업인 토스에서 프로덕트 매니저(PM)이 어떤 직무를 하고 있는지에 대한 글을 소개합니다.
요약
PO가 개울을 건너기 위해 바윗돌을 빠르게 놓아 가설을 검증한 다음, PM은 그 돌다리같은 제품을 넓고 튼튼한 다리로 만드는 역할을 합니다.
토스가 정의하는 PO와 PM
• PO는 혁신을 탄생시키는 것이 목표, PM은 그 혁신이 더 많은 이들에게 닿을 수 있도록 하는 것을 목표로 합니다.
• PO는 잠재적 고객, PM은 현재 고객에 집중합니다
• PO는 제품을 확장시키는 역할, PM은 현재 고객의 문제를 해결하는 역할을 합니다
• PO는 전략적 관점에서 가설을 세우고 실험을 설계하고, PM은 쌓아온 데이터를 분석해 가설을 설계합니다.
• PO는 제품이 일정 단계에 이르르면 다른 제품으로 이동, PM은 하나의 제품을 장기적인 관점으로 계속해서 관리, 개선해나갑니다.
PM에게 필요한 스킬셋
PM은 하나의 제품을 더 활성화 할 수 있도록 지속적으로 관리, 개선하는 업무를 담당하기 때문에 전체를 바라보는 눈이 중요합니다. 이는 즉 하나의 사안에서 발생할 수 있는 모든 케이스들을 상상하고 고려할 수 있는 역량입니다. 이 역량을 가졌다면 제품을 운영하는 과정에서 맞닥뜨리는 여러 리스크들을 미리 감지하고 관리할 수 있습니다.
다른 분들의 예상과 다르게, 금융 도메인 지식보다는 제품 고도화를 위한 데이터를 기반으로 의사결정 내릴 수 있는 역량, 제품 개선점을 발견하고 정의해 자동화, 효율화 할 수 있는 역량, 여러 내외부 이해관계자들과 원할한 의사소통 역량이 더 중요하다고 합니다.
요약
PO가 개울을 건너기 위해 바윗돌을 빠르게 놓아 가설을 검증한 다음, PM은 그 돌다리같은 제품을 넓고 튼튼한 다리로 만드는 역할을 합니다.
토스가 정의하는 PO와 PM
• PO는 혁신을 탄생시키는 것이 목표, PM은 그 혁신이 더 많은 이들에게 닿을 수 있도록 하는 것을 목표로 합니다.
• PO는 잠재적 고객, PM은 현재 고객에 집중합니다
• PO는 제품을 확장시키는 역할, PM은 현재 고객의 문제를 해결하는 역할을 합니다
• PO는 전략적 관점에서 가설을 세우고 실험을 설계하고, PM은 쌓아온 데이터를 분석해 가설을 설계합니다.
• PO는 제품이 일정 단계에 이르르면 다른 제품으로 이동, PM은 하나의 제품을 장기적인 관점으로 계속해서 관리, 개선해나갑니다.
PM에게 필요한 스킬셋
PM은 하나의 제품을 더 활성화 할 수 있도록 지속적으로 관리, 개선하는 업무를 담당하기 때문에 전체를 바라보는 눈이 중요합니다. 이는 즉 하나의 사안에서 발생할 수 있는 모든 케이스들을 상상하고 고려할 수 있는 역량입니다. 이 역량을 가졌다면 제품을 운영하는 과정에서 맞닥뜨리는 여러 리스크들을 미리 감지하고 관리할 수 있습니다.
다른 분들의 예상과 다르게, 금융 도메인 지식보다는 제품 고도화를 위한 데이터를 기반으로 의사결정 내릴 수 있는 역량, 제품 개선점을 발견하고 정의해 자동화, 효율화 할 수 있는 역량, 여러 내외부 이해관계자들과 원할한 의사소통 역량이 더 중요하다고 합니다.중니어
시니어
디자인에 유용한 데이터
Open
[디자인]
UX
리서치
데이터 분석
지표
데이터가 디자인을 결정하는 중요한 요소 중 하나가 되면서 디자이너에게도 데이터를 해석하는 능력이 요구되고 있습니다.
특히 제품에서 중요한 요소였던 ‘사용성’이 상향 표준화된 상황에서 더 나은 제품을 위해 디자이너의 데이터에 대한 이해는 불가피합니다. 또 처음부터 완벽한 제품이 아닌 출시를 빠르게 해서 계속해서 업데이트해가는 전략이 보편화된 상황이라면 데이터는 디자인에 큰 영향을 미치게 됩니다.
하지만 디자이너는 데이터를 보고 분석하는 일을 주로 하는 직무가 아닙니다.
그렇기에 디자이너는 문제를 해결하기 위해 어떤 데이터를 요청하고 데이터가 나타내는 숫자의 변화가 어떤 의미를 가지는지 파악하는 능력이 필요합니다. 즉, 데이터가 나타내는 추세를 파악하는 힘을 길러야 하는 것이죠.
그렇다면 디자이너가 웹사이트에서 파악해야 할 8가지 데이터에는 어떤 것들이 있을까요?
1. 페이지뷰: 페이지가 열람된 횟수
2. 순방문자 수: 특정 기간 동안 실제로 방문한 유저 수
3. 페이지뷰와 순방문자 수 증감 추세: 특정 기간에 페이지뷰가 늘었다면 순방문자도 같이 늘었는지 확인하여 어떤 원인이 있었는지 분석해 보기
- 여러 정보를 동시에 확인하고 그 연관성을 찾는 것도 중요
4. 세션: 웹사이트를 방문해서 이탈하기까지 사이트 내에서 페이지를 열람 또는 이동이 일어나지 않는 이벤트가 발생한 것을 의미
- 페이지뷰 당 세션 수: 사용자가 한 번 사이트에 방문할 때 몇 페이지나 열람하는지 확인
- 순방문자 수 당 세션 수: 사이트를 방문한 사용자의 사이트 이용 빈도를 비교할 수 있음
5. 전환율: 사이트에서 특정 행위(구매, 장바구니 담기 등)를 한 유저 비율
6. 이탈률: 한 페이지만 보고 벗어난 세션(방문) 행위 비율
7. 종료율: 모든 페이지 기준 1개 이상의 페이지를 보고 화면을 종료한 세션(방문) 행동 비율
- 종료율이 높다고 부정적인 신호인 것은 아님
- 회원가입 후 종료했다면 회원가입이라는 목표는 달성한 것이기 때문
8. 유입 경로: 페이지에 유입된 경로
1. 직접 유입: 직접 url 입력, 즐겨찾기로 이동
2. 추천 유입: 다른 사이트를 통해 유입, 초대 코드를 활용하기도 함
3. 검색 유입: 검색엔진을 통해 검색한 후 유입되는 경우
4. 소셜 유입: SNS를 통해 유입된 경우
하지만 이런 정량적인 데이터뿐만 아니라 정성적인 데이터를 함께 고려할 필요도 있습니다. 디자인은 경험에 대한 인지와 이해를 바탕으로 하기 때문이죠.
휴리스틱 개념
시간이나 정보가 불충분해서 합리적인 판단을 할 수 없거나, 굳이 체계적이고 합리적인 판단을 할 필요가 없다고 판단한 상황 속에서 신속하게 훑어보며 어림짐작하는 기술입니다.
[4가지 평가 방식]
제이콥 닐슨의 10가지 사용성 휴리스틱
아비 코버트의 10가지 IA 휴리스틱
웨인쉨크의 20가지 휴리스틱 분류
게르하르트-포월스의 10가지 인지 엔지니어링 원칙
[7가지 평가 기준]
#가시성 # 자연스러움 #통제성 #일관성 #적확성 #회복성 #가시성
5WHYS
5차례로 사용자에게 왜 그렇게 생각하는지 물으면서 사용성 문제의 원인을 파악하는 방법으로 사용성에 불편을 겪는 본질적 이유를 알아내면 디자인을 빠르게 개선할 수 있을 것입니다.
하지만 디자이너는 데이터를 보고 분석하는 일을 주로 하는 직무가 아닙니다.
그렇기에 디자이너는 문제를 해결하기 위해 어떤 데이터를 요청하고 데이터가 나타내는 숫자의 변화가 어떤 의미를 가지는지 파악하는 능력이 필요합니다. 즉, 데이터가 나타내는 추세를 파악하는 힘을 길러야 하는 것이죠.
그렇다면 디자이너가 웹사이트에서 파악해야 할 8가지 데이터에는 어떤 것들이 있을까요?
1. 페이지뷰: 페이지가 열람된 횟수
2. 순방문자 수: 특정 기간 동안 실제로 방문한 유저 수
3. 페이지뷰와 순방문자 수 증감 추세: 특정 기간에 페이지뷰가 늘었다면 순방문자도 같이 늘었는지 확인하여 어떤 원인이 있었는지 분석해 보기
- 여러 정보를 동시에 확인하고 그 연관성을 찾는 것도 중요
4. 세션: 웹사이트를 방문해서 이탈하기까지 사이트 내에서 페이지를 열람 또는 이동이 일어나지 않는 이벤트가 발생한 것을 의미
- 페이지뷰 당 세션 수: 사용자가 한 번 사이트에 방문할 때 몇 페이지나 열람하는지 확인
- 순방문자 수 당 세션 수: 사이트를 방문한 사용자의 사이트 이용 빈도를 비교할 수 있음
5. 전환율: 사이트에서 특정 행위(구매, 장바구니 담기 등)를 한 유저 비율
6. 이탈률: 한 페이지만 보고 벗어난 세션(방문) 행위 비율
7. 종료율: 모든 페이지 기준 1개 이상의 페이지를 보고 화면을 종료한 세션(방문) 행동 비율
- 종료율이 높다고 부정적인 신호인 것은 아님
- 회원가입 후 종료했다면 회원가입이라는 목표는 달성한 것이기 때문
8. 유입 경로: 페이지에 유입된 경로
1. 직접 유입: 직접 url 입력, 즐겨찾기로 이동
2. 추천 유입: 다른 사이트를 통해 유입, 초대 코드를 활용하기도 함
3. 검색 유입: 검색엔진을 통해 검색한 후 유입되는 경우
4. 소셜 유입: SNS를 통해 유입된 경우
하지만 이런 정량적인 데이터뿐만 아니라 정성적인 데이터를 함께 고려할 필요도 있습니다. 디자인은 경험에 대한 인지와 이해를 바탕으로 하기 때문이죠.
휴리스틱 개념
시간이나 정보가 불충분해서 합리적인 판단을 할 수 없거나, 굳이 체계적이고 합리적인 판단을 할 필요가 없다고 판단한 상황 속에서 신속하게 훑어보며 어림짐작하는 기술입니다.
[4가지 평가 방식]
제이콥 닐슨의 10가지 사용성 휴리스틱
아비 코버트의 10가지 IA 휴리스틱
웨인쉨크의 20가지 휴리스틱 분류
게르하르트-포월스의 10가지 인지 엔지니어링 원칙
[7가지 평가 기준]
#가시성 # 자연스러움 #통제성 #일관성 #적확성 #회복성 #가시성
5WHYS
5차례로 사용자에게 왜 그렇게 생각하는지 물으면서 사용성 문제의 원인을 파악하는 방법으로 사용성에 불편을 겪는 본질적 이유를 알아내면 디자인을 빠르게 개선할 수 있을 것입니다.주니어
2022년 & 이후 프로덕트 트렌드
Open
[프로덕트 & 데이터 분석]
프로덕트 분석
비즈니스 전략
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)
구매 잊기
이 키워드는 스토리지, 모니터링 및 백업의 기능을 제공하는 제품에 알맞습니다. 고객이 데이터를 어딘가에 저장해야 하는 기능적 요구 사항 을 찾고 있다면 더 중요한 것은 데이터가 안전하다는 것을 알고 마음의 평화를 얻는 감정적인 요소가 있습니다.
- 참여도가 낮은 제품은 핵심 기능에만 집중하면 되기 때문에 일반적으로 유지 관리가 더 쉽습니다. 즉, 고객은 문제가 발생했을 때만 제품을 찾아오면 됩니다.
- 반복 가치 는 고객이 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
Open
[그로스 전략]
스타트업
마케팅
비즈니스 전략
※ 자세한 설명과 예시는 원문에서 확인 가능합니다.
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님)
Open
[디자인]
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) 사용자의 액션을 강력하게 끌어와야 하는 버튼에 '-하기'를 쓴다.
- '-하기'는 워낙 은근한 장치이기 때문에 사용자의 선택에 결정적인 영향을 미치는 일은 없다고 본다.
- 다만 가능하면 구매, 구독, 결제와 같이 서비스 입장에서 중요한 버튼에만 드물게 '-하기'를 붙이면 좋겠다.
『웹 기획자가 알아야할 서비스 글쓰기의 모든 것』 (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) 사용자의 액션을 강력하게 끌어와야 하는 버튼에 '-하기'를 쓴다.
- '-하기'는 워낙 은근한 장치이기 때문에 사용자의 선택에 결정적인 영향을 미치는 일은 없다고 본다.
- 다만 가능하면 구매, 구독, 결제와 같이 서비스 입장에서 중요한 버튼에만 드물게 '-하기'를 붙이면 좋겠다.
신입
주니어
제품 로드맵에 대한 궁극적인 가이드
Open
[워크 프로세스]
프로덕트 전략
제품 로드맵에 대한 궁극적인 가이드
제품 로드맵이란 무엇입니까?
- 제품 전략을 실행하기 위한 계획과 지침이 되는 전략 문서
제품 로드맵이 중요한 이유는 무엇입니까?
- 제품 로드맵은 제품 전략이 어떻게 현실화되는지 요약
- 제품과 제품의 성공에 대한 영감, 동기 부여 및 공유 소유권의 원천
- 조직이 혼란을 피하고, 소규모 프로젝트가 구현 대기열에 들어가지 않고, 덜 중요한 작업에 리소스를 낭비하는 것을 방지
<제품 로드맵 구축>
제품이 성숙해짐에 따라 로드맵이 발전함. 새로 만든 MVP와 성숙한 제품은 다르다.
- 지평(Horizon): 스타트업은 미래 요구사항과 기회를 예측하기 어렵고, 로드맵이 멀지 않음. 기존 제품은 고객과 시장을 더 잘 이해하고, 확고한 장기 계획을 세움.
- 빈도(Frequency): 미숙할 때는 "항상 배포"해야합니다. 성숙한 제품은 덜 긴급하게 릴리즈할 수 있다.
- 종속성(Dependencies): 스타트업은 빠르게 움직이고 부술 수 있다. 성숙한 제품은 레거시, 써드파티 통합, 역행 이슈 등이 있다.
- 목표(Goals): 스타트업은 생존 가능성을 증명하고, 견인력(traction)을 얻고, 성장하려고 노력해야함. 엔터프라이즈는 미묘한 전략적 목표와 다양한 타겟을 가진다.
제품 로드맵을 어떻게 계획합니까? 몇가지 필터가 있음.
- 사용자에게 실제 가치가 있는가?
- 그 가치에 대한 증거가 있는가?
- 소유자(owner)가 있는가? (챔피언 역할)
- (기존 로드맵에) 어울리는가?
제품 로드맵에서 기능의 우선 순위를 어떻게 정합니까?
- OKR, MoSCow , RICE Scoring Model 등 선택할 수 있는 프레임워크가 다양함.
- 궁극적으로 어떤 접근 방식을 선택하든지 가치, 노력 수준 및 기회 비용에 대해 각 항목을 평가해야함.
- 팀은 또한 단기 승리와 장기 목표를 향한 진전의 이점을 비교해야 함.
<추가 로드맵 팁>
로드맵에 여러 제품을 추가하는 방법
- 일관성은 이 문제를 해결하는 열쇠
- 로드맵 스타일, 범례, 색상 코딩, 시간대 및 세분성 수준에 대한 정렬은 필수
- 버전 관리 문제도 잊지 마세요!
애자일 로드맵은 무엇입니까?
- 훨씬 더 짧은 기간을 가지며 변화하는 우선순위와 시장 기회를 수용하기 위해 더 자주 조정
- 로드맵을 최신 상태로 유지하는 것이 성공의 가장 큰 비결 중 하나
다양한 유형의 제품 로드맵은 무엇입니까?
- 경영진을 위한 내부 로드맵: 계획된 작업이 제품(및 회사)의 가치를 어떻게 높일 것인지에 중점
- 엔지니어를 위한 내부 로드맵: 기능, 릴리스, 스프린트 및 이정표에 중점
- 판매를 위한 내부 로드맵: 기능과 고객 이점의 조합에 중점
- 고객 및 잠재 고객을 위한 외부 로드맵: 릴리스 또는 출시 날짜를 포함하지 않는 것이 가장 좋습니다.
<로드맵 발표 및 사용>
5단계로 로드맵을 제시하는 방법
1. 로드맵을 누구와 공유해야 합니까?
2. 청중을 파악하십시오.
3. 내러티브에 집중하세요.
4. 높은 수준을 유지하십시오.
5. 메시지에 몇 가지 메트릭을 추가합니다.
로드맵 실행이란 무엇입니까?
- 제품 로드맵과 그 목표를 실현하는 임무를 맡은 팀이 명확하게 이해하도록 해야함
- 프로세스의 설계, 개발, 테스트 및 배포 단계 전반에 걸쳐 계속 참여해야함
- 새로운 기능이 예상대로 작동하고 요구 사항을 충족하는 동시에 기존 기능도 계속 작동하는지 확인해야함
기획자
SaaS 제품 담당자
접근성은 디자이너의 책임이다
Open
[디자인]
UX
접근성
접근성은 디자이너의 책임이다
시력과 청력에 지장이 없고 쉽게 읽고 쓸 수 있는 사람이 인구의 약 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간의 명확한 인터렉션에 도움이됨.주니어
중니어
알림 디자인을 위한 가이드라인
Open
[디자인]
UX
프로덕트 전략
더 나은 알림 디자인을 통한 더 나은 사용성
알림은 제품 사용성에 주요한 기능입니다.
'시스템 상태의 가시성' 은 Nielsen Norman Group의 "사용자 인터페이스 디자인을 위한 10가지 사용성 휴리스틱" 목록에서 첫번째 항목 입니다. 이 규칙은 "시스템은 적절한 시간 내에 적절한 피드백을 통해 사용자에게 무슨 일이 일어나고 있는지에 대한 정보를 항상 제공해야 한다."라고 말합니다.
알림 시스템은 디지털 제품 UX의 많은 부분을 차지하므로, 알림 시스템이 없으면 제품은 마치 무언가가 빠진 것처럼 느껴질 것입니다. '시스템 상태의 가시성'과 피드백이 없다면 대시보드 없이 자동차를 운전하는 것과 같습니다.
모든 유형의 알림은 디지털 제품에서 없어서는 안될 부분입니다.
유용한 알림 프레임워크 구축하기
알림 디자인을 나중에 생각하지 마세요
우리는 작지만 중요한 UX개선사항을 마지막으로 생각하는 경향이 있습니다. 경고, 오류메시지, 확인, 공지 등의 알림 디자인은 나중에 생각하는 경우가 많습니다. 이러한 접근방식은 UX를 손상시키는 조잡한 프랑켄슈타인과 같은 결과물을 만들기도 합니다.
이러한 상황을 피하려면 알림 디자인에 대한 통합 접근 방식을 사용해 제품 디자인 프로세스의 초기에서 부터 사용자 경험을 향상시켜야합니다.
'주의 수준'으로 알림을 분류하세요
알림 프레임워크를 잘 설계하려면 알림을 '주의 수준' 측면에서 생각하는 것이 도움이 될 수 있습니다. 예를 들어 테스크를 수행하는데에 큰 방해가되는 문제에는 "강력한 알림"이 필요하고, 그렇지 않은 경우에는 "조용한 알림"이 필요합니다.
알림 디자인에 대한 초기 접근 방식은 [높음, 중간, 낮음]의 세가지 수준으로 분류해보세요. 그 다음 경고, 확인, 오류, 성공메시지 등 특정 속성 내에서 추가로 유형을 정의할 수 있습니다.
높은 주의
Alerts 즉각적인 주의 필요
Errors 즉시 조치 필요
Exceptions 시스템 이상으로 무언가 작동하지 않음
Confirmations 진행하려면 사용자 확인이 필요해 잠재적인 주의요인
중간 주의
Warnings 즉각적인 조치가 필요하지 않음
Acknowledgments 사용자 작업에 대한 피드백
Success messages 성공 메시지
낮은 주의
Informational messages 볼 수 있게 준비된 항목
Badges 일반적으로 아이콘 위에 노출되며 마지막 상호작용 이후 새로운 것을 표시함
Status indicators 시스템 피드백
알림 유형에 맞는 디자인 시스템을 설계하세요
알림 목록이 준비되면 다음 단계는 원하는 주의 수준과 속성에 따라 알림을 분류하는 것입니다. 알림은 방해가 되어서는 안 되므로 신중하게 수행해야 합니다. 아래 질문에 따라 알림을 유형화하고 이에 맞는 색상코드, 아이콘, 위치, 동작 등 상세한 UX와 알림 디자인 시스템을 설계하세요. 이 과정에서 디자이너는 알림이 표시되는 모든 상황과 예외케이스들을 고려할 수 있어야합니다.
알림을 트리거하는 것은 무엇입니까?
어떤 유형의 피드백이 전달되고 있습니까?
알림은 어디에 어떻게 표시됩니까?
즉각적인 상호 작용이 필요한 알림은 무엇입니까?
알림이 지속적입니까 아니면 비지속적입니까?
사람들에게 적절한 양의 알림을 보내는것은 균형을 유지하는 작업이며, 이를 과도하게 사용되면 위험이 따릅니다.
과도한 알림이 사용되는 경우 제품에 대해 부정적인 피드백을 받을 수도 있고 최악의 경우 제품을 포기하는데에도 영향을 미칠 수 있습니다.
알림을 사용하는 시기와 방법을 이해하는 것은 뛰어난 사용성을 제공하고 제품 메시지의 일관성을 구축하는 데 필수적입니다. 적절한 순간에 표시되어야 하는 주변 메시지를 신중하게 평가함으로써 디자이너는 제품의 효율성을 높이고 UX를 향상시킬 수 있습니다.주니어
중니어
기획자
문제 해결을 위해 솔루션으로 달려가지 마세요
Open
[워크 프로세스]
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겸 디자이너가 전략에 더 많은 영향력을 만드는 방법
Open
[성장의 피땀눈물]
일하는 방법
마인드셋
이 글은 프로덕트 디자이너인 저자가 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가지 교훈
Open
[성장의 피땀눈물]
일하는 방법
마인드셋
경험 공유
엑셀로 데이터 쟁탈전, 파워포인트로 스토리텔링을 얼마나 잘했는지에 대한 글이 아닙니다. 모든 직업, 어떤 경우에는 삶에 적용할 수 있는 중요한 것들을 공유하고 싶습니다.
전문가가 아닌, 항상 학생으로서 문제에 접근하기.
신선하고 호기심 많은 마음으로 문제에 접근해야 합니다. 질문을 하고, 메모를 하고,더 깊이 파고들고 계속 압박하여 가설을 수정하십시오. 학생의 사고방식은 당신의 두뇌를 객관적인 환경에 놓이게 합니다. 문제를 합리적으로 분석하고, 팀원과 효과적으로 협업하고, 적절한 솔루션을 만들 수 있는 보다 개방적인 형식으로 아이디어에 접근합니다. 이 모든 것이 "모든 것을 알고" 있어야 하는 스스로 유발하는 압력을 완화하는 것입니다.
’사기꾼 증후군'의 사기꾼은 조직이 아닌, 나 자신입니다.
동료들이 나보다 더 많이 알고 더 잘 실행한다고 가정하지만,
현실은 대부분의 사람들이 진행하면서 알아가는 실행착오를 격습니다. 다른 사람들이 전문적으로 나보다 우월하다는 선입견을 가질 때, 그들(그리고 자신)을 그렇게 대하기 시작하며, 이는 큰 착각입니다. 모두가 당신과 같은 학생이라는 것을 인식해야 합니다.
실패는 일어날 수 있는 가장 좋은 일입니다.
거의 해고당할 뻔했습니다. 높은 스트레스 상황에서 까다로운 고객을 관리하면서 내 기술을 넘어 도전적인 프로젝트에 참여했지만, 비참하게 실패했습니다. 이때 스스로의 약점을 알고 실패의 핑계가 아닌 성장의 원동력이 되었습니다. 실패는 앞으로 나아갈 방향을 결정해 줍니다.
조직은 개인이 그만둘 때까지 영역에 맞춰 넣을 것입니다.
경영진은 배를 조종하는 방법에 대한 비전을 가지고 있으며, 그 비전은 더 작은 조각으로 쪼개지고, 개인은 만들어진 조작 내에서만 실행할 수 있습니다. 조직은 궁극적으로 배를 조종할 것이기 때문에 개인을 그 영역 안에 두도록 장려합니다. 하지만 조직의 방향과 영역이 배움, 흥미가 있지 않다면 스스로를 가두지 말고 다른 다른 곳을 찾는 것은 우리의 몫입니다. 마음가짐, 동기 부여, 회복력이 있다면 실행해 보세요.
모든 것에 대한 해결책이 있습니다.
침착하세요. 패닉은 해결책이 아닙니다. 한 발 물러서서 논리에서 감정을 풀고 가능한 최선의 계획에 착수하십시오. 휴식도 답이 될 수 있습니다.
좋은 의도가 사람을 움직입니다. 정치가 아닙니다.
리더가 개인적인 이득을 위해 팀원들 인형극 부리듯 조종하는 것은 단기적으로 승리할 수 있지만 장기적인 성공은 관계를 기반해서 움직입니다. 조직의 성공은 맞는 팀원들과 함께해야만 도달할 수 있습니다. 그리고 적합한 팀원이 합류되기 위해서는 리더가 팀원의 성취에 진정한 관심과 케어가 동반되어야 합니다.
만들어진 관계는 조직의 운영보다 더 깊습니다.
관계는 사건보다 오래 지속됩니다. 비록 당장 이익관계에서 틀어진다 하더라도, 함께 좋은 일을 할 수 있는 기회가 올 수도 있다는 것을 명심하세요. 긍정적인 관점에서 서로를 기억하는 것은 항상 승리할 것입니다. 그리고 서로에게 훌륭하지 않고서는 함께 위대한 일을 할 수 없습니다.
전문가가 아닌, 항상 학생으로서 문제에 접근하기.
신선하고 호기심 많은 마음으로 문제에 접근해야 합니다. 질문을 하고, 메모를 하고,더 깊이 파고들고 계속 압박하여 가설을 수정하십시오. 학생의 사고방식은 당신의 두뇌를 객관적인 환경에 놓이게 합니다. 문제를 합리적으로 분석하고, 팀원과 효과적으로 협업하고, 적절한 솔루션을 만들 수 있는 보다 개방적인 형식으로 아이디어에 접근합니다. 이 모든 것이 "모든 것을 알고" 있어야 하는 스스로 유발하는 압력을 완화하는 것입니다.
’사기꾼 증후군'의 사기꾼은 조직이 아닌, 나 자신입니다.
동료들이 나보다 더 많이 알고 더 잘 실행한다고 가정하지만,
현실은 대부분의 사람들이 진행하면서 알아가는 실행착오를 격습니다. 다른 사람들이 전문적으로 나보다 우월하다는 선입견을 가질 때, 그들(그리고 자신)을 그렇게 대하기 시작하며, 이는 큰 착각입니다. 모두가 당신과 같은 학생이라는 것을 인식해야 합니다.
실패는 일어날 수 있는 가장 좋은 일입니다.
거의 해고당할 뻔했습니다. 높은 스트레스 상황에서 까다로운 고객을 관리하면서 내 기술을 넘어 도전적인 프로젝트에 참여했지만, 비참하게 실패했습니다. 이때 스스로의 약점을 알고 실패의 핑계가 아닌 성장의 원동력이 되었습니다. 실패는 앞으로 나아갈 방향을 결정해 줍니다.
조직은 개인이 그만둘 때까지 영역에 맞춰 넣을 것입니다.
경영진은 배를 조종하는 방법에 대한 비전을 가지고 있으며, 그 비전은 더 작은 조각으로 쪼개지고, 개인은 만들어진 조작 내에서만 실행할 수 있습니다. 조직은 궁극적으로 배를 조종할 것이기 때문에 개인을 그 영역 안에 두도록 장려합니다. 하지만 조직의 방향과 영역이 배움, 흥미가 있지 않다면 스스로를 가두지 말고 다른 다른 곳을 찾는 것은 우리의 몫입니다. 마음가짐, 동기 부여, 회복력이 있다면 실행해 보세요.
모든 것에 대한 해결책이 있습니다.
침착하세요. 패닉은 해결책이 아닙니다. 한 발 물러서서 논리에서 감정을 풀고 가능한 최선의 계획에 착수하십시오. 휴식도 답이 될 수 있습니다.
좋은 의도가 사람을 움직입니다. 정치가 아닙니다.
리더가 개인적인 이득을 위해 팀원들 인형극 부리듯 조종하는 것은 단기적으로 승리할 수 있지만 장기적인 성공은 관계를 기반해서 움직입니다. 조직의 성공은 맞는 팀원들과 함께해야만 도달할 수 있습니다. 그리고 적합한 팀원이 합류되기 위해서는 리더가 팀원의 성취에 진정한 관심과 케어가 동반되어야 합니다.
만들어진 관계는 조직의 운영보다 더 깊습니다.
관계는 사건보다 오래 지속됩니다. 비록 당장 이익관계에서 틀어진다 하더라도, 함께 좋은 일을 할 수 있는 기회가 올 수도 있다는 것을 명심하세요. 긍정적인 관점에서 서로를 기억하는 것은 항상 승리할 것입니다. 그리고 서로에게 훌륭하지 않고서는 함께 위대한 일을 할 수 없습니다.주니어
중니어
디자인 시스템 101 - 닐슨 노먼 그룹
Open
[워크 프로세스]
디자인 시스템
가이드
<디자인 시스템이란?>
- 중복성을 줄이고
- 다양한 페이지와 채널에서 공유된 언어와 시각적 일관성을 만들어
- 대규모로 디자인을 관리하기 위한 일련의 표준
UI 디자인
- UI 화면을 생성해야 하는 규모와 속도가 높아져
- 각 앱과 웹 사이트에는 수백 또는 수천 개의 페이지(또는 화면)가 필요
- 조직에서는 설계 작업을 간소화해야 할 절박한 필요성이 대두
디자인 시스템을 사용하는 이유
- 설계(및 개발) 작업을 신속하게 대규모로 생성하고 복제할 수 있다.
- 더 크고 복잡한 문제에 집중하기 위해 설계 리소스의 부담을 덜어준다.
- 교차 기능 팀 내에서 그리고 팀 간에 통합된 언어를 만든다.
- 제품, 채널 및 (잠재적으로 고립된) 부서 전반에 걸쳐 시각적 일관성을 만든다.
- 주니어 레벨 디자이너와 콘텐츠 기고가를 위한 교육 도구 및 참고 자료로 사용할 수 있다.
디자인 시스템을 사용하지 않는 이유는 무엇입니까? (잠재적인 장애물과 제한사항)
- 디자인 시스템을 만들고 유지 관리하는 것은 전담 팀이 필요한 시간 집약적인 활동이다.
- 디자인 시스템을 사용하는 방법을 다른 사람에게 가르치는 데는 시간이 걸린다.
- 프로젝트는 일반적으로 재사용 가능한 구성 요소가 필요하지 않은 정적인 일회성 생성이라는 인식이 있을 수 있다.
<디자인 시스템의 요소>
1. 디자인 저장소(repository)
2. 그것을 관리 하는 사람들
1. 디자인 저장소
- 스타일 가이드
- 일반적인 스타일 가이드는 브랜딩(색상, 타이포그래피, 상표, 로고 및 인쇄 매체)에 초점을 맞춤
- 콘텐츠( 목소리 및 언어 권장 사항 등)와 시각적 및 상호 작용 디자인 에 대한 지침도 제공
- 컴포넌트 라이브러리
- 구성 요소 이름
- 설명
- 속성
- 상태
- 코드 조각
- 프론트엔드 및 백엔드 프레임워크 (필요 시)
- 패턴 라이브러리
- 컴포넌트 라이브러리는 개별 UI 요소를 지정하는 반면, 패턴 라이브러리는 UI 요소 그룹화 또는 레이아웃 컬렉션을 제공
2. 디자인 시스템 팀
- 오래되거나 쓸모없거나 중복된 항목이나 제출로 인해 과밀화되지 않도록 지속적인 유지 관리와 감독이 필요
- 팀에는 최소한 1명의 인터랙션 디자이너, 1명의 비주얼 디자이너 및 1명의 개발자가 포함되어야 함
- 인터랙션 디자인 가이드라인을 만들고, 시각적 예제를 만들고, 각 요소에 대한 코드 스니펫과 구현 사양을 각각 제공
설계 시스템 노력을 조율하기 위해 경영진 후원자를 확보하는 것을 고려해야함
스폰서는 자금과 자원을 확보하는 동시에 나머지 조직에 디자인 시스템의 전략적 중요성을 전달할 수 있음
<디자인 시스템 채택에 접근하는 방법>
- 기존 디자인 시스템 채택
- 기존 디자인 시스템 적용
- 나만의 독점 또는 맞춤형 디자인 시스템 만들기
디자인 시스템 솔루션이 맞춤화될수록 구현하는 데 더 많은 시간과 비용이 소요
기존 설계 시스템을 사용하는 것이 가장 비용이 적게 드는 접근 방식
개념 증명(PoC)이나 변경될 가능성이 있는 초기 프로토타입의 경우
본격적인 설계 시스템을 만드는 것은 단기간에 원하는 ROI가 안 나옴
미래에 있을 디자인의 복제 가능성에 도움이 됨
디자인 시스템은 작업 포트폴리오로 생각해서는 안됨
디자이너와 개발자가 보다 빠르게 작업할 수 있는 기능적 툴킷 또는 리소스로 간주해야 함
디자인 시스템을 만들 때 고려해야 할 주요 요소
- 프로젝트의 규모와 복제 가능성
- 사용 가능한 리소스와 시간
제대로 구현 및 유지 관리하지 않으면 디자인 시스템이 구성 요소와 코드의 다루기 힘든 모음이 될 수 있음
그러나 잘 구현되면 팀 구성원을 교육하고 작업을 간소화하며 디자이너가 복잡한 UX 문제를 해결할 수 있음
기획자
SaaS 제품 담당자
B2B 앱 참여 및 마케팅 심리학
Open
[디자인]
UX
마케팅
심리학
B2B 앱이 해결하려는 문제가 복잡할 수는 있지만 솔루션이 복잡할 필요는 없습니다. 사용자는 프로덕트 팀이 마주하는 문제에 관심이 없습니다. 단지 앱이 단순한지, 그것이 문제 해결을 더 쉽게 만들어주는지를 알고자 합니다.
B2C 앱 디자인에 널리 사용되는 행동 경제학 및 마케팅 심리학을 사용하여 앱을 간소화하고 관여도를 높일 수 있습니다.
default 값 정의를 신중하게 하자
'넛지'라는 책은 사람들이 비합리적이라고 이야기합니다. B2B 앱 제작자는 사용자가 풍부한 복잡성을 뚫고 모든 일을 처리할 거라 가정하지만, '넛지'는 너무 많은 선택이 장애가 될 수 있다고 합니다. 책 저자들의 연구에 따르면 너무 많은 옵션이 제시되면 사람들은 선택을 시스템에게 맡깁니다.
프로덕트 팀은 기본 옵션을 변경하여 원하는 방향으로 "넛지"할 수 있습니다. 이것을 "선택 아키텍처"라고 합니다. 사용자 선택을 줄이며 결정하기까지 길을 안내하도록 인터페이스를 설계합니다.
게임 메커니즘 사용하기. Gamification
사람들이 비용을 지불하고 쌓아둔 마일리지의 대부분은 사용되지 않습니다. 기업은 사람들이 마일리지를 쌓는 성취 자체를 보상으로 여기고 이 게임을 좋아한다는걸 알고 있습니다.
행동경제학에서는 목표 달성에 가까워졌을 때 더 열심히 일할 동기가 생긴다는 말이 있습니다. 이는 결과가 사용자에게 특히 흥미롭지 않거나 사용자가 생산성 혁신을 달성하기까지 몇 달이 걸릴 수 있는 B2B 앱에서 특히 두드러집니다.
그 효과를 극대화하기 위해 프로덕트 팀은 '게임' 결과만 공개하면 됩니다. B2B에서 이것은 인증과 같은 보상을 제공하고 받는 사람에게 명성을 주는 것을 의미합니다. 이는 고급 사용자에게 상을 제공하고 컨퍼런스에서 연설하도록 초대하는 것을 의미합니다.
사회적 증거가 있는 가이드
나이트클럽에는 왜 항상 줄이 있는 것 같습니까? 꽤 의도적입니다. 클럽이 붐비는 것처럼 보이려고 경비원은 줄을 세웁니다. 버지니아 주 전기세 고지서에 이웃 주민들이 절약한 전력량을 표시하기 시작한 이후 30억 kw/h의 에너지가 절약되었습니다. B2B 제품 팀은 이러한 경향을 사용하여 사용자를 넛지할 수 있습니다.
예를 들어, 사용자에게 새로운 기능을 알릴 때 제품 팀은 다른 사람들이 그것을 시도하고 좋아했음을 알려야 합니다.
사회적 증거 예시 몇 가지:
- 총 고객 수 또는 비율
- 인식 가능한 브랜드의 이름 또는 로고
- 고객 만족도 또는 업계 전문가의 후기
- 인증 기관의 승인 마크
- 신뢰할 수 있는 출처의 연구 또는 통계
긍정적인 인상을 극대화하는 UX 디자인
많은 호텔이 최근들어 결제 절차를 바꾸고 있습니다. 마지막에 결제를 받는 대신 체크인 시 결제를 사전 승인합니다. 왜일까? 나쁜 느낌이 오래 지속된다는 '최신성 원칙'을 호텔이 배웠기 때문입니다.
행동 심리학자의 연구를 인용한 McKinsey는 "고객은 제품이나 서비스를 사용한 후 며칠, 몇 주, 몇 달이 지나면 고객 여정의 모든 개별적인 측면이 아니라 높은 지점과 낮은 지점을 불균형적으로 기억하는 경향이 있다"라고 썼습니다.
B2B 앱 디자이너에게 사용자 여정 순서를 변경할 수 있는 기회는 무한합니다. 제품 분석과 사용자 인터뷰를 혼합하여 사용자 여정에서 낮은 지점을 식별할 수 있습니다. 디자이너가 문제를 해결할 수 없다면 최소한 낮은 지점이 경험 중간에 발생하거나 고르게 퍼지도록 해야 합니다.
default 값 정의를 신중하게 하자
'넛지'라는 책은 사람들이 비합리적이라고 이야기합니다. B2B 앱 제작자는 사용자가 풍부한 복잡성을 뚫고 모든 일을 처리할 거라 가정하지만, '넛지'는 너무 많은 선택이 장애가 될 수 있다고 합니다. 책 저자들의 연구에 따르면 너무 많은 옵션이 제시되면 사람들은 선택을 시스템에게 맡깁니다.
프로덕트 팀은 기본 옵션을 변경하여 원하는 방향으로 "넛지"할 수 있습니다. 이것을 "선택 아키텍처"라고 합니다. 사용자 선택을 줄이며 결정하기까지 길을 안내하도록 인터페이스를 설계합니다.
게임 메커니즘 사용하기. Gamification
사람들이 비용을 지불하고 쌓아둔 마일리지의 대부분은 사용되지 않습니다. 기업은 사람들이 마일리지를 쌓는 성취 자체를 보상으로 여기고 이 게임을 좋아한다는걸 알고 있습니다.
행동경제학에서는 목표 달성에 가까워졌을 때 더 열심히 일할 동기가 생긴다는 말이 있습니다. 이는 결과가 사용자에게 특히 흥미롭지 않거나 사용자가 생산성 혁신을 달성하기까지 몇 달이 걸릴 수 있는 B2B 앱에서 특히 두드러집니다.
그 효과를 극대화하기 위해 프로덕트 팀은 '게임' 결과만 공개하면 됩니다. B2B에서 이것은 인증과 같은 보상을 제공하고 받는 사람에게 명성을 주는 것을 의미합니다. 이는 고급 사용자에게 상을 제공하고 컨퍼런스에서 연설하도록 초대하는 것을 의미합니다.
사회적 증거가 있는 가이드
나이트클럽에는 왜 항상 줄이 있는 것 같습니까? 꽤 의도적입니다. 클럽이 붐비는 것처럼 보이려고 경비원은 줄을 세웁니다. 버지니아 주 전기세 고지서에 이웃 주민들이 절약한 전력량을 표시하기 시작한 이후 30억 kw/h의 에너지가 절약되었습니다. B2B 제품 팀은 이러한 경향을 사용하여 사용자를 넛지할 수 있습니다.
예를 들어, 사용자에게 새로운 기능을 알릴 때 제품 팀은 다른 사람들이 그것을 시도하고 좋아했음을 알려야 합니다.
사회적 증거 예시 몇 가지:
- 총 고객 수 또는 비율
- 인식 가능한 브랜드의 이름 또는 로고
- 고객 만족도 또는 업계 전문가의 후기
- 인증 기관의 승인 마크
- 신뢰할 수 있는 출처의 연구 또는 통계
긍정적인 인상을 극대화하는 UX 디자인
많은 호텔이 최근들어 결제 절차를 바꾸고 있습니다. 마지막에 결제를 받는 대신 체크인 시 결제를 사전 승인합니다. 왜일까? 나쁜 느낌이 오래 지속된다는 '최신성 원칙'을 호텔이 배웠기 때문입니다.
행동 심리학자의 연구를 인용한 McKinsey는 "고객은 제품이나 서비스를 사용한 후 며칠, 몇 주, 몇 달이 지나면 고객 여정의 모든 개별적인 측면이 아니라 높은 지점과 낮은 지점을 불균형적으로 기억하는 경향이 있다"라고 썼습니다.
B2B 앱 디자이너에게 사용자 여정 순서를 변경할 수 있는 기회는 무한합니다. 제품 분석과 사용자 인터뷰를 혼합하여 사용자 여정에서 낮은 지점을 식별할 수 있습니다. 디자이너가 문제를 해결할 수 없다면 최소한 낮은 지점이 경험 중간에 발생하거나 고르게 퍼지도록 해야 합니다.신입
주니어
JTBD 프레임워크 제대로 이해하기
Open
[프로덕트 & 데이터 분석]
프레임워크
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 매트릭스를 그릴 수 있습니다
• 고객이 과업을 해결하기 위해 사용중인 솔루션의 기능이 과다하다면 덜 제공하는 것도 하나의 방법이될 수 있습니다
3. 고객의 과업(JTBD)는 오랜 시간에 걸쳐 안정적이게 되었다
• '부모가 자녀에게 삶의 교훈 물려주기' 과업은 인류만큼 오래된 과업입니다
• '출근길의 무료함 달래기'는 지역과 관계 없이 동일하게 적용되는 과업입니다
• Amazon은 '고객에게 가장 좋은 것을, 가장 저렴하게, 가장 편리하게 제공하는 것'을 과업으로 정의했기 때문에 이커머스 플랫폼 뿐 만 아니라 다양하게 비즈니스를 운영할 수 있습니다
4. 고객의 과업은 솔루션이나 기술과 무관하다
• 자신의 제품이 최적의 솔루션이 될 수 있도록 고객의 불편함과 니즈를 입맛대로 정의하고 싶은 욕구에 매몰되어서는 안됩니다
• 킥보드 대여 서비스가 해결하고자 하는 과업은 킥보드를 더 쉽게 빌리는 것이 아니라, 도심 속 이동을 더 편리하게 하는 것입니다
• 이미 고객은 현존하는 기술이나 자신만의 솔루션으로 해당 과업을 수행하고 있다는 것을 잊어서는 안됩니다
5. 제품의 성공은 제품이나 고객에 대한 분석이 아닌 고객 과업의 단위 분석(Unit Analysis)에서 창출된다
• 고객은 자신의 과업에 대해서는 알고 있지만, 그 과업의 최적 솔루션에 대해서는 모르기 때문입니다
• 헨리 포드가 '고객에게 무엇이 필요한지 묻는다면, 그들은 더 빠르고 지치지 않는 말이 필요하다고 답할 뿐이다'고 한 말과 일맥 상통합니다
• 고객의 과업은 시작과 끝이 존재하는 프로세스 형태로, 대여섯 가지에서 많게는 20~30개의 단위 과업으로 이루어져 있습니다
• 각 단위 과업 중 어떤 부분이 병목이며, 예측이 불가능 하고 비효율이 발생하는지에 대해 학습 해야합니다
7. 과업을 정의함으로서 니즈 해결의 성공을 측정할 수 있는 측정 지표로 활용 가능하다
1) 고객이 과업 수행에서 진정으로 원하는 Desired Outcome을 정의합니다
2) 이를 달성하기 위한 측정 지표와 기준값을 정의합니다
3) 이 기준값을 달성할 수 있도록 제품을 개발하고 마케팅을 수행합니다
• Desired Outcome: '중고 아이폰을 제 값에 빠르게 판매하기'
• 측정 지표와 기준값: 제 값 = 60만원+, 빠르게 = 7일-
• 달성 방법: 물건을 먼저 수령해 위탁 판매하고, 판매 고객에게는 최소 가격을 보증한다
8. 사람들은 과업을 더 잘 수행하거나, 더 저렴하게 수행할 수 있는 제품이나 서비스를 원한다
• 과업을 더 잘 / 덜 잘 수행한다, 가격을 더 많이 / 더 저렴하게 제공한다 두 축으로 2x2 매트릭스를 그릴 수 있습니다
• 고객이 과업을 해결하기 위해 사용중인 솔루션의 기능이 과다하다면 덜 제공하는 것도 하나의 방법이될 수 있습니다중니어
시니어
A/B테스트는 죽었다
Open
[프로덕트 & 데이터 분석]
프로덕트 전략
지표
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를 고려하면 한 사람이 다른 사람보다 더 높은 지표를 가질 가능성이 더 높은지 여부를 알 수 없습니다.
참신 효과
고객을 대면하는 새로운 기능에는 자연스럽게 관심이 있고 경쟁자 반응 효과가 있을 수 있습니다. 하지만 참신함은 클릭을 생성한 다음 사라집니다. 결국 새 기능은 "표준”이 되고 영향은 줄어들 것입니다. 일부 시스템에서는 최종 결과만 중요합니다
너무많은 A/B 테스트 실행 중
실험은 대부분 상호 배타적으로 간주되므로 모집단이 겹칩니다. 실제로 대부분의 트래픽 분할은 일부 상호 배제와 함께 인구의 일부에서 수행되며, 불행히도 실험은 가장 충성도가 높은 사용자에서 훨씬 더 나은 성능을 보였습니다.
부정확한 측정항목
A/B 실험을 통해 그룹의 주문 수를 $5.5로 성공적으로 증가시켰습니다. 하지만 동시에 낮은 그룹에 대한 유지율은 48%로 떨어졌지만 이를 모니터링하지 않았습니다…이처럼 리텐션은 복합적인 지표입니다. 이처럼 장기 트래킹이 필요한 항목에 대한 A/B 테스팅은 관찰하기 어렵습니다.
범용적 결과
A/B 테스팅은 모든 방법론이 승자입니다. 프로덕트 특징에 맞춰 평가 되지 않습니다. 결과 대해 어떤 동작으로 이뤄졌는지 제공하지 않습니다.
인사이트 부족
버전 A가 B보다 전환율이 더 좋다는 것을 알게 되었습니다. 하지만 이것은 핵심 학습이 아닙니다! 개별적인 사용자, 실험한 버전에 대한 인사이트를 주지 않습니다. A/B 테스트는 개별 인과 관계 알고리즘이 아닙니다. 단지 현재 상황을 감안할 때 변이가 모집단에서 평균적으로 더 낫다는 것을 알려줍니다. 즉, 개인 X_i와 X_j를 고려하면 한 사람이 다른 사람보다 더 높은 지표를 가질 가능성이 더 높은지 여부를 알 수 없습니다.주니어
중니어
많은 SaaS 회사가 미디어를 자체적으로 운영 하고있는 이유
Open
[프로덕트 & 데이터 분석]
마케팅
실 사례
콘텐츠가 비즈니스와 마케팅 분야에도 엄청난 잠재력을 가지고 있다는 점이 증명되고 있습니다.
특히 지난 몇 년간 Salesforce, Hubspot, Shopify와 같은 SaaS 기업들이 미디어 회사처럼 움직이기 시작하면서 콘텐츠 마케팅은 한 단계 도약하고 있습니다.
Salesforce
지난 해 세일즈 포스는 대규모의 콘텐츠 투자를 발표하면서 할리우드 스타일의 콘텐츠 스튜디오를 만들었습니다.
B2B 고객 유치라는 궁극적인 목표를 가지고 고품질의 콘텐츠를 말들기 위함이었죠.
Hubspot
다양한 마케팅 솔루션을 제공하는 Hubspot은 뉴스레터, 팟캐스트 등을 운영하는 미디어 The Hustle을 330억에 인수했습니다.
Shopify
디스커버리 채널과 함께 Shopify's Studio라는 미디어 회사를 설립하여 I Quit라는 프로그램을 제작했습니다.
회사를 시작하기 위해 직장을 그만둔 기업가들에게 초점을 맞춘 예능 프로그램이었습니다.
위와 같은 테크 기반의 B2B SaaS 회사들이 콘텐츠에 투자하는 이유는, 하이엔드 테크놀로지의 가치를 고객에게 제대로 전달하기 위해서입니다.
기술이 충분히 발전했고 훌륭한 프로덕트도 넘치는 상황에서 그 가치를 제대로 전달할 양질의 콘텐츠는 턱없이 부족한 상황입니다.
제품과 서비스를 제대로 알리기 위해선, 그리고 고객의 재방문을 위해선 콘텐츠에 대한 투자가 필요합니다.
또한 테크 회사들은 이미 훌륭한 제품과 서비스를 통해 충분한 고객을 확보하고 있기 때문에,
양질의 콘텐츠에 투자할 여력까지 가지고 있습니다.
이러한 콘텐츠의 유형으로는 회사의 제품과 기술에 대한 교육자료나
회사의 흥미로운 이야기에 초점을 맞춘 다큐멘터리 형식의 프로그램 등이 있습니다.
다만 콘텐츠 마케팅을 구축 및 그 이점을 확인하는데에는 시간이 걸리고
콘텐츠의 지속적인 생산 역시 필요하다는 점을 염두에 두어야 합니다.
Salesforce
지난 해 세일즈 포스는 대규모의 콘텐츠 투자를 발표하면서 할리우드 스타일의 콘텐츠 스튜디오를 만들었습니다.
B2B 고객 유치라는 궁극적인 목표를 가지고 고품질의 콘텐츠를 말들기 위함이었죠.
Hubspot
다양한 마케팅 솔루션을 제공하는 Hubspot은 뉴스레터, 팟캐스트 등을 운영하는 미디어 The Hustle을 330억에 인수했습니다.
Shopify
디스커버리 채널과 함께 Shopify's Studio라는 미디어 회사를 설립하여 I Quit라는 프로그램을 제작했습니다.
회사를 시작하기 위해 직장을 그만둔 기업가들에게 초점을 맞춘 예능 프로그램이었습니다.
위와 같은 테크 기반의 B2B SaaS 회사들이 콘텐츠에 투자하는 이유는, 하이엔드 테크놀로지의 가치를 고객에게 제대로 전달하기 위해서입니다.
기술이 충분히 발전했고 훌륭한 프로덕트도 넘치는 상황에서 그 가치를 제대로 전달할 양질의 콘텐츠는 턱없이 부족한 상황입니다.
제품과 서비스를 제대로 알리기 위해선, 그리고 고객의 재방문을 위해선 콘텐츠에 대한 투자가 필요합니다.
또한 테크 회사들은 이미 훌륭한 제품과 서비스를 통해 충분한 고객을 확보하고 있기 때문에,
양질의 콘텐츠에 투자할 여력까지 가지고 있습니다.
이러한 콘텐츠의 유형으로는 회사의 제품과 기술에 대한 교육자료나
회사의 흥미로운 이야기에 초점을 맞춘 다큐멘터리 형식의 프로그램 등이 있습니다.
다만 콘텐츠 마케팅을 구축 및 그 이점을 확인하는데에는 시간이 걸리고
콘텐츠의 지속적인 생산 역시 필요하다는 점을 염두에 두어야 합니다.주니어
디자이너에서 매니저로 성장하기
Open
[성장의 피땀눈물]
PM/PO
마인드셋
직무 분석
이 아티클은 디자인 관리라는 커리어가 적절한 선택인지에 대한 판단을 돕고, 그 여정을 시작하겠다면 성공적인 길이 무엇일지를 설명합니다. 성공을 위한 방법 결정에 도움이 되는 핵심 프레임워크와 질문을 참고해보세요.
훌륭한 매니저의 자질
전략가로서 디자인 리딩하기
팀의 목표 및 핵심 결과(OKR)을 개발하고 추적하는 일을 담당합니다. 디자인팀 OKR은 팀 내부로만 한정짓지 않고 타 팀, 회사 전체의 성과를 바라보도록 설계할 수도 있습니다.
운영자로서 팀을 원활하게 운영하고 만족스러운지 확인하기
운영자의 역할은 효과적인 프로세스를 구현하여 팀 문화와 참여를 구축하고, 우수한 디자이너를 모집 및 고용하고, 팀 성과를 관리하는 것입니다. 또한 팀에 별일이 없게끔 하고, 안정감을 느끼도록 하며 긍정적인 환경을 만들 책임이 있습니다.
코치로서 팀원을 성장시키기
마지막으로 매니저는 팀원들에게 성장과 개발 기회를 제공해야 합니다. 1 on 1은 매니저에게 가장 중요한 무기입니다. 팀원과의 관계를 구축하고, 만족하는지 확인하고, 장애물을 제거할 수 있는지 알아보고, 경력 개발을 도웁니다.
그러한 자질을 개발하기 위해 연마할 기술
매니저가 되는데 가장 큰 어려움 중 하나는 위의 3가지 역할에 적절한 비중을 두고 유연하게 대처하는 것입니다. 순간순간 회사가 무엇을 필요로 하는지에 따라 주요 책임이 달라집니다.
스킬 측면에서는 아래와 같은 기술을 익혀야 합니다.
커뮤니케이션: 팀원에게는 탑다운, 동료 매니저와는 수평적으로, 임원과는 바텀업 식으로 하는 등 실무자일 때 경험하지 못한 다양한 커뮤니케이션 전략이 필요
팀원 코칭 및 성장 지도
위임 및 기대치 설정
인재 평가, 채용
자율적으로 프로젝트를 주도: 비즈니스의 핵심 요구 사항을 해결하는 자체 프로젝트를 관리하거나 생성하여 주도권을 잡습니다.
디자이너에서 매니저로의 커리어 전환에 대한 잘못된 통념과 반박
① 예전 직무로 되돌아갈 수 없다?
매우 일반적인 통념인데 사실이 아니며 역효과를 낳는 이야기입니다. Tech Managing 분야에는 충분한 교육, 지원에 대한 수요와 공급이 넘쳐납니다. 글쓴이는 커리어상에서 매니저와 실무 디자이너 직무를 오갔습니다.
② 매니저는 인적 자원을 서포트하는 역할이다?
다른 사람들을 지원하는 것은 매니저 업무 범위에서 빙산의 일각에 불과합니다. 운영, 관리 책임도 있습니다. 코칭이 매니저의 유일한 업무가 아닙니다.
③ 경력을 쌓으려면 매니저가 되어야 한다?
일부 회사에 해당될 수는 있지만 전부는 아닙니다. 많은 회사가 실무 디자이너의 연차가 쌓여도 개인으로서 활약하는 기여도를 유지하면서 매니저와 같은 수준에서 보상을 받고 영향력을 갖는 방법을 마련합니다. 예를 들어 Webflow라는 회사에서 수석 디자이너와 시니어 매니저는 동일한 등급이며 유사한 보상 및 영향력을 부여받습니다.
④ 디자인 매니저는 팀에서 최고의 디자이너다?
이것은 사실이 아닐 뿐더러 그렇게 되어서도 안됩니다. 직원의 작업을 평가하고 비판하기 위해 디자이너로서의 핵심 기술을 끌어내야 하지만, 그렇다고 해서 팀에서 최고의 디자이너가 되어야 하는 것은 아닙니다. NBA 역사상 최고의 코치 중 일부는 명예의 전당 선수가 아니었습니다.
⑤ 디자인 매니저는 더 이상 디자인 실무에 신경쓰지 않는다?
매니저로서 픽셀 하나하나에 덜 관여하는 것이 사실일 수도 있지만 결국 팀이 만드는 모든 산출물에 대한 책임은 매니저에게 있습니다. 디자인 매니저가 하는 일에는 팀원을 지도하고 디자이너로서 성장하도록 돕는 것입니다. 제품 설계 및 디자인에 쓰이는 프레임워크는 팀원들에게 모델 역할을 합니다.
훌륭한 매니저의 자질
전략가로서 디자인 리딩하기
팀의 목표 및 핵심 결과(OKR)을 개발하고 추적하는 일을 담당합니다. 디자인팀 OKR은 팀 내부로만 한정짓지 않고 타 팀, 회사 전체의 성과를 바라보도록 설계할 수도 있습니다.
운영자로서 팀을 원활하게 운영하고 만족스러운지 확인하기
운영자의 역할은 효과적인 프로세스를 구현하여 팀 문화와 참여를 구축하고, 우수한 디자이너를 모집 및 고용하고, 팀 성과를 관리하는 것입니다. 또한 팀에 별일이 없게끔 하고, 안정감을 느끼도록 하며 긍정적인 환경을 만들 책임이 있습니다.
코치로서 팀원을 성장시키기
마지막으로 매니저는 팀원들에게 성장과 개발 기회를 제공해야 합니다. 1 on 1은 매니저에게 가장 중요한 무기입니다. 팀원과의 관계를 구축하고, 만족하는지 확인하고, 장애물을 제거할 수 있는지 알아보고, 경력 개발을 도웁니다.
그러한 자질을 개발하기 위해 연마할 기술
매니저가 되는데 가장 큰 어려움 중 하나는 위의 3가지 역할에 적절한 비중을 두고 유연하게 대처하는 것입니다. 순간순간 회사가 무엇을 필요로 하는지에 따라 주요 책임이 달라집니다.
스킬 측면에서는 아래와 같은 기술을 익혀야 합니다.
커뮤니케이션: 팀원에게는 탑다운, 동료 매니저와는 수평적으로, 임원과는 바텀업 식으로 하는 등 실무자일 때 경험하지 못한 다양한 커뮤니케이션 전략이 필요
팀원 코칭 및 성장 지도
위임 및 기대치 설정
인재 평가, 채용
자율적으로 프로젝트를 주도: 비즈니스의 핵심 요구 사항을 해결하는 자체 프로젝트를 관리하거나 생성하여 주도권을 잡습니다.
디자이너에서 매니저로의 커리어 전환에 대한 잘못된 통념과 반박
① 예전 직무로 되돌아갈 수 없다?
매우 일반적인 통념인데 사실이 아니며 역효과를 낳는 이야기입니다. Tech Managing 분야에는 충분한 교육, 지원에 대한 수요와 공급이 넘쳐납니다. 글쓴이는 커리어상에서 매니저와 실무 디자이너 직무를 오갔습니다.
② 매니저는 인적 자원을 서포트하는 역할이다?
다른 사람들을 지원하는 것은 매니저 업무 범위에서 빙산의 일각에 불과합니다. 운영, 관리 책임도 있습니다. 코칭이 매니저의 유일한 업무가 아닙니다.
③ 경력을 쌓으려면 매니저가 되어야 한다?
일부 회사에 해당될 수는 있지만 전부는 아닙니다. 많은 회사가 실무 디자이너의 연차가 쌓여도 개인으로서 활약하는 기여도를 유지하면서 매니저와 같은 수준에서 보상을 받고 영향력을 갖는 방법을 마련합니다. 예를 들어 Webflow라는 회사에서 수석 디자이너와 시니어 매니저는 동일한 등급이며 유사한 보상 및 영향력을 부여받습니다.
④ 디자인 매니저는 팀에서 최고의 디자이너다?
이것은 사실이 아닐 뿐더러 그렇게 되어서도 안됩니다. 직원의 작업을 평가하고 비판하기 위해 디자이너로서의 핵심 기술을 끌어내야 하지만, 그렇다고 해서 팀에서 최고의 디자이너가 되어야 하는 것은 아닙니다. NBA 역사상 최고의 코치 중 일부는 명예의 전당 선수가 아니었습니다.
⑤ 디자인 매니저는 더 이상 디자인 실무에 신경쓰지 않는다?
매니저로서 픽셀 하나하나에 덜 관여하는 것이 사실일 수도 있지만 결국 팀이 만드는 모든 산출물에 대한 책임은 매니저에게 있습니다. 디자인 매니저가 하는 일에는 팀원을 지도하고 디자이너로서 성장하도록 돕는 것입니다. 제품 설계 및 디자인에 쓰이는 프레임워크는 팀원들에게 모델 역할을 합니다.신입
주니어
PM의 시간 다루기 : 로드맵, 타임라인, 릴리즈 플랜
Open
[성장의 피땀눈물]
PM/PO
마인드셋
직무 분석
PM의 능력은 시간을 얼마나 잘 다루느냐에 달려있습니다.
PM은 단순히 시작과 끝을 지정하고 관리하는 것이 아닌
① 시간 단위를 연결해야 하고
② 사용자의 시간에 맞추어서 프로덕트 동작이 다채로워야 하며
③ 고객이 원하는 시간에 딜러버리를 해야 하고
④ 로드맵이란 큰 마일스톤에 따라 잘 분배해야 합니다.
PM의 시간 - 정의
1) 로드맵
- 기업, 조직 또는 제품이 달성하고자 하는 전략을 기본으로 그 목표를 설명하는 문서입니다.(≠딜리버리 플랜)
- 로드맵은 타임라인이 정해져 있지 않은, 목표를 주관적이고 정성적으로 적어놓은 것입니다.
- 로드맵은 프로덕트의 성공의 기회를 만드는 시간에 생성됩니다.
2) 타임라인(≠타이밍_무언가를 결정하는 전략적 순간)
- 시작 날짜와 종료 날짜가 포함된 시간순으로 정렬된 이벤트의 시각적/물리적 순서입니다.
3) 프로덕트 사이클(=프로덕트 라이프 사이클, 프로덕트 개발 사이클)
- 아이디어를 내는 순간에서 릴리즈, 유지보수를 하고, 다시 새 버전을 위해 새로운 루프가 시작되는 것을 의미합니다.
- 프로젝트가 끝나더라도 프로덕트 라이프 사이클이 계속되는 한 프로덕트는 존속할 수 있습니다.
4) 데드라인(=Due Date)
- 프로젝트 또는 이벤트의 마감일입니다.
PM의 시간 - 로드맵과 타임라인의 조화
- 로드맵은 프로덕트 전략을 기반으로 달성해야 할 목표를 우선순위를 나누어 작성한 것이며, 타임라인을 기반으로 하지 않습니다.
- 하지만 사용자, 고객, 회사의 경영진은 목표의 달성 시점(시간)이 들어가야 비로소 관심을 보입니다.
- 따라서 로드맵은 방향, 의도 및 의사소통의 역할을 하는 동시에 전략적 목적을 위해 충족되어야 하는 타임라인과 데드라인을 포함해야 합니다.
로드맵, 타임라인, 릴리즈 플랜의 관계
- 아무리 훌륭한 로드맵이더라도 타임 팩터가 들어가 있지 않다면, 생명력이나 전달력이 부족해집니다.
- PM은 훌륭한 커뮤니케이터로써 지속적으로 투명성을 공유하는 것이 성공의 핵심입니다.
- 타임라인은 그 자체로는 어떤 의미도 없습니다.
- 타임라인은 우선순위 그룹과 만나야 하고 우선 순위를 정의한 로드맵은 시작일과 종료일을 제시한 타임라인과 만나야 합니다.
- 로드맵에 따른 기능을 정리하고 그 우선순위를 그룹화한 후 타임라인으로 나누면, 릴리즈 플랜을 만들어 출시 계획을 경영진, 고객 또는 사용자들과 소통할 수 있습니다.
PM의 시간 - 정의
1) 로드맵
- 기업, 조직 또는 제품이 달성하고자 하는 전략을 기본으로 그 목표를 설명하는 문서입니다.(≠딜리버리 플랜)
- 로드맵은 타임라인이 정해져 있지 않은, 목표를 주관적이고 정성적으로 적어놓은 것입니다.
- 로드맵은 프로덕트의 성공의 기회를 만드는 시간에 생성됩니다.
2) 타임라인(≠타이밍_무언가를 결정하는 전략적 순간)
- 시작 날짜와 종료 날짜가 포함된 시간순으로 정렬된 이벤트의 시각적/물리적 순서입니다.
3) 프로덕트 사이클(=프로덕트 라이프 사이클, 프로덕트 개발 사이클)
- 아이디어를 내는 순간에서 릴리즈, 유지보수를 하고, 다시 새 버전을 위해 새로운 루프가 시작되는 것을 의미합니다.
- 프로젝트가 끝나더라도 프로덕트 라이프 사이클이 계속되는 한 프로덕트는 존속할 수 있습니다.
4) 데드라인(=Due Date)
- 프로젝트 또는 이벤트의 마감일입니다.
PM의 시간 - 로드맵과 타임라인의 조화
- 로드맵은 프로덕트 전략을 기반으로 달성해야 할 목표를 우선순위를 나누어 작성한 것이며, 타임라인을 기반으로 하지 않습니다.
- 하지만 사용자, 고객, 회사의 경영진은 목표의 달성 시점(시간)이 들어가야 비로소 관심을 보입니다.
- 따라서 로드맵은 방향, 의도 및 의사소통의 역할을 하는 동시에 전략적 목적을 위해 충족되어야 하는 타임라인과 데드라인을 포함해야 합니다.
로드맵, 타임라인, 릴리즈 플랜의 관계
- 아무리 훌륭한 로드맵이더라도 타임 팩터가 들어가 있지 않다면, 생명력이나 전달력이 부족해집니다.
- PM은 훌륭한 커뮤니케이터로써 지속적으로 투명성을 공유하는 것이 성공의 핵심입니다.
- 타임라인은 그 자체로는 어떤 의미도 없습니다.
- 타임라인은 우선순위 그룹과 만나야 하고 우선 순위를 정의한 로드맵은 시작일과 종료일을 제시한 타임라인과 만나야 합니다.
- 로드맵에 따른 기능을 정리하고 그 우선순위를 그룹화한 후 타임라인으로 나누면, 릴리즈 플랜을 만들어 출시 계획을 경영진, 고객 또는 사용자들과 소통할 수 있습니다.주니어
UX 설계 문서 작성이 필요한 이유
Open
[워크 프로세스]
UX
문서 작성법
많은 팀에서 "지금은 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가지 우선 순위 정하기 기법
Open
[성장의 피땀눈물]
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에게 업무 중 가장 어려운 부분이 무엇이냐고 물으면 압도적으로 차지하는 대답은 "실제 시장의 피드백이 부족한 상태에서 로드맵에 따른 백로그의 우선순위를 지정" 하는 것이라고 합니다.
백로그 작업의 우선순위를 정하는 것은 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가지
Open
[성장의 피땀눈물]
마인드셋
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의 첫걸음
Open
[성장의 피땀눈물]
PM/PO
마인드셋
경험 공유
일하는 방법
[성장을 위한 데일리 아티클] '야근하지 않는 디자이너'
디자이너에게 요구되는 직무적 역할이 늘어나고 있는 요즘, 나를 포함한 많은 디자이너들은 처리해야 할 업무들에 둘러쌓여 있는 상태다. 나의 일을 효율적으로 처리하기 위해서는 똑똑하게 일하는 방법을 알아야 한다.
내가 야근을 했다는 것은 내가 효율적으로 일을 처리하고 있지 못하다는 뜻이다. 구조적으로 업무량에 비해 디자이너 리소스가 부족한 경우를 제외하고, 내가 가진 리소스로 내가 맡은 업무를 처리할 수 있다면 내가 야근하게 되는 이유는 아래와 같은 이유들로 발생하게 된다(이외에도 여러 이유가 있을 수 있지만 원 글의 내용을 기반으로 합니다).
1. 내가 가진 업무에 대해 제대로 파악하지 못했다
2. 일의 우선순위를 제대로 세우지 못했다
3. 작업 방향을 잘못 잡았거나 완성도에 집착하다 마감 기한을 놓친다
4. 물리적인 업무 시간 중 이미 시간을 배정해둔 협업 시간들을 유의미하게 보내지 못했다
이 중 1, 2, 3은 업무 효율성을 높이기 위한 순서이자 방법이다.
[1. 내가 가진 업무에 대해 제대로 파악하지 못했다]
나의 시간을 효율적으로 배분하고 어떤 일을 먼저 집중해서 처리해야 하는지 아는 것은 내가 가진 업무가 무엇인지, 왜 그 일을 해야하는지를 파악하는 것으로부터 시작한다. 업무를 완료하면 어떤것이 더 나아지는가? 누구를 위한 작업인가? 작업을 완료하기 위해서는 어떤 리소스가 필요한가? 작업을 완료하기 위해서는 어떤 일들을 해야 하는가?
[2. 일의 우선순위를 제대로 세우지 못했다]
각 업무를 왜 해야하는지를 알면 우선순위를 세울 수 있다. 다른 팀 지원 업무, 쉽게 끝낼 수 있는 일이지만 중요하진 않은 업무, 내부 회의에서만 쓰고 실제 프로덕트로 개발되지 않을 장표들의 경우 우선순위를 낮게 가져갸야 한다. 내 업무시간은 나의 팀의 목표에 맞고, 고객에게 더 중요한 일이며, 시간이 많이 필요하더라도 꼭 달성해야하는 어떤 것이다.
[3. 작업 방향을 잘못 잡았거나 완성도에 집착하다 마감 기한을 놓친다]
주로 주니어에게서 많이 발견되기도 하는 이 문제는 시간이 오래 걸리는 일이거나 아직 익숙하지 않은 일 일수록 쉽게 발생할 수 있는 문제이다. 내 상관이 원하는 방향은 이미 있는데 그것을 제대로 파악하지 못하고 잘못된 방향으로 일하고 있다거나, 중요하지 않은 디테일을 먼저 신경써서는 안된다. 전체적인 얼개를 그려 드래프트를 자주 공유해 방향을 자주 점검하고, 큰 줄기에서 작은 줄기, 마지막 디테일 순으로 작업해야 진짜 중요한 작업을 놓치지 않을 수 있다.
[4. 물리적인 업무 시간 중 이미 시간을 배정해둔 협업 시간들을 유의미하게 보내지 못했다]
스크럼, 회고, 의사결정을 위한 회의 등 다른 사람들과 협업하기 위한 시간은 고정되어있고, 여러 사람의 시간을 동시에 사용하기 때문에 더욱 귀중하게 쓰여야 한다. 회의 어젠다는 참석자에게 전달하고 수렴하고 싶은 내용이 확실하게 정해져야 한다. 이를 위해 주도적으로 회의를 준비해보는 것도 도움이 되겠다.중니어
시니어
PM을 위한 API 해설
Open
[성장의 피땀눈물]
마인드셋
직무 분석
커뮤니케이션
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 용어로 그것은 서비스를 사용할 수 없거나 게이트웨이 시간 초과를 의미합니다.
인증 (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 용어로 그것은 서비스를 사용할 수 없거나 게이트웨이 시간 초과를 의미합니다.주니어
중니어
Load more