어썸한 디자인이 나오려면

0

지인 가운데 핸드폰의 사용성 관련해서 일하는 분이 있습니다. 이분은 핸드폰의 사용성을 정량적으로 측정하는 작업을 오래 전부터 해왔습니다. 아이폰이 국내에 막 도입되려고 할 때, 이분을 만나서 핸드폰 UI관련한 이야기를 들었는데요. 이분이 일하는 조직에서 핸드폰의 사용성이 중요하다는 게 이슈가 되어 디자인 가이드 비슷한 것을 작성하게 되었다고 합니다.

디자인 가이드 작업이 한창 진행될 때, 사업부장님을 대상으로 한 업무 보고가 있었다고 합니다. 그 자리에서 사업부장님이 당시에 출시된 핸드폰의 UI에 대해서 이렇게 촌평을 하셨다고 하네요.

어플리케이션을 한참 쓰다가 종료하려고 종료 버튼을 누르려고 하는데, 버튼이 너무 작아서 나 같이 나이 먹은 사람은 누르기 힘들것 같다는 생각이 들더군. 내 생각에 버튼 크기는 얼마 이상으로 딱 정해서 디자인 가이드에 적어 놨으면 좋겠는데.

버튼이 커지면 누르기야 편해지겠지만, 전체적인 UI 디자인이 변경되어야 한다는 게 문제였습니다. 그런데 사업부장님 지시로 버튼 크기의 최솟값이 디자인 가이드에 들어가 버리면서 디자이너가 봐서, 영 마음에 들지 않는 UI가 만들어질 형국이었다고 하네요.

디자인 위원회라는 말이 있습니다. 디자인을 하거나 디자인을 평가할 때 위원회을 조직해서 수행하는 것을 말하는데요. 대체로 이 디자인 위원회에서 만들어내는 디자인은 평균만 가더라도 잘 나온 결과입니다. 위원회의 특성상 최적의 답을 찾기보다 위원끼리의 권력 구조나 협의의 결과가 반영되기 때문이죠.

디자인에서 통일성이 무척 중요합니다. 이런 통일성은 단순하게 디자인 가이드에 버튼 크기는 몇 픽셀 이상으로 할 것으로 정하거나, 디자인 위원회에서 몇 날 며칠을 머리를 싸매고 토론한다고 해서 얻어지는 게 아닙니다. 특히 소프트웨어의 UI를 구성할 때, 사용자의 마음 속에서 UI를 쓰면서 일관된 멘탈 모델을 구성할 수 있도록 해야 합니다. 이런 건 수천 페이지의 디자인 가이드로도 수 백명의 배테랑 위원으로 달성할 수 있는 게 아니죠.

구글에서 수많은 서비스를 제공합니다. 구글의 서비스를 써보면 엔지니어가 만든 것처럼 UI가 조금 부실한다는 생각이 듭니다. 하지만 쓰면 쓸수록 사용자 UI에 일관성이 있거나 사용자 경험이 동일한다는 것을 느낄 수 있는 것은, 최근에는 어떤지 잘 모르지만 마리사 메이어라는 구글의 검색제품 및 고객서비스 부문 부사장 덕분이었습니다.

이분은 1975년 생으로 진정한 엄친딸이라고 할 수 있죠. 구글의 최종 서비스를 고객이 사용하기 위해서 이분 손을 거치지 않으면 불가능했습니다. 구글에서 이분보다 직급이 높은 분이 와서 ‘검색 버튼’이 누르기 어려우니 조금 더 크게 해보는 게 어떻겠냐고 하더라도, 메이어씨가 봤을 때 형편 없는 조언이라면 제품에 반영이 되지 않았겠죠.

아이폰을 쓸 때마다 새삼 감탄하는 것은 UI의 통일성입니다. 이런 통일성이 제품 모든 곳에서 통용된다는 것은, 제품의 처음부터 끝까지 디자이너 한명이 내적 통일성을 고려해서 제품을 설계하지 않으면 불가능한 일입니다.

잡스 씨의 표현을 빌리자면 어썸(Awesome)한 디자인의 통일성은, 스타 다지이너의 역량을 인정하는 조직에서 가능한 일입니다. 즉 아무리 뛰어난 디자이너를 총괄 수석 디자이너 자리에 앉힌다 하더라도, 직급으로 디자인적 의사결정이 밀리는 곳에서 어썸한 다자인이 나올 수 없죠.

사용자 삽입 이미지

image source: http://www.flickr.com/photos/jakematesdesign/4689135843/

사용자 디자인 뿐만이 아니라 시스템 디자인이나 소프트웨어 디자인에서도 멋진 디자인이 나올려면, 한 사람의 마음 속에서 디자인적인 통일성을 추구해야 합니다. 이게 바로 소프트웨어에서 흔히 말하는 아키텍트입니다. 아키텍트를 만들거나 평가할 때, 다양한 아키텍트 후보를 이야기하고 설계적 대안을 내놓을 때는 다양한 사람들의 참여가 중요합니다.

하지만 그런 다양한 디자인 후보에서 아키텍처를 뽑아내고 아키텍처 요소 사이에 내적 완결성을 추구하려면 한 사람의 아키텍트가 디자인 요소를 통일시켜야 합니다. 그렇지 않다면 한 사람의 아키텍트가 있다 하더라도, 대개 그런 아키텍처는 상위 관리자의 코멘트가 반영된 기괴한 설계가 되거나 위원회의 협의 결과가 되어 버립니다.

About Author

/ root@talk-with-hani.com

신승환은 소프트웨어 개발, 프로젝트 관리, 프로세스 컨설팅 등의 업무를 십 년간 수행했으며, 현재는 차량용 임베디드 소프트웨어를 만들고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)와 트위터(http://twitter.com/talkwithhani)에 꾸준히 남기려고 노력한다. 지은 책으로는 '시지프스를 다시 생각하다',‘겸손한 개발자가 만든 거만한 소프트웨어’와 ‘도와주세요! 팀장이 됐어요’가 있으며, 다수의 IT서적을 번역하였다.

MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet
MS  httpwwwventuresquarenet