by
Jul 06. 2021
2월, 3월: 참사를 일으킨 실수 3가지
실패는 성공의 어머니지만 처음부터 성공하는 게 더 좋겠지?
주로 프로덕트를 디자인하며 배운 점을 기술하며, 회사 내부의 사업, 기획, 프로덕트 기능에 대해서는 언급하지 않을 예정입니다. (언급하더라도 출시된 기능 위주)
갑자기 2월, 3월이 묶였는데 편수가 더 줄어들 것 같기도 하다.. ^^계획성 J라고는 1도 없는 P 성향이기 때문에, 이해해주십사..
내가 디자인을 맡기 전 프로덕트는 웹/모바일 버전으로 막 출시된 상태였다. 이 말은 모바일 앱만 주야장천 디자인했던 내가 웹 디자인도 해야 한다는 뜻이었다. 웹도 결국 ‘유저 인터페이스’였으니, UX/UI 커리어 패스를 선택한 나로서는 언젠가는 꼭 다뤄야 할 분야 기는 했다. 그러나 처음부터 ‘회사’에서 ‘일'로 웹 디자인을 하게 될 줄은 몰랐다. 이럴 줄 알았으면 교양이라도 웹 디자인 수업을 한 번 들어볼걸! 호기롭게 맡긴 했으나 걱정이 앞섰다.
직전 졸업전시에서 아트 디렉팅을 맡으며 반 웹 페이지를 디자인한 경험이 있었으나, 원 페이지 기도 하고 웹 자체에 중요한 기능은 없었기 때문에 ‘저 웹 디자인도 했어요’하기에 민망했다. 그래도 무참히 깨져야 배움도 있지 않겠나? 이참에 웹 공부 좀 하자 싶었다. 드리블과 핀터레스트 등으로 GUI를 눈에 익히고 , 다른 B2B 사이트를 뒤지며 웹 환경을 이해해보려고 노력했다. 갖가지 노력에도 불구하고 실력 부족 상태에서 내가 저지른 실수가 몇 가지 있는데, 이 잘못들이 눈덩이처럼 불어나서 후에 대형 참사가 되었다는 것을 예고한다.
피자를 사 왔을 뿐인데...?한 달 후에 재앙을 일으킨 원인들은 이랬다:
1. 웹 환경에 대한 부족한 이해(모바일 환경과는 정말 다르다!)
2. 급하다고 한 부분만 디자인한 것 (한 번에 전체 페이지를 같이 작업했어야지!)
3.UI가 Hi-fi 단계까지 완성되도록 디자인했던 학부 시절과 다르게 업계에서 출시란 ‘시간 싸움'이라는 것 (물론 실력자라면 짧은 시간 안에 Hi-fi까지 디자인하겠지..)
1번의 경우, 할 말이 없다. 변명의 여지없이 실력 부족, 경험 부족이다.
죄송합니다...이 글을 쓰면서 많은 아티클을 찾아봤는데, 그 시절 내가 간과했던 것이 ‘피츠의 법칙’이었다. UI 디자이너로서 명심해야 할 원칙이라는데, 며칠 전에 처음 알았다. 아직도 UX/UI 배움의 길은 멀다…
피츠의 법칙
피츠의 법칙을 설명하는 그림을 보자.
뭐... 뭐임?수학/과학 포기자로서 그림을 보기만 해도 벌써 아찔해진다. 문과는 글이지. 위키피디아에서 그대로 긁어온 설명을 읽어보자.
피츠의 법칙은 인간-컴퓨터 상호작용과 인간공학 분야에서 인간의 행동에 대해 속도와 정확성의 관계를 설명하는 기본적인 법칙이다. 시작점에서 목표로 하는 지역에 얼마나 빠르게 닿을 수 있을지를 예측하고자 하는 것이다. 이는 목표 영역의 크기와 목표까지의 거리에 따라 결정된다. 이 법칙은 폴 피츠가 1954년에 발표하였다.
이를테면, 웹페이지에서 링크가 걸린 버튼이 너무 작으면 클릭하기 힘든 이유를 설명하는 것이다.
하… 뭐라는 걸까. 제가 피츠 씨의 말씀을 UX/UI에 적용하여 잘 풀어보겠습니다. 내 손꾸락(시작점)이 클릭하고자 하는 버튼(목표로 하는 지점)까지 빠르게 닿으려면 버튼의 크기가 크고, 손꾸락과 버튼과의 거리가 짧아야 한다는 것이다.
정말 당연한 이야기죠? 하하. 그러나 나는 모바일처럼 화면 전체를 써야 ‘직관적’으로 기기를 조작할 수 있다고 생각했다.
모바일과 데스크톱위에 그림은 약간 과장이 있고, 마우스(시작점)의 위치가 어디냐에 따라 결과가 바뀔 수 있지만, 그림을 보면 데스크톱(버튼과 마우스 포인터) 거리가 아이폰(버튼과 마우스 포인터) 거리보다 더 멀다. 데스크톱 인터페이스가 모바일보다 크기 때문에, 마우스 포인터와 버튼(목표로 하는 지점)이 멀 경우의 수가 많다.
모바일에서는 유저가 손가락을 움직여 화면 전체를 사용하도록 컴포넌트를 구성하는 것이 직관적이라고 여겼지만, 이는 웹에서는 적용되는 말은 아니었다. 넓은 화면에서는 오히려 부분적으로 화면을 사용하는 것이 조작하기에 편했다.
두 가지 액션(버튼 클릭 후 또 다른 버튼 클릭 등)을 요한다면 마우스가 최소한으로 움직이게 컴포넌트를 배치해야 한다는 것.
예시로 구글 캘린더를 보자. 모달이 아무 데나 뜨는 것이 아니라 마우스 포인터가 드래그 한 곳(시작점) 바로 옆에 모달이 뜬다.
모달이 저 위치에 뜨는 것은 유저가 캘린더 안에 자신이 만든 시간표를 보면서 모달 안의 항목을 작성하기 위함도 있지만, 드래그(액션 1) 후 다음 유저가 취할 액션이 ‘모달 안의 항목 작성'(액션 2)으로 예상되기 때문이다. 이렇게 유저는 바로 옆의 모달 안 항목을 클릭해서 빠르게 작성/저장할 수 있다.
어쨌든 나는 ‘마우스가 다음 액션을 취하기 위해 이동하는 거리’는 간과한 채 어디서 보지도 듣지도 못한 웹 UI를 만들어낸다.^^
참사의 원인 2번째는 개발이 시급하다고 생각한 부분만 계속 잡고 디자인한 것.
결국 이것도 실력 부족, 경험 부족과 관련 있는 부분인데, 참 바보같이 이렇게 하면 안 되는 것을 알면서도 실수했다.
보통 프로젝트를 하면 대부분의 화면을 같이 디자인하여 Low-fi에서 Hi-fi로 만들어간다. 이렇게 하는 이유는 한 번에 같이 작업해야 일관성 있는 화면을 만들 수 있기 때문이다.
그런데, 실무에서는 론칭 후 빠르게 업데이트 치는 과정을 거친다. 그러려면 빨리 개발해야 하고, 개발 전에 빨리 디자인을 마쳐야겠지? 그러나 나는 페이지를 다 같이 디자인하면 오래 걸린다는 판단 하에 핵심 기능이 있는 페이지 먼저 디자인하고, 다른 페이지를 후에 작업하는 바보 같은 짓을 저질렀다. 결과는 뻔하지. 와우~!!! 나중에 보니 화면들이 일관성 없이 엉망진창이 돼버렸다. 이쪽 페이지에서는 버튼이 여기 있고, 저쪽 페이지에서는 버튼이 저기 있고... 버튼 크기는 화면마다 왜 또 달라? 혼돈 그 자체였다.
사실 한 페이지만 만들어도 경험 많고 실력 좋은 디자이너라면 다른 페이지도 일관성 있게 만들 텐데, 나는 아니었다.
웹디자인 실력 부족+ 한 페이지씩만 디자인함 = 구성, 컴포넌트 엉망진창!
후에 디자인 가이드를 만들고, 그에 맞춰서 화면을 디자인하면서 실수는 어느 정도 만회하였다(하지만 그전에 모두가 고통받았기에 참회합니다..)
3번은 ‘실무는 학부시절과 다르다’는 것. 실무, 거기다 성장을 빠르게 해야 하는 스타트업으로서는 기능 배포> 디자인이라는 것. (물론 사용성에 문제없게 뼈대는 충분히 디자인되어야 한다!) 학부생 때, 수업에서 ‘ Low-fi에서 프로토타이핑을 해라~’, ‘워터폴 방식이 아니라 애자일 방식으로 일해야 한다~’ 등등 이야기는 귀에 딱지 앉도록 들었지만 막상 UT(User Test)는 형식적으로 했었다. 어차피 출시될 서비스가 아니라 학교에서 평가하는 프로젝트니까 GUI에 집중하는 것이 훨씬 점수가 잘 나왔다. 밤을 새우면서 UI가 Hi-fi로 보일 때까지 만들었다. GUI가 곧 결과물인데, 예쁘지 않으면 마지막 발표 때 동료 학생들에게 너무 부끄러웠다.
예쁜 것도 그렇고, 사용성도 자신이 없었다. 유저가 어떤 식으로 사용할 것이라는 시나리오를 가지고 디자인하기는 했지만, ‘내가 예상한 대로 사용하지 않으면 어쩌지?’라는 생각이 머릿속에서 떠나지 않았다. GUI도, 사용성도 완벽할 때까지 디자인하고 개발팀에게 드리고 싶었다.
CTO님이 “언제 넘겨줄 거예요?”라고 물어보셨을 때는 3월 초쯤이었을 것이다. CTO님 입장에서는 계속 나를 기다리시다 말씀하신 것이겠지. 그동안 나는 완성이 안되었다며 디자인 넘기는 것을 미루고 있었다. 그러나 아무리 디자인해도 완성 같아 보이지 않았다. 그때 CTO님이 말씀하신 것이 아직도 기억에 남는다.
“oo님, 사장님들이 그렇게 안 쓸 것 같아서 그래요? 어차피 예상대로 되는 것은 없어요. 문제가 생기면 그때 고치면 되는 거예요. 문제가 안 생기는 게 이상한 거예요. 너무 무서워하지 마세요.”
