수형 : 이벤트 카드에서 인원, 시간 등은 텍스트로 표현해도 괜찮지만 이모티콘이나 다른 방식으로 표현되면 더 좋을 것 같다. 스케쥴 관리하는 페이지도 없을 예정이고 실제로 이벤트 카드에 띄우는 내용이 많지 않아 현재 와이어 프레임의 카드 크기보다 더 작게 만들어질 것이다.

소원 : Q8) 컨셉 컬러 생각해 둔게 있는지?

수형 : 일단 젠리(모션과 지도, 아이콘 등)와 애플지도(검색 방식)를 벤치마킹 할 예정. 젠리처럼 동글동글한 느낌과 색감을 참고하면 좋을 것 같다.

규호 : + [1번]처럼 지도가 알록달록하면 핀과 구분이 잘 안될 것 같다.

수형 : 젠리처럼 주변 건물정보들을 다 지우고 보여줄 예정

소원 : Q9) 지도 디자인은 따로 해야하는가?

수형 : 애플 지도를 그대로 사용할 예정.

소원 : Q10) 옆의 표(miro의 db구조 트리)를 봤을 때 검색, 만들기, 스케쥴 기능이 중점적인데 버튼으로 만들 생각인지?

영훈 : 중점적인 것은 맞는데 아직 액션을 규정하지 않았다. 굳이 버튼이 아니어도 괜찮음.

추가적으로 바라는 UI 요구사항

영훈 : 핵심은 카드 부분과 검색 창이기 때문에 이 위주로 디자인 해주시면 감사하겠습니다.

수형 : 규호님이 말씀하신 것처럼 핀 또한 처리를 어떻게 하면 좋을지 조언 부탁드립니다.

수형 영훈 : 젠리는 아이콘 단계에서 시간과 다른 정보가 같이 표현되는데 우리도 유사하게 인원이나 시간정보가 [1번]지도 위에서 표현되면 좋을 것 같다. (복잡성과 가시성을 고려한 UI)

수형 : 추가적으로 한손으로 조작이 편리하게 하기 위해 주요기능들이 휴대폰의 하단에 위치했으면 좋겠다. 그 외 기능들은 상단에 위치해도 괜찮음.

2. 소원님과 와이어 프레임 UI 본격 이야기

카드뷰 vs 리스트뷰

의민 : <카드뷰>에서 왜 하나만 포커싱 해서 보여주는지 의문이다.

수형 : 일정들을 그때그때 포커싱하기 위해 설계했다. 또한 만약 <리스트뷰>로 할 경우 1인당 모임 수가 적어 화면상에 꽉 안 찰 것이기 때문에 <카드뷰>로 계획하고 있었다.

소원 : [1번]에서 화면을 끌어올려서 [2번]으로 넘어가는 동작 ⇒ 사람들은 심리상 위로 끝까지 올리고 싶어함. 따라서 이벤트 카드들도 화면에 꽉차게 표현하는 것이 좋을 것 같다. → 영훈 : 그럼 <카드뷰>보단 <리스트뷰> 형식으로 가는 것은 어떤가? →

소원님 그림

영훈님 그림

수형 : 그럼 <카드뷰>와 <리스트뷰> 별로 화면에서 최대 몇개까지 보여줄 수 있을지 생각해보자.

규호 : <카드뷰>와 <리스트뷰> 둘 중에 기본형을 먼저 정하고 다른 형태로 바꿀 수 있도록 하자.

수형 : . 둘다 시도해보고 정하는 것도 괜찮은 것 같다.

와이어 프레임의 매끄러운 연결

영훈 : 검색창은 위로 스와이프 했을 때 없어지는가?

수형 : 실제로 없애는 어플들도 있고 그대로 남겨두는 어플들도 있다.

소원 : 앱을 새로 켰을 때 모임이 잡혀있는 상황이면 어떻게 [2번]으로 넘어가게 할 것인가? 따로 버튼이 없는가? 카카오맵 처럼 하단에 버튼을 클릭해서 다른 카드가 나오도록 해야 잘 사용할 수 있지 않나?

영훈 : 검색바를 하단에 배치했기 때문에 버튼까지 추가하기엔 무리일 것 같다.

소원님 사진

소원 : [1번]과 [2번] 사이에서 연관성이 많이 부족한 것 같다. 유저 입장에서도 불편할 것으로 예상된다.

영훈 : 최대한 버튼을 없애서 깔끔하게 앱을 만드려고 했는데 소원님 말대로 오히려 버튼이 없을 때의 효용이 더 작은 것 같다. 젠리처럼 좌 우로 스와이프 하여 다른 기능이 등장하게 하는 것은 어떤가?

수형 : 최대한 버튼의 수를 줄여서 지도를 최대한 넓게 쓰고싶었다. 그럼 일단은 다음과 같은 버튼 형식으로 고려해보겠다.

수정된 디자인

초기 이벤트가 없을 경우

의민 : 생성된 모임이 없을 경우 띄울 이벤트가 없을 것이고 그럴 경우 그냥 애플지도가 되지 않는가? 띄울 이벤트가 없었을 때 생각한 부가기능이 있는가?

수형 : 젠리도 친구가 없으면 아무것도 띄우지 않고 그냥 애플지도이다. 따로 부가기능을 넣기보단 반경 3km 내의 모임들을 뷰에서 표현하고자 한다. (현재 화면을 벗어난 모임도 화면 안에 표시)

의민 : 젠리의 집모양 처럼 모임이 없을 때 저런 재미요소가 있었으면 좋겠다.

영훈 : 그래서 젠리의 하트 뿅뿅과 같은 인터렉션이 필요했다.

수형 : 지금은 핵심개발 단계이고 유령콕과 위 인터렉션이 제외되어 있는 상황이기에 일단은 수동으로 추가할 예정이다.

의민 : 지도의 경우 처음부터 다시 만들어야 하는 작업인지 아니면 간단하게 디자인 할 수 있는 것인지 궁금함. ⇒ 초기 어플의 부족한 귀여움을 채우기 위해

수형 : 실제로 커스터마이징 지도가 인터넷에 있지만 유료이다. 따라서 지금은 애플지도가 최선이고 그 위에서 귀여움을 추가할 수 밖에 없을 것 같다.

우리의 핵심기능 = 지도

수형 : 지도를 옮길 때마다 업데이트가 된다. 최대한 <리스트뷰> 등을 넣지 않고 심플하게 가져가고 싶었다.

영훈 : 어플의 핵심이 지도이기 때문에 지도 위에서 모든 것을 가능하게 구현하려고 했다.

의민 : 탐색할 때는 지도가 필요하더라도 만날 때는 딱히 지도가 필요 없지 않을까?

영훈 : 만날 때도 지도가 필요하다. 도로명주소로 보여주는 것보단 지도로 보여주는 것이 직관적이기 때문. 그리고 스케쥴을 화면의 반까지 올라가도록 한 이유도 지도가 핵심이기 때문이다. DB단에서도 위도, 경도를 저장해서 보여줄 것이기 때문에 핀이 가장 유용할 것으로 생각했다.

규호 : + 핀을 누르면 핀이 확대되면서 상세정보를 보여주는 제스쳐는 어떤가? 수형 :

의민 : 젠리랑 당근마켓 이야기에서 젠리는 지도를 중심으로 사용하지만 당근은 사람이 만나서 거래하는 것임에도 불구하고 1. 동네로 한정되어 있고 2. 물건의 거래가 더 중요하기 때문에 지도가 큰 부분을 차지하지 않는다. 우리도 지도가 중심인지 그 외 모임의 상세정보가 중심인지 고려해보는게 어떨까?

반반지도

의민 : 그리고 사진처럼 지도를 반으로 나눠서 사용하는 것은 어떤가?

영훈 : 우리 어플의 경우 상세정보가 심플하기 때문에 지도가 더 중요하다고 생각한다.

수형 : 반반지도를 해본 경험이 있는데 상당히 답답했다. 유저의 동선이 꼬이는 문제도 있었다. 근데 지금 상황에서는 반반도 나쁘지 않을 것 같다. 해봐야 할 듯

소원 : 둘 다 괜찮을 것으로 보임.

의민님 사진(반반지도)

기타 짧은 이야기들

의민 : 그런데 소원님이 띱에서 넵으로 좀 더 린하게 가는 상황을 알고 있는가?

수형 :

(상황 설명 한줄 요약 : 최대한 핵심 기능만 빠르게 만들고 앞으로 부가 기능을 추가할 예정)

영훈 : 핀이 여러개가 있을 경우 일일이 눌러서 확인해봐야 하기 때문에 리스트뷰의 필요성을 느낀다.

수형 : 그럼 일단 검색 버튼을 중간에 넣고 추후에 좀 더 생각해보자.

소원 : 젠리와 거의 비슷하게 갈 것인가?

수형 : 젠리와 유사한 UI를 가지는 것은 맞다. 하지만 핵심 기능이 다르기 때문에 문제될 것은 없음.

이벤트 카드와 상세주소에 대한 토론

의민 : '사보이 1층' 은 장소인데 날짜 처럼 아래 따로 두는 것이 맞지 않나? ⇒ 상세 주소 칸은 없는 것인가?

경민 : 추가적으로 동일 위치여도 층 수가 다르면 위치가 다른 것이기 때문에 상세주소가 필요할 것 같다.

영훈 : 아직 상세주소의 필요성을 잘 못느끼겠다.

의민 : 핀만 찍히고 상세주소를 안알려주면 길을 찾기에 어려움이 있을 것이다. 그리고 자신의 위치를 알려주지 않는데 상세 주소라도 안알려주는 것은 문제가 있지 않나?

규호 : 엥? 제 위치가 안나오나요?

수형 : 넵. 스케쥴에서는 나오지 않습니다...

의민 : 그럼 영훈님이 상세주소가 필요하지 않다고 생각하는 이유는 무엇인가요?

영훈 : 젠리같은 경우에는 실제로 상세주소가 나오지 않고도 충분히 잘 만나고 있습니다.

의민 : 하지만 그 경우는 친구이기 때문에 다른 통신 수단으로 연락이 가능하다. 우리는 모르는 사람들과의 모임이기 때문에 상세주소가 필요하다고 생각한다.

규호 : 충분히 인정한다. 그런데 여기서 '그 불확실성을 해결할 방법이 상세주소 뿐인가?' 도 생각해보면 좋을 것 같다. 추가로 상세주소로 간다면 상세주소 복붙기능도 넣어봐요.

소원 : 참고로 상세주소가 저 ui에 포함된다고 해서 더러워지는 것은 아니다. 충분히 깔끔히 가능

영훈 : 하지만 몇 층인지는 제목에서 충분히 표현할 수 있지 않나? 정 모르겠다면 다른 어플들을 통해서 위치를 찾을 수 있다. ⇒ 아직 그 '불확실성을 해결할 방법의 정답이 상세주소 뿐인가?' 에 대한 의문이 남아있다.

의민 : 모임을 만드는 입장에서는 당연히 장소를 안다고 생각하고 만들 것이다. 하지만 참여자는 장소를 잘 모를 수도 있으니 여기서 생기는 유저간 불편함이 있을 것이다.

영훈 : 그럼 db에 상세주소를 넣을까요?

의민 : 추가로 젠리의 경우는 친구들이기 때문에 핀으로 대략적인 장소파악이 가능하다. 하지만 우리 어플의 경우 모르는 사람과 모이기 때문에 그 장소파악이 쉽지 않을 것 같다.

수형 : 일단은 핀만 찍는 것으로 정했는데 추후 장소 선택과 관련된 회의를 해봐야 할 것 같다.

ETC

규호 : db구조는 언제 잡나요?

수형 : 일단 다음주 수요일 멘토링을 잡아놨는데 주말이나 다음주 월요일에 한번 회의를 진행하는 것이 좋을 것 같다. 추가로 멘토님께 물어보고 싶은 것은 db 구조를 최소한으로 잡고 시작하는 것이 좋은지, 최대한으로 잡고 시작하는 것이 좋은지 그 기준에 대해 물어보고 싶다.

영훈 : 참여테이블을 만드는 것이 좋은지, 아님 쿼리를 어떻게 날리는 것이 좋은지도 명확히 물어보고 싶다.

수형 : 그럼 db회의는 일요일 2시로 합시다!

규호, 경민, 의민 :

수형 : 금요일 12시에 와이어프레임을 더 디테일하게 논의해보자. 소원님 참여 가능하신가요?

소원 :

수형 : 그리고 어플의 flow 등의 부분도 더 디테일하게 다듬어보자.

다음 회의 주제

•

와이어 프레임 구체적 논의-2

◦

우리의 앱은 지도중심인가? 상세정보 중심인가?(feat. 젠리와 당근마켓)

◦

스케쥴 뷰는 풀스크린인가? 반반인가?

◦

상세주소 , 장소선택