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

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

최근 댓글

방명록

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

UIpac

Planning · PM/일하는 방법

목업 도구를 쓸 때의 원칙

2020. 6. 6. 16:30

 

기획을 하다 보면 글로 설명하기 어려운 화면이 반드시 나옵니다.
그럴 때 목업을 만들어 보여 주면 이야기가 훨씬 빨리 진행돼요.
다만 목업은 만들기 쉬운 만큼 잘못 쓰기도 쉽다고 느꼈습니다.
오늘은 제가 목업 도구를 쓰면서 지키려고 하는 원칙 세 가지와 주의할 점을 정리해 봤습니다.

 

목업은 예쁜 그림을 만들려고 하는 작업이 아닙니다.
머릿속 생각을 다른 사람이 볼 수 있는 형태로 꺼내서, 합의를 빠르게 하기 위한 수단이에요.
이 목적을 잊으면 어느새 버튼 모서리를 다듬는 데 한 시간을 쓰고 있게 됩니다.

그래서 작업을 시작하기 전에 한 줄로 적어 둡니다.
"이 목업으로 무엇을 결정하려는가."
가정 예시를 보면, 마이페이지에 주문 내역을 어떻게 보여 줄지 정해야 한다고 해 보죠.
결정할 것이 "목록형으로 갈지, 카드형으로 갈지"라면 두 가지 구조만 단순하게 비교하면 됩니다.
색상이나 아이콘은 그다음 문제이고, 지금 단계에서는 오히려 논점을 흐립니다.

목업을 만들기 전에 이 질문에 답이 없다면, 도구를 열기 전에 종이에 먼저 그려 보는 것도 좋은 방법입니다.
손으로 그린 스케치는 오 분이면 끝나고, 틀려도 아깝지 않아요.
그 스케치로 방향이 맞다는 확인이 된 뒤에 도구로 옮기면 수정 횟수가 확 줄어듭니다.

또 하나는 목업을 보여 줄 때 "무엇에 대한 의견을 구하는지"를 먼저 말해 주는 것입니다.
아무 말 없이 화면을 띄우면 사람들은 눈에 띄는 대로 색, 문구, 아이콘 이야기를 시작해요.
"오늘은 목록의 순서만 봐 주세요"라고 범위를 정해 두면 회의가 짧아집니다.

 

목업을 이미지로만 공유하면 보는 사람마다 다르게 이해합니다.
같은 화면을 보고도 "이 버튼은 뭐지" 하는 질문이 나오고, 만든 사람이 없는 자리에서는 답할 방법이 없어요.
그래서 목업 옆에 짧은 설명을 반드시 붙이려고 합니다.

설명에 넣는 내용은 대체로 이렇습니다.
이 화면의 목적과 진입 경로.
주요 요소의 동작, 예를 들어 버튼을 누르면 어디로 가는지.
비어 있을 때나 오류가 났을 때 같은 예외 상태.
아직 확정되지 않은 부분은 "미정"이라고 눈에 띄게 적기.

마지막 항목이 특히 중요합니다.
미정인 부분을 표시하지 않으면, 임시로 넣어 둔 문구나 값이 확정된 것처럼 받아들여져요.
실제로 샘플 문구가 그대로 개발까지 넘어간 사례를 주변에서 들은 적이 있습니다.

예를 들어 예약 취소 화면의 목업을 만들었다고 가정해 보죠.
화면에는 "취소하기" 버튼 하나만 있습니다.
그 옆에 "예약 시간 한 시간 전까지만 취소 가능, 이후에는 수수료 안내 화면으로 이동"이라는 설명을 한 줄 붙이면, 개발자는 분기가 필요하다는 것을 바로 알아요.
설명이 없었다면 버튼 하나로 끝나는 줄 알고 구현했다가 나중에 다시 물어봤을 겁니다.
설명은 길 필요가 없고, 화면에서 보이지 않는 규칙을 적는 것만으로 충분합니다.

 

목업은 계속 바뀝니다.
의견이 나올 때마다 고치다 보면 어느 것이 최신인지 헷갈리고, 예전 안이 더 좋았다는 이야기가 나오면 되돌릴 방법이 없어집니다.

제가 쓰는 방식은 단순합니다.
큰 방향이 바뀔 때는 파일을 복사해서 이름에 날짜와 안 번호를 붙입니다.
작은 수정은 같은 파일 안에서 하되, 무엇을 왜 고쳤는지 한 줄 메모를 남깁니다.
채택되지 않은 안도 지우지 않고 보관해 둡니다.
나중에 "그때 왜 이 안은 안 갔죠" 하는 질문이 나오면 이유까지 같이 설명할 수 있기 때문이에요.

버전 이름은 의미가 드러나게 짓는 편이 좋습니다.
"v3수정"보다 "0606목록형_안2"처럼 무엇이 다른지 알 수 있는 이름이 낫더라고요.
회의에서 안을 비교할 때도 번호로 말할 수 있어서 "2안으로 가죠" 하고 정리하기 쉽습니다.
반대로 모든 변경을 새 파일로 남기면 폴더가 금방 지저분해지니, 방향이 바뀔 때만 새 파일을 만들고 그 기준은 팀과 합의해 두세요.

 

도구가 좋아지면 목업이 점점 실제 서비스처럼 정교해집니다.
그러다 보면 보는 사람도 "이미 거의 다 만든 것"으로 오해하는 일이 생깁니다.
일정을 물어볼 때 "화면 다 나왔는데 금방 되지 않나요" 같은 말을 듣는 거죠.

그래서 합의 전 단계에서는 일부러 거친 느낌을 남겨 두기도 합니다.
선과 박스만으로 그린 화면은 "아직 바뀔 수 있다"는 신호를 줍니다.
정교한 화면은 구조가 확정된 뒤에 올려도 늦지 않아요.

또 하나의 함정은 목업 자체를 목표로 삼는 것입니다.
화면을 많이 만들면 일을 한 것 같은 기분이 들지만, 합의된 결정이 늘어나지 않았다면 진전은 아니에요.
하루를 마칠 때 "오늘 목업으로 무엇이 결정되었나"를 스스로 물어보면 방향을 점검하기 좋습니다.
도구를 고르는 기준은 다음 글에서 따로 정리해 보겠습니다.

 

목업은 소통을 위한 도구이고, 그림 자체가 결과물은 아니라고 생각하게 됐습니다.
목적을 적고, 설명을 붙이고, 버전을 남기는 세 가지만 지켜도 불필요한 되돌림이 많이 줄어요.

앞으로 더 고민하고 싶은 질문이 있습니다.


목업과 정책 문서가 따로 있을 때, 둘 사이의 불일치를 어떻게 자연스럽게 막을 수 있을까요.
화면 번호로 묶는 방법을 써 보고 있는데, 더 나은 방식이 있는지 계속 찾아보려고 합니다.

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

'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

티스토리툴바