# 대표님 질의 (Figma 기획의 [페이지] 단위로)
- [회원가입] 이메일 입력이 회원가입에 굳이 필요한가?
- Android, IOS에서 앱 출시할때는 개인정보 수집하여 어따 쓰는지 다 물어본다.
- [대표님] 이메일을 아이디로 쓰는 것이 어떨 것인가? 에 대한 고객사에 제안해보길.
- [회원가입] 휴대폰번호는 계정에 고유해야 한다.
- [대표님] 휴대폰 번호 중복 체크는 고객사에서 요구하지 않는 한 굳이 필요 없다.
- [대표님] 필수 Validation 외에는 나중에 하는 것이 좋을 것 같다.
- [대표님] 어뷰징에 대한 염두가 쿠폰 기능이 없는 경우 필요 없다. (회원가입 쿠폰에 대한 어뷰징 방지)
- [관리자] 관리자 페이지 수에 대해서
- [대표님] 대충 30개 페이지 이하이지 않을까 해서 넣어 두심
- [대표님] 고객사에서도 관리자 페이지가 불편할 것이라는 것 염두
- [대표님] 1차에서는 모든 테이블에 대한 CRUD만 진행하기로 함
- [홈] Today 게시글 확인하기 위한 페이지 원안에 없음.
- [대표님] Today가 상품이냐, 아니면 관리자가 업로드 한 것인가에 대해 질문 해주세요.
- [대표님] 질문에 대한 답변을 바탕으로 견적 추가
- [18] 사이드바가 어떻게 열리는지? (FIgma19. 햄버거 메뉴클릭?)
- 고객사에 대한 질문
- [18] 카테고리 대 - 중 - 소 로 나뉘어 지는 것. (3depths)
- [대표님] 2depths로 구현한다면 parent_id 갖고있는 테이블구조로 짜야할 것 같다.
- [대표님] 3depth라면 고객사에게 안내 잘 하기
- [20] 브랜드 필터 / 브랜드 필터를 넣을 지 말지에 대해
- [대표님] 1차 개발 완료 기간을 최대한 앞당기고 싶으시다. 때문에 기능에 대한 고려가 더 많이 들어갈 수록 딜레이가 길어질 것이다. 때문에 1차 개발 종료 기간을 늘리는 것이라면 최대한 배제시키고 싶다.
- [대표님] 기한(대표님께서 생각하시는 내년 7월 or 그보다 일찍) 안에 끝낼 수 있으면 하고 아니면 빼는게 나을 것 같다.
- [대표님] 고객사와의 방어적인 커뮤니케이션 -> 모든 관리자로서의 정보 등록은 일원화. 즉, 브랜드 개별로 관리자 페이지에 접근하여 각자의 브랜드 정보를 관리하는 것이 아니다.
- [대표님] 최대한 1차적인 기능 구현을 빨리 끝내야 -> 미뤄놨던 기능들을 ‘안정적으로’ 구현할 수 있게 된다. 즉, 1차를 빨리 끝내야 미뤄뒀던 기능들을 넣을 수 있다. 버그도 적게 생길 것임. 검수할 부분을 좁히는 것이 좋을 것 같다.
- [20] 브랜드 필터 / 아티스트 빠지는 것에 대해 고객사의 인지 정도
- [대표님] 고객사 측에서 md, 아티스트 관련 기획이 아직 나오지 않았다.
- [대표님] 기획이 나중에 나오면 견적이 나올 것이다.
- [대표님] 고객사에게 관리자 페이지에 대한 1차 구현은 완전 CRUD라 했음. 그래서 못 쓸 정도라고 했었음. 근데도 OK. 고객사는 견적이 많이 나와도 되지만, 기간이 중요하다고 요청함. 전체 디자인은 어느정도 나와있고, 1차에 없는 부분들은 2차 개발로 들어갈 예정. 추가적으로 여러 시행착오를 바탕으로 Fingr의 사용 경험을 끌어올리기 위한 개선을 수행할 예정. 매 미팅마다 대표님도 같이 참여하실 예정.
- [대표님] 진행하지 않기로한 범위에 대한 명시 또한 중요하다. Slack에 공유해 주실 예정.
- [23] 키친 / 공간분류가 무엇인가?
- [대표님] 고객사에 대한 질문
- [23] 카테고리가 3depth?
- [대표님] 3depth면 질문하면 될 것 같다.
- [23] 공유하기 / 공유하기 기능 또한 견적서에 빠져 있더라.
- [대표님] Slack으로 올리심. 구체적으로는 “베너, 찜, 리뷰, 쿠폰, 아티스트, 브랜드, 공유, 결제 취소, 프로모션 관리 기능은 1차에서 제외. 교환/반품 부분은 우선 제외하고 견적을 산출.” + “플레이오토 API 연동은 1차에서 제외하며 현재 시점에서 견적 산출 불가.” + a 는 Slack을 통해 확인
- [대표님] UI 미리 만들어 놓는 것이 좋을 것 같다. 임의로 뺐을 때 더 복잡해 질 수 있다. 구현 범위가 아닌 부분들에 대해서는 구현하지 않아도 된다.
- [33] 검색어 페이지 / 최근 검색어
- [대표님] 최근 검색어 로컬 스토리지 사용해도 될 듯 하다. 근데, 굳이 쓸 필요가 없을 것 같다. 브라우저까지의 확장 가능성을 고려했을 때는 서버에 저장하는 것이 나을 것 같다.
- [33] 검색어 페이지 / 인기있는 검색어
- [대표님] 견적 항목에 요소를 추가하는 것은 돈보다 시간을 벌 수 있는 것이다. 인기 검색어는 3시간 기준 업데이트. 청구된 것으로 그냥 진행.
- [40] 내 정보 수정에 전화번호 인증 필요?
- [대표님] 휴대폰 번호를 못바꾸게 못박아버려도 될 것 같다. 아니면 휴대폰 번호 변경에 대해서 고객사에게 언급해보는 것이 좋을 것 같음. 만약에 변경 기능 추가해달라고 하면 견적 추가.
- [44] 탈퇴시의 정책이 중요하다. -> 탈퇴할 경우 어떤 일이 벌어지게 할 것인지?
- [56] 휴면계정에 대한 정책 결정 -> 어떻게 휴면 계정에 대한 정보를 관리하는가?
- [59] 어떤 결제사를 사용할 것인가?
- [60] 주문한 상품에 대한 부분 취소 -> 결제 API에 대한 내용
- [70] 취소(배송 준비 전) / 환불(배송완료 때) / 교환의 맥락 구분 -> 각각의 프로세스에 대해
- 입금.결제 : 취소, 배송지 변경, 배송 조회
- 배송 준비중 : 교환, 반품(환불), 배송 조회
- 배송중 : 교환 ,반품(환불), 배송 조회
- 배송완료 : 리뷰쓰기, 배송 조회 (7일을 기준으로 교환 / 반품 가능 불가능으로 나뉨) - [대표님] 취소/환불/교환을 제외하고는 모두 존재한다. 자세한 것은 고객사에게 문의를 드려야.
- [46] 자동 로그인
- [대표님] 자동 로그인이 필요하면 로컬 스토리지 사용하여 처리할 수 있지 않을까 하고 설정으로 추가하셨음. 생각보다 까다롭더라도 구현 한번만 해보면, 그대로 사용할 수 있을 듯.
- [75] (페이지 하단) 찜하기 / 구매하기 / 장바구니에 대한 기능은?
- [79] 상품문의 -> 누가 보는것이고, 누가 답변을 어떻게 다는 것인지?
- [86] 카드 결제의 견적에서의 누락 (현금결제..?)