- 인천작업실
- 세실내과
- 도쿄지헨
- 유학생 건강검진
- 막달운동
- 세운전자상가
- sony nex vg20
- 월디스플레이
- 시이나링고
- formex
- 이슬비침
- raspberrypi wifi
- formex E400
- 라즈베리파이 와이파이
- 東京事変
- IR sensor
- Skins
- 러쉬 해외 직구
- Arduino
- 4대 대첩
- OPT #EAD
- 흥성전기
- 東京事變
- 라즈베리파이 모니터벽
- 파이월
- 동경사변
- Shena Ringo
- piwall
- wall display raspberrypi
- 시온여성병원
- Today
- Total
'_'
Goal-JTBD, checklists 본문
지수님께 입사 초기에 슬랙으로 전달드렸던 내용..
Goal - JTBD
Goal은 해당 기능을 통해 이루거나 달성해야하는 것입니다.
이를테면 “카메라라는 기능을 통해 유저는 항해중 위험한 상황의 전방 객체들을 위험도별로 인지하고싶고 그러면 안전한 항해경로를 선택할 수 있다.” 라고 써볼수 있을것 같아요.
보통 When(상황) ~~, I want(voc 혹은 니즈) ~~, so that(이루고자하는 것)~~ 의 구조로 씁니다.
이걸 적는 이유는 특정 기능이 왜 필요하고 개발할 여러 내용중 우선순위는 무엇인지 등을 정하기 위함입니다. 이를테면 위의 카메라에서도 제일 위험한 장애물을 알려주는게 중요한지, 가장 안전한 항해경로를 보여주는게 중요한지, 아니면 사람의 시야가 못보는것을 알려주는게 중요한지 등 사람마다 중요하다고 생각하는게 다른경우가 많아서요. 이걸 먼저 적고 어느정도 컨센서스를 맞추고 나면 우선순위를 정해서 뭘 먼저 개발하고 어떤 기준으로 디자인할지 정해나갈수 있어서 제품이 중구난방으로 산만해지는걸 방지할 수 있습니다.
JTBD의 경우는 위의 goal을 바탕으로 해당 기능에서 달성되어야할 내용을 하나씩 정의한 것입니다.
“카메라라는 기능을 통해 유저는 항해중 위험한 상황의 전방 객체들을 위험도별로 인지하고싶고 그러면 안전한 항해경로를 선택할 수 있다.” 가 goal 이므로
항해중 카메라화면을 볼 수 있다.
카메라화면의 객체들이 분류되어 표시된다.
유저는 카메라화면 정보를 보고 가장 위험한것을 인지할수 있다.
(유저는 카메라화면 정보를 줌인-줌아웃하여 확인할수 있다)
유저는 카메라화면을 보고 안전한 항해경로를 이해할수 있다.
이런식으로 나열해볼수 있습니다. 이건 나중에 유저테스트때
task항목으로 활용해서 해당 기능이 잘 개발되었는지 확인하는 용도로도 쓸수있어요.
1:36
우선 위의 내용이 어느정도 나오면 디자인도 어느정도 기준을 가지고 시안을 만들어서 pros / cons 를 비교할수 있어서 의사결정이 좀 빠르게 진행될수 있는것 같아요.
아무래도 IT쪽은 속도가 빨라야하다보니 의사결정을 효율적으로 하기위한 방법론이 적용된편이고 논리적으로 디자인과 개발 우선순위를 잡아가기위한 설득이 중요해서 위와같은 방식으로 해왔었어요.
8가지 checklists
- Goal
- JTBD
- Hypothesis
- Tension
- Suceess
- Fail
- Metric
- Feedback