상위 기획 & 상세 기획
용어를 다 정의하는 것.
- 같은 이름을 가진 다양한 부분들이 있다.
- 같은 RoLE이더라도? 이게 여기 role인지 다른데있는건지? 다 다름.
→ 그래서 맨 처음에 시작할 때 가장 먼저 해야하는 건?
우리 서비스 내에서 사용하는 그 용어를 다 정의하는 것.
- 이미 있는 건 잘 가져다 쓰되, 우리 서비스에만 해당하는 것들도 있을 수 있으니깐? 그건 우리가 정의해야함.
iOS와 Android 용어를 구분하자.
→ 왜냐면 각 OS개발자에게 다른 용어로 말해야하므로
ex. 똑같은 알림창을 놓고 보더라도?
ios에서는 alert
안드에서는 dialog임.
점점 경험이 많아지면? 대상에 따라서 어떤 용어로 말할 지가 딱 나온다!
하나의 기획서 안에서 iOS, Android 둘다 들어간다면?
→ 둘을 혼용할 수 있기 때문에 아싸리 구분해서 쓰거나, 혹은? 아싸리 내가 새로이 정의한다.
ex. 알림창은 → alert로 정의하겠다- 라고 한다.
기획안을 읽는 대상에 따라서 다르게 쓰자.
- 새로운 아이디어를 위한 토론인지,
- 이미 다 정해진 것의 세부사항을 공유하기 위한 논의인지,
- 바뀐 부분만 전달하면 되는 건지 등등 목적이 다를 겁니다.
⇒ 이거에 따라서 문서는 달라져야해요.
- 개발자분들은 문서를 잘 안읽는다. 왜냐면? 너무 내용이 많음. 그러다보니 그걸 읽지 않고 임한다.
- → 개발자의 이해 수준을 파악한뒤에, 가장 중요한 것들 중심으로 적어야한다.
- 플로우앱을 하더라도? 스토리보드를 만들더라도? 그건 다 대상의 이해수준에 따라 다를 것임.
내가 맨 처음에 싱크를 기획할 때.. 기획안을 만들지 못했다.
문서를 만들 때 이걸 개인정보보호파트(법무팀)에서 볼지, 개발자가 볼지, 기획자가 볼지?에 따라서.. 정말 다를 것임.
그리고 개발자라고 하더라도? 기획에 대해서 너무 모르는 개발자에게는 정말 자세하게 썼어야하고, 잘 아는 개발자에게는 중요한 부분만 넣어야하고..
- 용어도 정의하지 않았기 때문에 지금 이 모든 것들이 혼란이 생겼다.
기획안의 버전을 잘 명시한다.
- 개정 이력을 적어야 함.
- 안 그럼 내가 이걸 과거 버전을 보는지 아닌지 파악이 어려움.
기획자마다 스타일이 있다.
- UI 디자인을 많이 짜서 주는 기획자가 있고, 디자인은 아주 rough하게만 넣고 기능에 대한 설명에만 치중하는 기획자도 있음.
- 전자의 경우에는 디자이너 입장에서는 크리에이티브 바운더리가 너무 제약이 생김.
- 나는 어떤 스타일일까?
동적 vs 정적을 구분해준다.
관건은 데이터가 어디서 오냐-임.
- 어떤 거는 클라(내 스맛폰)에서 가지고 오고, 어떤 거는 서버에서 가지고 온다.
동적인거는 그 때그 때 서버든 클라든 계속 가지고 와서 그 시점에서 새로운 걸 보여줘야한다.
- 동적인 거는 대부분 : 계속 바뀌어야하는 것들임. 무한대일수도 있고 아닐 수도 있음. 정적인거는 그냥 코딩 한번 하고 나면 끝임. DB랑 소통할 것이 없음. 그래서 쉬움. → 그래서 동적 스펙에 대해서는 고민이 더 필요함.
→ 동적이다 보면.. 소비자들이 어떤 DB를 가지고 있을지 모르기 때문에
극단적인 상황에 대한 혹은 다양한 경우의 수에 대한 고민이 필요함.
1) DB가 아예 하나도 없는 상황
없었을 때 뭐가 뜰지? 고민이 필요하다.
왜냐면 동적이면 혹시라도 DB가 없을 때 아무거도 안 뜰거임.
ex. 예를 들며 mele에 넣은 to-do가 아무것도 없는 경우에는 sample이나 instruction을 넣도록 기획한다던지?
2) 여기에 들어갈 Data가 무진장 길거나 짧은 상황
그럼 이런 극단적인 경우에 어떤 모습으로 보여줄 지를 딱 알려주지 않으면 → 디자이너나 개발자가 어려워.
ex. 너무 길 때 스크롤을 한다.
ex. 입력창도 대부분 동적이겠지? → 그럼 그것도 4줄 이상이면 스크롤 보인다 등등을 설정해야함.
ex. 너무 길면 디자인이 바뀐다. 시간이 어디에 들어간다- 등등.
ex. 길었을 떄 줄바꿈은 어떻게 할지?
3) 어떤 내용이 들어갈지 모르는데, 내가 만약 뭔가를 강조하고 싶다면?
- 예를 들면 일정 앱이니까 '일정'이라는 키워드에 대해서는 강조 처리를 하거나 클릭 시 어디로 넘어가게 하고 싶다? → 미리 알려줘야 함.
- ex. 서비스 이름이 들어갔을 때 빨간색으로 들어간다던지?
ex. 페이스북 댓글 축하 효과
4) 유저의 상태에 따라서 어떤 게 나올 지가 다 다르다면, 그걸 일일이 다 케이스별로 구분
ex. 페이스북 그룹
ex. 싱크 동의창의 동적 약관 스펙을 적용한 롯데면세점
- 유저가 오프라인에서 QR스캔을 통해서 들어왔다면, tag를 통해서 동의창의 약관을 오프라인 꺼로 노출해야하고,
- 유저가 온라인환경에서 들어왔다면, 동의창의 약관을 온라인으로 노출해야한다.
5) 유저가 어떤 인풋을 할지 모르기 때문에 모든 상황을 다 고려해야한다. 예를 들면 유저가 opt-in을 했을 수도 있고, opt-out을 했을 수도 있다.
- 광고성 메시지 수신 동의에 따라서 팝업 여부 결정
- 싱크 동의창의 파트너사 선택 약관 중에서는 유저가 일부는 선택하고 어떤 거는 동의하지 않을 것이다.
- 그럼 어떤 걸 동의했을 때는 이런 페이지, 동의하지 않았을때는 이런 페이지 → 이렇게 나뉘어야한다.
개발자에게 뭔가를 요청할 때 혹은 수정할 때 → 동적인 부분인지, 정적인 부분인지.. 파악하고 하자 ^^ㅋㅋ
안그러면 이게 얼마나 걸릴지 산정이 어렵다.
동적인 부분이라면? 고려할 게 아주 많다. 그럼 개발자는 하기 싫을 것이다.
유저 인풋이 많다거나 하는 앱들은 대부분 동적임.
- 동적인거랑 정적인거랑 하나만 있기는 어려움.
내가 기획한 것을 → 디자이너에게 넘기면 다양한 고민을 해서 그걸 많이 바꾸게 된다. → 그럼 기획자 입장에서는? 마냥 좋기만 할까? 어떤 부분들을 고려해야할까?
- 추가되고 삭제된 것 중에서 일단은 동적인 부분이 어디어디인지를 파악
왜냐면? 그건 공수가 많이 든다.
→ 디데이 하나만 추가되어도?
- 그 데이터를 어떻게 어디서 불러올지?
- 그걸 어디서 유저가 입력할 수 있게 할지? 다 ~ 고민해야함.
- 디데이 데이터를 어디에 저장할지?
- → 이에 따라서 시간이 더 많이 걸리니깐?
2. 애니메이션으로 볼 수 있어야 한다.
- 이건 캡쳐로는 확실하게 느껴지지 않음.
- 왼쪽으로 땡긴다- 라는 것에도 너무 다양한 종류가 있음.
- 이걸 더 쉽게 하려고 프로토타이핑 툴이 생김.
3. 디자이너에게 우선순위를 넣어 달라고 해야 한다.
- 특히 동적인 부분은 시간이 걸리기 때문에 그 스펙이 얼마나 중요한지를 파악해야 한다.
- 정적인 부분인데 중요한 것부터 빠르게 처리.
4. 프레임워크에 있는 기능인지 아니면? 직접 개발해야하는 기능인지 파악해야함.
- 이미 iOS에서는 왼쪽으로 스크롤 시에 나오는 애니메이션은 다 만들어두었음.
→ 이런 거는 그냥 빠르게 할 수 있음. 근데 막 우리 서비스만을 위한 기능이라면? 이미 OS 프레임워크나 타 프레임워크에서 가지고 올 수 있는거라면? 그냥 빠르게 갈 수 있음.
기획자가 프레임워크를 공부한다면 그 목적은?
- 우리가 원하는 이 기능이 프레임워크에서 이미 준비한 기능인지 아닌지를 구분하기 위함일듯.
- 개발자에게 말할 때 이게 어떤 프레임워크에 있다는 거를 미리 말해줄 수 있으니깐