StoriesAds.com을 디자인하다
맨 바닥에서부터 웹사이트를 디자인하기까지의 생각과 과정
이 글은 먼저 게재된 원문 “Designing StoriesAds.com”을 번역한 것입니다.
회사에서 일하다 보면, 항상 원하는 대로만 일이 진행되지는 않는다. 항상 예상치 않던 (또는 원하지 않던) 순간에 변화가 찾아오고, 많은 경우에 그 변화는 꽤 과격한 변화를 요구한다. 기존에 세워두었던 스케줄과 계획은 더 이상 유효하지 않게 되고, 더 중요한 것을 위해 이미 작업하고 있던 것을 중단해야만 할 때도 있다. 스타트업의 개발팀에서 일한다면 어쩌면 꽤 흔히 접하는 일인지 모르겠다만, 몇 차례의 경험을 통해 어느 정도로는 이미 이런 것이 익숙해져서, 최대한 능숙하게 급격한 스케줄의 변화와 상황에 대응할 수 있는 능력이 단련되어졌다. 대부분의 경우 이렇게 갑작스럽게 닥쳐온 프로젝트들은 그 때의 상황에 따라 “지금 당장” 하지 않으면 그 가치를 잃는, 시간에 매우 민감한 것들이 많았다.
이번에도 비슷한 상황이었다. 새롭게 작업해야하는 프로젝트가 주어졌고, 데드라인은 처음에는 이게 가능할까 싶을 정도로 매우 타이트했다. 하지만 만약 해낼 수 있다면, Shakr의 인지도와 우리가 전달하는 가치에 큰 추진력을 더할 수 있는 가능성이 있었다.
그래서 이번에도 도전했다.
그 도전, 받아들이도록 하지요.
4월 중순에 우리는 “StoriesAds.com”의 작업에 착수했다. 간단히 설명하면 이건 우리가 Instagram Stories에 쓸 용도로 만든 최신 세로 비율의 비디오 디자인에 집중해 쇼케이스하는 마이크로사이트다. 그리고 이걸 만드는데 우리에게 주어진 시간은 고작 2주였다. 2주! 주말을 제외한 업무일로 따지자면 7일밖에 안 되었다.
프로젝트를 시작하기 전 스케줄과 상세 사항들을 논의하기 위해 회의를 했다. 이것저것 상의한 후, 최소 2일간의 런칭 전 테스팅을 빼면 5일만에 제대로 작동하는 웹사이트를 바닥부터 만들어야한다는 결론이 났다. 중간 과정에서 여러 사람들로부터 도움을 받았지만, 핵심적으로 이 프로젝트에 투입된 멤버는 4명이었다: 디자인 1명 (바로 접니다), 프론트엔드 개발 2명, 백엔드와 옵스 1명. 버릴 시간이 정말 1분도 모자랐기 때문에 각자 서로에게 최대한 의존성이 생기지 않고 모두가 동시에 무언가를 작업할 수 있는 타이트한 스케줄을 짰다.
결과를 미리 누설하자면, 이 엄청난 스케줄을 뚫고 결국 해냈다. 팀으로서 달성한 또 하나의 대단한 업적이며 새로운 마일스톤으로 본다. 팀원 모두가 각자 자신과 서로의 능력과 역량을 정확히 이해하고 있었고, 수 개월, 수 년간 함께 일하며 다져진 협업 스킬 덕분에 가능했던 프로젝트라고 생각한다. 나는 언제나 우리 회사와 팀에 대해 자랑스러운 마음을 가지고 있었지만 이번 프로젝트를 끝낸 후 더욱 자랑스러워졌다. (다른 사람들도 그렇게 생각하리라 생각한다) 이 때문에 더욱이나 이 프로젝트를 진행하며 겪은 과정을 글로 정리해 보존하는 것이 좋겠다는 생각이 들었다.
안타깝기도 내가 이 프로젝트에서 맡은 부분은 디자인과 프론트엔드 코딩뿐이였으므로, 다른 팀멤버가 많은 노력을 부은 부분에 대해서는 소개할 수 없다. 따라서 여기에서는 내가 맡았던 디자인 과정과, 결정하는 과정에서 겪은 어려움들, 그리고 왜 어떠한 결정을 내리게 되었는지에 대해 설명해 보고자 한다.
브랜드 아이덴티티
‘브랜드 아이덴티티’와 ‘디자인 언어’는 절대 가볍게 생각되어져서는 안 될 것이다. 정체성 그 자체가 되는 일관성 있는 디자인을 위해 모든 것의 뼈대가 될 것이므로 항상 충분한 시간을 들여 세심하게 고안해야 될 것이다. 그러나… 이번에는 시간상 정말로 딱 하루밖에 디자인에 쓸 시간이 없었기 때문에, 이 안에 웹사이트와 브랜드의 디자인을 생각하고 결정해야만 했다.
이 프로젝트의 목적과 성격을 생각할 때, 웹사이트의 전체적인 외관은 일단 방문자의 눈을 사로잡는 강한 인상을 주는 느낌일 것이 적합해 보였다. 무언가 대담하고 강한 색상이 연상되었다. 사실 이 때문에 이 프로젝트를 위해 새로운 디자인 스타일을 만들기로 한 것이기도 하다. 기존에 Shakr에서 정립한 디자인 언어는 다소 얌전한 느낌이기 때문이다.
자, 그러면 이제 ‘대담하고 강한' 룩을 만들기 위한 요소들을 골라볼 차례다.
폰트 고르기
먼저 프로젝트에 사용할 폰트 패밀리를 찾는데부터 시작했다. 우리는 사내에서 Adobe의 Creative Cloud 구독을 이용하므로 그 안에 TypeKit이 포함되어있다. 다양한 상용 폰트가 제공되므로 새 디자인에 쓸 폰트를 찾는다면 시작하기 좋은 곳이다.
머리속에 떠올렸던 폰트의 이미지는 볼드하고 도형적인 인상이었기에, 적합한 옵션으로 폰트를 걸러내기 시작했다. 폰트 패밀리가 엑스트라-헤비 두께의 뚱뚱한 폰트 베리에이션을 가지고 있다면 반드시 레귤러 두께의 폰트도 포함할 테지만 거꾸로도 항상 그렇지는 않으므로, 두꺼운 폰트를 기준으로 선택한 후 찾아보기 시작했다.
그래서 위의 6개까지 선택 폭을 줄였다. Futura의 1층짜리 ‘a’ 글자 모양은 마음에 들었지만, Futura는 워낙 유명한 폰트라 좀 흔하다는 생각이 들었다. (헬베티카가 내가 가장 좋아하는 폰트중 하나지만 막상 실제 프로덕션 디자인에서는 잘 안 쓰는 이유와 비슷하기도 하다.) Proxima Nova도 상당히 좋은 폰트지만 이 또한 최근 웹에서는 꽤 자주 보이는 폰트라서 걸러냈다.
몇 가지 시험해본 후에, 최종적으로 Filson을 쓰기로 했다. Futura와 Proxima Nova의 중간정도라는 느낌으로 적절히 모던해보였고, R의 말려올라간 다리처럼 나름의 개성도 가지고 있었기 때문에 마음에 들었다.
특히나 볼드체와 이탤릭체가 마음에 들었는데, 헤더 텍스트용으로 딱 좋을 것 같아 보였다.
색상 고르기
사실 나는 개인적으로 트렌드에 있어서는 약간 보수적인 쪽이라고도 할 수 있겠다. 최근의 유행(?)으로 밝고 채도가 강한 색상들이 점점 세력을 넓혀가는 것이 그리 마음에 들지는 않았다. 그러나 트렌드나 개인적 취향의 문제를 떠나서, 이번 프로젝트에서 목표로 하던 ‘대담하고 강한' 이미지를 위해서는 튀어보이는 색상이 적합하다고 생각했다. 그래서 조금 도전적으로 평소 작업할 때보다 더 화사한 컬러 스킴을 시도해보았다. 몇 가지 색상을 조합해 배치해보다가, 밝은 마젠타와 보라색을 색상 팔레트의 주요 색상으로 삼았다.
아주 우연하게도… (웃음) 인스타그램도 2016년의 리디자인부터 비슷한 톤의 색상을 사용하고 있었던 관계로, 우리가 만들 StoriesAds.com의 주요 타겟을 고려하면 결론적으로 꽤 괜찮은 선택인것 같았다.
디자인과 레이아웃
초기 회의에서 결정된 바로, 웹사이트는 사실상 페이지 하나짜리로 구성되기로 되었다. 기능상으로도 개발 시간상으로도 최대한 간단한 플로우가 되어야만 했으므로, 유저 방문 후의 흐름은 아래와 같았다:
- 유저가 사이트를 방문, 미리보기 비디오를 시청하고, 디자인을 고른다.
- 유저가 콜투액션(call-to-action) 버튼을 눌러 Shakr 비디오 에디터를 연다.
- 유저가 비디오 제작을 마치면, 이메일을 통해 완성된 비디오를 보내준다.
위의 단계를 고려해 필요한 요소들을 넣은 페이지 레이아웃을 구상했다. 필수로 들어가야하는 것은 비디오 미리보기, CTA버튼, 그리고 웹사이트를 한 눈에 소개할 수 있는 헤더 텍스트와 서브텍스트. 위에서도 언급했듯이 한 페이지짜리 간단한 웹사이트였고 복잡한 UI컴포넌트와 깊은 단계의 내비게이션이 요구되지 않았기 때문에, 와이어프레임(wireframing) 단계를 건너뛰고 곧바로 레이아웃 배치와 비주얼 디자인의 작업을 동시에 진행했다. 요즘은 UI프로토타이핑 과정에 쓰기에 더 적합한 도구들이 많지만, 이번에는 가장 빠른 결과물을 위해 내가 작업하는데 익숙한 오랜 친구 Illustrator을 잡았다.
시작한지 몇 시간 후에, 만족스러운 정도의 이미지를 내놓을 수 있었다. 주 색상을 이용해 배경에 그라디언트를 깔고, 그 위에 단색 직사각형들을 올려 뜬 느낌을 주었다. 컨텐츠가 전체적으로는 스크린의 중심에 정렬되어 있지만, 텍스트 상자에는 일부러 살짝 오프셋을 주어 너무 페이지가 단조로워보이지 않도록 했다.
이 시점에서 프론트엔드 개발을 맡은 다른 팀원들이 새 프로젝트를 위한 git 저장소와 개발 환경의 셋업을 끝냈으므로, 곧바로 내가 만든 목업 이미지를 기반으로 HTML/CSS 코딩에 뛰어들수 있었다.
UX 결정들
전체 과정 중 목업 디자인을 실제 코드로 바꾸는 작업은 아마 제일 쉬운 부분이 아니었나 싶다. 1–2시간정도에 완성할 수 있었고, 모바일 디스플레이를 위해 반응형 CSS 코드를 추가하는 것도 페이지가 워낙 간단했기 때문에 그리 어렵지 않았다. 사실 가장 어려웠던 부분은 UX(유저 경험)을 위해 내려야만 했던 결정들이다. 처음에 구상했던것에 비해 때로는 시간의 제한때문에 포기해야만 했던것들도 있고, 기술적인 문제때문에 바꿔야했던 것들도 있다.
캐러셀(Carousel)
우선 웹사이트에 들어오자 마자 헤더 텍스트 외에 눈에 띄어야 할 것은 세로 비디오의 미리보기를 보여주는 부분이었다. 우리가 쇼케이스할 비디오는 손으로 셀 수 있을 정도로 그리 많은 개수가 아니었기 때문에, 간단한 캐러셀(carousel)같은 인터페이스가 적합하리라 생각했다.
처음에는 비디오를 담는 스마트폰 기기의 프레임 양쪽에 화살표 버튼을 띄우는 쪽으로 생각을 했었다. 좌우 버튼을 주어 뒤로나 앞으로나 전환할 수 있게 하는 것이 가장 흔한 캐러셀 UI겠지만, 쉬울것 같아보여도 앞뒤로 넘겨지고 모든 UX를 완벽하게 다루는 것은 매우 어렵다는 것을 우리는 알고 있었다. Shakr.com의 마켓 메인 페이지 상단에 떠있는 배너 캐러셀을 개발하면서 배운 사실이다. 제대로 무한 루프되게 하기(맨 마지막 항목 다음에는 다시 1번으로 돌아가야하므로), 자연스러운 터치 스와이프 반응, 애니메이션, 화살표 버튼 위치와 크기… 우리에겐 시간이 별로 없었으므로 제대로 된 캐러셀을 만드는데 시간을 너무 할애할 수 없었다.
그래서 최종 결과물로는, 시간을 많이 잡아먹을 것은 전부 배제하고 가장 핵심적인 기능만 남기기로 했다. 화살표 대신에 보다 간단하게 스크린을 눌러 다음 비디오로 넘기는 방식을 쓰기로 했다. 실제 Instagram Stories도 스크린을 한 번 터치하는 것이 다음으로 스킵하는 동작이기 때문에, 그런 면에서도 의미가 맞는것 같았다.
하지만 물론 이렇게 함으로 유저가 비디오를 ‘뒤로’ 돌릴 수 없게 된다는 말이었다. (리스트는 계속 루프되므로 계속 누르다보면 결국 첫 번째 아이템으로 돌아오긴 한다) 하지만 간단한 인터페이스와 개발 시간 절약을 위해 합리적인 희생이라 생각했다. 만약 우리가 보여주려고 했던 비디오의 개수가 더 많았더라면 이 방법을 택하기 어려웠겠지만 다행히도 10개 이하였기 때문에 괜찮았다.
많은 캐러셀에 있듯이 실제 리스트의 항목을 목차 식으로 나열해 보여주는 것도 구현하지 않았는데, 이것도 결과적으로는 나름 도움이 된 것이, 실제 리스트를 보여주지 않기 때문에 매 번 사이트가 로드될 때마다 비디오 목록의 순서를 무작위로 섞을 수 있었다. 방문자들이 들어올 때마다 매 번 다른 디자인을 표시해 공평한 노출 기회를 주기 위함이었다.
모달을 쓸까? 말까?
최종 결과물에 들어가지 않은 또 다른 부분은 바로 ‘확인 모달’ 이었다. 유저가 완성한 비디오를 보내주기 위해, 이메일 주소를 먼저 받을 필요가 있었다. 처음에는 위의 이미지처럼 화면을 가리는 오버레이 형식으로 모달을 띄워 그 안에 이메일 칸을 넣을까 생각했었다. 메인 페이지에 바로 이메일 입력 칸을 넣지 않은 이유는, 안 그래도 한 눈에 모든 내용이 들어오는 단일 페이지 웹사이트에서 이메일 입력 칸이 딱 바로 보이면 너무 눈치보이지 않을까 싶어서이다. 무언가 한 단계 숨겨진 레벨의 뷰 안에 넣은 후 유저가 한 번 클릭하면 나타나도록 하는 것이 좋을 것 같았다.
하지만 개발을 진행하다 보니, 위의 방법은 UX적으로 몇가지 난감한 부분이 있었다. 한 번 ‘비디오 제작’ 버튼을 눌러서 모달을 띄우면 기존의 화면을 가리니 이 상태에서는 더 이상 비디오를 미리보기할 수 없게 된다는 점과, (SDK 에디터의 작동 방식에 의해) 에디터를 열면 모달이 열린 상태에서 또 위에 모달이 열리는 것이 되었기 때문이다.
몇 가지 대안을 논의한 후, 확인 단계와 이메일 입력 칸을 표시할 다른 방법을 생각해냈다.
위의 방법이 마음에 들었던 것은, 모달처럼 기존의 뷰를 가리지 않는다는 점이었다. 두 맥락 간의 전환이 애니메이션 덕분에 더욱 자연스러워졌다는 느낌이 들었고, 확인 단계와 초기 단계 간 이동하는 것도 커서가 더 적은 거리를 이동해야했기 때문에 쉬워졌다.
자연스럽게 비디오 미리보기의 문제도 해결이 되었는데, 더 이상 화면을 가리는 것이 없으므로 비디오를 계속해 재생해도 되었기 때문이다. 초기 상태에서는 비디오가 자동으로 재생하고 끝나면 다음 비디오로 넘어가게 되어있지만, 유저가 확인 단계로 넘어가 비디오를 ‘선택한’ 상태라면, 현재 선택된 비디오 하나를 루프하는 식으로 보여준다.
테스팅, 그리고 고치기
이 쯤 하여, 기능상으로는 웹사이트가 완성이 됐다. 비디오 에디터를 연결하는 작업도 완료되어, 웹사이트에서 성공적으로 에디터를 열 수 있었고, 비디오 제작을 한 후 뜰 완료 페이지도 만들었다. 다운로드 링크를 포함한 이메일도 제대로 보내지는 것을 확인했다.
웹사이트가 여러 다른 브라우저에서 제대로 보이고 작동하는지 확인하기 위해 테스트를 해보았다. Chrome, Firefox와 Safari는 문제 없이 괜찮았지만 Edge (사실 약간 걱정하긴 했다만)는 비디오 재생과 관련해 문제가 있어서 약간의 수정이 필요했다.
데스크탑 브라우저에서는 대체로 괜찮았지만 모바일 브라우저는 좀 관심을 요구했다. 사실 iOS에 있어서는 HTML5 비디오의 인라인 재생이 지원되기 시작한 것이 그리 오래되지 않았다. 아직 1년도 채 지나지 않았는데, iOS 10이 출시되면서 함께 딸려온 모바일 Safari 새 버전의 WebKit엔진과 함께 도입되었다. 자동재생과 인라인 재생에 대한 정책을 바꾼 후 겨우 지원되기 시작된 것이다.
모든 개발팀 멤버가 이미 iOS의 최신 버전인 10을 쓰고 있었기 때문에 (보통 새 소프트웨어 업데이트가 뜨면 한주 이내로 올리곤 한다) 모바일에서 테스트를 해봤음에도 불구하고, 구 버전의 iOS와 사파리에선 자동재생 기능의 미지원 때문에 사이트가 깨질 수 있다는 사실을 미처 인지하지 못했었다.
비디오를 자동 재생하지 못한다는 것은 즉, 숨겼던 수동 비디오 플레이어 컨트롤을 되살려야한다는 말이였다. 재생 버튼을 놓을만한 가장 적합한 위치는 역시 비디오의 위였기 때문에, 이 부분의 클릭을 재생 액션을 위해 쓰게 되면 더 이상 기존의 방식대로 ‘스크린을 클릭해 다음 비디오로 넘기기’를 쓰지 못하게 되었다. 열심히 머리를 굴려 수동 컨트롤을 요구하는 레거시 브라우저들을 위한 대안의 UI를 생각해냈는데, 비디오 위에 재생 버튼을 띄우고, 그 옆에 항상 떠있는 ‘다음' 버튼을 표시하기로 했다.
또 하나 발견한 것은 OS버전과 상관 없이, 앱 안에 들어간 인앱 브라우저들은 비디오 자동재생과 인라인 재생에 대해 각자 또 다른 정책을 갖고 있다는 사실이었다. 가령 Facebook 앱은 인라인 재생은 지원했지만 자동재생은 지원하지 않았다. Twitter (공식) 앱은 인라인 재생도 자동재생도 지원하지 않았다. 앱을 만들때 넣은 웹뷰에 선언되는 정책인지라 웹사이트 단에서 어떻게 할 수 있는 방법이 없어서, 결국 위에서 만든 ‘레거시’ UI를 인앱 브라우저들에도 적용할 수밖에 없었다.
유저 에이전트를 찾아서 예외 처리를 한 후 테스팅하는것도 고역이였는데, 이 브라우저들에는 URL을 직접 칠 수 있는 주소창이 없으므로, 각 서비스에 비공개 포스트로 개발 서버를 돌리는 머신의 로컬 IP주소를 적어 올린 뒤 모바일 앱에서 링크를 눌러 사이트를 띄우는 꼼수를 썼다.
출시
그래서 그렇게, 수 일간 열심히 일해서 데드라인을 맞이했다. 최종적으로 최신 코드를 테스트 환경에 배포한 뒤에, 링크를 사무실에 있는 모두에게 전달해 각자의 기기에서 테스팅하도록 부탁하고 발생하는 문제점이 있나 모니터링했다.
그런 다음에, 드디어 스위치를 당겼다. StoriesAds.com이 세상에 공개되었다!
여기까지가 그동안 작업하면서 겪었던 어려움들, 그리고 내렸던 결정들의 뒤에 지나쳐온 생각의 과정들이다. 혹여나 글을 읽고 계신 여러분의 프로젝트에도 도움이 될만한 내용들이 있을까 싶지만, 우리가 진행해온 방식이 반드시 모든 경우에 적용되리라고 생각하지는 않는다. 이번 프로젝트는 아무래도 너무 시간이 촉박해서 생략한 것들이 많았기 때문에. 시간에 쫓기는 (또는 하드한 데드라인에 의해 추진력을 얻는) 개발은 가끔은 있을수 있더라도, 자주 맞닥뜨리게 되어선 안 되는 것이라고 생각한다. 프로젝트의 퀄리티를 유지하기가 굉장히 힘들뿐만 아니라 작업하는 구성원들의 정신건강에도 별로 좋지 않기 때문이다.
하지만 분명 큰 노력 끝에는 큰 보상이 있다. 만약 해낼 수 있다면, 팀으로서 한 단계 레벨 업 할 수 있는 귀중한 경험을 얻을 수 있다. 이번에 우리가 바로 그런 경우였다고 생각하며, 이런 좋은 팀의 일원으로 함께 일할 수 있는 것이 얼마나 감사하고 자랑스러운지 다시한번 강조하며 글을 마친다.
