신입 PM이 너무 강해짐 -(5)
1-Pager. PM의 무기
이번 화는 조금 길게 느껴질 수 있어요.
하지만 걱정 마세요! 1편부터 4편까지의 내용을 정리하면서,
1-Pager라는 개념에 대해 함께 이야기 나눌 예정이에요.
오늘 다룰 주제들은 신입 PM 여러분이 실행했을 때 정말 유익한 내용들이고,
앞으로의 경험을 통해 각자에게 맞는 버전을 만들어갈 출발점이 될 거예요.
함께 멋진 시작을 해봐요!
2화에서 우리는 "그래서 고객의 문제가 해결되었나요?" 라는 주제로 이야기를 나누었습니다.
어떤 고객의 문제인가요?
고객의 문제는 무엇인가요?
다른 서비스는 그런 고객의 문제를 어떻게 풀고 있나요?
그렇다면 우리는 어떻게 풀어보면 좋을까요?
고객의 문제가 해결되었나요?
1-Pager는 위의 5가지 질문에 대한 우리의 가설을 간결하고 논리있게 전달하는 소통의 수단 입니다.
1-Pager는 소통의 수단
제가 정말 가장 많이 강조하고 중요하게 생각하는 부분입니다. 소통이 빠진 1-Pager는 얼음과 커피 빠진 아이스 아메리카노 같아요. 실제로 고객의 문제를 이해하고 해결하기 위해서는 다양한 전문가들과의 협업이 필수적이며, 효과적인 협업을 위해서는 서로 원활하게 소통하며 공통된 목표를 바라봐야 합니다.
1-Pager는 이러한 소통의 중심에 있는 유용한 도구입니다.
1-Pager 목차
1. Target Customer(대상 고객)
2. Observation(현상)
3. Problem Statement(문제)
4. Jobs to be done(JTBD)
5. Benchmarks(벤치마크)
6. Hypothesis(가설)
7. Success Metrics(성공 지표)
8. High Level User Story(해당 가설을 맞이한 고객이 어떻게 행동하는가)
9. Information Flow(어떤 정보들이 고객에게 전달되어야 하는가)
10. Low-fidelity wireframe(러프한 와이어프레임. 화이트보드 손그림도 OK)
11. High-fidelity wireframe(UX 디자인 완성본)
12. User Story & Acceptance Criteria(개발 들어갈 수 있을 정도의 상세한 스토리와 만족 조건들)
모든 목차를 한번에 다 채워서 전달하는 문서가 아니에요
1-Pager는 소통의 수단 입니다. 1번부터 12번까지 다 채운 다음에 누군가에게 전달 한다면, 소통이 아닌 Top-Down 지시가 되어버리고 서로의 의견이 초반부터 나뉘지 못해 공감대 형성이 어렵게 됩니다.
PM은 제품의 성공을 위해 다양한 팀원들과 협력하는 역할을 수행합니다. “Manager”라는 단어 때문에 오해가 있을 수 있지만, PM의 주요 임무는 정답을 준비해서 팀을 이끄는 것이 아닌, 제품을 성공적으로 관리하고 발전시키기 위한 정답들을 팀과 함께 만들어가기 위해 소통을 원활히 하는 데 있습니다.
PM이 “내가 PM이니까 제품에 대한 방향성과 의사결정은 내가 해야 해. 반대 의견이 있더라도 내가 제안한 방향대로 가야 해. 내가 PM인데 왜 자꾸 반대하지?“라는 마음을 가지면, 팀원들의 창의성과 다양성을 억압하게 됩니다. 이는 제품의 질을 저하시키고, 팀의 사기를 떨어뜨리며, 궁극적으로는 프로젝트의 성공 가능성을 낮춥니다.
반면에, PM이 팀원들의 다양한 의견을 경청하고, 이를 바탕으로 더 나은 해결책을 찾으려는 태도를 취한다면, 팀은 더욱 협력적으로 변할 것입니다. 예를 들어, 개발자가 특정 기술적 제약을 지적하거나, 디자이너가 사용자 경험 측면에서 개선점을 제안할 때, PM은 이를 적극적으로 받아들이고 논의해야 합니다. 이러한 과정에서 모든 팀원이 프로젝트의 일원이자 기여자라는 느낌을 받게 되며, 이는 팀의 응집력과 동기 부여를 강화합니다.
또한, PM은 회복탄력성을 가져야 합니다. 프로젝트가 진행되면서 예상치 못한 문제나 장애물에 부딪히게 되는데, 이때 PM은 유연하게 대처하고, 팀원들과 협력하여 해결책을 찾아야 합니다. 예를 들어, 시장 상황이 변화하거나 고객 요구가 달라질 때, PM은 이를 빠르게 파악하고 팀과 함께 전략을 조정해야 합니다.
따라서 PM은 단순히 지시를 내리는 관리자가 아니라, 팀의 의견을 조율하고, 함께 최선의 해결책을 찾아가는 리더입니다. 겸손하게 팀원들의 의견을 수용하고, 더 나은 방향을 함께 모색하는 자세가 중요합니다. 이렇게 할 때, PM은 팀의 신뢰와 존경을 얻을 수 있으며, 제품의 성공 가능성을 극대화할 수 있습니다.
언제 어떤 소통을?
1-Pager는 크게 두 단계로 나눠볼 수 있어요.
1번부터 7번: 어떤 문제를 어떤 가설로 풀고자 하는지에 대한 논리적인 소통
8번부터 12번: 가설을 어떻게 구현할지에 대한 세부적인 소통
첫 번째 단계는 프로젝트의 방향과 목표를 설정하는 데 중점을 둡니다. 대상 고객을 정의하고, 현상을 관찰하며, 문제를 명확히 진술하고, 이를 해결하기 위한 JTBD(Job to be Done)를 설정합니다. 이어서 벤치마크를 통해 비교 기준을 정하고, 가설을 수립하여 성공 지표를 통해 목표 달성 여부를 판단합니다.
두 번째 단계는 이러한 가설을 실제로 어떻게 구현할 것인지에 대한 세부적인 계획입니다. High Level User Story를 통해 고객이 가설에 어떻게 반응할지 예측하고, 정보 흐름을 정리하여 필요한 정보가 고객에게 적시에 전달되도록 합니다. Low-fidelity wireframe은 초기 아이디어를 시각화한 것으로, 러프한 형태로 팀과 공유하여 피드백을 받습니다. High-fidelity wireframe은 최종 UX 디자인으로, 구현 가능한 수준까지 구체화된 것입니다. 마지막으로, User Story와 Acceptance Criteria를 상세히 작성하여 개발팀이 이를 기준으로 작업을 진행할 수 있도록 합니다.
논리적인 소통
Target Customer, Observation, Problem Statement
우리는 신입 PM이 너무 강해짐 2편에서 현상과 문제에 대해 알아봤습니다.
그리고 3편에서는 Jobs to be done에 대해 다루었고, 4편에서는 Benchmark와 Hypothesis에 대해 이야기했습니다.
이 모든 과정은 1-Pager를 잘 작성하기 위한 준비 단계였습니다. 2편, 3편, 4편에서 나누었던 내용들을 되짚어 보며, 1-Pager 첫 단계를 잘 작성한다면 여러분은 PM이 생각하는 문제 해결 방안에 대해 논리적으로 소통할 준비가 된 것입니다. 현상과 문제, Jobs to be done을 기반으로 소통하지 않은 다른 PM들과는 확연한 차별점을 가지며, 더 나은 PM이 되었음을 자부할 수 있습니다.
지금부터는 어떤 현상이 발견 되었을때, 항상 해답을 요구하는 질문을 만들어 보고 답을 찾아내는 습관이 필요합니다. 예를들어, 회원 탈퇴율이 증가하는 현상을 발견했을 때, "왜 사람들이 탈퇴할까?" 라는 질문을 만들어보고 "혜택이 별로 없음" 이라는 답을 찾아내는 것처럼요. 가상의 케이스를 놓고 현상과 문제를 정의하는 연습도 추천드립니다.
매번 점심 메뉴를 고민하는 동료를 보면서 “왜 고민할까?“라는 질문을 만들어보고 답을 만들어보는 것도 좋습니다. “이 주변 식당을 다 이용해봤고 딱히 생각나는 메뉴가 없어서”일 수도 있고, “빨리 정해서 점심시간을 낭비하고 싶지 않다”일 수도 있습니다.
또 다른 예시로, 프로젝트 마감 기한이 자주 지연되는 현상을 발견했을 때, “왜 기한이 자주 지연될까?“라는 질문을 던져보고 답을 찾아보는 것도 유용합니다. “작업량이 과다해서”일 수도 있고, “팀원 간의 커뮤니케이션이 원활하지 않아서”일 수도 있습니다. 이러한 질문과 답변을 통해 문제를 더 명확하게 정의하고, 보다 효과적인 해결책을 모색할 수 있습니다.
최근 제품에 대한 리뷰 수가 감소하는 현상을 발견했을 때, “왜 리뷰가 줄었을까?“라는 질문을 던져보세요. “고객이 리뷰를 남길 동기가 부족해서”일 수도 있고, “리뷰 작성 과정이 번거로워서”일 수도 있습니다. 이를 통해 고객이 리뷰를 더 쉽게 남길 수 있는 방법을 찾고, 리뷰 수를 증가시킬 수 있습니다.
이처럼, 일상적인 상황에서 현상을 관찰하고 질문을 만들어 답을 찾아내는 연습을 지속적으로 하다 보면, 문제 해결 능력이 향상되고, PM으로서 더 나은 결정을 내릴 수 있게 될 것입니다. 정답이 없는 문제에 대해서도 다양한 관점을 통해 답을 모색하는 습관을 기르는 것이 중요합니다.
#
실무에서는 관찰된 현상을 통해 만들어진 질문에 대한 답을 찾기 위해 다양한 파트너들이 필요합니다.
예를 들어, “왜 리뷰가 줄었을까?“라는 질문에 대한 답을 찾기 위해 우리는 User Research 팀의 도움을 받을 수 있습니다. 1-Pager에서 1번 Target Customer와 2번 Observation이 정리되었고, 이제 3번 Problem Statement를 만들어가는 과정에서 우리는 첫 번째 중요한 소통을 1-Pager를 가지고 시작하게 됩니다.
상품을 구매했지만 리뷰를 남기지 않은 고객 인터뷰를 통해 다양한 피드백을 받을 수 있습니다. 이러한 피드백은 문제의 근본 원인을 이해하고, 더 나은 해결책을 찾는 데 큰 도움이 됩니다.
예시: 리뷰 감소 문제 해결을 위한 User Research팀과의 협업 과제
1. Target Customer (대상 고객): 최근에 제품을 구매했지만 리뷰를 남기지 않은 고객.
2. Observation (현상): 최근 제품에 대한 리뷰 수가 감소함.
3. Problem Statement (문제 진술): 고객이 리뷰를 남기지 않는 이유를 파악하고, 이를 해결할 방법을 찾는 것.
이제, 첫 번째 중요한 소통을 시작했습니다. User Research 팀과 협력하여, 리뷰를 남기지 않은 고객들을 인터뷰하고, 고객 인터뷰를 통해 얻은 피드백을 분석하여, 아마도 다음과 같은 원인을 찾을 수 있습니다:
• 리뷰 작성 과정이 번거롭고 복잡함.
• 리뷰를 남기는 인센티브가 부족함.
• 제품에 대한 만족도가 낮음.
생각보다 많은 회사가 User Research팀을 운영하고 있지는 않습니다. 이때는 주변인들에게 직접 물어보는 방법을 사용하거나, 온라인 설문조사를 활용하여 데이터를 수집할 수 있습니다. 예를 들어, 동료, 친구, 가족 등에게 질문을 던져보는 것도 좋은 방법입니다. “왜 사람들이 리뷰를 남기지 않을까?“라는 질문을 통해 다양한 의견을 수집하고, 이를 바탕으로 문제의 원인을 분석해볼 수 있습니다. 이러한 비공식적인 방법들도 충분히 유용한 인사이트를 제공할 수 있습니다.
또는 데이터를 보고 원인에 대한 가정을 세워볼수도 있어요.
예를들어, 리뷰 작성하러 들어왔다가 이탈하는 고객이 많음을 보고 "리뷰 작성 과정이 번거롭고 복잡함" 이라는 가정을 세울수도 있습니다. 가정이라고 이야기 하는 이유는 "리뷰 작성하러 들어왔다가 이탈" 또한 현상이고 "리뷰 작성 절차가 복잡해서" 라는 가정을 세웠기 때문입니다.
하지만 데이터에 기반한 가정은 보다 정확할 가능성이 높습니다. 따라서 이러한 가정은 문제의 원인일 확률이 높으며, 해결책을 찾는 성공 확률을 높입니다. 이를 통해 우리는 더욱 효율적으로 문제를 분석하고 해결할 수 있습니다.
중요한건 우리가 얼마나 논리적으로 현상과 문제에 대해 소통하는가 입니다.
예시 1)
"최근 제품에 대한 리뷰 수가 지난주 대비 20% 감소해서, 제품을 구매했지만 리뷰를 남기지 않은 고객 5명을 인터뷰 해봤습니다. 그랬더니 제품에는 만족했지만 사진이 필수가 되면서 귀찮아서 안쓰게 된다가 대부분 이었습니다. 이를 통해 우리는 리뷰 작성 과정이 번거롭고 복잡해서 귀찮아함을 고객의 문제로 생각할 수 있습니다."
예시 2)
"최근 제품에 대한 리뷰 수가 지난주 대비 20% 감소해서, 리뷰 작성 페이지에 들어온 고객의 이탈율이 사진 등록 단계에서 15%증가 했습니다.이를 통해 우리는 리뷰 작성 과정이 번거롭고 복잡해서 귀찮아함을 고객의 문제로 생각할 수 있습니다."
위의 예시를 1-Pager 목차와 맞춰보면 아래와 같습니다.
1. Target Customer: 제품을 구매했지만 리뷰를 남기지 않은 고객
2. Observation: 리뷰 수가 지난주 대비 20% 감소함
3. Problem Statement: 제품에는 만족했지만 사진이 필수가 되면서 리뷰 남기기 귀찮아함.
이처럼 1-Pager 기반 소통은 우리가 일반적으로 대화하며 상대방을 이해시키는 방식과 상당히 유사합니다.
Jobs to be done
3편에서 우리는 Jobs to be done(JTBD)에 대해 알아봤습니다. JTBD는 고객의 관점을 이해하고, 더 나은 서비스와 경험을 제공하기 위한 핵심입니다.
하지만 처음 Jobs to be done을 작성할 때, 아마 어떻게 정의해야 할지 감을 잡기 어려울 수 있습니다.
작성하다 보면 Problem Statement와의 차이에 대해 의문이 들 때도 있습니다.
이럴 때는 "고객은 왜 이 행동을 하려고 할까?" 또는 "이 행동을 통해 무엇을 얻고 싶어 할까?"등 고객의 속마음을 생각해보는 것이 중요합니다.
고객이 완료하고자 하는 일에 대한 이해 없이 바로 실행에 옮기면, 사진 등록이 귀찮다는 이유로 다시 사진 등록 필수를 해제하게 될 수도 있습니다. 하지만 사진이 있는 리뷰가 더 잘 팔린다는 이유가 있을 수 있습니다. 그렇기 때문에 제품이 더 발전하는 방향으로 이어지려면 현상을 해소하기 보다는 고객 이해의 관점에서의 고민이 필요하게 됩니다.
예를들어 고객이 리뷰를 남김으로해서 얻고자 하는 것은 사회적 인정일 수도 있습니다. 자신의 의견이 중요하고 가치있게 판단되기를 바랄수도 있어요. 그렇다면 이 경우의 Jobs to be done은 "리뷰를 남겼을 때, 그 리뷰가 다른사람에게 유용하고 가치있게 사용되었음을 알게한다" 가 될 수도 있습니다.
여러 Jobs to be done을 가질 수 있습니다.
"리뷰를 남겼을 때, 그 리뷰가 다른사람에게 유용하고 가치있게 사용되었음을 알게한다."
"리뷰를 쉽고 빠르게 남길수 있게한다"
어떤 Jobs to be done을 선택하는지는 누가 어떤 의사 결정을 하는지에 따라 달라지지만, 고객에세 제공하는 서비스와 경험 또한 달라진다는 점을 유의해야 합니다.
Jobs to be done은 그 개념을 이해하기가 쉽지는 않지만, 중요한 것은 하나입니다.
고객이 완료하고자 하는 일을 이해한다.
몇가지 예시를 들어볼께요.
예시1) 화장품 광고의 JTBD
"나도 광고속 여주인공처럼 될 수 있다는 상상을 하게 한다."
예시2) 바베큐 그릴의 JTBD
"가족들과 맛있는 고기를 먹으며 즐거운 시간을 지내게 한다"
예시3) 전기드릴의 JTBD
"멋진 선반을 벽에 설치할 수 있게 도와준다"
예시4) 텀블러의 JTBD
"공간의 제약 없이 좋은 커피잔에 담겨진 커피를 즐기는 경험을 준다"
Benchmark, Hypothesis, Success Metrics
Target Customer, Observation, Problem Statement, JTBD까지 정리가 되었다면, 이제 어려운 부분은 다 지나갔습니다.
Benchmark 단계에서 중요한 소통은 UX 디자이너와의 공감대 형성입니다. 예를 들어, “리뷰를 남겼을 때, 그 리뷰가 다른 사람에게 유용하고 가치 있게 사용되었음을 알게 하고 싶어요. 그렇게 하면 사진 등록을 포함한 좀 더 고퀄리티 리뷰를 더 많이 남길 수 있다고 생각합니다.“와 같은 의견을 UX 디자이너와 공유한다면, 여러 사례를 함께 찾아보는 좋은 파트너가 생기게 됩니다.
Benchmark를 할 때 중요한 점은 우리가 정한 JTBD를 다른 서비스가 어떻게 잘 완수하는지, 그래서 고객의 문제를 어떻게 잘 해결하는지를 시뮬레이션해보는 것입니다. 다른 서비스들이 어떻게 JTBD를 구현하고 있는지를 분석함으로써, 우리는 무엇이 효과적인지 배울 수 있습니다. 이러한 분석을 통해 얻은 인사이트를 바탕으로 우리 서비스의 개선점을 찾을 수 있습니다.
예를 들어, 다음과 같은 질문들을 만들고 시뮬레이션해보는 것이 중요합니다:
“OOO 서비스에서 리뷰를 작성하면, 이 리뷰가 다른 사람에게 유용하고 가치 있게 사용되었음을 어떻게 알려주지?”
“OOO 서비스는 어떻게 고객들이 좀 더 고퀄리티 리뷰를 남기도록 하지?”
이러한 질문을 통해 다른 서비스의 성공 사례를 분석하고, 우리의 서비스에 적용할 수 있는 방법을 모색합니다.
Hypothesis(가설): 우리의 서비스에 적용할 수 있는 방법
가설은 다른 서비스들이 JTBD를 구현하는 방식을 분석하여 얻은 인사이트를 우리 서비스에 어떻게 적용할 수 있는지에 대한 방안을 제시하는 것입니다. 가설을 설정할 때는 디자인적인 세밀한 포인트를 과도하게 기술하지 않는 것이 중요합니다. 디자이너가 UX 측면을 고려할 때, 너무 구체적인 지침은 창의적 사고를 제한하고 더 나은 방안을 모색하는 데 제약을 줄 수 있습니다. 대신, 가설은 문제의 본질과 사용자가 원하는 결과에 집중해야 합니다. 이를 통해 디자이너는 다양한 접근 방식을 탐색하고, 사용자 경험을 최적화할 수 있는 혁신적인 솔루션을 개발할 수 있는 자유를 가지게 됩니다.
따라서, 가설을 설정할 때는 문제의 핵심을 명확히 정의하고, 디자이너가 이를 바탕으로 창의적이고 효과적인 디자인을 제안할 수 있도록 여지를 남겨두는 것이 좋습니다. 이는 결과적으로 사용자에게 더 나은 경험을 제공하는 데 기여할 것입니다.
예시)
사용자가 리뷰를 작성하러 들어왔을 때, "현재 몇 건의 리뷰가 고객의 구매 여정에 도움이 되고 있습니다. 좋은 리뷰로 좋은 구매 경험을 주셔서 감사합니다."와 같은 측면을 강조해서 알려 준다.
잘못된 예시)
사용자가 리뷰를 작성하러 들어왔을 때, 팝업창에 "현재 몇 건의 리뷰가 고객의 구매 여정에 도움이 되고 있습니다. 좋은 리뷰로 좋은 구매 경험을 주셔서 감사합니다." 문구를 보여준다.
가설에서 전달해야 하는 중요한 메시지는 앞으로 우리가 구체화시켜 나갈 방향에 대한 공감대 형성이며, 구체적인 방향에 대한 디렉션이 아닙니다.
Success Metrics: 우리의 가설이 잘 동작했음을 어떻게 알까?
Success Metrics(성공 지표)는 우리의 가설이 잘 동작했음을 알게되는 지표들을 설정하는 단계 입니다.
예를 들어, 사용자가 리뷰를 작성하러 들어왔을 때, "현재 몇 건의 리뷰가 고객의 구매 여정에 도움이 되고 있습니다. 좋은 리뷰로 좋은 구매 경험을 주셔서 감사합니다."와 같은 측면을 강조해서 알려 준다면 "리뷰 작성페이지에 랜딩된 고객의 리뷰작성 완료율"과 같은 지표들로 가설을 검증할 수 있습니다.
1-Pager Review
1번 Target Customer 부터 7번 Success Metrics 까지 작성이 되면, 1-Pager 리뷰 시간을 가져서 보다 확실한 공감대 형성을 가져가는 것을 추천드립니다. 이 리뷰의 목적은 공감대 형성 이며, 이 과정에서 설정된 가설에 법적, 윤리적, 기술적 문제가 없는지, 그리고 해당 가설이 고객의 문제를 잘 해결하는지를 확인하며 해당 1-Pager를 좀 더 디벨롭 할지 말지에 대한 의사결정을 하게 됩니다. 리뷰를 통과한 1-Pager만이 보다 구체적인 디자인 작업에 들어가기 때문에, 디자인팀은 보다 확실한 방향성을 가지고 작업을 진행할 수 있습니다. 이 과정은 불필요한 커뮤니케이션과 재작업의 위험을 줄여주고, 전체 업무의 효율성을 높여줍니다. 또한, 초기 단계에서 팀원 간의 의견을 조율하고 합의를 이루어, 프로젝트 진행 중 발생할 수 있는 갈등을 최소화하는 데 도움이 됩니다.
세부적인 계획
1-Pager 리뷰가 완료되어 해당 1-Pager를 좀 더 발전시키기로 결정되었다면, 이제 1-Pager의 두 번째 단계인 “세부적인 계획”으로 넘어가게 됩니다.
두 번째 단계는 디자인과 요구사항을 명확히 하는 과정으로, 이 단계에서 디자이너와 가장 활발하게 소통하게 됩니다. 디자인 작업에 들어가기 전에 미리 High level user story와 Information flow를 준비하고, 이를 토대로 디자인을 진행하는 것이 중요합니다.
세부적인 계획 단계에서는 구체적인 예시를 들지 않으려고 합니다. 이 단계는 각 기업과 팀마다의 문화에 따라 다양한 방식들이 존재하며, 여러분이 앞으로 세부적인 기획을 하면서 겪는 시행착오를 통해 더 나은 방향을 찾아가는 과정입니다. 정해진 모범 답안이 없는 영역이니, 자유롭게 다양한 방법을 시도해보면서 여러분만의 최적의 방안을 찾아가길 바랍니다. 다만 각 영역의 목적성 만큼은 아래 설명을 바탕으로 깊이 고민해보셨으면 합니다.
High level user story & Information flow
두 번째 단계에서 가장 중요하게 생각해야 할 부분입니다.
High level user story는 해당 가설을 맞이한 고객이 어떻게 행동하는지를 기술하게 되고, Information flow는 어떤 정보들이 고객에게 전달되어야 하는지를 기술하게 됩니다. 이는 디자이너가 작업하면서 해당 스토리와 정보들이 효과적으로 디자인 되는지를 검토하는 가이드라인으로 작용합니다. 특히 Information flow가 제대로 정립되지 않았을 때는 디자인 재작업이 빈번하게 발생합니다. "정보 하나 더 넣는 게 뭐가 어렵겠어?"라고 생각할 수도 있지만, 실제로는 그 추가 정보로 인해 레이아웃 수정, 정보의 우선순위 재검토, UX 이슈 조정 등 다양한 작업이 필요할 수 있습니다. 이러한 변경 작업은 생각보다 복잡하며, Information flow가 명확하지 않으면 디자인 과정 중간에 재작업 요청이 지속적으로 발생해 업무 효율성을 크게 저해할 수 있습니다.
Low-fidelity wireframe
Low-fidelity wireframe은 기본적인 레이아웃과 요소 배치를 단순화하여 표현한 초안입니다. 이는 빠르게 시각적 개념을 잡고, 초기 단계에서 큰 그림을 파악하는 데 유용합니다. 예를 들어, 버튼의 위치, 주요 텍스트 블록, 이미지 배치 등을 간단한 박스와 텍스트로 표현하여 아이디어를 시각화할 수 있습니다. Low-fidelity wireframe은 디자이너와 팀원들이 아이디어를 공유하고 피드백을 받을 수 있는 좋은 출발점이 됩니다.
Tech feasibility check
또 다른 중요한 지점은 Hi-fi wireframe 작업 전, Lo-fi wireframe 기반으로 개발 검토 받는 부분 입니다.
큰 이슈 없을것 같은 디자인 이더라도, 레거시 또는 쌓여있는 기술부채등으로 구현이 어렵거나 연관성 높은 다른 작업으로 인해 디자인 변경이 필요할 수도 있습니다. 따라서 곧바로 Hi-fi wireframe 작업에 들어가면, 마치 정성껏 차려놓은 식사를 다시 준비해야 하는 것처럼, 많은 재작업이 발생할 위험이 있습니다.
이런 이유로, Lo-fi wireframe을 기반으로 사전 검토를 받는 것이 중요합니다.
High-fidelity wireframe
High-fidelity wireframe은 보다 세밀하고 정교한 디자인 초안으로, 실제 제품에 가까운 시각적 요소와 인터랙션을 포함합니다. 예를 들어, 색상, 글꼴, 이미지, 버튼 스타일 등을 실제와 유사하게 표현하여 최종 사용자 경험을 시뮬레이션할 수 있습니다. 이는 디자이너와 개발자가 구체적인 피드백을 주고받으며, 최종 디자인을 확정하는 데 도움을 줍니다.
Design Review
디자인 리뷰의 목적은 완성된 디자인이 가설을 충족하는지, 그래서 고객의 문제가 해결되는지를 검토하는데 있습니다. 이 때 주의할점은, 디자인의 호불호에 따른 피드백입니다. 가설을 충실히 충족하고, 고객의 문제가 해결된다면 디자인 호불호는 디자이너의 판단에 맡겨야 합니다.
User story & Acceptance Criteria
User story와 Acceptance criteria는 개발팀에 티켓을 넘기기 전에 가장 중요한 단계라고 할 수 있습니다.
보다 상세한 고객의 행동과, 제품동작에 대한 만족조건들을 최대한 상세하게 작성 합니다.
신입 PM이 너무 강해짐은 1편부터 5편까지를 1부로, PM으로서 고객의 문제를 정의하고 해결해나가는 가장 중요한 과정을 신입 PM 여러분이 좋은 멘토가 없더라도 올바른 방향으로 나아가는 데
도움이 되고자 작성되었습니다.
2부에서는 실무에서 겪게 될 가능성이 높은 상황들을 어떻게 헤쳐 나가면 좋을지 이야기하려고 합니다. 계속 힘내시고, 좋은 PM으로 성장하시길 진심으로 응원합니다.
여러분의 성공을 항상 기원합니다!
