jun-as-designer

[jun-as-designer]

친구 개발자와 새벽 두 시..라는 다소 오글거리는 제목의 어플리케이션을 개발하기로 했다. 사진에 아트워크를 합성할 수 있는 앱이다. 역시 이런 앱은 얼마든지 많다. 새벽 두 시의 차별성은 위트있는, 혹은 감각적인 문구의 아트워크를 제공한다는 데 두기로 했다. 결국 시스템을 갖춘 다음에 콘텐츠 차별성으로 승부를 봐야 한다. 내가 캘리그래피 입문자 수준인 건 차치하자. 

스플래시 스크린에 오랜만에 정성을 쏟아 봤다. 새벽 길을 가다 올려다 본 어느 불이 켜진 창가의 이미지를 연출하고 ‘새벽 두 시’라는 텍스트를 세리프 서체로 넣어 늦은 밤에 쓰는 어떤 글..을 연상할 수 있게 해보았다. 더미 이미지를 보여주더라도 사용자가 대기 시간을 짧게 느끼도록 하는 게 권장되는 요즘엔 딱히 스플래시 이미지가 기억나는 서비스가 없다. 그래도 ‘새벽 두 시’는 좀 더 유저에게 감성적 소구를 하고 싶은 의도가 있어 스플래시 스크린에서 서비스 분위기를 전달해보려고 했다. 

Sketch 플러그인 - inVision Craft 를 활용한 프로토타이핑

난 inVision을 좋아하지 않았다. 프로토타이핑 툴 중에서도 fidelity가 떨어져서 버튼을 클릭하면 화면이 넘어가고, 헤더를 고정시킨 상태에서 스크롤이 가능하다 정도 외엔 표현할 수 있는 인터렉션이 풍부하지 못했기 때문이다. 그래서 Pixate를 써왔는데 왜 서비스가 종료된거니..

프로토타이핑 툴로 경쟁력이 떨어지는 inVision이 이번에 제대로 노린 게 있다. 간단한 인터렉션 디자인을 Sketch에서 끝내버릴 수 있게 Craft에 넣었다는 거다. 위의 이미지처럼 그냥 드래그, 드래그, 드래그 반복으로 각 화면간 인터렉션을 정���할 수 있다. 사실 그리 복잡한 인터렉션 디자인을 할 게 아니라면 framer나 pixate를 쓰기 귀찮아지곤 하는데, 이정도 접근성이라면 쓸만했다. 아래는 위의 프로토타입 동작을 녹화한 것.

이정도 프로토타입만 만들어 봐도 여러가지를 검증할 수 있다. Sketch상의 정적인 화면만으로는 화면 흐름이나 유저의 행동에서 발생하는 예외적인 케이스들을 모두 예측해내긴 쉽지 않다.

아트워크 선택 후에 사진을 선택하게 하기

‘새벽 두 시’와 유사한 대부분의 앱들은 사진을 먼저 선택하고 아트워크를 다음에 선택하게 흐름이 구성되어 있었다. 사진 위에 본인이 직접 메시지를 적기 원하는 사용자들에겐 adobe spark와 같은 서비스가 알맞고, 이 경우엔 사진 선택이 먼저 와도 괜찮다. 하지만 위에 설명한 것처럼 우리는 아트워크 콘텐츠가 가진 차별성으로 유저를 붙잡을 생각이라, 사진부터 선택하는 흐름은 그다지 도움이 되지 않는다. 그래서 우리는 우리가 제공하는 아트워크 중 가장 많이 사용되는 것들을 추려서 ‘인기’ 탭으로 두고 앱 실행시 해당 화면에 랜딩시킬 생각이다.

↑ 직접 쓴 게 맞긴 한데.. 메시지와 캘리 실력은 좀 더 다듬어보자.

그래서 ‘인기’ 탭에서 첫 눈에 들어오는 아트워크 중에 분명히 관심을 사로잡는 아이템이 있어야 한다. 요즘 뜨는 유행어 같은 것들이 여기 들어가 있으며 좋을 거다. 요즘 분위기로 치면 ‘그뤠잇’ 같은?

맘에 드는 아트웍을 골랐다면 거기에 어울릴 사진을 고르도록 안내된다. 사진의 ‘다운로드’탭에서는 언스플래시 이미지를 긁어와서 보여줄 생각이다. Over같은 서비스에서 이미 그렇게 하는 걸 봤는데 좋은 접근인 것 같다.

편집 단계

사진은 크롭 단계가 하나 더 들어가 있다. 이 단계부터는 인터페이스 컬러 테마를 어두운 톤으로 바꿔서  사용자에게 이전과는 다른 성격의 단계에 들어왔다는 걸 알려주려고 했다.

편집 단계에서 제공하는 기능은 아래와 같다.

사진: 크롭, 필터 적용 

아트워크: 리사이즈, 위치 조정, 컬러 변경

위와같은 사진과 아트워크의 편집이 한 화면에서 이뤄진다고 할 때, 어떻게 두 모드를 오갈 것인지 생각하던 끝에(탭을 나누나..?), 그냥 직관적으로 사진을 탭한 경우 사진 편집 모드가, 아트워크를 탭한 경우 아트워크 편집 모드가 실행되게 했다. 벤치마킹한 다른 서비스들도 이 방식을 가장 많이 택한 것으로 봤다.

그리고 각 편집 모드에서는 선택한 사진 또는 아트워크에 보더라인을 노출해서 사용자에게 선택 상태를 알려주고, 아트워크의 경우 보더라인 우하단에 리사이즈 핸들로 사용할 수 있음을 암시하는 앵커 포인트도 노출했다.

흠.. 이제 디자인은 끝난 것 같다. 개발만 마무리 되면 되겠군..

↑ 나만의 규칙을 따라 깔끔하게 정리된 아트보드 레이블링과 배열. 이너피스.

마침 이 무렵 제플린 업데이트에서 아트보드의 섹션 구분과 접기, 펴기를 지원하기 시작했다. 이것만 해도 정말 유용하다.(예전에 어느 개발 팀장이 제플린 아트보드 순서 안 맞다고 나한테 어필했던 기억이 나네..ㅡㅡ)

자, 이제 코딩에 들어가기 전에 필요한 모든 디자인 작업은 끝이 났고, 디자인 에셋들도 모두 착착 res 폴더 안에 dpi별로 정리를 해뒀다. 이렇게 관리를 하면 이미지 에셋이 변경돼도 개발자와 싱크가 어긋날 리가 없어서 효율적이다.

개발 마감 일정이 나오면 아마 또 TC를 쓰고 마케팅 준비를 하느라 귀찮겠다 바쁠테지만, 이번 프로젝트도 재밌는 학습이 되길 바라고 있다. 이런 게 엑스트라프로젝트의 묘미랄까.

[jun-as-designer]

같이 프로젝트를 했던 개발자가 알람을 만들자고 했다. 본인의 필요에 꼭 맞는 알람 앱이 없다며.. 이 친구에겐 매일 새벽 5:10분 알람을 스누즈 없이 진동만으로 착착 일어나는 나는 상상도 못할 특이한 기상 매커니즘이 있었다. 그래서 그 필요를 충족시켜주는 앱을 만들어보기로 했다. 일단 잠재고객이 1명이니 문제의 분석과 솔루션 도출에 집중하기도 쉬웠다.

이 앱의 개발자이자 유일한 잠재고객이 기존의 알람앱을 사용하면서 겪고 있는 문제는 아래와 같았다.

아무리 많은 알람을 설정해놔도 잠결에 알람을 꺼버리고 일어나지 못한다.

타이머를 복수로 설정할 수 없어서 동시에 여러가지 행동의 시간을 관리해야할 때 능률적이지 못하다.

사실 이런 문제를 해결하기 위한 다른 앱들은 이미 많다. 1의 문제 해결을 위해서는 특정 공간으로 이동해서 약속된 물건의 사진을 찍어야만 알람이 종료된다거나, 게임을 해서 통과해야 한다거나, 알람이 꺼질때까지 폰을 세차게 흔들어야 한다거나..하는 식의 솔루션들이 있었다. 하지만 이런 것들은 귀찮음이 모든 것을 이기는 잠재고객님의 마음에 들진 않았다. 2의 문제를 해결하기 위한 앱들도 많이 있었는데, 이 친구는 한 번 설정한 타이머는 사용 후에도 삭제되지 않고 유지되길 원했다. 예를 들면 마스크팩을 붙일 때마다 사용할 수 있는 15분 짜리 알람은 한 번 만들어 두고 계속 사용할 수 있으면 좋겠는데 매번 세팅하기 귀찮다는 거다.

그래서 aka ‘미미알람’ 프로젝트가 시작됐다.(미미는 개발자의 별명에서 따왔다.) 인터뷰를 통해 정리된 이 제품의 요구사항은 다음과 같다.

안드로이드 어플리케이션으로 개발한다. → 타겟 유저가 안드로이드를 사용한다.(혹은 안드로이드 개발자다..;)

알람과 타이머 기능이 있다.

알람은 복수를 생성할 수 있으며, 각 아이템은 요일 반복 기능과 스누즈 기능이 있다. → 남들 있는 건 다 있어야 한다.

사용자의 선택에 따라, 알람이 울리는 화면에서 아예 알람을 끄는 버튼을 노출하지 않을 수 있다. → 잠결에 알람을 끄지 못하도록 하는 특단의 조치다. 단, 앱 내에 진입하면 울리고 있는 알람의 목록을 보고 중단할 수 있다.

타이머는 복수를 생성할 수 있으며, 사용한 알람은 비활성화 상태로 전환되고 삭제하지 않는다. → 빨래용, 팩용, 조리용 등으로 활용하시고 싶단다. ...이쯤에서 우리는 아무리 이게 둘이서 하는 엑스트라 프로젝트지만, 혹여나 지구 어딘가에 더 있을지도 모르는 비슷한 니즈를 가진 사용자들을 커버하고 싶다는 생각이 들었고, 그러면 수익을 낼 수 있는 방법을 고안하면 좋겠다고 생각했다. 그래서 요구사항이 하나 더 추가된다.

사용자에게 앱의 테마를 바꿀 수 있는 옵션을 제공하고, 테마를 바꾸는 조건으로 리워드 동영상 광고(admob)을 시청하게 한다. → 이건 우리 고객님으로부터 천재적인 발상이라는 칭찬을 들었다. 하지만 결과를 보면 그리 천재적인 발상은 아니었던 것으로..

디자인 시작

Sketch 아트보드를 채워 나간다. 나만의 규칙은, 횡 방향으로는 사용 과정에 따른 동위의 화면들을 배열하고, 종방향으론 그 화면에서 나올 수 있는 베리에이션 화면들을 그린다. 동시에 아트보드의 넘버링을 깔끔하게 해서 관리하는 게 큰 제품의 디자인일수록 중요해진다. 기획서가 있는 프로젝트라면 기획서상의 화면 넘버링과 일치시켜 두는 게 파트간 커뮤니케이션에 좋더라.

요구사항이 정리됐다고 바로 디자인 툴로 다이브인 하는 걸 우려하는 사람들도 많지만, 나는 페이스북의 DONE is better than PERFECT 정신을 정말 좋아한다. 최대한 짧은 주기로 반복해서 여러번 만들어나갈 때 예측이 도달할 수 없는 범위의 문제를 해결할 수 있다고 생각한다. 한 번 앉았다가 자리에서 일어날 땐 perfect하진 않더라도 done 상태의 결과물이 있어야 평가와 개선이 빨라진다. 이 프로젝트도 매일 매일 1픽셀의 업데이트라도 만들어내는 데 집중했다.

요구사항 1~5를 충족하는 방향의 디자인이 완성되고, 이제 6번이 남았다. 앱 테마 컬러. 이건 미리 개발자와 상의해두고 컬러를 경제적으로 관리를 했기 때문에 아래 이미지처럼 구글독스에 각 테마별로 10개의 컬러 값을 지정해주는 것으로 테마 베리에이션이 가능해졌다. 

그리고 Zeplin으로 스펙을 전달하면 개발 준비가 완료 된다. 이제 진디사대천명(디자이너가 할 일을 끝내고 개발 결과물을 기다린다) 상태가 되었다. 스펙을 제대로 잡았다면 제플린으로 공유한 것 이상으로 디자인에 관해 왈가왈부할 건 없다. 결과물이 어떻게 나왔는지는 앱을 받아 보시면 알 듯. 

QA를 해보자

두 명이서 진행하는 프로젝트니 기획서는 쓰지 않았지만, QA는 할 필요가 있다고 압박을 받았다 생각됐다. 그래서 TC를 써내려가기 시작한다. 스펙에 대한 상세한 합의를 문서화한 적은 없으니, TC 작성 중에 개발자와 내가 서로 기능에 대한 이해가 다른 사항을 꼼꼼하게 확인하고 협의할 수 있었다... 라고 쓰고 ‘그게 왜 그렇게 동작해야 해?’하고 싸웠다고 읽는다.

명세기반으로 테스트를 진행하지만, 케이스들은 주로 유저의 행동에 대한 기대결과 형태로 굵게 잡았다. 명세기반과 탐색적테스팅의 중간쯤 어디랄까. 그리고 그 케이스를 확인하는 데서 발행한 추가 이슈들은 코멘트 컬럼에서 치열한 키배를 통해 결론을 내렸다. 구글 독스도 컨플루언스처럼 코멘트에 대해 댓글을 달고, 해결상태로 아카이빙 할 수 있어서 이런 토론에 유용하다.

총 106개 케이스를 도출하고 업데이트 된 apk 파일이 나올 때마다 Fail 이슈들을 확인했다. 사실 Pass된 항목들까지 모두 리그레션 테스트를 하는 게 정석이지만 나는 사파라서.. 

앱 출시!

이름은 알람 - 기상을 부탁해로 정하고, 스토어정보에 소개글을 쓰며 검색에 걸리기 위한 나름의 SEO를 했다. ‘기상’이 7번, ‘알람’이 12번, ‘타이머’가 5번 반복해서 노출되는 앱 설명을 작성하고 스크린샷 이미지들은 제품 이상의 매력을 표현할 수 있게 하려고 애썼다. 구글플레이에는 애플 앱스토어와 달리 키워드를 따로 쓰는 란이 없으므로 앱 소개글을 잘 써야 검색에 걸릴 확률이 높다.(하지만 지금까지도 구글플레이에서 ‘알람’을 검색하면 우리 앱은 안 나온다. 아 알람 시장은 너무 레드오션이었어......)

구글플레이엔 베타 버전 출시 기능이 있어서 그걸 활용해서 closed beta 테스트를 했다. 나는 친구가 없어서 개발자가 주변 사람들에게 테스트 버전을 깔아보게 하고 일주일정도 반응을 봤다. 자잘한 오류들을 찾아준 분들, 이 플젝이 깃헙에 오픈 돼 있다 보니 빌드를 해보겠다고 설치는(?) 님도 있었다고 한다..

그리고 대망의 리얼 릴리즈를 했다!

마케팅을 해야겠다

완성도가 낮은 제품을 내어 놓으면 엔지니어로서 내 평판이 나빠 지지는 않을까 혼자서 걱정했다. 사람들이 내가 완성도 있는 서비스 를 개발하는 방법을 모른다고 생각할까봐 걱정되었다. ... 그런데 막상 출시하고 보니, 아무 일도 일어나지 않았다. 걱정하던 불안감은 아무런 근거가 없는 것임이 밝혀졌는데, 아무도 우리 제품을 쓰지 않았기 때문이었다. - 에릭 리스, <린 스타트업> p.42

역시 그런 일이 일어났다!... 하지만 그럴 줄 알고 우리는 크게 힘들여 만들지 않았으니 괜찮다. ^^ 진짜다. 진짠데..

그러던 중 마침 애드워즈에서 3만 크레딧 이상 지출하면 10만 크레딧을 준다는 메일이 와서 미끼를 물어 보기로 했다.

애드워즈 기록을 보면 유니버셜 앱 프로모션으로 처음 3만 크레딧으로 첫 주간 꽤 급격한 커브를 만들어내다가 중간에 크레딧이 소진되고 주말간 업데이트를 못해줘서 급락, 월요일에 부랴부랴 프로모션으로 받은 10만 크레딧으로 일 1만 크레딧 캡으로 다시 진행했는데 전과 같은 상승세는 다시 나오지 않아서 정말 아까웠다. 10만 크레딧은 일 예산을 꽉꽉 채우면서 10일간 진행이 됐다. 결론적으론 1천 다운로드 정도 상태에 머물렀다. 그리고 역시 광고를 하지 않으니 아무 일도 일어나지 않는다^^. 

중간에 캠페인을 유니버셜 앱 타입에서 검색 키워드 타입으로 전환해봤다. 아래 그림에서 캠페인1이 유니버셜 앱 타입, 캠페인2가 검색 키워드다.

캠페인 2에 해당하는 검색 키워드는 ‘알람’, ‘알람 앱’, ‘모닝콜’, ‘타이머’ 등이었다. 다른 자료들과 종합하면 대충 결론이 나오는데.. 검색 키워드 광고는 CTR은 높았다. 그러면 과연 앱 사용자도 늘었냐. 그건 firebase에서 집계된 정보랑 비교해보면 전혀 아니다. 결국 알람 앱을 받으려는 목적이 분명한 사람들은 이런 저런 앱을 비교해보느라 검색 → 우리 앱을 클릭할 수는 있지만 결국 다운로드는 하지 않았다. 알람앱 군에서 비교해보면 그리 매력은 없다는 거다.(현실직시) 결국 검색 키워드 광고는 CTR은 굉장히 높게 나오지만 앱 인스톨로 이어지진 않아서 우리에겐 비용 부담만 너무 큰 광고 형태다. 

아래 그래프는 키워드 광고 집행 기간인데, 총 5일간 총 CTR이 100정도 나왔지만 아래 동기간의 firebase의 활성 사용자 집계를 보면 DAU가 꿈쩍도 하지 않는다. 5일만에 이건 아니다 판단하고 빠르게 유니버셜 앱 프로모션으로 전환..

그래서 오히려 알람을 받으려는 목적이 분명한 사람이 아니라 일반 유저들을 대상으로 광고를 노출하면 광고 효율이 높은 편이었다.

  내친김에 A/B 테스트도 해보자

출시 후 프로모션 기간에 구글플레이에서 제공하는 스토어 등록정보 실험 기능을 통해 스토어에서 앱 소개 화면 진입시 상단에 뜨는 이미지의 A타입과 B타입을 실험해봤다. 소박하게.. 

사실 좀 더 극단적으로 메시지의 차이가 있거나 그래픽이 완전히 다르면 더 의미있는 실험이 되었겠지만 이정도로 준비했다. 사실 저 이미지를 가지고 어느게 좋냐고 토론하면 이런건 취향의 문제라 굉장한 소모전이 된다. 유저에게 물어보면 될 것을!

결론은 오른쪽의 이미지가 근소하게 앞섰다. 의미있는 데이터가 되려면 모수도 훨씬 많고 실험하려는 목적도 분명했어야 하는데 아쉽지만 그런건 또 기회가 있을테니 이쯤에서 정리.

급기야 글로벌도 가보자

앱 사용자 수가 일단 증가를 해야 우리 광고 수익도 날 거라서 해외 시장에도 내보기로 했다. 여기엔 전문 발번역가인 내가... 앱 소개 이미지와 소개글을 작성하는 참사가 있었다. 

온 맘 다해 부끄럽다. 나중에 도와줄 사람이 생기면 전문가가 작성한 문장으로 노출했을 때와 내 발번역으로 노출했을 때의 DL 지표 비교를 해보고 싶다^^.... (난 돌이킬 수 없는 상처를 받겠지..) 그래도 뭐 어떤가. DONE is better than PERFECT!

....어차피 정통 영어권 사람들이 받는 게 아니니까 조금 쪽팔림이 감소했다..... 페루에 급 호감이 생기네? 

그래서 돈은 벌었을까?

우리 앱의 광고 노출 구좌는 2개다. 하나는 앱 하단의 배너고, 하나는 테마를 바꿀 때 동영상 리워드 광고다. 

출시 후 첫 한 달, 92명의 사용자가 만들어낸 실적이다. 내가 관심있었던 건 테마 변경을 통한 리워드 광고 노출량인데.. 사람들이 얼마나 테마를 바꾸려는 의지가 있을까..를 보고 싶었다. 결론은 1인당 2번 정도 테마 변경을 시도한 것으로 보인다. 혹하는 테마가 많으면 노출 수가 증가할 거 같아서 출시 전에 급하게 5개의 테마를 추가했었지만 음. 큰 의미는 없었던 거 같다. 결론적으로 효자는 하단배너다. 유저 입장에서는 그렇게 거슬리는 하단배너를.. 개발자들이 꾸준히 집어 넣는 이유가 있다. 클릭률은 떨어지지만 임프레션이 높아 결국 수익은 저기서 다 잡히고 있다.

출시 후 첫 한달간 $29 수준이었으니까(그리고 저건 광고 집행도 했...) 현재 우리 수익 상태는 추측 가능한 수준일 거다. 그리고 겨울이 왔다.

뭘 배웠을까?

그래도 오늘 아침 10시 기준, 이 앱으로 기상한 사람이 4명이 있다는 사실에 감격하며(근데 왜그렇게 늦게 일어나요..?) 배운 점을 종합해본다.

유저의 니즈를 파악하는 데는 working product가 최선이다. → 역시 말로 할 때는 같은 생각을 하는거 같지만 막상 동작 하나 하나에서 유저가 기대하는 것은 내 이해랑 다를 수 있다. 그러니 빠른 이터레이션을 통한 제품 공개와 개선이 답이다.

TC 작성은 정말 귀찮지만 역시나 필요하다. → 세부 정책을 확인하고 구현 여부를 판단하는 데 크게 도움을 받는다. 물론 개발자랑 싸울 일이 생긴다..

광고 수익을 기대한다면 임프레션을 높일 수 있는 아이템을 찾아야겠다. → 허튼 리워드 광고 같은 수작 부리지 말고 광고 배너 노출을 크게, 오래 할 수 있는 앱이 뭐가 있을까 생각해보자.(그러다 자 앱을 만드는 게 어떨까 하는 소기의 결론에 도달했었다. 큰 면적에 오랫동안 광고 배너를 노출할테니..)

동일 아이템 시장에서 경쟁력이 있다면 키워드 광고로, 확신이 없다면 다른 캠페인을 진행하는 게 좋겠다. 

발번역도 좋으니 해외 출시도 꼭 하자. ..마지막으로 가장 큰 교훈을 남기며 ‘기상을 부탁해’ 프로젝트 후기를 마무리한다.

역시 사용자는 알 수 없다. → 본인 니즈에 맞는 앱을 손수 참여해서 개발했지만 우리 개발자는 아�� 아침에 잘 못일어 난다고 한다.. 문제 정의와 솔루션 도출을 너무 표면적으로 했나보다......

[jun-as-designer]

이전 성경 작업 경험을 바탕으로 수주(?)했던 프로젝트다. 온세상성경은 이미 구글플레이에 등록돼 있는데 너무 오래된 버전이라 전반적으로 UX/UI 업데이트를 원한다는 주문을 받았다. ���을 설치해보고 이것 저것 들여다보고.. 한숨을 쉬고.. UI가 문제가 아니라 전체적으로 기능에 대한 목록을 작성하고, 새 버전에 넣을 것과 이번 기회에 버리고 갈 것들을 추리는 작업부터 선행하자고 제안했다. 

무엇이 핵심 가치일까?

온세상성경의 현재 어플리케이션에 포함된 기능들을 써내려 가다 보니 쓸데 없는 기능이 너무 많이 들어가 있다는 생각이 들었다. 예배를 중심으로 필요한 모든 자료들(성경, 찬송가, 교독문 등)이 수록된 건 이해할 수 있지만 유명인의 찬송가 대금연주, 구연동화까지 수록 돼 있는 건 뭔가 사연은 있겠지만 제품의 핵심 가치가 불명확하다는 걸 보여주는 듯 했다.

프로젝트에는 제품의 오너인 사장님과, 개발 리드, 그리고 내가 주로 커뮤니케이션 하면서 일을 진행했는데 정기 미팅에서는 항상 이 시트를 켜놓고 진행 상황과 히스토리를 추적했다. 내가 참여한 기간 내에는 개발이 병행되지 않았고 ready to code 상태가 되는 게 목표였던지라 별도의 프로젝트 관리 툴은 필요치 않았다.

몇 번의 논의 끝에 우리는 온세상성경의 핵심가치가 오디오 지원을 중심으로 형성돼 있다는 데 공감을 하게 되었다. 

이건 성경을 재생하는 옵션(의 리뉴얼 디자인)인데 기능이 이렇게 많이 들어가 있다. 성경 전체에 대해 2가지 타입의 읽기 음성 데이터 라이선스를 가지고 있고, 재생속도 조절 및 구간 재생, 반복재생, 재생 후 액션 정의까지 가능하다. 또 찬송가 반주와 순서에 따라 찬송가 반주를 재생하는 플레이리스트 기능도 가지고 있었다. 이정도면 누가 따라하고 싶어도 엄두가 나지 않는 수준이라 생각 됐다. 그래서 다소 헤비한 감은 있지만, 이 기능들은 온세상성경의 특색으로 인정하고 유지하기로 했다. ‘이건 왜 있지?’라는 질문에 대해 제품의 오너께서 이런 저런 설명을 하셨는데 곧잘 이해가 되었고, 실제로 앱 리뷰에도 오디오 지원에 대한 좋은 평이 많았다.

그 외에 사용 빈도가 낮거나 불필요하게 반복돼 있는 기능들을 깨알같이 엮어내고 버리고 하는 의사결정들이 이뤄졌다. 나는 이런 작업들이 선행되지 않고선 디자인이 손에 잡히질 않는데 이사하면서 쓸데 없는 짐을 쏟아 버리듯 속이 시원했다.

BI

예상하긴 했지만 도무지 이전 BI를 쓸 수가 없어서 새 BI를 만들기로 했다. 사실 BI는 프로젝트 말미에 완성되었다. 프로젝트를 진행하면서 온세상성경을 어느 정도 이해하게 되었고, 그제서야 몇가지 안이 그려졌다. 최종적으론 아래의 안이 선정되었다. 개발 리드께선 이걸 처음 봤을 때 소름이 돋았다고 했다.(좋은 의미겠지?)

심벌에는 세 가지 메타포를 담았다.

산 위에 해가 뜨는 모습. 온세상을 상징.

‘온세상’의 자음인 ‘ㅇㅅㅅ’으로 만들어진 조형. 

책을 펼쳐 읽고 있는 사람의 모습을 상징.

보여준 순간 그냥 만장일치로 통과.. 간단히 베이직 시스템을 잡아뒀다.

UI

의뢰 받을 때 화면이 20개 정도라고 했던 거 같다^^. 역시. 안 보이는 사람에겐 안 보이는 화면들이 있다^^. 성경, 찬송가, 부록 등의 메뉴에서 꽤 많은 분량의 화면들이 쏟아져나왔다. 디자인 스킴을 잡아둔 상태니까 사실 이런 작업은 시간만 있으면 이렇게 저렇게 테트리스를 하면서 구성해낼 수 있다.

↑ 성경 본문쪽 아트보드 페이지(찬송가, 부록 등등이 더 있다!). 잘 정돈된 네이밍과 화면 배열은 역시 마음에 평화를 준다..

전반적으로 비슷한 디자인 톤을 유지하며 구성을 했다. 나는 특별한 목적이 없는 한 색과 형태를 경제적으로 관리하는 편이다. 그래야 유저의 혼란도 줄이고 코드도 한줄이라도 줄일 수 있으니까. 디자인은 아트가 아니라서 굉장한 경제성이 요구되는 비즈니스 활동이란 걸 인식하는 게 IT 필드의 디자인에선 더욱 중요하다.

어느 정도 작업이 된 화면이 있으면 미팅에서 Sketch mirror를 통해 화면 단위로 보여주고, 수정 의견이 있는 경우 왈가왈부 하지 않고 바로 Sketch에서 수정, 결과물을 mirror로 지켜볼 수 있게 했다. 그랬더니 서로 찜찜한 구석 없이 바로 보면서 결정을 할 수 있어 좋았다.(개발 리드께선 이 부분에 너무 깊은 감명을 받으셨다..) ‘다음 미팅까지 한 번 그려보고요..’ 이런거 난 정말 질색이다.

인터렉션 디자인

그럼에도 불구 Sketch에서 정적 화면을 보여주는 것 만으로�� 아이디어의 유효성을 검증하기 어려운 것들이 있다. 이런 건 Pixate를 활용해서 프로토타입을 만들고 같이 손에 넣고 사용해 봤다. 괜히 거창하게 앱 전체를 프로토타입으로 만들려고 하지 않았고 의사 결정에 필요한 부분만 조금씩 만들어서 테스트를 해봤다. 아래는 성경 본문의 챕터 전환에 좌우 화살표 버튼을 넣는게 좋겠다는 오너의 생각을 반영해 본 프로토타입이다. ‘내가 생각하기엔 그건 좀 아닌 거 같아요’ 할 시간에 프로토타입을 만드는 게 낫다. 

그래서 저커버그가 그랬다. ‘Code Wins Argument’라고. 결론적으로 저 좌우로 붙어있는 화살표는 드랍되었다.

배경화면 바꾸기

오너께선 배경화면을 설정하는 기능은 꼭 들어갔으면 좋겠다고 했다. 기존에도 기본 프리셋 이미지를 제공하고, 그 외 본인이 원하는 이미지가 있으면 (가족사진 등을) 앱의 랜딩화면 배경으로 지정할 수 있는 기능이 있었다. 그 기능을 이어가기 위해 앱의 홈 화면 버튼들의 투명도와 위치에 신경을 썼다. 그리고 추천할 만 한 이미지들을 언스플래시에서 골라 프리셋으로 제공하도록 했다.

↑ 나도 가급적이면 개인화 기능이 있는 앱이 좋다. 오래 쓰는 앱일수록 더욱. 

약 한 달 반의 작업이었다. 예상보단 할 일이 많았지만 나름 일을 하면서 나도 배우는 바가 있었다. 디자인을 감각적인 활동으로 이해하고 있던 두 분에게 합리적인 프로세스로서의 디자인을 소개해 준 것도 보람이 있었다.(개발 리드께선 팀의 디자이너를 곧장 Sketch 교육 프로그램에 보내셨다.) 이제 앱만 출시되면 좋겠는데.. 진디사대천명...

[jun-as-designer]

물류 브랜드인 VROONG TMS(Transportation Management System)의 바코드 스캐너 어플리케이션이다.

물류센터들은 센터에 입고되는 상품, 그리고 각 스테이션으로 출고되는 상품의 효과적인 관리를 위해 바코드 스캐너를 사용하게 되는데, 이 과정에서 WMS(Warehouse Management System)의 핵심적인 역할을 담당하는 어플리케이션이다. VROONG에는 여러 제품들이 있었지만, 워낙 정형화된 시장의 B2C 서비스라 특별히 UX적인 돌파가 필요한 작업은 없었다. 그나마 바코드스캐너에서는 재밌는 부분이 있어 정리를 해본다.

이 앱의 사용자는 주요하게 다음 세가지 목표를 달성하기 원한다.

상품이 센터에 들어왔을 때, 바코드를 찍는다. → 입고

상품이 센터에서 나갈 때, 바코드를 찍는다. → 출고

1, 2에서 이뤄진 행동을 조회한다. → 조회

유저가 목표를 손쉽게 달성하도록 돕기 위해 다음 두 가지 포인트에서 고민을 했다.

첫번째 고민: Quick Access

위 세가지 행동은 반복적으로, 빈번하게 일어난다. 이것이 어플리케이션 메인 화면 디자인에 가장 큰 영향을 미친 요소중 하나이다. 이 메뉴들은 사용자가 앱을 실행 하자마자 한 눈에 보여야 하고, 손쉽게 누를 수 있어야 한다는 부분에 집중했다.

사내에서도 백오피스 시스템에 가까운 '부릉 TMS’의 제품들은 그다지 인터페이스가 중요치 않다고 생각하는 쪽도 있었다. 그도 그럴 것이 동종 업계에선 거의 별도의 디자인 과정 없이 개발자들이 필요한 기능이 존재하도록만 만든 시스템을 사용중이기 때���이다.

머터리얼 디자인 가이드를 따라 네비게이션 드로어에 모든 메뉴를 다 집어넣었다면, 개발하기도, 디자인하기도 수월했을지는 몰라도 결국 사용자는 불편하지 않았을까. 여하튼 나는 이 앱을 사용하는 유저들의 편의를 돌봐주기로 했다.

앞에서 정리한 대로 사용자는 크게 입고, 출고, 조회 태스크를 이 앱을 통해 수행하는데, 세부적으로는 입고, 입고취소, 개별출고, 간선출고, 출고취소, 조회의 6개 액션이 주요하게 활용될 것으로 보았고, 이 버튼들을 모두 첫 화면으로 끄집어 냈다. 

두번째 고민: 정보 묶기

나는 유저의 주요 태스크를 위 그림의 A와 같이 입고, 출고, 조회의 세 가지로 보고, 해당 태스크를 수행할 수 있는 기능들을 메인 화면으로 빼내는 식으로 구성을 했지만, 어떤 사람은 B와 같은 구성이 이 시스템을 설명하는 데 더 적절한 구조라고 생각할 수 있다. 이런 예를 들어서 잠시 정리를 해보자. 어제 마침 마트를 갔다 왔으니..

고기 양념은 고기 섹션에 있어야 할까, 조미료 섹션에 있어야 할까?

이 문제에서 마트는 양쪽 모두에 고기 양념을 갖다 놓는 기지를 발휘했지만, 고기 옆엔 그렇게 많은 수량을 갖다 놓지 않은 걸로 봐서 조미료 섹션이 고기 양념이 있어야 할 곳이라 보는 것 같다. 그러면 왜 일부 고기 양념들은 고기 섹션에 있을까. 사용자가 거기서도 찾기 때문이다. 마트는 도서관이 아니다. 분류를 거스르더라도 고객이 필요를 느끼는 순간에 그것을 노출시키는 것이 비즈니스적 효용을 가져온다.

메인화면에 들어가는 버튼들을 두고 내가 한 고민도 비슷한다.

이건 논문을 쓰는 게 아니니까 각 기능들의 상하위 관계가 흐트러진다던지 하는 우려로 사용자를 불편하게 하는 선택은 하지 않으려고 한다. 대신 엑세스가 쉽고 사용자의 학습용이성, 기억용이성을 높일 수 있는 구조를 생각해보았다. 빈번하게 사용되는 기능들을 모두 앞으로 빼고, 입고예정, 입고완료, 출고완료 정보는 다른 것들에 대비 사용빈도가 낮아 조회 안으로 숨겼다. 그리고 사용 빈도를 고려하여 버튼 크기와 위치를 정리했다.

이 버튼들의 배열도 여러가지 베리에이션을 거쳤는데, 그때도 항상 어떻게 정보를 묶어야 할 것인가, 어느 게 고기고 어느게 양념인가를 두고 고민했다. 각각 나름의 분류 기준들이 있긴 하다. 결국 맨 오른쪽 안으로 진행을 했다.

바코드 스캐너 앱의 메인 화면을 두고 두 가지 고민에 대해 정리해봤는데, 아쉬운 건 정말 이 구성과 배열이 사용자에게 편리했는지 추가적으로 파악할 기회가 없었다는 거다. GA라도 박아 두면 좋았을텐데 그땐 프로젝트가 워낙 급하고 여유가 없어서 개선 단계까진 생각도 못했다는 변명을 남겨 본다.

[jun-as-designer]

BGF 리테일의 CU 모바일 앱 내에 배달 서비스를 추가하는 과제다. 배달 서비스의 실질 운영은 부탁해! 서비스에서 담당하므로 양사의 비즈니스적 특성을 이해하고, 배달 서비스의 주요 UX를 고려하여 인터페이스를 구성하였다. 

CU 모바일 앱은 BGF 리테일에서 관리하므로 앱 빌드가 필요한 과제를 그쪽에 부담하도록 할 수는 없었다. 따라서 우리는 배달 서비스를 웹으로 구현하고 앱 내에 해당 웹을 호출하는 뷰를 삽입하는 방향으로 진행하게 되었다. 웹 특성을 고려한 디자인이 필요했다.

지금도 CU 앱에 이 기능이 살아있으니 결과물을 확인할 수 있다. iOS, Android 모두 지원한다.

디자인은 역시 Sketch로 진행했다. 사실 이 프로젝트는 인터페이스의 복잡도 보다는 use-case별 흐름 기획이 복잡했다.

Pixate 프로토타입

Sketch 작업이 끝나고 나서 실제 동작 흐름�� 확인과 인터렉션 디자인을 위해 Pixate으로 프로토타입을 만들었다. 이것부터 보면 프로젝트를 이해하는 데 도움이 될 것 같다.

주소 입력 받기의 Concerning Point

배달대행 관련 서비스를 기획/디자인해본 사람이라면 이 죽일놈의 주소 입력 받기 과제가 얼마나 복잡한지 알 것이다. 여기선 조그만 UI나 UX상의 실수로 유저가 실컷 상품을 골라서 결제까지 가서야 서비스 지역이 아닌 걸 알게 된다거나 남의 집으로 음식을 배달하게 하거나 퇴근 후에 회사로 배달을 보내거나 등등 어마어마한 혼란을 초래한다.

콜 택시 서비스처럼 사용자의 현재 위치로 서비스를 요청하는 경우가 대부분인 서비스는 GPS 활용이 효과적이다. 하지만 배달대행의 경우 사용자가 다른 사람이 있는 위치로 배달을 시키는 경우도 많았다. 이 경우 GPS를 통해 서비스 가능한 점포의 목록을 보여주는 건 꽤나 큰 착각을 일으킬 수 있다.

그렇다고 사용자의 GPS정보를 활용하지 않고 반드시 주소 입력을 해야만 서비스 가능 점포 정보를 볼 수 있게 구성한다면 이건 최초 실행시 회원가입부터 요구하는 앱처럼 높은 허들이 될 거다. 그래서 기본 GPS를 활용해서 서비스 가능한 점포 정보를 보여주더라도, 사용자가 혼선을 느낄 만 한 컨텍스트에서는 항상 추가적인 얼럿이나 가이드 텍스트로 주소를 정확하게 설정하라는 안내를 주도록 구성했는데 대중교통으로 이동중이면 어떡할 거냐, 기존 주문했던 주소가 우선이냐 현재 위치가 우선이냐, 결제 화면에서 최종 배송지 주소를 서비스 되지 않는 지역으로 수정하면 어쩔거냐, 주문하는 사이에 점포의 재고가 소진돼 버리면 다른 점포로 주문을 할거냐 등등 케이스가 여간하지 않았다. 다시 떠올려도 지긋지긋하네.

편의점, 배달대행 업 특성에 따른 Concerning Point

사실 이런 부분에서는 로직을 다루는 사람들이 더 피곤했을 거다. 먼저 배달대행에는 한 번에 배달할 수 있는 상품 부피의 한계가 있다. 이륜차 배달통에 실을 수 있는 상품의 부피는 그렇게 크지 않다. 따라서 우리는 편의점의 각 상품(음료수 한 캔, 과자 한 봉지, 물티슈 한 팩, 도시락 하나 등)의 부피를 일정 기준에 따라 분류해서 사용자가 장바구니에 담고 있는 상품의 총 부피가 이륜차 1대가 배달할 수 있는 분량인지 파악해줘야 했다.

또 CU 점포의 커버리지와, 배달대행 업체의 커버리지의 교집합 위치에서만 주문이 가능한데, 이게 단순히 반경 몇 킬로, 혹은 OO동 XX동.. 이런 식이 아니라 폴리곤 형태를 그리고 있어서 사용자가 주문하려는 위치가 애매하게 배달 가능 지역을 벗어날 수 있다. 이럴 때 사용자의 GPS를 기준으로 현재 위치에서 배달이 된다고 안내되었을 경우 일이 어렵게 된다.

마지막으로 편의점은 보유 재고량이 많지 않다. 그래서 사용자가 상품에 표시된 주문 가능 재고량을 따라 주문을 시도했다 하더라도, 결제하는 사이 오프라인 매장에서 해당 상품이 팔려서 재고가 모자랄 수 있다. 이런 경우 사용자에게 주문 불가능하다는 사실을 가장 마지막 단계에서 알려주게 되는데 정말 끔찍한 경험을 선사하게 된다.

여튼 이 프로젝트에 참여했던 개발자들과 함께 이런 이슈들을 케어하며 대안을 찾느라 정신이 없었다. 각각의 이슈에 대해 우리가 도출했던 솔루션은 부족하긴 하지만 CU 모바일앱에서 직접 확인해볼 수 있다.

 UX는 디자이너 혼자서 할 게 아니더라..

이 프로젝트를 진행하면서 UX는 사업단에서 풀어줘야 할 게 많다는 걸 느꼈다. 이런 문제들에 대해 사업에서 미리 잘 인지하고 있었다면 방향이 어떻게 달라졌을까? 재고량의 문제라던가 지역 커버리지 문제는 어떤 새로운 대안이 사업단에서 나올 수 있지 않았을까? 디자이너들만 UX 붙잡고 늘어질 게 아니라 UX를 고려한 영업과 비즈니스 운영도 필요하다는 생각이 들었다. 

아, 물론 그게 이뤄지지 않아도 그 안에서 최고의 경험을 사용자에게 선사하는 게 디자이너가 있는 이유긴 하다. 

[jun-as-designer]

인스타스티커는 인스타그램이나 페이스북에 올려둔 사진을 자석사진으로 주문할 수 있는 서비스다. iOS와 Android 어플리케이션으로 서비스되었다. 

WYSIWYG

이 서비스에서 반드시 갖춰야 할 요건은 사용자가 앱에서 주문한 모습 그대로 결과물이 나와야 한다는 것이다. 특히 사진은 예민한 구석이 많다. 사용자가 크롭한 위치에 정확히 크롭이 되어야 하고, 색감도 본인의 폰에서 보던 그대로 나오길 바랄 것이다. 이건 단순히 앱에서 디자인을 어떻게 해야하느냐의 문제를 넘어 자석 사진의 제작 공정과 협력해서 확실한 프로세스를 갖춰야 가능한 일이다.

제작을 담당하던 회사와 조율을 통해 사용자가 앱에서 선택한 크롭 위치와 결과물의 오차 범위를 1mm 내로 줄였고, 실제 제품의 모서리 곡률, 단면 부분에서 자석과 종이가 노출되는 것 등 최대한 실 제품의 느낌을 그대로 앱에서 보여줄 수 있도록 했다.

IA Wireframing

인터페이스 설계 겸 유저의 행동 흐름을 구성해 본 자료다. 당시엔 Sketch가 없던 시절이라 그냥 일러스트레이터에서 그렸다. 포토샵은 툴 자체가 디자이너를 하나의 화면 디자인에 집중하게 만드는 경향이 있어 이렇게 일러에서 미리 각을 재 보는 것도 좋았다. 이런 작업은 오브젝트 단위 핸들링이 수월한 툴에서 해야지 pixel 베이스의 툴에서 하면 괴로워진다..

BI

인스타그램이 로고타입 레터링을 바꾼지 얼마 되지 않았던 때였고, 우리는 과감하게 그 로고를 따다 썼다. 당시에도 인스타그램의 많은 서드파티 서비스들이 있었는데 거의 ‘Insta’또는 ‘gram’을 ���져다가 서비스 네이밍을 했다. 아이콘은 즉석 카메라를 연상시키는 디자인에서 사진보다는 좀 더 두꺼운- 자석 사진이 나오는 걸 스큐어모픽하게 표현했다. 이후 플랫 UI가 유행하면서 저 디자인을 좀 매끈하게 눌러놓기도 했다.

Store Screenshot

론칭 때 스토어에서 노출했던 스크린샷 이미지, 지금 보니 이상한 구석이 많지만.. 저 고양이는 여전히 귀엽네.. 당시 사용자들이 올려줬던 인증샷 중에 허락을 받아 사용했다.

인스타스티커는 스토리박스 중후반부터 취급하기 시작했던 자석사진 아이템을 주력으로 다뤘다. 포토북은 높은 단가에 비해 유저풀이 충분히 확보되지 않아 제품 개발 투자에 어려움을 겪었다. 반면 자석사진은 ���가가 낮고, 사이즈 외엔 큰 베리에이션 요소가 없어 주문이나 제작에 허들이 낮았다. 인스타스티커는 지금은 서비스가 종료되었지만 당시 제작을 담당했던 회사에서는 여전히 같은 상품의 서비스를 이어가고 있는 걸로 안다.

[jun-as-designer]

스토리박스는 카카오스토리 사진을 포토북으로 만들 수 있는 서비스다. iOS와 Android에서 서비스 하였으며, 카카오로부터 제휴사업자에게 공개된 closed api를 활용하여 서비스를 구축했다.

포토북을 주문하는 과정도 어마어마한 일이었다.

역시 세상에 그냥 되는 일은 없다. 이 서비스 준비를 위해 타 포토북 제작사들의 홈페이지에서 제작 과정을 경험해보고 나서 알았다. 정말 더럽게 복잡하고 오류가 많았다. 디자인을 선택하고, 사진을 배치하고, 글을 쓰고, 페이지 레이아웃을 변경하고, 포토북의 재질, 페이지 매수 등을 거치면서 이런 어마어마한 프로세스를 모바일에서 감당할 수 있을까 싶었다.

여러 고민 끝에 작은 스크린, 제한된 입력 장치, 짧은 사용시간 등 모바일 환경의 특성에 맞는 스펙을 추려냈다. 

Minimum Viable Product

‘모바일에서 포토북을 주문한다’는 것은 강점이기도 하고 단점이기도 했다. 그래서 우리는 기존의 포토북 시장의 저작툴 개념을 완전히 벗어나서 새로운 경험을 주기로 했다. 유저에게 다소의 자유도를 빼앗는 대신, 그 이상의 편리함을 제공하는 것이다.

처음 출시하던 스토리박스는 카카오스토리에서 사진을 불러올 뿐, 텍스트를 불러오진 않았다. 사용자들은 18장의 사진을 선택하고 순서를 배열할 수 있을 뿐이었다. 텍스트를 함께 인쇄하기 원하는 사용자는 처음부터 있었다. 하지만 우리가 거기까지 도달하기 전에, 모바일로 주문하는 포토북이라는 상품 모델에 대해 검증을 할 필요가 있었다. 

론칭시점엔 카카오 레버리지로 주문량이 꽤 들어왔다. 하지만 ‘포토북’이라는 아이템 특성상 어느 정도 시간이 지나기 전까지 재구매가 일어나긴 어렵고 신규 유저 인입도 녹록치는 않았다.

개발쪽 마일스톤은 계속 예정사항이 있었기 때문에 시스템 서포트가 크게 필요치 않은 포토북 실 제품 자체에 대한 디벨롭을 꾸준히 진행했다. 프리미엄 포토북 라인과 미니 포토북 라인이 생겼다. 또 컬러 베리에이션을 추가하면서 사용자들이 취향에 따라 선택할 수 있게 했다.

ARPPU 높이기

우리는 유저들의 재주문율이 상대적으로 높다는 데 계속 착안하면서 스토리박스 서비스 안에서 사진을 현물로 만드는 여러가지 방식을 제공하여 ARPPU를 높이는 방향의 전략을 잡았다. 그래서 자석 사진(이게 이후 인스타스티커의 모체가 된다..)과 자석 사진을 붙일 수 있는 자석판까지 판매하게 된다.(자석판은 정말 우리가 카테고리를 불문하고 돈 버는 데 ARPPU를 높이는 데 집중했다는 증거인 것 같다.)

세세하게 기록할 순 없지만 정말 어려운 일이 많았던 프로젝트였다. 제품 개발에 들인 기간 대비 단기적인 성과가 부족했고 카카오 쪽의 협력도 아쉬운 구석이 많았다. 또 인쇄물에 감이 부족했던 내가 불량 재고를 만들기도 했고.. 쨌든 이 프로젝트에 대한 경험을 기반으로 인스타스티커가 시작됐고 아쉬운 서비스 종료를 맞았다.

[jun-as-designer]

도서출판 로고스, 헤븐리스파이와 함께 제작한 성경 어플리케이션이다. 성경은 도서 중에서도 굉장히 특이한 형식을 갖추고 있고 고정 사용자층도 두텁다. 스마트폰의 등장 이후 도서 중에는 가장 먼저 사업성을 보장 받은 콘텐츠가 아닐까 한다.(사실 이 작업을 시작으로 이후로 두 건의 성경 어플리케이션 계약 건이 생긴다.. 무서운 아이템이다..)

BI

기존 성경 어플리케이션들은 성경의 텍스트를 보여주는 기능에 매몰돼 있었다면, 픽트리성경은 성경 공부를 위한 성경 어플리케이션을 지향한다.(실제로 출시 후 신학대학원생들에게 굉장히 인기가 많았다.) ‘픽트리’라는 네이밍은 무화과 나무를 뜻하며, 과거 이스라엘에서는 성경을 공부하던 장소로 ‘무화과 나무 아래’가 상징적인 공간이었다고 한다.

무화과 나무 잎에 theme color 그라데이션을 주고, ‘figtree’ 레터링의 T를 십자가 모양으로 형상화 했다. 전반적으로 무화과 나무 잎에서 딴 ��색 컬러를 사용해서 UI를 그렸다.(그리고 컬러 테마도 넣었다. 매일 쓰는 앱이 본인 취향 색이 아니라면 꽤 괴로울 것 같아서..)

IA Wireframing

성경 어플리케이션은 꽤 복잡한 구조를 가지고 있다. 뿐만 아니라 사용자에 따라 이용 양태도 다양하다. 성경을 위한 네비게이션 구조를 잡는다면 애플이 설명한 Hierarchical Navigation, Flat Navigation, Content-Driven or Experience-Driven Navigation 세가지 중에는 마지막에 가깝다. 

그렇긴 한데 위에 그린 와이어프레임은.. 너무 정신이 없긴 하다..

스플릿 뷰, 챕터 네비게이션

성경은 워낙 방대한 분량의 책이다보니 챕터 단위의 네비게이션이 편리해야 하고, 또 다양한 위치의 본문을 함께 참조하는 상황도 발생한다. 이런 니즈를 해결해줄 수 있는 UI 설계가 무엇일지.. 고민 끝에 아래와 같은 인터페이스로 표현되었다.

가장 왼쪽이 기본 1개의 본문을 열람하는 상태고, 중간이 스플릿 뷰를 이용해 두개의 서로 다른 본문을 열람할 수 있는 상태를 보여준다. 위쪽과 아래쪽은 서로 독립적으로 동작해서 두 권의 책을 펼친 것과 같은 상태라고 할 수 있다. 

맨 오른쪽은 챕터 이동을 위한 사이드 네비게이션이다. 사용자는 어느 위치에서든지 화면을 왼쪽으로 밀면 해당 책의 챕터들 중에 이동할 챕터의 위치를 선택할 수 있다.

이 기능은 클로즈드 베타 테스트 때 인지하긴 어려웠지만 한 번 학습하고 나면 굉장히 유용하게 쓰이는 기능인 것으로 조사되었다. 

노트, 탐색, 지도 열람

성경 공부를 위한 성경 어플리케이션 답게 노트 기능에 힘을 주었다. 노트는 본문에서 발췌한 구절을 삽입할 수 있게 해두었고, 에버노트 백업과 메일 발송 기능도 추가했다.(추후 이 기능이 설교 준비에 굉장히 유용하다는 피드백을 받았다.)

중간의 화면은 성경의 특정 위치로 이동하는 화면이다. 성경은 ‘책 → 장 → 절’의 구조를 갖는데, 각각의 단계에서 수십, 수백개의 베리에이션이 존재한다. 이 경우 최대한 한 화면에 많은 데이터를 보여줄 수 있는 정방형 버튼 그리드가 유용할 거라 생각했다.(책, 장, 절이 한 눈에 보이는 3단 스크롤 뷰 모드도 추후 추가되었다.)

지도는 성경 역사를 이해하는 데 주요하게 사용된다. 일러스트는 헤븐리스파이에서 담당했다. 주요 지명에 핀을 표시하고, 눌렀을 때 해당 지명이 언급된 성경 내 구절들을 표시해주었다.

출시 후 마케팅, 지표 트래킹

성경이란 콘텐츠 자체가 꾸준한 사용자를 확보하고 있는 콘텐츠라 픽트리 성경의 경우에도 출시 직후 심해로 직행하는 일은 없었다. 어느 정도 안정성이 담보된 후엔 페이스북 등을 통해 광고를 집행했고 그 데이터들도 흥미로운 지표를 보여주었다. 

픽트리 성경은 지금까지도 계속해서 제품이 유지되고 있는 걸로 알고 있다. 그 후로 또 성경 어플리케이션 작업을 할 기회가 있었는데 역시 이때의 경험이 많은 도움이 되었다. 성경은 꽤 흥미로운 설계 주제로 가득한 아이템이었다.