DEVOCEAN

[D+38] 9월 5일(목)

<현재 상황>

  - 대시보드 디자인 : 디자인 완료 --> 모바일 사이즈 디자인 진행 중

  - BI 서비스 디자인 : 디자인 진행 시작

  이제 디자인 시안만 받으면 UX/GUI 작업은 드디어 마무리다..!!!!!

  와우. 

  뭐, 특별히 수정해 달라고 할 것도 없이 마음에 들었다. 특히 냉장고를 선택했을 때 나오는 플로팅(floating) 팝업이라던가, 중요한 정보들을 살리고, 비교적 덜 중요한 것들은 톤(tone)을 낮춰 준 부분들이 역시나 의도를 이해하고 디자인 했구나 라는 생각이 들었다.

  몇 가지 수정 요청을 했던 부분은,

1) 그래프와 우측의 정보 (체류시간 / 오픈율/ 매출) 가 매칭된 정보라는 것을 인지하기 어려울 것 같아서, 닷(dot)을 동일한 색으로 달아주었다.

2) 구매 / 방문 / 재방문 정보를 위아래의 정보들과 구분하기 위한 의도는 좋았는데, 전반적으로 봤을 때 너무 도드라지기도 하고, 시인성이 떨어지는 면이 있어서, 살짝 톤 다운(tone down) 해주었다.

3) 마지막으로, 시간 테이블의 색상 그라데이션(gradation) 단계를 좀 더 나누고, (기존:5단계 --> 이후:10단계) 1단계가 하얀색(white)이 아니라, 가장 연한 색상을 지니도록 했다. 컨셉 이미지는 상단의 정보가 깨끗해 보일 수도 있지만, 실제 매장 데이터가 돌아갈 때, 단계가 적게 나눠져 있으면 대부분 하얗게 보이거나 빨갛게 보이는 등 극단적으로 보일 수 있기 때문이다.

  매니저 입장에 있다면, 디자이너가 '의지'를 갖고 작업한 디자인에는 크게 손대지 않는 게 좋다. 손을 대면 댈 수록 산으로 가기 마련이어서, 사용성이나 시인성에 지장을 주지 않는 선에서는 디자이너의 의도대로 두는 편이 맞다. 

  사실 폰트가 작아야 디자인이 깔끔하게 보여서, 디자이너들은 가능한 폰트를 줄이는 편이다. 그렇다 보니, 시안을 보고 나서 폰트를 키워달라는 요청을 많이 하곤 하는데, 폰트 사이즈에 맞춰 나머지 디자인의 사이즈나 배치등을 잡기 때문에, 폰트만 키우면 전반적인 밸런스가 맞지 않게 된다. 

  디자인에 함께 의견을 내겠다는 의욕에 이것저것 수정하다가 나중에는 뭔가 이상한데 뭐가 이상한지 알 수 없는 상태가 되는 걸 볼 수 있는데, 이런 경우에는 그 과정을 보지 않았어도 결과물만 보면 알 수 있다. 간혹 앱이나 서비스들을 보다 보면, 도대체 이 앱의 디자인 컨셉은 뭔가 싶을 때가 있다. 열의 아홉은 보스의 숨결이 깃든 서비스가 아닐까 생각해 본다.

  그래서, 앞서 언급 했듯이 이와 같은 기준을 프로젝트 초반에 잡아두고 시작해야 한다. 안드로이드나 iOS같은 경우에는 공통 가이드라인이 있기 때문에, 보통은 그 기준으로 작업하면 되고, 어지간한 디자인 업체는 앱이나 웹 등에 대한 디자인 가이드라인이 있기 때문에 초반에 확인 정도만 하고 넘어가면 된다. 다만, 위와 같이 자사의 디자인 룰(rule)이 별도로 있는 경우에는, 처음 프로젝트를 시작할 때 디자인 업체에 전달해 줘야 한다.

  그리고 초반에 셋업 한 대로 결과물이 나왔을 때는, 사이즈 조정 요청은 불가피한 경우가 아닌 이상, 하지 말아야 한다. 당장 눈으로 보기에 좀 작아 보이거나 커보일 수 있지만, 모니터나 디바이스 환경 탓일 수도 있기 때문이다. 

  함께 보내 온 모바일 사이즈 버전도 특별히 수정 요청할 사항은 없어서, 이제 개발 단계로 넘어가기로 했다. 개발 단계로 넘어간다고 표현했지만, 개발팀은 디바이스 연동이나 플랫폼 구축하는 작업을 계속 해 왔고, 이제 디자인 작업이 끝났으니, 퍼블리싱(publishing) 단계로 넘어간다고 보면 된다.

  퍼블리싱 단계는 디자이너가 퍼블리셔와 함께 디자인 시안대로 화면에 잘 구현될 수 있도록, 한땀한땀 확인해야 하는 작업이라, 사실 UX 팀이 한숨 돌릴 수 있는 단계이다. 

  다만, 매니징 하는 입장이라면, 퍼블리싱이 끝난 뒤에 디자인 시안이 작 적용 되었는지 확인할 필요가 있다. 개발자는 화면 비율(%)로 배치하거나 픽셀(px)이 아닌 단위를 쓰곤 하다 보니, 결과물을 보면 디자인 시안과 애매하게 다른 느낌일 때가 있다. 차이가 느껴질 정도라면, 꼼꼼히 다시 체크해서 디자인 시안대로 적용해 달라고 요청해야 한다.  

  한숨 돌렸다고 해서, UX 작업이 끝난 것은 물론 아니다. 개발이 어느정도 진행될 때까지 여유가 생긴 것 뿐이고, QA 검증이 들어가기 전까지는 의도에 맞게 잘 적용이 되었는지 수시로 확인하고, 개발 중에 이슈가 생기면 사양을 변경하는 작업을 계속 진행해야 한다.

  이 프로젝트의 경우 멤버 전원이 상당히 촉박하게 고생하며 개발을 해서, 10월 초에 데모 사이트를 열어 전시를 진행했고, 11월에 PoC 매장을 오픈해서 운영하는 것으로 마무리할 수 있었다. 이 일정을 보고, 3달이면 서비스 하나 만들 수 있는거 아니냐고 하면 안된다. 이 서비스는 PoC 수준의 프로젝트였고, 상용이었다면 훨씬 더 많은 시간이 필요했을 것이다. 급하게 개발한 서비스에는 구멍이 날 수 밖에 없다는 걸 기억하고, '적절'한 일정을 잡아 진행해야 한다.

  스토어 작업기는 어디까지나 하나의 예이다. 모든 프로젝트는 각기 다 다른 상황을 갖고 있다. 예산 규모나 인력 차이, 개발 기간이나 목표 수준 등이 모두 다르기 때문에, 참고 삼아 유연하게 대처해 나가면 될 것이다. 이제 이 정도로 작업기를 마치고, 다음 장에서 길다면 길었던 연재를 마무리 하려 한다.