David.Cheon
UIpac
David.Cheon
  • UIpac (647) N
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (64) N
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (33) N
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352) N
      • Weekly Curation (251)
      • Performing Arts (17) N
      • Collection (6)
      • Books (0)
      • Life (78) N

인기 글

Tags

  • 트렌드
  • Gartner
  • trend
  • 기획
  • 트랜드
  • 디자인참고
  • 2015
  • 웨어러블
  • 2014
  • 동향
  • 디자인
  • 반응형웹
  • 인공지능
  • 벤치마킹
  • Curation
  • 가트너
  • 모바일
  • 분석
  • 사이트
  • 애플리케이션
  • Mreport
  • 세계 게임시장 규모
  • 큐레이션
  • 기획참고
  • 유니티
  • daumkakao
  • UX
  • 사물인터넷
  • 다음카카오
  • UI

최근 댓글

방명록

전체 방문자
오늘
어제
hELLO · Designed By 정상우.
David.Cheon

UIpac

Planning · PM/일하는 방법

기획 메시지를 발전시키는 방법

2020. 6. 6. 14:40

 

기획서를 열심히 썼는데 회의에서 "그래서 하려는 게 뭐죠" 하는 질문을 받은 적이 있습니다.
내용이 틀려서가 아니라, 가장 말하고 싶은 것이 한 문장으로 잡혀 있지 않았기 때문이었어요.
그 뒤로 저는 기획의 핵심을 메시지라고 부르면서, 한 줄로 시작해 조금씩 키워 가는 방식으로 정리하고 있습니다.
오늘은 그 과정을 세 단계로 나누어 적어 봅니다.

 

처음에는 가장 단순한 한 문장을 만듭니다.
형식은 "누가, 무엇 때문에, 무엇을 하게 만든다" 정도면 충분해요.
기능 이름을 나열하는 문장은 메시지가 아니라 목록이라서, 이유와 변화가 들어가야 합니다.

가정 예시를 들어 볼게요.
동네 학원의 수강 신청 화면을 개편하는 기획이라고 해 보죠.
처음에는 "수강 신청 화면을 개편하고 결제 단계를 줄인다"고 적었다고 가정합니다.
이건 할 일의 설명일 뿐입니다.
이를 "학부모가 신청을 시작한 뒤 중간에 포기하지 않고 끝까지 마칠 수 있게 한다"로 바꾸면, 무엇이 달라져야 하는지가 드러납니다.
이렇게 쓰고 나면 다른 사람이 읽어도 목적이 같은 방향으로 이해돼요.

메시지가 한 문장으로 잘 안 써진다면 아직 생각이 정리되지 않았다는 신호입니다.
그럴 때는 이 문장을 말로 해 보라고 권하고 싶어요.
옆 사람에게 십 초 동안 설명해서 "아, 그거요" 하는 반응이 나오면 통과입니다.
글로 쓰면 그럴듯해도 입으로 하면 막히는 문장이 의외로 많아요.

 

메시지가 선 다음에는 왜 그렇게 말할 수 있는지를 뒷받침합니다.
근거는 크게 세 가지 종류로 나누어 생각하면 편했습니다.
데이터에서 나온 근거, 사용자에게서 들은 근거, 그리고 비교나 사례에서 얻은 근거입니다.

위 예시로 이어 가 보겠습니다.
신청 흐름에서 어느 단계에서 가장 많이 이탈하는지가 데이터로 확인되었다고 가정합니다.
문의 내용에서 "입력할 항목이 너무 많다"는 말이 반복되었다고도 하고요.
이 두 가지가 같은 방향을 가리키면 메시지에 힘이 생깁니다.
반대로 근거가 하나뿐이거나 서로 다른 방향이면, 아직 메시지를 확정하기에는 이르다는 신호로 읽습니다.

숫자를 쓸 때는 출처와 기간, 대상을 같이 적습니다.
확인되지 않은 수치를 그럴듯하게 넣는 것보다 "아직 확인 전"이라고 적는 편이 신뢰를 잃지 않아요.

근거의 순서도 중요합니다.
가장 강한 근거를 먼저 말하고, 보조 근거는 뒤에 두면 듣는 사람이 흐름을 놓치지 않아요.
예시에서는 이탈이 가장 큰 구간이라는 데이터를 앞에, 문의 내용을 뒤에 둘 수 있겠죠.
그리고 근거가 메시지를 직접 뒷받침하는지도 확인합니다.
멋진 숫자라도 메시지와 관계가 없으면 설득이 아니라 장식이 됩니다.

 

좋은 메시지는 반대 의견을 만났을 때 비로소 단단해집니다.
그래서 발표 전에 "이 기획에 반대한다면 어떤 이유를 댈까"를 직접 적어 봅니다.
이 작업은 자기 기획을 의심해 보는 일이라 처음엔 불편한데, 해 보면 구멍이 꽤 많이 보여요.

흔히 나오는 반론은 몇 가지로 모입니다.
비용이 너무 크지 않은가.
다른 우선순위가 더 급하지 않은가.
이게 정말 원인인지 어떻게 아는가.
실패하면 되돌릴 수 있는가.

예시에서라면 "입력 항목을 줄이면 필요한 정보를 못 받아서 운영이 힘들어진다"는 반론이 나올 수 있습니다.
그러면 미리 "필수 항목과 나중에 받아도 되는 항목을 나누겠다"는 대응을 준비해 둡니다.
대응이 없는 반론은 숨기지 말고 "아직 답을 못 찾은 부분"으로 솔직하게 공유하는 쪽이 오히려 논의를 건설적으로 만들어 줍니다.

반론을 생각할 때는 입장을 바꿔 보는 것이 도움이 됩니다.
개발자라면 어디가 부담일지, 운영 담당자라면 어디가 번거로울지, 의사결정자라면 무엇이 가장 불안할지를 각각 떠올려 봐요.
세 사람의 시선으로 한 번씩 읽으면 혼자서는 놓치던 질문이 나옵니다.

 

메시지를 키우다 보면 문장이 점점 길어지고 욕심이 붙습니다.
이것도 해결하고 저것도 개선한다는 식이 되면 한 문장 요약이 다시 불가능해져요.
저는 문장이 두 줄을 넘으면 일단 기획이 두 개가 섞인 것은 아닌지 의심합니다.

발전시킨 메시지는 마지막에 다시 한 줄로 줄여 봅니다.
처음 한 줄과 비교해서 더 구체적이고 근거가 붙었는지 확인하는 거예요.
예시라면 "학부모가 신청을 끝까지 마치게 한다"는 처음 문장에 "입력 항목을 줄여서"라는 방법과 "이탈이 가장 큰 단계를 중심으로"라는 범위가 더해진 모양이 되겠죠.
이렇게 다듬어진 문장은 회의 제목이나 문서 맨 앞 요약으로 그대로 쓸 수 있습니다.

또 하나는 듣는 사람에 따라 강조점을 바꾸는 일입니다.
개발자에게는 범위와 예외를, 의사결정자에게는 기대 효과와 위험을 먼저 말합니다.
다만 핵심 메시지 자체는 바꾸지 않아야 하고, 그래야 사람마다 다른 이야기를 들었다는 혼란을 막을 수 있어요.

 

메시지는 한 번에 완성되지 않고, 쓰고 근거를 붙이고 반박해 보는 과정에서 다듬어진다고 생각합니다.
처음 한 줄이 어설퍼도 괜찮아요.
그 한 줄이 있어야 비로소 고칠 대상이 생기니까요.

남은 질문은 이것입니다.


근거가 충분하지 않은 시점에 어디까지 확신 있게 말해야 하는지가 늘 어렵습니다.
너무 조심하면 힘이 빠지고 너무 단정하면 나중에 곤란해지는데, 그 중간 지점을 계속 찾아가 보려고 합니다.

저작자표시 비영리 변경금지 (새창열림)

'Planning · PM > 일하는 방법' 카테고리의 다른 글

프로토타이핑 도구 고르는 기준  (0) 2020.06.09
웹 서비스 기획 시행착오와 도구 정리 (1)  (0) 2020.06.09
목업 도구를 쓸 때의 원칙  (0) 2020.06.06
파워포인트 단축키 모음  (0) 2018.08.10
Choosing a good chart  (0) 2014.05.21

티스토리툴바