랜선 사수의 디자인 피드백 #3
핀터레스트, 비핸스, 드리블.
그런데 최근, 특히 드리블 레퍼런스를 볼 때 주의해야 한다는 글들이 많이 보인다.
그 이유는 드리블에에 올라오는 작업물들은 대부분 실 구현을 고려하지 않은, 말 그대로 ‘드리블용’ 시안들이기 때문이다. 프로젝트에서 해당 레퍼런스를 보고 활용할 경우 많은 문제가 발생할 수 있다는 게 주된 이유였다.
그래서 최근 디자인 레퍼런스 추천 사이트들은 실제 구현된 사이트 또는 실제 구현된 서비스를 캡처한 사이트들을 많이 추천한다.
물론 실제 오픈된 서비스들의 디자인을 확인하는 것도 매우 중요하다.
하지만 현재 고객들에게 오픈된 서비스들만 벤치마킹할 경우 어디서 많이 본 디자인이 되거나 퀄리티가 떨어져 보이는 경우가 종종 발생한다.
왜 그럴까?
기업이 크면 클수록 프로젝트에 연관된 사업부가 많아진다.
여러 사업부의 콘텐츠가 한 페이지에 노출되는 경우, 기획자나 디자이너는 유저의 입장에서 주요 콘텐츠에 주목도를 주어 페이지 내에서 강·약·중간약 등의 리듬감 있고 균형감 있는 디자인으로 구현하고자 한다.
하지만 여러 사업부를 거쳐 피드백을 반영하면 모든 콘텐츠가 강·강·강·강이 되어버린다.
그들의 피드백은 대략 이렇다:
"우리 사업부도 중요한데 영역이 너무 작아요. 키워주세요."
"우리 사업부에는 왜 이미지가 없죠? 이미지 넣어주세요." (이미지가 들어갈 수 있는 콘텐츠가 아닌데...)
"우리 사업부는 이 항목이 중요하니 굵고 크게 넣어주세요. 빨간색은 어때요?" (유저 입장에서 절대 중요한 콘텐츠가 아닌데...)
물론 이러한 피드백을 다 반영하는 건 아니지만, 어느 정도는 반영되기 때문에 이때에는 디자인 가이드는 소용없다. 균형성과 통일성은 사라지고 무수히 많은 예외 케이스가 생겨나기 시작한다.
(많은 디자이너들이 여기서 해탈한다. "네... 네... 마음대로 하세요...")
외국이나 스타트업은 어떤지 모르겠다 (일해본 적이 없어서...). 하지만 한국은 아직까지 매우, 상당히 수직적인 구조를 가지고 있다.
금융권 프로젝트를 하면 디자인은 최소 3번의 보고를 거치게 된다: 시안 보고, 중간 보고, 최종 보고.
시안 보고 때의 피드백은 디자이너만 화병 걸리는 경우가 많지, 그렇게 크리티컬한 이슈가 발생하지는 않는다. 문제는 중간 보고 이후부터다.
중간 보고부터는 최소 임원 아니면 부사장 보고가 이루어지는데, 이때의 피드백은 거의 90% 반영되어야 하는 경우가 많다. 그 이유가 매우 말도 안 된다 하더라도 무조건 반영이다.(왜? 임원이니까요...)
이때의 피드백은 주로 이렇다:
"글자가 너무 작지 않아?" (타깃층이 20대인데...)
"여기 너무 비어 보이지 않아?" (시선 분산 요소를 최소화해 UT 때도 긍정적 평가가 많았던 사항이었는데...)
"요즘 민트 컬러가 유행한다던데?" (브랜드 컬러에 민트가 없고, 심지어 유행은 이미 지났는데...)
피드백이 놀랍나? 그러나 프로젝트마다 허다하게 발생하는 사항들이다. 놀랍게도.
금융권에서 개발 구현 어려움으로 디자인을 변경하는 사례는 상당히 자주 발생한다. 이유는 as-is 방식의 문제일 수도 있고, 전산 시스템 문제일 수도 있고, 개발자의 귀차니즘일 수도 있다.
어찌 되었든 처음에는 보다 효율적인 UI 디자인이었던 것이 개발 구현 어려움으로 복잡한 UI로 바뀌어서 오픈하는 경우가 허다하다. 따라서 현재 서비스되고 있는 UI가 잘 되어 있는 것이라 확답할 수 없다.
누구나 그럴듯하고 놀라울 만한 서비스를 만들고 싶어한다. 그러나 실제 프로젝트는 늘 타이트한 일정에 시달린다.
1000페이지가 넘는 작업량이 남아있는데 디자인할 수 있는 시간은 고작 한두 달에 그친다. 이러한 상황에서 프로젝트에서 제일 중요한 사항이 뭘까?
퀄리티? 꿈같은 소리다.
모든 프로젝트에서 제일 중요한 건 일정이다. 기획·디자인·개발팀 할 것 없이 모두 오로지 일정을 지키기 위해 고군분투하며 움직인다. 그러한 상황에서 새로운 아이디어나 퀄리티는 뒷전이 되기 마련이다.
이런 경우 대부분은 늘 봐왔던, 흔히 쓰는 UI를 만들기 마련이다. 그저 별말 없이 그냥 그냥 넘어갈 수 있는 페이지를 만들기에도 벅차기 때문이다.
신규 서비스를 오픈하고 나면 정말 말도 안 되는 CS들이 발생한다고 한다.
기획이나 디자인에서 아무리 고민하고 최적화된 UI를 만들어도, 기존 서비스를 사용하던 사용자들은 익숙하지 않은 UI에 불편함을 호소하고 숨겨진 메뉴는 무조건 드러내라고 강요한다.
결국 오픈 이후, 서비스는 점점 원래 의도와는 다른 모습으로 변한다.
이러한 이유들로 실제 오픈한 서비스들이 완벽하다고 믿으며 참고하기에는 어려움이 있다.
실제 오픈한 서비스들을 당연히 벤치마킹하고 자료 조사해야 하는 것과 더불어, 디자인 시안 단계에서는 최대한 디자인적으로 잘된 레퍼런스를 참고하여 디자인하는 것이 필요하다.
결국 균형이 중요하다.
드리블: 시각적 영감과 트렌드 파악용
실제 서비스: 구현 가능성과 사용성 검증용
비핸스: 전체적인 프로젝트 프로세스와 컨셉 참고용
나만의 팁이 있다면 이렇다.
실제 서비스의 콘텐츠를 어떻게 하면 드리블 시안처럼 보이게 만들 수 있을까? 최대한 고민하고 테스트하는 것이다. 구현 가능한 범위 안에서 최대한 정돈되고 감각적인 방식으로 설계해 보는 것.
무진장 어려운 일이지만 어쨌든 우리는 디자이너고, 예쁜 게 좋잖아?