디자인 발전과정과 개발, Q/A 테스트
지난 글에서는 MVP선택, Hi-Fi 와이어프레임, 화면 설계, 그리고 사용자 플로우에 대한 이야기를 다루었다. 이번 회차에서는 디자인 콘셉트와 발전과정, 개발과 Q/A 테스트에 대한 과정을 나눠보려고 한다.
지난 호를 못 읽은 분들이라면 아래 링크를 참고하시길 바란다.
https://brunch.co.kr/@hailey-hyunjee/48
Index
1. 디자인 콘셉트의 변화와 프로젝트 지연
2. 새로운 디자인 콘셉트 발전시키기
3. <찐픽> 디자인 소개
4. 개발 과정
5. QA 테스트
1. 디자인 콘셉트의 변화와 프로젝트 지연
우리 서비스의 구성은 크게 <내기록>, <사진 올리기>, <모두의 기록>로 나뉜다. 얼핏 봤을 땐 인스타그램 기본 프레임과 다를 게 전혀 없는 스펙이다. 하지만 서비스가 커지면서 나날이 복잡해지는 인스타그램의 불편함을 개선하여 '기억'하고 싶은 소중한 순간을 쉽고 빠르게 공유하는 것이 것이 1차 목표였다.
1차 아이디어에 착안해 처음 디자인 콘셉트는 '힐링'과 '꿈' '휴식' '나른함' 등의 키워드를 대표할 수 있는 디자인 색상으로 가게 되었고, 그런 키워드를 대표할 수 있는 색상인 핑크부터 녹색, 보라색으로 이어지는 파스텔톤의 색상 계열을 메인 컬러로 잡았다.
디자인팀에선 약 1-2주가량 힐링 콘셉트를 표현할 수 있는 색상과 디자인 레이아웃을 놓고 고민하였다. 색상을 바꾸기도 하고 곡선의 디자인 패턴을 적용하여 유기적인 디자인을 시도하기도 했다. 하지만 <서비스명>을 결정한 후 그동안 고민했던 모든 디자인 콘셉트를 바꿀 수밖에 없었다.
우리 팀은 <서비스명>이 디자인에 큰 영향을 주지 않을 것이라고 생각했기 때문에 <서비스명>을 결정하기 전에 디자인 콘셉트를 먼저 들어갔다. 하지만 서비스명이 <찐픽>으로 확정되면서 디자인 콘셉트를 완전히 바꿀 수밖에 없었다.
<찐픽>의 '찐'에서 느껴지는 이미지는 통통 튀고, 색도 강렬하거나 선명한 느낌을 지울 수가 없었다. 디자인팀에서 초기에 잡은 '힐링'의 느낌과 '찐'의 느낌은 상반되는 느낌이었기 때문에 이미 진행된 디자인 콘셉트를 가져가는 것에는 무리가 있다는 판단을 하게 되었다.
결국 디자인 초기 단계에서 시간이 지체되었고 결과적으로 프로젝트 전반에도 영향을 끼칠 수밖에 없었다.
배운 점:
1. 항상 그런 것은 아니지만 서비스명에 따라서 디자인 콘셉트가 바뀔 수 있다. 프로젝트를 빠르게 진행하는 팀이라면 서비스명을 확정 짓고 디자인 콘셉트를 결정하는 것이 좋다.
2. 3개월이라는 짧은 프로젝트는 모든 단계가 유기적으로 연결되어 있기 때문에 한 파트에서 1-2주만 지체해도 전체 프로젝트 기간에 영향을 끼친다. 또한 개발 단계로 넘어가게 되면 예상치 못한 일이 생기기 마련이다. 기한 안에 프로젝트를 완수하기 위해선 시간 관리를 더 철저히 하거나 원래 계획보다 1주 더 빨리 일을 마무리하는 게 좋다.
2. 새로운 디자인 콘셉트 발전시키
서비스명이 <찐픽>으로 확정된 이후, 모든 디자인이 일사천리로 빠르게 진행되었다. 기존의 Hi-Fi 와이어프레임을 토대로 <내 기록>, <사진 올리기>, <모두의 기록> 디자인을 진행하였다. 와이어 프레임의 완성도가 높은 덕도 보았지만 함께 협업했던 베테랑 디자이너 덕분에 약 2주간의 딜레이를 무마시킬 수 있었다.
<내기록>과 <모두의 기록> 디자인은 레이아웃을 통한 차별화를 시도하였다면 <사진 올리기> 디자인에선 카테고리화 되어 있는 태그와 하위의 감성 태그를 효율적으로 보이는 디자인에 집중을 하였다.
<찐픽> 서비스의 디자인 특징은 다음과 같다.
1. 유저의 이미지를 집중시켜줄 수 있는 다크 모드 디자인
2. <찐픽> 서비스명에 어울리는 포인트 컬러 도입
3. 디자인 레이아웃을 통한 타 서비스와의 차별화
4. 무분별한 태그 사용을 방지하기 위한 태그 제한 설정 및 원활한 UX 디자인 고민
배운 점:
- 우리 팀은 안드로이드는 코틀린으로, ios는 스위프트로 개발을 진행했기 때문에 각 디바이스에 따른 디자인 규격이 달랐다. 필자의 경우 그동안 ios 디바이스만 디자인을 해서 ios 디자인 규격에만 익숙했었는데 이번 사이드 프로젝트를 통해서 구글 머트리얼 디자인 규격을 제대로 배우는 계기가 되었다.
- 필자보다 훨씬 경력도 많고 유능한 디자이너와 함께 협업을 한 덕분에 디테일한 기본기를 확실히 다질 수 있었다. 디자인을 하다가 막힐 때 질문을 하기엔 너무 쉬운 기능인 것 같아 꺼려질 때가 종종 있다. 평소였다면 책을 찾아보고 이리저리 고민을 하다가 시간을 보냈겠지만 경험이 많은 디자이너 덕분에 하나를 물어보면 2-3개를 덤으로 더 배우게 되는 시간이 되었다.
- 처음으로 진행해보는 다크 모드 디자인의 매력에 빠져버렸다.
3. <찐픽> 디자인 소개
시작하기
온보딩 과정은 서비스의 정체성을 대변할 수 있도록 3장의 이미지로 구성하였다. 이미지를 다 보고 <시작하기> 버튼을 누를 수도 있고 바로 <시작하기> 버튼으로 갈 수 있다.
간편 회원가입을 도입하여 개발 시간을 단축시켰다. 현재는 ios 기준으로 애플 로그인, 카카오 로그인, 구글 로그인이 전부이지만 서비스 수요가 커지면 네이버나 페이스북 로그인을 추가할 계획이다.
메인 페이지
이전 글에서도 말했듯이 <찐픽>의 메인 페이지는 <내기록>이다. 타인의 기록을 먼저 보는 대신 <내기록>을 기록하고 저장하는 것에 집중하였다.
사진이 등록되지 않은 상태의 UX writing 은 딱딱하지 않고 친근한 표현을 사용하려고 하였고 <내기록>을 볼 수 있는 형식은 그리드와 리스트 두 가지 형식으로 나누었다.
그리드 형식의 경우, 유저가 올린 이미지의 크기에 따라서 미리 보기 이미지가 보이는 형태로 디자인했다.
하단 두 번째 이미지에서
1. 그리드 디자인의 왼쪽에 보이는 자신이 올린 이미지를 쉽게 찾아보는 기능이다. 인스타그램에서 불편했던 것 중 하나가 과거 기억을 찾기 위해서 스크롤링을 끊임없이 내려야 하는 것이었다. 디자인팀은 전화번호부 디자인에서 착안을 하여 자신이 올린 이미지를 쉽게 찾아볼 수 있도록 디자인하였다. (보노 디자이너 최고!)
2. <내기록> 옆에 있는 <PICK>은 공개된 <모두의 기록>에서 마음에 드는 이미지를 따로 픽할 수 있는 기능이다. 커뮤니케이션 기능을 없애는 대신 마음에 드는 이미지는 내 공간으로 저장할 수 있는 기능을 부각했다. (커뮤니케이션 기능은 추후 업데이트 예정이다)
모두의 기록
<모두의 기록> 디자인에도 레이아웃의 변화를 주어 이미지가 지그재그로 보일 수 있도록 디자인하였다.
작은 모바일 화면에서 이미지가 더 줄어들면 사용자 경험이 떨어질 수 있었지만 평소에 해보지 못한 레이아웃을 디자인하는 것이 디자인팀의 목표 중 하나였기 때문에 약간의 무리수를 두고 디자인을 진행하였다.
일단 디자인팀은 자체 만족하고 있다. :)
1. <모두의 기록>을 보다가 관심이 있는 사진은 <Pick>을 선택할 수 있다. 그럼 <내 기록>에 픽한 이미지가 저장되고 저장된 이미지는 쉽게 찾아볼 수 있도록 디자인하였다.
상세 지도
초기에 사용자가 기록한 모든 장소를 지도로 보는 기능은 메인 페이지에 바로 보이도록 설계되었으나 실제 디자인에선 지도 아이콘을 눌러서 상세내역을 볼 수 있도록 변경하였다. 결과적으로 훨씬 깔끔하고 군더더기 없는 메인 페이지가 탄생할 수 있었다.
이미지 업로드
초반부터 우리 팀에서 핵심 스펙으로 강조했던 스펙이 '쉽고 빠르게 기록하기'였다.
인스타그램의 무분별한 태그에 피로감을 느낀 유저들을 위하여 태그 카테고리를 크게 나눠서 그 안에서 감성 태그를 선택할 수 있는 플로우로 디자인을 진행하였다. 감성 태그의 경우 서비스가 출시되면 기획팀에서 유저들이 자주 사용하는 태그를 정기적으로 업데이트해서 제공할 예정이다.
글을 등록할 때도 유저가 <공개>와 <비공개>를 선택할 수 있게 하는 자유도를 제공하였다.
또한 초기 스펙에서는 사용자가 글쓰기에서 태그를 달아도 활성화되지 않도록 하였지만 버전을 업데이트하면서 사용자가 달 수 있는 태그수를 한정시키고 활성화시키는 방안도 계획 중이다.
찐픽 로고와 아이콘
안드로이드와 ios를 별도 제작하여 디자인하였다.
4. 개발 과정
1-2주의 디자인 진행의 시행착오가 끝이었으면 좋았으련만 더 깊고 높은 산이 우리를 기다리고 있었다. 바로 이 디자인을 얼마나 실제로 구현이 가능한가이다.
초반의 빵빵한 기획안은 디자인에서 한 번 걸러지고 개발에서 또 한 번 걸러진다.
우리 팀의 프런트엔드 개발자들은 모두 웹 기반의 개발을 전문으로 하던 사람들이었고 모바일 기반 개발은 이번 프로젝트가 처음이었다. 또한 안드로이드와 ios를 따로 개발하면서 한 명은 안드로이드, 한 명은 ios 개발을 진행하였다. 그리고 코비드 19로 인해 미국에 있던 개발자들은 중간에 한국에 들어오고 나가는 등의 복잡한 일들이 생겼고 그 기간 동안 2명의 개발자는 2주간의 자가격리를 겪기도 하였다.
그런 쉽지 않은 개발 환경이 있었기에 프로젝트가 후반으로 갈수록 '과연 우리 서비스를 앱스토어에서 볼 수 있을까?'란 회의적인 생각을 끊을 수 없었다. 부정적인 생각이 스멀스멀 올라올 무렵, ios를 담당한 조셉 개발자는 2주간의 자가격리 기간 동안 엄청난 양의 개발을 진행하고 있었다!
일반적으로 회의를 진행하면 개발자들은 말수가 별로 없다. 기획팀과 디자인팀에서 열띤 토론을 한 후에 개발이 가능하냐고 물어보면 거의 대부분은 '가능할 것 같습니다.'라고 화답한다.
하지만 이 말에는 숨은 뜻이 있다.
"(시간이 많으면) 가능할 것 같습니다."
로 이해해야 한다.
조셉 개발자 역시 질문을 하면 대부분 긍정의 메시지로 답을 했지만 사실 반은 믿고 반은 걸러냈었다.(조셉, 미안!) 점점 의심의 늪으로 가려던 어느 날, 조셉은 기적처럼 엄청난 양의 개발을 진행했고 결국 테스트 앱까지 마무리지을 수 있었다!!!!!
업무용 슬랙에 테스팅 앱을 깔고 팀원들과 감격했던 9월의 어느 날.
배운 점: 개발자들의 언어는 디자이너들의 언어와 사뭇 다르다!
5. QA 테스트
끝날 때까지 끝이 아니야
끊임없는 테스트, 테스트, 테스트....
개발의 끝은 또 다른 시작이라는 말이 있었던가? 끝날 것 같지 않았던 개발의 긴 터널을 지나 감격스럽게 테스트 앱을 실행하고 작동해 보는데 버그가..... 버그가...... 많아도 너무 많았다.
노션을 통해 버그 이슈를 올리고 수정하는 과정을 반복하고 있다파리에서 (특별한 정보 없이) 베르사유 궁전을 가 본적이 있는가?
전철을 몇 번 갈아타고 힘들게 베르사유 궁전에 겨우 도착하면 전철역에서 약 20분을 걸어 궁전으로 가야 한다. 궁전 앞에 도착했는데 입장료 구입에 1시간, 입장하는데 1-2시간을 더 기다려야 한다. 입장은 했는데 사람에 치여서 인파서 쏠리듯이 궁전 내부를 봐야 하는 그런 느낌을 아실는지??
배운 점:
끝날 때까지 끝이 아니다. 처음부터 끝까지 중요하지 않은 부분이 없다. 하나의 아이템이 기획을 거쳐 서비스로 구체화되는 과정, 화면 설계가 디자인이란 옷을 입고 전혀 다른 분위기로 발돋움하는 과정, 우리의 디자인이 모바일 앱으로 탄생하는 과정, 그 앱이 백엔드의 서버와 만나 실제 구현이 가능해지는 과정, 모바일앱이 어디서나 부드럽게 작동되는 과정 등 모든 과정이 중요하다.
우리끼리 만들어서 사용하는 앱이 아니라 시장의 심판을 받아야 하는 앱은 거쳐야 할 것이 정말 많았다. 누군가에게는 이 정도 퀄리티밖에 안되냐고 무시할 수 있어도 3개월 동안 이 모든 과정을 경험한 입장에서는 완성도 높은 퀄리티 못지않게 과정에서 배운 경험들이 셀 수 없이 많았다.
다음 시간에는 끝을 향해 달려가는 찐픽앱의 버그 잡기 과정을 간단히 소개하고 프로젝트를 통해 느낀 점을 나눠보려고 한다. 또한 앱스토어에 등록되어 있는 <찐픽>을 소개하며 화려한 막을 내릴 수 있기를 바라본다!
