실전 UI/UX - 포털 메일 서비스는 어떻게 다를까?
PC / Desktop
1997년 5월. 소수 전문가들의 전유물로만 여겨졌던 이메일의 대중화를 이끈 한메일 등장 이후 20여 년이 흘렀습니다. 인터넷의 발전 속도만큼이나 메일 서비스도 빠르게 발전해왔고 그 반작용으로 우편과 팩스의 위상이 급격히 추락하면서 이메일로 빠르게 대체되는 사회변화도 있었죠. 이제 이메일은 우리 일상, 특히 업무에서 빼놓을 수 없는 중요한 요소로 자리매김한 지 오래입니다. 웹 보급에 중추적인 역할과 함께 포털사이트에서 빠지지 않은 중요 기능인 메일 서비스. 오늘은 각 포털 사이트의 메일 서비스 UI/UX 분석을 통해 각 포털이 지향하는 UI/UX의 철학과 방향성에 대해 조금 들여다볼까 합니다.
메일에서 처음 하는 일은 뭘까?
- 메일 쓰기와 구덴베르크 법칙
메일 서비스의 UI/UX를 분석하려면 우선 사람들의 행동양식부터 파악해야 합니다.
사람들이 메일 서비스에 왜 접속할까?라는 의문부터 시작하는 거죠.
사람들이 메일 서비스에 접속하는 이유는 크게 두 가지입니다.
① 메일 읽기 : 새로 받은 메일이나 전에 받았던 메일의 내용을 확인하기 위해
② 메일 쓰기 : 메일을 작성하기 위해
사람들이 메일 서비스에 접속하는 이유는 메일을 읽거나 메일을 쓰거나 두 가지 행동 중 하나를 하기 위해서입니다. 첨부파일을 다운로드하거나 스팸메일을 삭제하거나 하는 메일 서비스에서 일어나는 모든 활동들이 저 두 가지 범주에서 벗어나지 않죠. 그렇다면 메일 서비스는 메일을 읽거나 쓰는 행위에 최적화된 UI로 구성되어야 할 것입니다.
(상단부터) 구글, 네이버, 네이트, 다음의 메일 서비스 초기화면위 이미지는 주요 포털 사이트 4사(구글, 네이버, 네이트, 다음) 메일 서비스 상단 화면입니다.
위 이미지를 보면 한 가지 특이한 지점을 알 수 있는데요. 국내외 서비스할 것 없이 메일 쓰기 버튼이 좌측 상단 영역에 위치해있다는 걸 알 수 있습니다. 동일한 서비스라도 서비스의 성격이나 개성에 따라 UI가 조금씩 다르기 마련인데 마치 베끼기라도 한 것처럼 동일한 위치에 동일한 기능이 엇비슷한 사이즈로 배치되어 있죠. 왜 이렇게 된 것일까요? 놀랍게도 별거 아닌 것 같은 메일 쓰기 버튼 위치에도 UX의 치밀한 과학이 숨어 있습니다.
구덴베르크 법칙에 따른 사용자의 시선 흐름요하네스 구덴베르크가 고안한 구덴베르크 법칙(Gutenbergs Diagram)이라는 이론이 있습니다. 구덴베르크 법칙은 화면을 4 분할하여 사용자의 시선은 좌측 상단부터 시작하여 중력의 영향을 받아 조금씩 아래로 내려가 대각선 방향으로 이동해 우측 하단에서 끝난다고 하는데요. 이 이론을 웹사이트에 대입하면 사용자가 사이트 접속 시 시선은 좌측 상단에서 시작해서 우측 하단으로 이동하게 됩니다. 그렇다면 구덴베르크 법칙에 따라 콘텐츠의 중요도에 따른 순번을 매긴 뒤 사용자의 시선 이동 흐름에 맞춰 해당 콘텐츠를 배치하면 높은 효과를 얻을 수 있을 겁니다. 사용자가 사이트나 서비스에 접속해서 가장 많이 사용하는 메뉴나 기능을 시선의 시작점인 주시 지역에 배치하고 중요도나 사용빈도가 떨어지는 기능은 Fallow Area에 배치하는 거죠.
자 그럼 다시 앞으로 돌아가서 사용자가 메일 서비스에 접속해서 제일 먼저 하는 행동은 무엇일까요? 앞선 사용자 행동 패턴 분석에 따르면 메일 읽기 또는 메일 쓰기 기능일 것입니다. 그렇다면 주시 영역에 메일 읽기 기능이나 메일 쓰기 기능을 배치해야겠죠. 그런데 메일 읽기는 위치를 특정하거나 고정할 수 없는 반면 (사용자가 새로운 메일을 읽고 싶어 하는지 과거에 보냈거나 받았던 메일을 읽고 싶어 하는지 의도를 파악할 수 없기 때문에) 메일 쓰기는 단일 기능이라 위치를 고정할 수 있습니다. 일반적이라면 메일 읽기와 쓰기 기능의 사용빈도를 고려해서 빈도가 더 높은 기능을 배치하는 게 맞으나 서비스의 특성을 고려하면 메일 쓰기 기능을 주시 영역에 배치하는 것이 더 적절해 보입니다.
요약하자면 사용자가 가장 많이 사용하는 기능은 메일 쓰기 또는 읽기 기능이고 사용자의 시선 흐름에 맞춰 서비스 접속 시 사용자의 시선이 가장 처음 머무는 곳에 가장 많이 사용하는 기능을 배치하면 사용자가 기능을 찾으려 노력할 필요 없이 빠르게 원하는 서비스에 접근이 가능할 겁니다. 그래서 가장 많이 사용하고 위치를 고정하기 적합한 메일 쓰기 버튼이 좌측 상단에 위치하게 되는 것이죠.
메일 쓰기에 숨겨진 UI/UX의 비밀
- 메일을 읽으면서 동시에 쓸 수 있는 방법
메일 쓰기 버튼의 숨겨진 UX에 대해 알아보았다면 다음은 메일 쓰기 페이지에 대해 알아볼 차례입니다.
다들 메일 쓰기 페이지는 다 똑같지 않아?라고 생각할 수 있지만 사실 굉장히 큰 차이가 하나 있습니다. 이 차이에 대해 알아보려면 일단 메일 쓰기 페이지를 나란히 놓고 비교해봐야겠죠?
구글, 네이버, 네이트, 다음의 메일 쓰기 페이지네이버, 네이트, 다음은 메일 쓰기 버튼을 클릭 시 메일 쓰기 페이지로 화면이 이동합니다. 메일 쓰기의 세세한 기능 차이는 있을 수 있어도 메일 쓰기 버튼 클릭 → 메일 쓰기 페이지 이동이라는 페이지 전환 자체는 동일하죠. 그런데 구글은 타 메일 서비스와 약간 다릅니다. 페이지 전체를 이동하지 않고 현재 페이지에서 레이어 팝업 형태로 메일 쓰기 팝업을 표시하죠. 구글만 왜 이런 차이를 보이는 걸까요?
이건 메일을 쓴다는 행위에 대한 국내 포털들과 구글의 관점 차이 때문입니다. SNS와 카카오톡, 라인 같은 인스턴스 메신저가 대중화된 요즘에는 개개인간의 소통이나 연락 수단으로써 메일 기능은 상실하였고 주로 업무용으로 사용하는 것이 일반적인 형태입니다. 연락수단으로 메일이 활용되던 시절에는 자신의 머릿속에 있는 내용을 글로 적거나 답장 기능을 사용해서 메일을 주고받았던 내용을 확인할 수 있기 때문에 다른 메일의 내용을 확인하면서 필요가 없었지만 업무용으로 메일을 사용하다 보면 과거 보냈던 내용이나 템플릿 등을 참조해야 할 상황이 많이 생기게 됩니다. 그래서 메일을 쓰면서 옛날에 보냈던 내용을 참고하면서 작성할 수 있도록 메일 쓰기 기능을 새창으로 만든 거죠. 새창이면 백그라운드에 목록은 그대로 있으니 과거 메일 내역을 보면서 메일을 쓸 수 있으니까요.
이 기능이 생각해보면 별거 아닌데 업무용으로 사용할 때는 상당히 요긴한 기능입니다. 구글이 업무용으로 많이 활용되는 이유도 바로 여기에 있습니다. 구글은 다른 메일 서비스에 비해 업무용 메일에 최적화된 기능과 UI/UX를 제공하고 있으니까요.
구글엔 왜 내게쓰기 기능이 없을까?
- 국내 메일 서비스에는 내게 쓰기 기능이 있고 구글에는 없는 이유
반대로 구글에는 없는데 네이버, 네이트, 다음에는 있는 특이한 기능이 하나 있습니다.
바로 내게쓰기란 기능이죠.
내게쓰기란 보내는 사람도 나, 받는 사람도 나. 한마디로 내가 보낸 메일을 내가 받는 기능입니다. 주로 자료보관이나 메모 등 임시 또는 장기적으로 보관해야 할 내용이나 파일을 보관하기 위해 고안된 사용자 편의 기능입니다. 회사에서 메일이나 그룹웨어를 사용하시는 분들은 잘 아실 거예요. 이 내게쓰기가 업무에서 얼마나 요긴하게 사용되는지. 그런데 업무용 메일에 최적화되어 있다는 구글에는 이 내게쓰기 기능이 없습니다. 왜일까요?
내게쓰기란 기능이 한국의 환경과 사용 특성에 맞게 제작된 기능이기 때문입니다.
글이나 파일을 보관해야 한다라고 생각할 때 한국인에게 가장 간편하고 안전하며 유용한 수단이 메일이기 때문입니다. 일찍이 클라우드가 보급되고 활성화된 서구에서는 글을 보관할 때는 메모 기능, 파일을 저장할 때는 저장소 기능을 사용해 메일로 첨부파일이나 글을 쓸 필요가 없지만 클라우드 보급과 활성화가 늦은 한국은 메일이 클라우드의 기능을 일정 부분 대체하는 역할을 하고 있는 것입니다. 구글은 Keep, Drive 기능을 기본 제공하고 서비스 간의 연계성이 뛰어나 내게쓰기란 기능 자체를 사용할 필요가 없고요.
메일과 다른 서비스를 연계하는 방법
- 링크와 연계
포털에는 메일 말고도 메모나 달력, 클라우드 저장소 같은 다양한 기능과 서비스가 있습니다. 필요에 따라 다른 기능에 있는 내용을 참고해야 할 상황이 발생할 수 있죠. 이런 상황을 대비해 포털들은 어떤 형태로 연계기능을 제공할까요?
다음은 연계기능 자체가 없습니다. 과거에는 캘린더나 클라우드 같은 서비스를 제공했지만 2015년 수익성 악화를 이유로 모두 정리한 이후 연계할 서비스 자체가 모두 사라진 상황입니다. (다음아 아프지 마... 눈물이 ㅠㅠ)
네이트는 상단에 문자, 주소록이라는 연계 기능이 있긴 있는데 연계라기보다는 바로가기 링크에 가까운 느낌입니다. 서로 연계해서 뭘 하고 그런 기능은 없고 그 서비스로 빠르게 이동할 수 있는 바로가기 링크라는 개념에 가깝습니다.
이러한 상황은 네이버도 마찬가지입니다. 캘린더, 메모, 주소록, 클라우드 등 연계할 수 있는 기능들이 많은데도 불구하고 단순 링크만 제공하고 있습니다. 마치 명검을 가지고도 휘두르지 못하는 느낌이랄까요?
마지막으로 어쩌다 보니 모범사례가 된 우리의 히어로 구글입니다. 위 이미지처럼 우측에 애드온으로 연계기능을 제공합니다. 저 연계기능을 클릭하면
위처럼 우측에 사이드 패널로 애드온 기능을 표시합니다. 이 기능은 사용자가 애드온을 추가하거나 편집할 수 있는데요. 메일을 쓸 때 예를 들면 미팅이나 약속을 잡을 때 스케줄을 열어 내 일정을 확인한다거나 메일을 쓰다가 TASK를 열어 내 업무 목록을 확인한다거나 메모를 열어 내용을 참고한다거나 하는 형식으로 구글 내에 있는 다양한 서비스를 연계할 수 있습니다. 열람뿐만 아니라 일정이나 메모를 추가하거나 삭제할 수도 있는데요. 이런 연계기능을 통해 사용자가 KEEP(메모), TASK(업무관리), 캘린더 등 다양한 기능과 편의성을 인지하고 사용을 유도함으로써 사용자를 구글 생태계에 끌어들이는 역할도 겸하게 됩니다.
메뉴를 접겠습니다
- 메뉴를 접어도 되는 이유, 접을 수 없는 이유
최근 L모 패스트푸드 광고 중 햄버거를 접겠습니다 라는 카피가 있습니다. 메일에도 비슷한 기능이 있죠. 일명 메뉴를 접겠습니다.
네이트, 다음 메일 서비스는 왼쪽 메뉴 접기 기능을 제공하지 않습니다. 프레임을 늘리거나 줄일 수는 있는데 (줄이는 것은 제한이 있음) 메뉴 자체를 접거나 숨기는 기능은 없습니다.
네이버는 메뉴 접기 기능을 제공하는데 접는다라는 개념보다는 메뉴 숨기기에 더 가깝습니다.
반면 구글은 좌측 상단에 왼쪽 메뉴를 접는 기능이 있습니다. 좌측 상단에 있는 햄버거 버튼을 누르면 메뉴가 접히고 픽토그램만 표시되죠. 궁금증이 많은 우리는 여기서 한 가지 의문을 가져야겠죠? 구글은 메뉴가 접히는데 네이트, 네이버, 다음은 왜 왼쪽 메뉴가 안 접힐까? 국내 메일 서비스들은 접고 싶어도 접기 어려운 몇 가지 특성이 있기 때문입니다.
메뉴를 접을 수 없는 이유 - 첫 번째
메뉴의 픽토그램화입니다. 메뉴 접기 기능을 지원하는 구글은 각 메뉴마다 왼쪽에 메뉴를 연상시키는 픽토그램을 배치해놨습니다. 그래서 메뉴를 접어도 픽토그램을 통해 메뉴를 인식할 수 있죠. 접혀있는 메뉴는 해당 위치에 마우스를 오버하면 네이버도 유사한 스타일의 픽토그램을 배치해놓긴 했지만 메뉴 접기 기능은 제공하지 않습니다. (이유는 두 번째랑 세 번째에서 설명) 네이트는 픽토그램을 제공하는데 픽토그램보다는 옛날 스타일 아이콘 같은 느낌입니다. 다음은 메뉴에 픽토그램을 제공하지 않습니다. (다음아 아프지마2 ㅠㅠ) 픽토그램이 없으면 메뉴를 접어도 어떤 메뉴인지 유추할 수 없죠. 메뉴 접기의 첫 번째 조건은 픽토그램의 존재 유무입니다.
메뉴를 접을 수 없는 이유 - 두번째
내 메일함의 존재 유무입니다. 위 이미지에서 보이는 것처럼 네이버, 네이트, 다음은 사용자가 폴더를 생성하여 메일을 분류할 수 있는 내 메일함이라는 기능을 제공합니다. 트리구조로 사용자가 하위 폴더를 생성하고 메일을 취향에 맞게 분류할 수 있죠. 한국 메일 서비스 사용자들에게는 익숙한 이 기능이 왼쪽 메뉴를 접는 데는 큰 문제가 됩니다.
내 메일함은 픽토그램을 붙일 수 없습니다. 사용자가 어떤 형태로 메일을 분류할지 예상이 어렵기 때문이죠. (해당 폴더가 중요 메일함인지 자료보관용인지 알기 어려워 임의로 픽토그램을 붙일 수 없음) 접기 기능에서는 하위 폴더 트리구조를 표현하기 어렵기도 하고 사용자가 임의로 생성 가능한 폴더가 있으면 픽토그램으로 표현하기 어려운 구조가 되는 겁니다.
그럼 구글은 하위 폴더도 있고 사용자가 임의로 생성 가능한 라벨(폴더와 비슷한 개념)도 있는데 왜 접기 기능이 가능할까? 구글과 국내 메일 서비스의 폴더 개념 자체가 다르기 때문입니다. 구글은 국내처럼 트리구조의 폴더 개념보다는 메일은 받은 편지함 한 곳에 존재하고 사용자 또는 구글이 임의로 메일마다 라벨을 붙여서 그룹핑하는 형태로 메일 분류 서비스를 제공합니다. 소, 돼지, 양을 키우는 가축 사육장을 예로 들어서 표현하면 국내 메일 서비스는 소의 방, 돼지의 방, 양의 방 가축 종류별로 별도의 방을 만들어서 각 가축들을 사육한다면 구글은 가축은 한방에 몰아넣고 각 가축들에게 너는 소야 저는 돼지야 저는 양이야 라벨을 붙여놓고 라벨 별로 가축을 이해하는 방식이라고 설명하자면 조금 이해가 될까요? 이렇듯 구글과 국내 메일 서비스는 메일 분류의 개념 자체가 달라 이러한 차이가 생기게 됩니다. (구글과 국내 메일 서비스의 메일 분류 체계에 대한 내용은 뒤에서 조금 더 자세하게 설명)
메뉴를 접을 수 없는 이유 - 세 번째
메일함의 비움(메일 삭제)과 수신확인 버튼의 존재 유무 때문입니다. 국내 메일 서비스는 메일함 정리나 수신확인 기능을 제공하는데 비해 구글은 기본적으로 메일함에 대한 정리나 수신확인 기능을 제공하지 않습니다. (보낸 메일함도) 구글에서 공식적으로 밝히기로는 사용자의 개인정보 보호를 위해서라고 합니다.
어쨌든 이 버튼도 메뉴 접기 기능을 제공할 수 없는 주요 원인 중 하나입니다. 메뉴를 접어버리면 수신확인이나 비움 버튼을 노출할 수 없기 때문이죠. 사실 접자고 마음만 먹으면 그 버튼은 숨겨도 되는데 국내 사용자들이 저 버튼의 기능에 익숙해져 있기도 하고 딱히 접을 이유를 못 느끼니 저런 형태로 UI가 유지되는 거죠. 뭐랄까 닭이 먼저냐 달걀이 먼저냐 같은 문제랄까요.
위 세 가지 말고도 접을 수 없는 이유는 몇 가지 더 있지만 크게는 저 3가지 이유들로 인해 메뉴를 접을 수 없습니다. 반대로 생각해보면 구글은 메뉴를 접어야 할 필요성이 있어 의도적으로 메뉴를 접을 수 있도록 메일 서비스의 UI/UX를 구성했고 국내 메일 서비스는 그렇지 않았기 때문에 메뉴를 접지 않았다고도 볼 수 있죠.
메일의 페이징
- 위와 아래, 페이징 위치에 따른 차이
메일의 목록 페이지에서는 페이징 기능을 제공합니다. 언뜻 보면 유사해 보이는 페이징 기능도 각 서비스에 따라 위치나 기능이 조금씩 다릅니다.
네이버는 하단 영역에 스크롤을 표시합니다. 좌측 메뉴 영역과 리스트 스크롤 영역, 페이징 영역을 영역별 프레임으로 분할하여 리스트 영역을 하단으로 내리더라도 페이징은 하단 영역에 고정되도록 UI를 구성했습니다. 페이징 영역에서는 이동 가능 유무에 따라 화살표를 활성화 비활성화 상태로 표시합니다. (현재는 1페이지 제일 앞이므로 맨 앞으로 이동 ◀◀ 과 앞으로 이동 ◀ 은 비활성화, 다음 페이지로 이동 ▶ 과 맨 뒤로 이동 ▶▶ 은 활성화)
네이트는 네이버와 프레임 구조는 동일하나 페이징에서는 약간 차이를 보입니다. 맨 앞으로 이동 (◀◀)과 맨 뒤로 이동 (▶▶) 버튼이 없고 맨 마지막 페이지가 표시되어 있습니다. 네이버와 비교했을 때 어떤 방식이 좋다 나쁘다 말하기는 어렵고 표현방식의 차이일 뿐이죠.
다음은 리스트 영역과 페이지 영역의 스크롤이 분리되어 있지 않습니다. 카카오와 통합 이후 모바일 중심으로 힘을 쏟고 있는 것 같은데 이런 세세한 부분은 조금 아쉽습니다.
구글은 좌측 메뉴와 리스트 영역의 프레임 분할은 동일한데 좌측 메뉴의 스크롤 영역은 약간 다릅니다. 다른 메일 서비스는 페이징이 하단에 있는데 구글만 페이징이 상단에 위치하고 있죠.
4개 메일 서비스를 나란히 놓고 비교해보면 이런 모습이 됩니다. 따로 봤을 때는 몰랐는데 나란히 놓고 보니 확연한 차이가 느껴지죠? 다른 메일 서비스는 페이징이 하단에 있는데 왜 구글만 상단에 있을까? 이건 앞서 설명드렸던 구덴베르크 법칙과도 약간 연관이 있습니다.
국내 메일 서비스의 리스트 페이지는 전통적인 게시판 구조에서 UI를 따왔습니다. 우리가 메일을 볼 때 습관을 생각해보면 메일 제목을 마우스 포커스를 이동해가면서 눈으로 읽는 사람도 있지만 보통은 휠 이동이 가능한 상단이나 중단쯤에 마우스를 놓고 휠을 돌리면서 눈으로 메일을 읽습니다. 실제 마우스 포커스가 주로 위치하는 영역은 보통 상단 50~70% 정도죠.
그렇다면 우리가 메일 서비스에 들어와서 메일을 읽고 다음 페이지로 넘어갈 때 시선 이동방향과 포커스 이동 동선은 위와 같은 형태가 됩니다.
동일한 동선을 구글과 비교해보면 더 명확한 차이를 알 수 있습니다. 구글은 네이버에 비해 동선이 훨씬 짧고 상단에서 모든 동선을 해결할 수 있죠. 메일과 관련된 Funtion이 (삭제, 보관, 라벨 등등) 이 상단에 있어 구글을 사용할 때는 하단에 있는 메일 제목을 클릭하지 않는 한 마우스 포인터가 아래쪽으로 내려갈 일이 별로 없습니다. 즉 사용자의 이동 동선 자체를 상단으로 집중시키기 위해 페이징을 상단에 배치하는 겁니다. 상단에 집중함으로써 동선을 최소화하는 효과도 있지만 사용자에게 서비스를 학습시키는 효과도 있습니다. 상단 이동 동선에 익숙해진 사용자는 앞으로 무언가 기능을 찾을 때 하단보다는 상단을 주시할 확률이 높으니까요.
메일을 분류하는 방법
- 폴더와 카테고리 그리고 라벨
앞서 메뉴 접기 기능에서 국내 메일 서비스와 구글의 메일 분류 체계 차이에 대한 설명을 잠깐 드렸었는데 이번에는 조금 더 심도 있게 메일 서비스의 분류 기능에 대한 차이를 짚어볼까 합니다.
국내 메일 서비스는 전통적인 트리구조 폴더 방식으로 메일을 분류합니다. 이런 방식은 윈도우의 점유율이 높고 폴더와 트리구조 방식에 익숙한 국내 사용자 특성에 적합한 방식입니다. 반면 구글은 폴더나 카테고리 같은 방식이 아니라 각 메일에 라벨을 붙이고 라벨 별로 메일을 그룹핑하는 형태로 메일을 분류합니다. 국내 메일 서비스가 물리적으로 메일의 공간을 나누어 분류하는 방식이라면 구글은 논리적으로 메일에 라벨을 붙여서 그룹핑하는 방식이죠.
받은 편지함의 기본 분류 기능 (기존, 소셜, 프로모션, 업데이트, 포럼)국내 메일 서비스와 다른 특이한 점은 받은 편지함을 3~5개 구분 값으로 구분한다는 점입니다. 기본 (일반메일함), 소셜(SNS 관련 메일함), 프로모션(광고메일함), 업데이트, 포럼 5개 카테고리로 구분된 메일함은 사용자가 스팸메일을 거를 필요 없이 중요 메일이나 일반 메일만 모아서 볼 수 있다는 장점이 있습니다. 강력한 자동 분류 시스템의 뒷받침이 있기에 가능한 구조입니다.
윈도우식 트리구조에 익숙한 국내 사용자들은 콘텐츠 자동 분류 시스템 + 사용자 커스터마이징을 통해 라벨로 콘텐츠를 구분하는 방식이 다소 생소할 수 있는데 MacOS와 구글에서는 이런 방식이 보편적으로 사용됩니다. (대표적으로 구글 포토와 아이튠즈가 그 예) 이런 방식은 초기 세팅이나 적응에 시간이 걸린다는 단점이 있지만 익숙해지면 강력한 효과를 발휘할 수 있죠.
구글의 메일 설정 기능구글은 다양한 사용자 메일 설정 기능을 통해 자동 분류 시스템의 단점을 보완합니다. 국내 메일 서비스와 비교해보면 굉장히 세세하게 메일에 관한 설정들을 지원합니다. 별표 (중요 메일 체크) 하나만 해도 국내 메일 서비스는 1개만 지원하는 반면 구글은 12개의 중요 메일 체크 아이콘이 있을 정도로 꽤나 디테일한 것이 특징입니다. 설정창 하나만 봐도 국내 메일 서비스에 아쉬움이 느껴지는 대목이죠.
첨부파일을 표현하는 방법
- 목록에서 첨부파일을 볼 순 없을까?
이메일 서비스 초기에는 메일 수신함의 용량 제한(초기에는 보통 100MB) 문제도 있었고 메일이 파일을 주고받는 용도보다는 커뮤니케이션 수단으로써의 목적이 강했기 때문에 첨부파일의 중요성이 대두되지 않았습니다. 그러나 SNS의 등장으로 인해 커뮤니케이션 용도보다는 업무용으로 메일의 위상이 변화되고 메일 수신함의 용량이 점점 증가하면서 대용량 파일을 주고받을 수 있게 됨에 따라 메일에서 첨부파일의 중요성이 점차 대두되기 시작했습니다. 특히 각종 공과금과 통지서를 메일로 받는 경우가 많은 우리나라의 경우 첨부파일의 중요성이 더 커질 수밖에 없죠.
이처럼 메일에서 첨부파일의 중요성이 점점 커지고 있지만 국내 메일 서비스들의 UX는 아직도 메일 서비스가 시작된 초창기에서 벗어나지 못하고 있습니다. 하지만 우리의 히어로! 구글은 다릅니다.
목록에서 첨부파일의 이름과 바로가기 링크를 제공하는 구글국내 메일 서비스들은 목록 페이지에서 아이콘으로 첨부파일의 유무를 표시합니다. 이러면 사용자들은 메일 안에 어떤 첨부파일이 몇 개나 있는지 제목을 눌러 상세페이지로 가기 전까지는 알 수 없는 상황이 됩니다. 이런 불편함을 간파한 구글은 목록에서 첨부파일의 이름과 개수까지 친절하게 안내하고 해당 링크를 누르면 연결 프로그램을 이용해 미리보기까지 가능한 서비스를 제공합니다. 이런 미리보기 기능은 업무 시 메일을 주고받을 때 메일 내용보다 첨부파일이 중요한 경우 강력한 힘을 발휘합니다. 메일 내용을 볼 필요 없이 목록에서 바로 첨부파일을 볼 수 있게 해 줘 불필요한 클릭을 방지하는거죠.
메일 상세페이지에서 첨부파일 표시 영역보너스로 구글과 네이버의 상세페이지에서 첨부파일의 표시 영역 비교. 링크 영역이 넓고 아이콘이 큼직큼직해 클릭이 수월한 구글에 비해 네이버는 링크 영역이 좁아 구글에 비해 클릭에 어려움이 있습니다. 어떤 방식이 더 고객의 편의성을 고려한 것인지는 말하지 않아도 알 수 있겠죠?
읽은 메일을 표시하는 방법
- 하이퍼링크와 고대비
메일함에서 읽은 메일과 읽지 않은 메일을 표현하는 방법. 각 서비스마다 어떻게 다를까요? 하나씩 살펴봅시다.
네이버는 읽지 않은 메일은 파란색, 읽은 메일은 검은색 폰트로 표시합니다. 이런 스타일은 과거 하이퍼링크에서 유래를 찾을 수 있는데요. HTML에서 하이퍼링크가 걸린 텍스트 중 클릭한 텍스트는 보라, 클릭하지 않은 텍스트는 파란색으로 표시합니다. 네이버는 여기서 착안하여 읽지 않은 메일의 형태를 표현한 것으로 보입니다. CSS를 적극 활용하는 지금은 이런 형태의 링크를 찾아보기 쉽지 않지만 해외 사이트만 가도 이런 형태를 어렵지 않게 찾아볼 수 있습니다. 기본 하이퍼링크 컬러를 사용하기 때문에 색상만으로 읽은 메일, 안 읽은 메일 구분이 가능하다는 장점이 있습니다.
네이트는 안 읽은 메일을 굵은 폰트(Bold)로 표시합니다. 딱히 크게 장점도 단점도 없는 표현 방식입니다.
구글은 표현방식이 약간 다른데 안 읽은 메일은 굵은 폰트로 표시하고 읽은 메일은 행 영역 배경을 그레이로 표시합니다. 메일 열람 여부를 볼드만으로 구분하는 네이트가 조금 밋밋한 감이 있다면 구글은 읽지 않은 메일과 읽은 메일을 시각적으로 확실히 구분할 수 있죠. 이러한 형태는 시각장애인을 위한 고대비 모드와 유사합니다. 대치되는 컬러를 통해 가독성을 높이는 방식이죠.
마우스 호버 기능을 활용하는 방법
- Mobile First 시대에 호버 기능 활용 법
스마트폰이 생활화되면서 웹사이트와 서비스 제작의 트렌드 역시 Mobile First가 기본이 되어버린 요즘입니다. 스마트폰이 처음 등장하던 시절 Mobile Web은 PC Web의 보조 접근 수단으로만 여겨지던 시절이 있었는데 이제 전세가 뒤바뀌어 거꾸로 PC Web이 Mobile Web의 보조적인 수단이 되어버렸습니다. 이제는 PC Web 없이 모바일로만 서비스를 하는 서비스들도 많이 생겨났고요.
가끔 PC Web은 구색 맞추기용으로 만드는 거 아니에요? 라고 말하며 PC Web을 등한시하는 주니어 기획자들이 있습니다. Mobile Frist의 개념을 잘못 이해해도 한참 잘못 이해한 거죠. Mobile First는 PC Web을 먼저 만들고 Mobile Web을 만들면 Mobile 웹의 UI/UX 구현에 한계가 있으니 Mobile Web을 먼저 만들고 PC Web을 나중에 만드는 우선순위의 개념이지 PC Web은 구시대의 산물이니까 등한시하라는 의미가 아닙니다. Mobile은 모바일대로 PC는 PC대로 나름대로 영역과 역할이 있는 것이니까요.
PC Web을 만들 때 Mobile Web과 차별화할 수 있는 기능이 하나 있습니다. 바로 Funtion에 마우스 포인터를 이동시키면 등장하는 마우스 호버(mouse hover) 기능입니다. Mobile Web은 하드웨어 특성상 터치 기능만 있기 때문에 호버 기능을 구현할 수 없어 잘만 활용하면 PC와 Mobile을 차별화할 수 있는 좋은 기능이죠. 그렇다면 각 메일 서비스는 마우스 호버 기능을 어떻게 활용하고 있을까요?
보낸 사람 이름 위에 마우스를 올리면 이름과 메일 주소를 보여주는 네이버의 호버 기능네이버는 목록에서 보낸 사람의 이름만을 표시하고 보낸 사람 위에 마우스 포인터를 이동시키면 숨겨져 있던 메일 주소를 보여주는 형태로 호버 기능을 사용합니다. 애석하게도 국내 1위 포털 서비스라는 네이버의 마우스 호버 기능은 이게 끝입니다. 네이버가 이 정도라면 다른 서비스들은 볼 필요도 없겠죠?
구글은 마우스 호버 기능을 적극적으로 활용합니다. 메일 영역에 포인터를 두면 숨겨져 있던 Funtion 기능을 노출하기도 하고 (그림1) Funtion 기능에 영역 활성화와 기능 설명 툴팁을 표시하기도 하고 (그림 2-1) 숨겨져 있던 기능을 표시하기도 합니다 (그림 2-2)
마우스 호버 기능을 사용하는 이유는 크게 두 가지입니다. ① 포커싱 영역을 강조하기 위해 호버 기능을 삽입하거나 ② UI상 기능을 넣어야 하나 해당 영역에 정보가 너무 많아서 기능이나 텍스트를 넣을 수 없는 경우 전환 형태로 기능을 삽입하는 경우가 그 예죠.
호버 기능은 사용하기에 따라 여러 가지 용도로 응용할 수 있습니다. 마우스 포커스의 위치를 안내하거나 강조할 수도 있고 (그림1) 툴팁 형식으로 기능에 대한 도움말을 제공할 수도 있고 (그림2-1) 기능 전환을 통해 부족한 레이아웃 공간을 보충하고 사용자에게 기능을 학습 (그림2-2) 시키는데 도움을 줄 수 있습니다.
잘 만든 서비스의 척도, 포커스 영역
- 놓치기 쉬운 포커스 영역 이야기
제가 잘 만든 서비스(혹은 사이트)를 판단할 때 중요하게 생각하는 요소가 하나 있습니다. 별거 아닌 것 같지만 신경을 쓰지 않으면 놓치기 쉽고 서비스 사용성에 큰 영향을 줄 수 있는 요소, 바로 포커스 영역입니다.
포커스 영역은 마우스가 기능을 인식하는데 필요한 영역을 의미합니다. 아이콘이나 버튼으로 범위를 좁혀보면 어느 영역까지 클릭했을 때 아이콘이나 버튼이 동작할까? 라는 개념이죠. 이해를 돕기 위해 예를 하나 들어보겠습니다.
위 이미지는 네이버의 중요 메일 별표 아이콘 사이즈와 포커스 영역입니다. 좌측이 중요 메일 별표 아이콘의 크기이고 (가로 16px / 세로 15px) 우측이 별표 이미지의 포커스 영역입니다 (가로 36px / 세로 41px). 실제 아이콘 크기는 16 * 15인데 상하좌우 패딩 값을 이용해 아이콘 클릭 영역을 36 * 41로 설정해놓은 것을 알 수 있습니다.
실제 아이콘 크기보다 클릭 영역을 넓게 설정한 이유는 간단합니다. 사용자가 클릭하기 편하기 위해 영역을 일부러 넓게 잡아놓은 것이죠. 원래 아이콘 사이즈인 16 * 15px로 클릭 영역을 설정해놓으면 크기가 작아 사용자가 클릭하기 불편하니까 주변 여백을 적당히 클릭해도 아이콘을 클릭한 것과 동일한 효과가 나게끔 포커스 영역을 넓게 잡아놓은 것입니다. 별표 아이콘 사이즈가 굉장히 작기 때문에 포커스 영역을 넓게 설정해놓으면 사용자가 아이콘을 클릭하는데 조금이라도 불편함을 덜 수 있죠.
포커스 영역을 잘 만든 사이트의 척도라고 생각하는 이유는 기획자가 가장 놓치기 쉬운 부분이기 때문입니다. 아이콘이나 버튼, 기능의 사이즈가 제각각이라 일괄적으로 포커스 영역을 지정하기 어렵고 (아이콘 사이즈는 20 * 20px이고 버튼은 30 * 60px 일 경우 동일하게 여백을 상하좌우 10px씩 주는 것보다 적정 퍼센트 비율을 정해놓고 각 사이즈 비율에 맞춰서 여백을 주는 것이 가장 이상적. 예를 들면 여백을 50% 라고 가정하면 아이콘의 상하좌우 여백은 10px이고 버튼의 상하는 15px 좌우는 30px을 여백으로 둠) 설계서에 포커스 영역까지 지정하는 기획자가 없기도 하고 (가끔 변태적인 기획자들이 있긴 함) 경험이 많지 않은 퍼블리셔의 경우 포커스 영역 없이 아이콘 사이즈로 포커스 영역을 정하기 때문에 기획자가 테스트 시 이러한 부분을 잘 걸러줘야 합니다. 반대로 말하면 기획자가 신경을 못쓰면 포커스 영역을 엉망으로 설정할 수도 있다는 이야기지요. (물론 유능한 퍼블리셔를 만나면 알아서 잘해줌)
자 이제 포커스 영역을 알아봤으니 각 메일 서비스에서 포커스 영역을 어떻게 활용하고 있는지만 알아보면 되겠죠?
구글은 아이콘 영역에 마우스 포커스를 이동하면 해당 영역 (혹은 기능)의 포커스를 원형으로 안내해줍니다. 이 기능은 사용자의 현재 마우스 포인터 위치를 알 수 있는 동시에 클릭 범위까지 알 수 있다는 장점이 있죠. 혹시나 사용자가 해당 기능을 모를까 봐 툴팁으로 친절하게 안내까지 해줍니다. 여러모로 사용자를 배려한 잘 만든 사이트의 표본이 아닐 수 없습니다.
네이버는 Padding (상하좌우 여백 값)을 이용해 실제 아이콘 크기보다 포커스 영역을 넓게 설정했습니다 (파란색 영역이 아이콘 사이즈 / 초록색 영역이 해당 아이콘의 포커스 영역) 구글만큼은 아니지만 기본은 했다고 볼 수 있는 수준입니다.
다음도 네이버와 동일한 구조입니다. 차이가 있다면 네이버보다 아이콘 크기가 조금 크다 정도?
마지막으로 한때 포스트 포탈을 자처했던 네이트입니다.
한눈에 봐도 아이콘이 굉장히 작은 걸 알 수 있죠. (네이버 16 * 15 / 네이트 12 * 11) 아이콘만 작은 게 문제가 아니라 포커스 영역을 별도로 설정하지 않고 아이콘 영역만 지정했습니다. 가뜩이나 아이콘도 작은데 작은 아이콘을 마저 클릭하려면 작은 12 * 11px의 아이콘 위에 마우스 포커스를 정확히 위치시켜야 한다는 겁니다.
포커스 영역을 따로 설정하지 않은 건 담당자의 미스라고 해도 아이콘까지 작은 이유는 뭘까요?
4개 메일 서비스 메일 한통의 폭(높이)입니다. 제일 큰 Gmail과 비교해보면 네이트가 25% 정도 폭이 좁은 걸 알 수 있습니다. 이건 기본적인 설계의 문제인데 한 화면에 더 많은 메일을 보여주려다 보니 메일 폭이 좁아질 수밖에 없고 메일 하나의 폭이 좁다 보니 아이콘도 좁은 폭에 맞춰 작아질 수밖에 없었던 거죠. 사용성을 높이자는 취지에서 많은 메일을 보여주기 위해 폭을 줄였는데 좁아진 폭이 더 사용성을 떨어뜨리는 독이 되어버린 겁니다.
액티브와 언액티브
- 기능을 비활성화하거나 숨기거나
스크립트 기술이 발전함에 따라 기능의 액션 처리 양상도 변화하고 있습니다. 액션을 통해 숨겨져 있던 기능이 나타나기도 하고 변화하기도 하는 것이 그 예이지요. 기능을 숨기거나 액션 처리를 할 때 디자이너와 기획자가 가장 많이 고민하는 부분은 해당 기능을 고객에게 어떻게 인지시키느냐 하는 문제입니다.
보이지 않는 기능을 어떤 액션을 했을 때 나타날 것이다 라고 추론을 할 수 있게 한다거나 학습을 통해 인지시키는 것이 가장 좋은 방법인데 이러한 방법은 고도의 UI/UX 이론이 바탕이 되지 않는다면 없다면 실제로 적용하기가 무척 어렵습니다. 반대로 얘기하면 사이트나 서비스가 UI/UX 적으로 일관성을 가지고 있고 유사한 스타일의 기능이 많아 선행학습이 가능한 구조라면 설계자는 부담 없이 도전적인 UI/UX 구조를 만들 수 있고 사용자는 기능의 일관성이나 과거 사례 경험을 통해 이 버튼을 누르면 이런 액션이 펼쳐지겠지라고 자연스럽게 예상할 수 있는 환경이 조성됩니다.
한 가지 기능 예시를 통해 메일 서비스들이 어떤 형태로 액션 처리를 하는지 알아보려고 합니다.
구글은 액션을 상당히 적극적으로 활용합니다. 특정 기능이 아니라 사이트 전반적으로 액션 기능을 적극 활용하고 있는데요. 이러한 적극적인 액션 기능의 활용은 UI/UX의 다양성을 확보해줄 뿐만 아니라 사이트가 전반적으로 역동적인 액티브한 느낌의 인상을 사용자에게 심어줄 수 있습니다. 일관성 있고 고도화된 UI/UX 기반이 갖춰져 있기 때문에 가능한 구죠조.
메일 선택 기능 하나를 예로 들어보면 구글은 체크박스를 선택하기 전에는 새로고침 페이징 등 메일을 선택하지 않아도 사용되는 일반적인 기능을 표시하다가 메일을 선택하면 해당 영역이 선택한 메일을 처리하는 기능들을 표시하도록 변경됩니다 (메일 삭제, 이동, 표시 등등) 이러한 구조는 몇 가지 장점이 있는데요. 한 가지 영역에 2가지 기능을 동시에 노출해 효율적인 영역 구성이 가능하다는 장점 (UI/UX의 다양성) 그리고 특정 영역에 시선을 고정시킴으로써 사용자의 이동 동선을 설계자의 의도대로 조절하여 사용자의 의도가 아니라 설계자의 의도대로 사이트의 흐름을 조절할 수 있다는 점 (UI/UX의 의도성) 히든 기능의 학습을 통해 사용자가 다른 액션 기능에 대해 유추할 수 있다는 점 (UI/UX의 학습성) 마지막으로 정적인 사이트가 아니라 역동적인 느낌의 이미지를 사용자에게 전달할 수 있다는 점입니다. 뜯어보면 뜯어볼수록 정말 치밀하게 설계된 구조입니다.
반면 네이버는 액션 기능을 다소 소극적으로 활용합니다. 기능은 노출하되 비활성화되어 있는 형태로 표시하는 거죠. 구글과 동일하게 체크박스 기능을 살펴보면 네이버는 기능은 노출하되 비활성화 형태로 기능이 동작하지 않도록 처리하다가 체크박스 선택 시 해당 기능이 활성화되는 형태로 액션을 처리합니다. 구글과 비교해보면 차이가 느껴지는데 페이징, 메일 선택 펑션, 새로고침 기능을 한 줄에 모두 표시하는 구글에 비해 3개 기능을 노출하기 위해 네이버는 3개 영역을 사용하는 것을 알 수 있죠.
왜 이러한 차이가 생기는 걸까요. 설계자의 UI/UX에 대한 이해도와 역량 차이도 있겠지만 가장 큰 문제는 의사결정 과정의 차이입니다. 해외 서비스(대표적으로 구글)가 UI/UX에 대한 전반적인 부분을 담당 디자이너에게 일임하거나 결정권자가 UI/UX의 전문가들인데 비해 국내 회사들은 UI/UX 디자이너의 역할이 극히 제안되어 있고 최종 결정권자 주로 비즈니스 관련자 (예를 들면 CEO) 이기 때문입니다. UI/UX를 서비스를 얼마나 사용자가 편리하게 이용할 수 있느냐에 초점을 맞추지 않고 이 서비스로 얼마나 수익을 거둘 수 있느냐에 초점을 맞추기 때문이죠. 최근에는 UI/UX의 중요성이 증가하고 전문 조직도 생겨나고 있어 이러한 풍토도 조금씩 변화하고 있지만 상명하복식 문화가 자리 잡고 있는 기업문화특성상 아직 갈길이 멀어 보입니다.
불필요한 정보는 보여주지 않는다
- 메일 구분 값과 날짜
UI/UX를 구성할 때 혹은 벤치마킹을 할 때 가장 주의해야 할 것은 바로 고정관념에 사로잡히지 않는 것입니다. 이런 기능은 이렇게 표시하는 것이 국룰이지 하는 것들이요. 우리는 혹시 국룰이라는 함정에 빠져 혹은 타성에 젖여 사용자 중심의 서비스라는 UI/UX의 본질, 중요한 것을 잊고 있었던 것은 아닐까요?
구글을 통해 우리가 국룰이라고 생각했던 요소들은 구글은 어떻게 바꿨는지 알아볼까 합니다.
웹 표준이 자리잡기 이전 퍼블리싱, 아니 코딩의 기본 베이스는 테이블 코딩이었습니다. 사용자의 눈에 보이지 않는 테이블(테두리 값을 0으로 설정해놓은)로 레이아웃을 만들어놓고 셀안에 콘텐츠를 배치하는 방식이죠. 그래서 게시판을 비롯한 기능들은 이 테이블 베이스로 설계되어 있습니다.
테이블은 기본적으로 항목을 설명하는 구분 값을 표시합니다. 게시판을 예로 들면 번호, 제목, 작성자, 날짜, 조회수 등이 구분 값이죠. 그래서 테이블 베이스로 만든 게시판이나 메일은 상단에 이 구분 값을 표시하는 것이 일명 국룰이었습니다.
네이트는 이 국룰에서 벗어나지 않았습니다. 테이블 구조인 메일 최상단에 보낸사람, 제목, 날짜, 크기 정보를 표시한 거죠. 참으로 정직한 UI입니다.
구글과 네이버는 동일한 테이블 구조인데도 화끈하게 구분 값을 없애버렸습니다. 그런데 생각해보면 재미있는 지점을 알 수 있습니다. 우리가 그동안 Gamil이나 네이버 메일을 사용하면서 한 번도 구분 값이 없어서 어떤 내용인지 알 수 없거나 불편했던 적이 한 번도 없었다는 것을요. 구글이나 네이버가 구분 값이 없어도 메일을 인지하는데 문제가 없는 이유. 이건 두 사이트가 구분 값이 가지는 본질을 정확히 파악했기 때문입니다.
테이블은 데이터를 보기 쉽게 표시하거나 저장 (데이터베이스에) 하기 위해 사용하는 도구입니다. 테이블에서 구분 값이 필요한 이유는 데이터가 어떤 것인지 설명하고 인지 하기 위해서죠. 텍스트로 되어 있는 게시판이 아니라 숫자로 이루어져 있는 연간 매출표라면? 구분 값이 없다면 숫자가 어떤 뜻을 의미하는 것인지 알 수 없을 겁니다. 그러면 반대로 메일에는 구분 값이 없어도 데이터가 어떤 항목인지 인지할 수 있을까라는 원론적인 질문으로 돌아가봅시다.
메일 목록은 보통 보낸 사람, 메일 제목, 보낸 날짜(시간), 메일의 용량 4가지 요소로 구성됩니다. 그런데 4가지 항목의 데이터 타입이 모두 다르죠. 4개 항목을 DB로 표현해보면 보낸 사람은 Name, 메일 제목은 Subject, 보낸 날짜는 Date, 용량은 Number가 될 겁니다. 목록에서 표현하는 데이터 타입이 다르기 때문에 딱히 구분 값이 없어도 사용자가 인지하는데 큰 무리가 없습니다. 반대로 4개 데이터 타입이 비슷하거나 같다면 항목을 인지하는데 문제가 있겠죠.
위 이미지처럼 데이터 타입이 같으면 구분 값이 없을 때 항목이 어떤 내용인지 인지 할 수 없지만 아래 이미지처럼 데이터 타입이 다르면 내용만 가지고도 어떤 내용인지 유추가 가능합니다. 그래서 구글과 네이버 메일이 항목 구분 값을 없앴는데도 사용자가 내용을 인지하는데 문제가 없는 거죠. 심지어 위 캡쳐는 네이트인데도요!
구글과 네이버 메일이 구분 값을 없앨 수 있었던 이유 한 가지 더. 학습효과와 고객에 대한 믿음입니다. 메일 서비스가 출시된 지 이미 10년도 넘었고 메일 서비스의 목록 UI 가 유사하기 때문에 메일 서비스를 사용하는 사용자들은 이미 메일 서비스 구조에 익숙해진 상태입니다. 이미 많은 부분 학습이 이루어졌기 때문에 구분 값을 없애도 고객이 메일을 인지하는데 문제가 없을 거라는 믿음. 그 고객에 대한 믿음이 있었기 때문에 과감하게 구분 값을 없앨 수 있었던 거죠. 구분 값이 과연 필요할까? 구분 값을 없애도 고객이 메일을 인지하는데 문제가 없을까?라는 문제의식에서 시작한 훌륭한 UX 개선사례의 표본입니다.
유사한 개선 사례 하나 더. 바로 메일의 수신 날짜입니다.
과거의 메일의 수신 날짜(메일을 받은 날짜)는 년-월-일 / 시간 정보를 표시합니다. 예를 들면 네이트가 그렇죠.
참으로 정직한 네이트는 메일의 날짜를 년-월-일 / 시간의 전통적인 방식으로 표현합니다. 정직하다 못해 올곧음 마저 느낄 수 있죠.
구글은 전통적인 방식에서 벗어나 받은 메일을 날짜를 3가지 형태로 표현합니다.
① 오늘 받은 메일 / 시:분
② 올해 받은 메일 / 월.일
③ 올해 이전에 받은 메일 / 년.월.일
구글은 메일 수신 날짜에도 기본적인 의문을 던집니다. 년월일시간을 다 표시할 필요가 있을까? 사용자가 필요로 하는 정보만 보여주면 되지 않을까?
구글이 파악한 메일 수신 날짜의 정의는 이렇습니다.
① 오늘 받은 메일 /시:분
오늘 받은 메일에서 중요한 건 시간이다. 오늘 받은 여부만 사용자가 판단할 수 있다면 년-월-일은 중요하지 않다
② 올해 받은 메일 / 월.일
올해 받은 메일은 목록에서 날짜만 알면 되지 세세하게 받은 시간까지는 알 필요가 없다. 년도도 올해 받았는지 여부만 알 수 있다면 필요 없다.
③ 올해 이전에 받은 메일 / 년.월.일
올해 받은 메일과 동일하게 시간은 알 필요가 없다. 언제 받았는지 연도는 알아야 하니 년-월-일 정보가 필요하다.
이러한 프로세스에 의해 년-월-일 시:분이라는 기존의 패러다임에서 벗어나 사용자가 정말 필요로 하는 정보만 볼 수 있도록 구성했습니다. 이런 구성에는 불필요한 정보를 노출하지 않는것외에 장점이 하나 더 있는데요. 날짜의 형태를 보면 이 메일이 오늘 받은 건지 올해 받은 건지 작년에 받은 건지 알 수 있다는 점이죠. 년월일시간이 일률적으로 표시되어 있다면 숫자 중에서 다른 숫자를 찾아야 하는데 구글 같은 형태는 표시하는 것이 시간이냐 월-일이냐 년-월-일이냐만 파악하면 이 메일이 언제 받은 건지 눈으로 빠르게 구분할 수 있다는 장점이 있습니다.
기존의 통념, 패러다임에서 벗어나 이게 정말 필요한 정보일까? 더 좋게 개선할 수 없을까?라는 근본적인 물음. 혁신은 거기서부터 시작됩니다.
마치며
오늘은 각 포털 사이트의 메일 서비스 목록 페이지 분석을 통해 각 서비스의 차이점과 철학에 대해 알아보았습니다. 모바일 퍼스트 시대를 맞이하여 PC의 중요성이 떨어지고 소외되고 있지만 아직도 일부 영역에서는 Mobile보다 PC의 중요성이 더 높고 대체되기 힘든 특성이 있습니다. 대표적으로 메일 서비스가 그렇죠.
메일 서비스를 분석하면서 가장 아쉬웠던 건 Mobile의 UI/UX에는 많은 신경을 쓰지만 PC의 UI/UX는 상대적으로 등한시한다는 점이었습니다. PC와 Mobile은 각자의 영역과 장점을 가지고 있으며 상호보완적인 관계라고 생각합니다. Mobile과 PC가 서로 공존하고 발전하는 세상이 되길 기원합니다.
추신 / 각 포털 사이트의 담당자분들에게
본글은 특정 서비스를 까내리거나 두둔하자는 목적으로 작성된 글이 아닙니다. 각자 회사가 처한 환경, 투입하는 리소스에 따라 서비스의 질도 달라지겠죠. 그러한 부분을 잘 알고 있고 누구보다도 피부로 겪었던 사람이기 때문에 현재 상황이 참으로 안타깝습니다. 포스트 포털 제가 많이 좋아합니다. 힘내주세요!
