세상에 온전하게 혼자 만든 물건은 매우 드뭅니다. (풀스택이라는 개념도 있지만) 웹서비스 역시 여러 사람의 협업으로 만듭니다. 슬로워크에서 운영하는 이메일마케팅 서비스 스티비도 예외는 아닙니다. 살짝 말씀드리면 스티비는 기획/PM 1명, 디자이너 1명, 개발자 2명이 만들고 있습니다. 큰 조직은 아니지만 소통의 틈은 늘 존재하기 마련입니다. 


그중 하나가 UI 용어입니다. 동상이몽이라는 말처럼 각자 웹서비스 개발을 해왔지만, 모두가 같은 상황과 맥락에서 학습한 것이 아니고, 머릿속에 그리는 이미지가 달라 사용하는 용어가 서로 다를 수 있습니다. 그리고 같은 용어를 사용하면서도 그 의미와 구현된 결과물이 다를 수 있습니다. 


“‘드롭다운'이 들어가야 해요"라고 요청받고 나온 결과물은 ‘버튼을 클릭하면 아래로 펼쳐지는 메뉴'일 수 있습니다. 하지만 요청한 사람이 실제로 원했던 것은 <select>일 수 있다는 것이죠. 이런 소통의 틈을 채우기 위해 우리는 장문의 기획서를 쓰고 시간과 공을 들여 프로토타이핑을 합니다. 시간과 인력 자원이 허락된다면 아주 좋은 과정입니다. 하지만 자원이 적은 스타트업 팀에게는 부담스러울 수 있습니다. 모든 것이 비용이죠. 그저 “‘드롭다운'은 아래로 펼쳐지는 메뉴이고, 옵션 선택을 위해서는 셀렉트(<select>)를 쓰자"고 미리 약속하면 많은 부분이 해결됩니다. 그래서 UI 용어 통일은 중요합니다.



이런 것이 헷갈리고, 이렇게 씁니다. 


몇 가지 사례를 살펴보겠습니다. 서비스를 2년 가까이 만들어 오면서 헷갈렸던 용어와 서로 약속을 통해 바로 잡은 것들, 그리고 아직도 헷갈리는 것들이 섞여 있습니다. 그리고 다른 팀에서 사용하는 의미와 또는 웹표준과 다를 수 있습니다. 그저 “스티비는 이렇게 쓰는구나"하고 봐주시면 되겠습니다.



1. 버튼(button)


사용자의 클릭을 끌어내는 버튼. 마우스와 키보드를 가지고 할 수 있는 많은 액션이 있지만 무언가를 클릭하는 것만큼 직관적이고 친숙한 UX는 없을 것입니다. 그 중심에 버튼이 있습니다. 어떤 때는 이동을, 어떤 때는 실행이나 취소를 위해 버튼을 클릭합니다. 


버튼의 개념과 역할은 아주 명확한 것처럼 보이지만 프론트엔드 개발자 입장에서는 때로 ‘링크'와 혼동될 때가 있습니다. 어떤 것은 <a>로 만들어진 링크로 만들어야 하고, 어떤 것은 <button>으로, 또 어떤 때는 <input type=”submit”>처럼 하기도 합니다. 하지만 표현되는 결과물은 마우스를 올리면 색이 변하는 ‘버튼'이죠. 보통 <a>는 페이지의 이동을 나타내고, <button>은 실행이나 취소, <input type=”submit”>은 양식의 전송을 말합니다. 


스티비에서는 ‘버튼', ‘링크', ‘링크 버튼'을 혼용해서 사용합니다. 결과물은 버튼이지만 개발자의 재량에 따라 어떤 방식으로 구현할지 정합니다. 위 용어들에 대한 추가 질문은 따로 하지 않습니다. 그리고 SPA 방식으로 개발된 탓에 실제로 구분이 명확히 되지 않는 경우가 있습니다. 


* 이렇게 씁니다.

→ “개발자가 알아서 한다"



2. 팝업(popup)과 모달(modal) 


다음으로 헷갈리는 것이 팝업과 모달입니다. 과거 ‘팝업’은 작은 새로운 윈도우를 띄우는 기능을 말했습니다. 최근 팝업 차단이나 모던 브라우저들의 다중탭 기능 덕분에 많이 사용하지 않는 기능이 되었습니다만 아직도 많이 사용되는 용어입니다. 그리고 모달은 비교적 최근에 등장한 개념으로 화면 위에 레이어를 덮어 마치 새로운 창이 나타나는 것처럼 보여주는 방식입니다. 


“이 부분은 모달로 해주시고요.", “다음 페이지는 역시 같은 팝업에서 이동하는 것으로...”. 이처럼 초기에는 위 용어를 혼재하여 사용했습니다. 새로운 윈도우를 띄우는 상황은 없거나 매우 희박하므로 소통에 큰 문제는 없었습니다. 다만 모달은 ‘기존(부모) 페이지와 맥락을 달리하는...”이라는 함의를 가지고 있습니다. 이런 경우는 되도록 ‘모달'이라는 용어로 통일하려고 합니다. 


* 이렇게 씁니다. 

→ 팝업/모달은 중에 하나를 선택하지는 않지만 열리는 상황과 맥락에 따라 용어를 구분하면 좋다. 구현은 하나의 통일된 템플릿으로 진행한다. 

 


3. 얼럿(alert)



‘얼럿’은 사용자가 무언가 잘못된 길로 갔을 때, “띵"하고 뜨는 그 경고창입니다. 과거에는 브라우저에 내장된 기본 기능을 많이 사용했지만, 디자인과 사용성을 위해 최근에는 디자인이 입혀진 레이어로 구현된 유사 얼럿이나 하단에 위치한 토스트얼럿UI 등 다양한 변형이 사용되고 있습니다. “사용자가 취소하려고 하면 이런 메시지로 경고를 해주세요"라는 요청을 받는다면 개발자는 이것을 단순히 alert()으로 처리할지 상단에 뜨는 예쁜 레이어로 띄웠다가 일정 시간이 지나면 없앨지, 하단에 커다랗게 보여줄지 고민이 됩니다. 앞서 살펴본 모달 형식의 경고도 있으니 혼란은 커집니다. 


대부분 서비스가 그렇겠지만 스티비는 미리 설계된 얼럿 디자인을 사용합니다. 보통의 경우 당연히 이 UI를 사용하고, 추가 액션이 필요하거나 화면의 가운데 모달 형식으로 보여줘야 할 경우라면 디자인 작업물에 명시합니다. 화면에 붉은 글씨로 보여주는 경우도 있어 이 부분은 대부분 디자인 결과물로 소통합니다.


* 이렇게 씁니다.

→ 디자이너가 각 상황과 맥락을 파악하며 적당한 경고 방식을 선택, 디자인 작업물에 배치하여 개발팀에 전달합니다. (디자인 결과물은 제플린으로 전달합니다)



4. 드롭다운(dropdown)과 셀렉트(select)



결과부터 말씀드리면 ‘드롭다운'과 ‘셀렉트'는 다른 UI입니다. 하지만 비슷한 역할을 하는 경우가 있어 혼용하여 사용되는 것 같습니다. ‘드롭다운'은 하위 메뉴가 숨겨져 있다가 사용자의 마우스 오버나 클릭에 숨겨진 메뉴를 보여주는 UI입니다. 셀렉트는 <select>태그로 구현되며 사용자에게 내재된 옵션값 중 하나(또는 여러 개)를 받기 위한 양식 UI입니다. 


예쁜 디자인을 위해 레이어로 구현된 드롭다운처럼 구현한 셀렉트도 있고, 셀렉트인데 옵션의 선택에서 그치는 것이 아니라 선택과 동시에 페이지가 이동된다든지 하는 액션을 가진 경우가 있어 혼란이 생긴 것으로 생각됩니다. 


* 이렇게 씁니다.

→  초기 기획 단계에서 이 둘은 명확히 구분합니다. 사용자에게 어떤 값의 입력(선택)을 요구하기 위해서는 셀렉트를 사용합니다. 이때 디자인은 변형될 수 있지만, 선택이라는 핵심 기능은 그대로 둡니다.

버튼 뒤에 숨겨진 메뉴를 표현하기 위해서는 드롭다운을 사용합니다. 하위 메뉴에서 어떤 액션이 있어야 한다면 드롭다운으로 합니다. 구현은 기획에 맞추어 진행합니다.



5. 인풋(input)


‘인풋’, ‘입력창', ‘필드' 등 여러 이름으로 불리웁니다. 사용자에게 텍스트 형식으로 어떤 내용을 입력받기 위한 UI로 보통은 그냥 사각형이고, 여기에 테두리(border)나 옅은 배경(background)를 주어 사용합니다. 


딱히 헷갈릴 일이 없긴합니다. 하지만 뭔가 용어 통일을 한다면? 아마도 ‘텍스트 입력'이나 ‘텍스트 인풋'이 적당하지 않을까 합니다. 결과물은 입력을 위한 상자이지만 구현은 보통 <input>태그로 합니다. 하지만 단순히 인풋이라고만은 할 수 없는 것이 <input type=”checkbox”>나 <input type=”radio”>, <input type=”submit”> 같은 예외가 있기 때문입니다. “인풋으로 해주세요", “인풋 중에 뭐요?”같은 상황이 생길 수 있습니다. 그렇다고 ‘텍스트 입력'이라고 한다면 <textarea>와 혼동할 수 있습니다. 구현 과정을 생각하여 되도록 명확한 용어가 사용되는 편이 좋습니다.


* 이렇게 씁니다. 

→ 무엇을 입력할지 디테일한 전달 필요. 용어 통일은 조금 더 논의해 본다.



마치며 

쓰임에 따라, 상황에 따라 다를 수 있는 UI 관련 용어들. 각자 편한 대로 쓰면 되지 왜 꼭 통일해야 할까요? 오히려 하나의 단어로 통일하는 순간 그 단어만 제한되는 것은 아닐까요? 개발 조직마다 다르겠지만, 스타트업이나 스타트업처럼 작고 빨라야 하는 조직에서의 팀원 사이의 이런 작은 ‘싱크'들은 매우 중요합니다. 드롭다운을 열심히 그렸는데, 실제로 필요한 건 셀렉트였다면? 이렇게 소통이 어긋났을 때 발생하는 시간과 자원의 낭비가 줄어듭니다. 세세한 UI까지 디자이너가 그리는 시간을 줄일 수 있습니다. 미리 약속된 UI(일종의 스타일 가이드)가 있다면 개발자는 상세 디자인 없이도 기존 것을 재사용하면 되기 때문입니다. UI 용어의 싱크만 잘해도 많은 시간을 절약할 수 있습니다. 그 시간에 더 많은 아이디어를 실험하고 구현해볼 수 있습니다. 



Posted by slowalk

이 글은 코알못의 스케치 플러그인 개발 도전기 (1) - 시작하기에서 이어지는 글입니다. 지난 글에서는 스케치(Sketch) 플러그인을 개발하기 위해 플러그인의 구조와 플러그인 개발을 위해 필요한 것들을 알아봤습니다.


이제 만들어보겠습니다.


  1. 스케치는 MacOS용 애플리케이션이며 플러그인도 MacOS에서만 개발할 수 있습니다. 이 글도 MacOS를 기준으로 작성됐습니다.
  2. 이 글은 스케치 플러그인 개발 방법을 설명하는 글이 아니라 말그대로 ‘개발 도전기'입니다. 코딩을 모르는 사람도 간단한 스케치 플러그인을 개발할 수 있다는 것을 전달하기 위한 것입니다.
  3. 코알못의 스케치 플러그인 개발 도전기 (1) - 시작하기를 먼저 읽어보는 것을 권장합니다.



뭘 만들지?


개발 과정이 순탄하지 않겠지만, 가장 먼저 뭘 만들지 정해야 합니다. 가장 쉬운 방법은 내가 불편했던 것에서부터 시작하는 것입니다. 적어도 나한테는 필요한 것을 만드는 것이기 때문에 순탄하지 않은 개발 과정에서 동기부여가 될 뿐만 아니라 스스로가 사용자로서 기능에 대한 정확한 피드백을 줄 수 있기 때문입니다.


물론 더욱 많은 사람에게 필요한 게 무엇인지 생각해보면 좋겠지만, 이건 어디까지나 개발을 해본다는 것이 목적이기 때문에 너무 깊은 고민은 하지 않았습니다.


스케치를 사용하면서 불편하다고 느꼈던 것 중 하나는, 복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export(내보내기) 할 수 없다는 것이었습니다. 다른 것들도 많았지만 그리 복잡한 로직이 필요하지 않아보였기 때문에 플러그인 개발 도전기의 대상으로 낙점했습니다. (물론 모든 기획이 이렇게 단순한 발상과 근거로 진행되지 않거니와, 이렇게 단순한 발상과 근거로 진행된다고 해서 꼭 좋은 결과로 이어지는 것도 아닙니다.)


그럼 “복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export 할 수 없다"는 문제를 좀 더 자세히 알아보겠습니다.


우선 제가 저런 작업을 해야했던 이유는 다음과 같습니다.


스티비 런칭을 위한 초기버전 개발이 한창이던 때, 스케치로 와이어프레임을 만들고 이를 인비전(Invision)으로 Export 해서 디자이너, 개발자와 커뮤니케이션을 했었는데, 세부적인 기능이나 시나리오에 대한 정의를 전달하기 어렵다고 느꼈습니다. 그래서 스케치로 와이이프레임을 만들되, 인비전이 아닌 다른 도구를 활용하여 세부적인 기능이나 시나리오에 대한 정의를 전달하기로 했고, 결과적으로는 보편적인 방식인 - 벗어나고 싶었던 - “화면기획서"를, 구글 프레젠테이션으로 만들기로 했습니다.



누구를 위한 화면기획서인가



정리하면 다음과 같습니다.

  1. 스케치로 와이어프레임 제작 (1개 화면 = 1개 아트보드)
  2. 화면 단위인 아트보드를 이미지 파일로 Export
  3. 이미지 파일을 구글 프레젠테이션에 삽입하고 기능, 시나리오 등에 대한 상세 정의를 추가


이런 상황에서 복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export 할 수 없다는 것은 큰 불편을 초래했습니다. 아트보드를 복수 선택하는 것은 가능하지만 페이지를 복수 선택할 수는 없었기 때문에, 20여 개의 페이지를 하나씩 선택한 뒤 아트보드를 선택해서 Export 해야했습니다.


그래서 페이지를 하나씩 선택하지 않고 모든 아트보드를 한 번에 Export 할 수 있다면 좋겠다는 생각이 든 것이죠.



근데 이걸 꼭 내가 만들어야 하나?


이미 솔루션이 나와있다면 굳이 고생해서 만들 필요는 없겠죠. 그래서 복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export 할 수 없다는 문제를 해결할 수 있는 다른 솔루션은 없는지 찾아봤습니다.


  1. 이런 기능을 제공하는 플러그인이 있는지 찾아봤습니다. Export를 편리하게 하는 플러그인들이 있긴 했지만 복수의 페이지에 속한 모든 아트보드를 한 번에 Export하는 플러그인은 찾지 못했습니다.
  2. 스케치에 유사한 기능 - “Export Artboards to PDF”- 이 있다는 걸 알게됐습니다. 하지만 1) PDF로 저장된다는 점과 2) 선택한 페이지에 있는 아트보드만 Export 하기 때문에 결국 페이지를 하나씩 선택해가면서 Export해야한다는 점에서, 제가 느꼈던 문제를 완전히 해결해줄 수는 없었습니다.


1에서 유사한 플러그인이 있는지 찾아보는 것이 중요한 다른 이유는, 이런 플러그인에서 유사한 기능을 어떻게 구현했는지를 알면 내가 필요한 플러그인을 개발할 때도 도움이 되기 때문입니다.


여전히 과연 나 말고 누가 이런 기능을 필요로 하겠냐는 의구심이 들고 있지만, 어쨌든 나는 필요하고, 다른 솔루션은 없으니, 일단 만들어보기로 했습니다.



그럼 본격적으로 만들어보겠습니다.


일단 위에서 얘기한 복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export 할 수 없다는 문제를 해결할 수 있는 논리적인 과정을 생각해봤습니다.


  1. 플러그인을 실행합니다.
  2. 페이지를 조회합니다. (조회한 모든 페이지에 대해 A, B를 반복 실행합니다.)
    1. 페이지를 선택합니다.
    2. 선택한 페이지의 아트보드를 조회합니다. (조회한 모든 아트보드에 대해 I, II를 반복 실행합니다.)
      1. 아트보드를 선택합니다.
      2. Export 합니다.
  3. 플러그인을 종료합니다.


요는 2와 2-B의 반복실행 단계를 자동화한다는 것입니다.


그럼 먼저 위의 내용으로 구성한 코드를 살펴보겠습니다. 이해를 돕기위해 위의 내용을 그대로 주석으로 옮겼습니다. (스케치 플러그인의 파일 구조를 잘 모르겠다면 스케치 플러그인 개발 도전기 (1) - 시작하기를 먼저 읽어보세요.)



위 코드는 아직 동작하는 코드는 아닙니다. 일단 기본적인 내용으로 구성해본 것입니다. 실제로 동작하게 하려면 몇 가지 고려해야 할 것들이 있습니다.


  1. 스케치 플러그인으로 실행되기 위한 함수를 정의합니다. (모든 스케치 플러그인의 스크립트에 공통적으로 필요한 내용입니다.)
  2. 열려있는 스케치 문서를 조회합니다. (모든 스케치 플러그인의 스크립트에 공통적으로 필요한 내용입니다.)
  3. 아트보드에 미리 정의된 Export 설정값을 초기화합니다. (사용자가 Export 설정 값을 따로 정의해놨다면 저장되는 이미지마다 크기가 다를 수 있기 때문에, 이를 무시하기 위한 것입니다.) 방법은 다음과 같습니다.
    1. 선택한 아트보드를 복제합니다.
    2. 복제한 아트보드의 Export 설정값을 초기화합니다.
    3. 복제한 아트보드를 삭제합니다.
  4. 이미지를 저장할 경로를 정의합니다. 방법은 다음과 같습니다.
    1. 저장 경로에 사용하기 위해 페이지 이름을 조회합니다.
    2. 저장 경로에 사용하기 위해 아트보드 이름을 조회합니다.


그럼 위의 내용을 코드에 추가해보겠습니다. 역시 이해를 돕기위해 위의 내용을 그대로 주석으로 옮겼습니다.



아직 한 가지 빠진 게 있습니다. 바로 이미지를 저장할 경로를 정의하기 위해 사용자가 경로를 선택하는(파일을 저장할 때 파인더에서 폴더를 선택하는) 과정입니다.


완성된 코드입니다.



완성된 플러그인 패키지는 여기에서 내려받을 수 있습니다. 이미지 저장 경로 선택 및 호출과 Export 부분의 코드는 Quick Export를 참고했습니다.



스케치 플러그인 개발을 통해 얻은 것


안타깝게도 글을 쓰기 시작했던 시점과 달리, 지금은 스티비 팀의 개발 프로세스가 바뀌었고, 화면기획서를 만들고 있지 않고, 스케치로 작업한 모든 UI/GUI 관련 산출물은 제플린(Zeplin) 또는 인비전 인스펙트(Invision Inspect)로 Export 해서 확인하고 있습니다. 그래서 이번에 만든 플러그인은 이제 쓸 일이 없어졌습니다 (누군가에겐 쓸모가 있었으면 하지만 애초에 나 말고 누가 쓸까 하는 마음이었기 때문에 기대는 하지 않습니다.)


그럼에도 의미가 있었던 건, 코드에 대한 거부감을 줄일 수 있었다는 것입니다.


간단하게나마 스케치 플러그인을 개발해보면서 코드를 구성하는 논리적인 사고의 과정을 경험해볼 수 있었습니다. 문제점을 해결하기 위한 아이디어를 “문장의 나열"이 아닌 “논리적인 구조"로 만들어본다면, 개발자와의 커뮤니케이션이 한층 수월해지지 않을까요?


꼭 스케치 플러그인일 필요는 없습니다. 비개발자가 코딩을 비교적 쉽게 경험해볼 수 있는 다양한 도구가 존재합니다. 프레이머(Framer)도 그중 하나입니다. 자신의 필요에 맞게 - 화면기획서를 만들기 위해 스케치를 사용하면서 느꼈던 불편함에서 출발했던 이 글처럼 - 선택하면 됩니다. 일단 시작해보세요!



참고

The Beginner’s Guide to Writing Sketch Plugins Part 2 — User Notifications

Sketch Developer Reference

Quick Export


작성: 임호열

Posted by slowalk



슬로워크의 스티비 팀에서는 디자인 작업을 할 때 스케치(Sketch)를 적극적으로 활용하고 있습니다. 와이어프레임을 만드는 일부터 GUI를 입히고 간단한 아이콘을 만드는 일까지, 스케치로 시작해서 스케치로 끝난다고 할 수 있을 정도입니다.


스티비 팀이 쓴 스케치 관련 글



스케치로 작업 중인 새로운 스티비의 와이어프레임(좌)과 GUI(우)



스케치를 사용하다보면 가끔씩 ‘이런 기능도 있으면 참 좋을텐데'하는 생각이 들 때가 있습니다. 이런 부족함을 충족시켜주는 것이 스케치의 플러그인*입니다. 스케치 외에도 대부분의 유사한 애플리케이션들(포토샵, 일러스트레이터 등)이 플러그인 기능을 가지고 있지만, 고작 6년 밖에 되지 않았고(26년 된 포토샵과 비교하면 ‘고작 6년’) 19명 밖에 되지 않는 작은 규모의 팀이 만들고 있는 스케치 입장에서, 플러그인의 다양성은 다른 애플리케이션들과의 경쟁에서 앞서나갈 수 있는 좋은 무기 중 하나일 것입니다.


* 플러그인이란 애플리케이션이 제공하지 않는 기능을 사용하기 위해 설치하는 일종의 확장 프로그램을 말합니다.



스케치 공식 홈페이지에는 무려 366개의 플러그인이 소개되고 있습니다. 이제 여기에 소개되는 일만 남았습니다!



스케치 플러그인을 직접 만들어볼 수는 없을까요?


아티스트라면 자신이 사용하는 도구 정도는 직접 만들 줄 알아야 한다는 말이 있듯이, 디지털 시대의 기획자라면 자신의 제품을 만드는 도구를 만들지는 못하더라도 그 도구의 손잡이 정도는 만들 수 있어야 하지 않을까 싶지만, 물론 코알못(‘코딩을 알지 못하는 사람’의 줄임말) 입장에서 플러그인을 만든다는 것은 손잡이는 커녕 정말이지 상상도 안 되고 감도 잡히지 않는 것입니다. 플러그인은 누군가 만들어놓은 걸 내려받아서 설치해서 사용해보기만 했지, 그걸 직접 만든다는 생각은 해본 적이 없으니까요.


하지만 스케치 플러그인은 비교적 접근하기 쉬운 CocoaScript*로 만들 수 있다는 사실에 약간의 흥미가 생겼고(정확히 말하면 두려움이 줄어들었다는 게 맞겠네요), 마침 개발 과정을 아주 쉽게 소개한 글을 발견하고 도전해보기로 했습니다.


* CocoaScript는 스케치가 실행되는 MacOS의 개발 언어인 Objective-C와 Cocoa의 코드를 비교적 쉬운 Javascript 문법으로 사용할 수 있게 해주는 프레임워크입니다.


그럼 시작합니다.


  1. 코알못이 무작정 도전해본 스케치 플러그인 개발 과정을 연재할 예정입니다. 코알못이 쓴 글이니 코알못이 아닌 분의 입장에서는 지루할 수 있습니다. 물론 저같은 코알못인 분의 입장에서도 지루할 수 있습니다.

  2. 스케치는 MacOS용 애플리케이션이며 플러그인도 MacOS에서만 개발할 수 있습니다. 이 글도 MacOS를 기준으로 작성됐습니다.

  3. 중간에 포기한다면 이 글이 마지막이 될 수도 있습니다.



준비하기


1. 텍스트 에디터를 설치합니다.

글을 쓰려면 노트가 필요하듯 코드를 쓰려면 에디터가 필요합니다. 프론트엔드 개발자들이 가장 많이 사용하는 에디터 중 하나인 Sublime Text 3를 추천합니다.


2. '콘솔(Console)'을 실행합니다.

디버깅(코드를 실행한 결과를 확인하는 과정)을 위해 MacOS의 기본 애플리케이션인 콘솔을 실행합니다. MacOS의 ‘Spotlight’(단축키 control+space)에서 ‘콘솔’ 또는 ‘console’을 검색하면 실행할 수 있습니다. 콘솔이 실행되면 왼쪽 사이드바에서 ‘리포트'의 ‘system.log’를 선택합니다. 여기에서 스케치 플러그인을 개발하면서 작성한 코드가 어떤 결과를 출력하는지 확인할 수 있습니다.


콘솔은 이렇게 생겼습니다. 외계어 같은 것이 써있네요. 검색 창에 ‘sketch plugin’를 입력하면 스케치 플러그인과 관련된 로그만 따로 볼 수 있습니다.



3. 스케치 플러그인 폴더를 찾아갑니다.

스케치 플러그인 폴더의 경로는 다음과 같습니다. (이 폴더는 스케치 플러그인을 개발하면서 자주 확인해야 하므로 파인더(Finder)의 즐겨찾기에 추가해두면 좋습니다.)

/사용자/[사용자 이름]/라이브러리/Application Support/com.bohemiancoding.sketch3/Plugins


이미 설치한 플러그인이 있다면 스케치 플러그인 폴더에 ‘.sketchplugin’이라는 확장자를 가진 파일이 있는 것을 확인할 수 있습니다.



플러그인 만들기


스케치 플러그인은 ‘.sketchplugin’이라는 확장자를 가진 패키지 파일로 존재합니다. 이미 설치한 플러그인이 있다면 ‘.sketchplugin’ 파일을 오른쪽 클릭한 뒤 ’패키지 내용 보기'를 선택하면 플러그인을 구성하는 파일들을 확인할 수 있습니다.


스케치 플러그인의 파일 구조는 다음과 같습니다.



‘.sketchplugin’ 아래 ‘Contents’ 폴더가 있고 그 아래 ‘Sketch’ 폴더가 있습니다. ‘Sketch’ 폴더 안에는 플러그인의 기본 정보를 담고있는 ‘manifest.json’ 파일과 플러그인이 실제로 작동하는 코드를 담고있는 js 파일이 있습니다.


위 구조를 참고하여 ’MyPlugin’이라는 샘플 플러그인을 만들어보겠습니다.


1. ‘Plugins’ 폴더 아래 ‘MyPlugin.sketchplugin’이라는 폴더를 만듭니다.


2. ‘MyPlugin.sketchplugin’을 오른쪽 클릭한 뒤 ’패키지 내용 보기'를 선택합니다. (‘MyPlugin.sketchplugin’은 확장자를 가지고 있기 때문에 더블클릭하면 파일이 실행됩니다. 폴더를 탐색하려면 ’패키지 내용 보기'를 선택해야 합니다.)




3. 이 안에 ’Contents’라는 폴더를 만듭니다.


4. ‘Contents’ 폴더 안에 ’Sketch’라는 폴더를 만듭니다.


5. 이제 ‘manifest.json’ 파일과 js 파일을 만들 차례입니다. js 파일의 이름은 편의상 ‘MyScript.js’로 하겠습니다. js 파일의 이름은 원하는대로 수정해도 되지만 ‘manifest.json’ 파일 안에 js 파일의 이름이 정의되어있기 때문에 함께 수정해야 합니다. 설치한 텍스트 에디터를 실행하고 각각 아래 코드들을 붙여넣어 저장합니다.


먼저 ‘manifest.json’ 파일입니다.



'manifest.json' 파일은 플러그인에 대한 기본적인 정보와 실제 플러그인을 실행하기 위한 플러그인 파일 정보, 스케치 애플리케이션에 표시할 메뉴 구성, 단축키, 플러그인 식별 값 등 일종의 트리거(trigger)를 담고 있습니다.


그리고 MyScript.js 파일입니다. js 파일의 이름을 수정하면 ‘menifesto.json’의 ’“script” : “MyScript.js”’ 부분을 함께 수정하면 됩니다.



'MyScript.js' 파일이 담고있는 이 코드가 실제로 플러그인이 동작하는 내용입니다. 코드의 내용에 대한 자세한 설명은 우선 건너뛰겠습니다. 



플러그인 실행하기


이제 스케치의 ’Plugins’ 메뉴를 열어보면 ’My Plugin’이라는 플러그인이 설치된 것을 확인할 수 있습니다. ‘My Plugin’의 ‘Get Page Names’를 선택하면 ‘MyScript.js’의 코드가 실행됩니다. 




플러그인 실행 결과 확인하기


플러그인이 실행된 결과는 ‘준비하기’ 단계에서 미리 열어놨던 콘솔에서 확인할 수 있습니다. 왼쪽 사이드바에서 ’리포트’의 ‘system.log’를 선택하면 나오는 화면에 아래와 같은 내용이 출력됐다면 플러그인이 정상적으로 실행된 것입니다.


플러그인을 실행할 때 선택되어있던 페이지 이름인 ‘Page 1’이 출력됐습니다!!



여기까지 문제없이 잘 따라오셨나요? 이제 스케치 플러그인을 생성하고 코드 실행 결과를 확인하는 방법을 알게 됐을 뿐입니다. 하지만 일단 이 과정을 이해했다면 적어도 다른 플러그인의 구조를 뜯어보는 것까지는 가능할 것입니다. 


이어지는 글에서는 플러그인을 통해 스케치의 기능을 어떻게 제어하는지, 그것을 코드로 어떻게 구현하는지 알아보겠습니다. 그 전까지 제가 포기하지 않는다면…



참고

The Beginner’s Guide to Writing Sketch Plugins Part 1 — Getting Started

Sketch Developer



Posted by slowalk

올 초 인터랙션 디자이너로 스티비에 합류하면서 어도비(Adobe)를 벗어나 다양한 프로토타이핑 툴을 사용했습니다. 그 중 가장 선호하는 툴은 스케치(Sketch)로, 새로 리뉴얼하는 스티비의 90% 이상을 스케치 기반으로 만들고 있습니다. 처음에는 왜 스케치를 쓰는 디자이너가 많아지는 걸까? 의문이 들었는데요. 스케치를 쓸수록 반복적인 업무가 효과적으로 단축되고 협업할 때 편리해서 제게도 다른 툴을 제치고 가장 많이 사용하는 툴로 자리잡았습니다.



지난해, 디자이너 툴 서베이 결과에 따르면 조사 대상자 중 스케치 사용자가 34%, 포토샵 사용자는 29%로 스케치 유저가 포토샵 사용자보다 많았습니다. 기존 유저 중 절반을 스케치에 빼앗겨버린 어도비가 안쓰러울 정도였는데요. 이렇게까지 유저들이 포토샵에서 스케치로 작업 환경을 옮겨간 이유는 무엇일까요? 바로 아직까지 어도비에서 모바일 어플리케이션 제작에 최적화된 툴을 내놓지 않았기 때문입니다.


모바일 어플리케이션 디자인은 화면을 만든 후 끝나는 작업이 아니라 직접 사용해보며 기획한 대로 시나리오가 흘러가는지, 화면 이동이 자연스러운지 여러 번 테스트를 거쳐야 합니다. 이때 스케치로 작업하면 레이어까지 그대로 활용해 프로토타입을 만들 수 있는 여러 도구가 있어 다양한 프로토타이핑을 시도해볼 수 있습니다. 하지만 어도비에서는 Photoshop과 Illustrator에서 만든 작업물을 이미지로 추출한 후 AfterEffect나 Keynote 등을 활용해 프로토타이핑을 하게 되는데, 이때 작업에 필요한 레이어를 추출하는 것부터 쉬운 일이 아닙니다.


이렇듯 UI/UX 디자이너들은 빠르게 프로토타입을 만든 후 논의와 수정을 거쳐 새로운 서비스를 내놓아야 하는 환경에 놓여있는데 어도비의 프로그램은 이런 흐름을 쫓아가지 못하고 기존의 개별 프로그램만 업데이트하고 있던 것이죠. 그 사이 UI/UX 디자이너들은 자신들의 메인 툴을 어도비에서 스케치로 옮겨버리게 된 것입니다.


그렇다면 디자인 프로그램의 제왕인 어도비가 유저들이 마구 이탈하는 상황에서 가만히 손놓고 당하고 있을까요? 아닙니다. 이들도 UI/UX 툴의 춘추전국시대를 재패할 엄청난 무기를 만들고 있습니다. 그것이 바로 “Adobe XD(Experience Design)”입니다.


어도비 XD(Experience Design) 프리뷰 공개


어도비는 스케치의 가장 큰 단점인 “스케치만 사용해서 프로토타이핑까지 끝낼 수 없다”는 점을 노리고 스케치와 스케치 플러그인들의 장점을 합친 XD를 시장에 내놓았습니다(아직 시험판입니다). 근데 이게….시험판인데도 ‘우와!’ 소리가 납니다. 그도 그럴 것이 스케치와 다양한 플러그인 조합을 사용해 만든 편리한 디자인 환경을 어도비 XD 하나로 경험할 수 있게 했다는 점이 어마어마한 장점이기 때문입니다. 특히 디자인과 프로토타이핑을 하나의 어플리케이션에서 작업할 수 있는 것은 어도비 XD가 지금까지 나왔던 자잘한 프로토타이핑 툴과 스케치를 대체할 수 있는 유일한 대체제로 우뚝 설 수 있다는 것을 점을 시사하고 있습니다.


그럼 이제 본격적으로 Sketch와 Adobe XD를 비교해보겠습니다.



쉽게 사용할 수 있는 스티비의 새로운 에디터를 만든 스케치!

스케치의 기본 인터페이스



단순 반복작업을 일괄적으로 처리


스케치를 통해 다양한 사이즈로 이미지를 추출하는 모습



이미지를 다양한 모바일 화면에 적합한 크기로 추출할 때 이미지마다 저장과정을 반복해야 하는 기존 프로그램과 달리 스케치는 다양한 크기와 포맷으로 이미지를 한번에 추출할 수 있습니다.


이런 단순 반복 작업일수록 스케치의 장점이 가장 돋보이는데요. 여러 페이지에 반복해서 사용하는 도형을 “심볼”로 정해놓고 작업 중간에 “심볼” 하나를 수정하면 전체에 반영되기 때문에 일일이 수정하지 않아도 빠르게 작업을 마칠 수 있습니다. 이 밖에도 도형을 만드는 것부터 정렬하는 것 까지 이렇게 편할 수가! 하는 순간들이 한 두 번이 아닙니다.


다양한 협업툴

웹 서비스를 만들 때 기획자-디자이너-개발자간의 원활한 소통이 가장 중요합니다. 이를 위해서 다양한 문서작업을 하게 되는데, 스케치를 활용하면 문서작업에 들이는 시간이 훨씬 줄어듭니다.

먼저 시나리오를 만들때 스케치를 활용하면, 각 화면을 인비전(Invision)과 연동해 시나리오가 제대로 만들어졌는지 간단한 프로토타입을 빠르게 만들어볼 수 있습니다. 시나리오 확인 후, 디자이너는 시나리오 파일에 그대로 디자인을 얹어 작업을 진행할 수 있습니다. 따로 틀을 다시 그릴 필요가 없이 한 파일로 mock-up과 시나리오 프로토타이핑 그리고 디자인까지 연동이 가능합니다.


스케치로 작업한 파일을 제플린으로 확인하는 모습


디자인을 마친 후엔 스케치로 작업한 파일을 제플린(Zeplin)으로 연동하게 되면 자동으로 각 페이지의 asset이 얼마인지 개발자가 보기 편하도록 이미지를 문서로 변환해 보여줍니다. 이때 이미지 파일도 함께 연동할 수 있어 디자이너와 개발자 사이에 쓸데없이 오고 가는 문서의 양과 문서를 제작하는데 걸리는 시간을 획기적으로 줄일 수 있습니다.(Photoshop도 CC버젼부터 제플린을 사용할 수 있습니다.)


만약 텍스트 여백 때문에 제플린에 디자이너가 의도한 정확한 수치가 나타나지 않는다면 measure를 사용해 정확한 간격을 입력할 수 있습니다(지금까지 단점으로 지목된 부분은 어도비 CC에서 많이 개선되었습니다).




스케치에게 빼앗긴 유져를 되찾으려 왔다: 어도비 XD

XD의 시작화면. 다양한 사이즈의 화면을 선택해 디자인을 시작할 수 있습니다.


어도비에서도 UI, UX유저를 겨냥한 어도비 XD를 만들었습니다. 스케치와 다양한 프로토타입 툴에 빼앗긴 기존 유저를 되찾아 올 수 있을까요? 지금은 정식 버전 이전으로 프리뷰 버전만 출시되었지만 앞으로 출시될 XD의 모습을 미리 살펴보도록 하겠습니다.


단축키 = 기존 어도비+스케치

디자이너들은 프로게이머와 견줄 수 있을 정도로 끊임없이 단축키를 누르며 작업합니다. 그런데 스케치와 어도비 계열 프로그램은 서로 단축키가 달라 스케치로 작업하다 Photoshop이나 Illustrator에서 작업을 하게 되면 머리와 손에서 단축키가 충돌을 일으킵니다. 허나 XD는 어도비에서 만든 프로그램 아닙니까! 어도비에서 사용하던 단축키를 그대로 사용할 수 있는 것부터 내집에 온듯 편안한 기분이 들게 해줍니다.(만약, XD에서 단축키는 물론이고 Illustrator와 Photoshop 파일까지 자유자재로 호환이 된다면 유저들은 다시 어도비에 충성을 맹세할 것입니다)


Repeat Grid

Repeat Grid로 반복적인 디자인을 구현하는 XD


스케치에서는 craft 플러그인을 활용해서 만들 수 있는 Repeat Grid를 XD에서는 버튼 하나로 바로 구현 가능합니다. (추측이지만 craft팀에서 XD 데모 영상 중 특별한 툴바 없이 finder에서 파일을 드래그만 하면 이미지와 글이 알아서 변경되는 부분을 보고 뒷목을 잡지 않았을까 싶네요.) Repeat Grid, 이것 하나 만으로도 어도비 XD가 위대해 보이는 부분입니다.


인터페이스

Design과 Prototype 패널로 쉽게 페이지를 오고갈 수 있습니다.


스케치와 흡사합니다. 스케치를 사용하던 유저는 조금 더 쉽게 사용할 수 있습니다. 오른쪽 패널은 정렬과 크기, 컬러 등을 선택할 수 있고 왼쪽은 툴이 나열되어 있습니다. 레이어 창이 없는 것이 스케치와 다른 부분입니다. 디자인과 프로토타입 패널도 쉽게 오고갈 수 있습니다.


디자인과 인터렉션을 한번에. 완벽한 프로토타이핑툴

XD는 프로토타입을 만들때 그 장점이 돋보입니다. 스케치에서는 프로토타입을 만들기 위해서 다른 어플리케이션과 스케치파일을 연동시켜 작업하는 것이 일반적입니다. 반면 XD는 디자인과 프로토타입을 한번에, 하나의 어플리케이션 안에서 만들 수 있는 툴입니다.



만드는 방법도 아주 간단합니다. 화면이 시작하는 지점을 클릭하고 그 다음 나타나는 화면을 선택하고 세부 사항을 정하면 완성됩니다. 이렇게 만든 프로토타입은 웹에서 바로 실행해볼 수 있고 핸드폰으로 미러링해 직접 동작해보는 테스트도 가능합니다. URL도 생성할 수 있어 다른 사람들과 바로 공유할 수도 있습니다.


기존 어도비 유저를 그대로 흡수할 가능성이 높은 XD와 다양한 어플리케이션과 함께하는 스케치. 그 최후의 승자가 누가 될까요. UI/UX툴의 홍수 속에서 어서 빨리 XD 정식버전이 나오길 기대합니다.


참고: adobe XD, design tools survey

작성: 조은지


Posted by slowalk


‘디자이너’라는 용어는 매우 광범위하고도 애매하게 쓰이고 있습니다. 그 종류만 해도 제품 디자이너부터 편집 디자이너, 웹, 모바일 디자이너까지 다양합니다. 특히 스크린 기반의 인터페이스 디자이너인 UI, UX의 개념은 디자이너조차 혼돈에 빠뜨립니다. 오늘 포스팅에서는 이렇게 헷갈리는 기술/미디어 기반 디자이너의 역할에 대해 살펴보고자 합니다.


우선 사전적 정의를 살펴보면 아래와 같습니다.


사전적 정의 (출처: 두산 백과, 미디어 백과)



비슷한 것 같으면서도, 비슷하지 않은 듯한 느낌입니다. 흔히 UI는 그래픽 디자인을 기반으로 시각적인 부분을 담당하고, UX는 프로토타이핑 툴과 관련이 깊은 정도로 알고 있습니다.


그렇다면 누가, 어떻게 이 불명확한 개념을 명확하게 정의할 수 있을까요? 해답은 사전이 아닌, 실제 프로젝트가 발생하는 회사가 가장 잘 알고 있지 않을까요? 그래서 기술, 미디어 분야의 선도 기업인 구글, 페이스북, 애플의 채용공고를 살펴보았습니다.




UI 디자이너


구글 비주얼 디자이너


직무 내용 설명(Job description)을 살펴보면, 구글의 비주얼 디자이너는 아이코노그래피, 타이포그래피, 색, 공간, 텍스처를 종합적으로 사용해 사용자들이 제품을 효율적으로 이용할 수 있도록 돕는다고 설명합니다. UI를 비주얼적으로 제시하여 정보의 가독성과 접근성을 높이는 작업을 수행합니다. 또한 비주얼 디자이너를 UX 직군으로 분류하고 있습니다.


페이스북 커뮤니케이션 디자이너

페이스북 프로덕트에 대한 설명


UI 디자이너 대신, 커뮤니케이션 디자이너라는 직종이 있습니다. 역시 UX/디자인 직군으로 분류됩니다. 직무 설명에는 디지털 프로덕트와 브랜드 디자인에 능한 디자이너를 찾고 있다고 명시하고 있고, 다양한 미디어 플랫폼으로 작업하는데 익숙해야 한다고 합니다. 또한 프로덕트 디자인과 프로젝트 전략에 대한 깊은 이해를 요구합니다. 프로그래밍 경험은 필요 없다고 합니다.


애플 비주얼 디자이너

구글과 동일한 비주얼 디자이너라는 용어를 사용합니다. 직무 분석에는 소비자들을 매료시키는 다양한 디지털 자산을 디자인하며, 비주얼 디자인 팀, UX 디자이너, 에디터, 제품 팀과 협업한다고 소개합니다. 구글, 페이스북과 다른 점은 비주얼 디자인과 UX 디자인 직군을 구분해서 사용한다는 점입니다. 따라서 프로덕트 디자인보다는 애플 자체의 브랜딩, 광고, 매체 등에 사용될 비주얼을 제작하는 것에 중심을 두고 있는 듯합니다.



요약

애플을 제외한 나머지 회사에서 UI 디자이너는 UX 직군으로 분류됩니다. 통상적으로 그래픽 디자인을 기반으로 프로덕트 UI 디자인에 관여하기도 하지만, 회사의 비주얼 브랜딩에도 관여합니다.




UX 디자이너


구글 UX 디자인 매니저


따로 UX 디자이너라는 직책은 없습니다. 다만 UX 디자인 매니저가 UX 팀의 리더로 업무를 이끕니다. 팀 리더이자, 매니저로서 총체적인 디자인을 살필 수 있어야 합니다. UX 설계, 반복적인 업데이트가 가능해야 하며 일관성있고 포괄적인 UX를 구축해야 합니다. 웹과 모바일 어플리케이션 관련 포트폴리오가 필수입니다.



페이스북 프로덕트 디자이너


페이스북 프로덕트 디자인 VP인 Julie Zhuo의 블로그


페이스북에는 프로덕트 디자이너라는 직책이 있습니다. 브레인스토밍에서 픽셀 수정까지 제품 개발의 모든 과정에 참여합니다. 프로덕트 디자인, 인터랙션 디자인, 비주얼 디자인 등을 모두 활용할 수 있어야 합니다. 브랜딩에 관여하는 ‘커뮤니케이션 디자이너’보다는 좀 더 프로덕트 자체의 디자인이 중심이며, 차이점은 프론트엔드 프로그래밍이 가능해야 한다는 점입니다.


애플 UX 디자이너


애플의 플랫폼인 iOS, OSX, 웹 앱 등의 인터페이스 디자인을 맡습니다. 다양한 플랫폼 상의 복잡한 인터랙션 문제를 해결할 수 있어야 합니다. 디테일을 볼 줄 알고, 인터랙션과 비주얼 디자인 스킬을 통합적으로 갖춰야 합니다. 포토샵, 일러스트레이터, Sketch, Axure를 능숙하게 다룹니다.



요약


UX 팀 내에 속해 있는 경우가 많으며, 주로 프로덕트 디자인 전반을 다룹니다. 그런 만큼 웹과 모바일 플랫폼, 어플리케이션 디자인에 익숙해야 하며, 프로그래밍에 대한 이해가 필요합니다.


인터랙션 디자이너





스티비 인터랙션 디자이너의 디자인


구글 인터랙션 디자이너

구글 인터랙션 디자이너는 전세계 수백만의 사람들이 직관적이고, 쉽게 사용할 수 있는 디자인을 제공할 수 있어야 합니다. 그 과정에서 다른 디자이너, 리서처, 엔지니어 팀과 협업해야 합니다. 사용자 흐름(user flows)과 와이어프레임의 프로토타이핑이 가능해야 합니다. HTML과 자바스크립트 역량은 플러스 요인입니다.


애플 인터랙션 디자이너


어플리케이션 디자인 팀의 멤버로서 맥과 iOS의 비주얼 인터페이스 디자인을 담당합니다. 인터랙션 디자인, 비주얼 디자인 스킬을 갖춰야 합니다. 업무적으로는 UI 디자인에 가깝습니다.


요약


인터랙션 디자이너의 개념은 회사마다 다르게 설정되어 있습니다. 구글 인터랙션 디자이너는 UX 디자이너의 업무와 비슷한 역량이 필요하며, 애플 인터랙션 디자인은 UI 디자인에 중점을 두고 있습니다.



지금까지 대표적인 세 기업의 디자이너 채용공고를 살펴보았는데 기업 마다 요구하는 역량이 조금씩 달랐습니다. 동일한 ‘비주얼 디자이너’  ‘인터랙션 디자이너’라는 용어를 사용하지만, 업무 내용은 달랐습니다. 혼란스러운 가운데 공통점을 찾아내어 정리를 하자면


  • UI 디자인, 비주얼 디자인은 주로 그래픽을 기반으로 하며 기업의 전반적 브랜딩에도 관여한다

  • UX, 인터랙션 디자인은 각 회사의 프로덕트 디자인을 다룬다. 웹, 앱 디자인, 프로그래밍에 대한 이해가 필요하며 프로토타이핑 툴을 다룬다

  • 대부분 UX를 큰 틀로 두고, 각각의 디자인 팀들이 존재한다


UI, UX라는 분야가 소개 된 지 많은 시간이 지났고, 그 경계는 흐려졌으며 많은 기업들에서 두 역량이 결합된 인재를 원하고 있습니다. 비주얼(그래픽) 디자이너와 UI 디자이너의 구분도 많이 없어졌습니다. 특히 스크린을 기반으로 하는 기술/미디어 기업에서는 더욱 그렇습니다. 경계가 흐려지고 모호해지는 디자인 영역에서, 앞으로 어떤 디자인 분야에 종사할지 고민인 학생, 현재 자신의 디자인 역할에 의문이 든 디자이너는 다른 기업의 채용공고를 보면서 역량을 점검해 보는 것도 좋을 것입니다. 결론적으로 각 기업마다 사용하는 용어에 차이가 있으며 요구하는 역량도 달랐지만, 살펴본 세 기업 모두 공통적으로 중요시한 것은 다른 팀, 디자이너와의 협업 능력이라는 것을 잊지 않아야겠습니다.


by 돼지 발자국


참고: Google Careers, Work at facebook, Jobs at Apple, Fastcompany



Posted by slowalk

 최근 구글Material Design Guide(다양한 디바이스를 아우르는 구글의 디자인 가이드라인, 일관된 사용자 경험을 위해 제작되었다)에 Bottom navigation이란 요소를 추가했습니다. iOS와 UI를 차별화 하고 콘텐츠 영역을 확보하겠다는 의도에서 하단에 내비게이션을 두지 않는 것을 원칙으로 하였던 구글이 결국에는 하단 내비게이션을 선택한 것이죠.

구글의 하단 내비게이션, 사진출처



이스북의 변화도 인상적입니다. 주요 메뉴들을 하단 내비게이션으로 끌어냈습니다. 구글의 프로덕트 디렉터인 Luke Wroblewski의 ‘Obvious Always Wins’에 따르면, 기존에 메뉴와 내비게이션의 역할을 하였던 햄버거 메뉴를 없애고 하단에 내비게이션을 두면서 사용성이 더 높아졌습니다.




햄버거 메뉴를 하단 내비게이션으로 대체한 페이스북과 Redbooth, 사진출처




이러한 변화들은 무엇을 말하고 있을까요?  그리고 왜 하단 내비게이션일까요?



스티븐 후버는 일반인의 모바일 기기 사용에 대한 자신의 연구에서, 응답자의 49%가 스마트폰을 사용할 때 한 손으로 잡고 엄지 하나 만을 사용한다고 밝혔습니다.



스마트폰을 잡는 손의 위치에 따라 생기는 두 가지 주요 터치 영역, 사진출처



엄지 손가락을 사용할 때 터치하기 쉬운 영역, 사진출처



 스마트폰을 사용할 때 엄지손가락을 사용하게 되면, 위의 그림과 같이 Thumb Zone이 생깁니다. 녹색이 엄지손가락이 닿기 쉬운 위치이고, 붉은색으로 갈 수록 엄지손가락이 닿기 어려운 위치입니다. 스마트폰의 크기가 커질 수록 그 경계가 더욱 극명합니다.



구글 Material Design의 주요 내비게이션 터치 영역 비교, 사진출처



Thumb Zone을 실제로 대입해보면 그 차이가 더욱 명확합니다. 위의 그림처럼 한 손만 사용하는 사용자의 경우에는 상단에 왼쪽에 위치하는 햄버거 메뉴보다 하단의 내비게이션에 엄지손가락이 접근하기 쉽습니다. 두 손으로 스마트폰을 사용하는 사용자들이 상대적으로 영역에 구애 받지 않는다고 할 때, 기존의 햄버거 메뉴보다는 하단의 내비게이션을 사용함으로써 대부분의 사용자들을 고려한 서비스를 제공할 수 있습니다.  




그렇다면 하단 내비게이션을 잘 만들기 위해서는 어떻게 해야 할까요?



1.가장 중요한 목적지만 담을 것


하단 내비게이션에는 3~5개의 목적지를 담는 것이 좋습니다. 목적지가 3개 미만일 경우는 사용자가 받는 정보가 빈약하여 서비스를 제대로 파악하지 못하게 되고, 5개가 넘어가면 선택 영역이 좁아져서 사용자가 불편함을 느끼고 이용 중인 서비스에 대해 복잡함을 느끼게 됩니다.



목적지가 2개일 때보다 안정적인 3개짜리 내비게이션, 사진출처



5개가 넘어가자 아이콘이 작아지고 복잡해진 내비게이션, 사진출처



Gaumengut의 안정적인 하단 네비게이션, 사진출처



따라서 하단 내비게이션에 너무 축약하거나 너무 많이 보여주기보다는, 3~5개의 엄선된 목적지를 배치하여 안정으로 구성할 필요가 있습니다.



2.현재 위치를 잘 보여줄 것


‘내가 지금 어디에 있는가?’를 사용자가 아는 것은 매우 중요합니다. 여행을 할 때 지도를 펼쳐 들고 내가 지금 어디에 있는 지를 알아야 다음에 어디를 갈지, 어떻게 가야 할 지 한눈에 파악할 수 있는 것과 같습니다.


하단 내비게이션에는 주로 아이콘을 사용하는데, 아이콘에 각기 다른 색을 쓰는 것보다는 주요 색으로 통일하고 사용자가 현재 있는 위치의 아이콘만 색깔을 다르게 하는 것이 좋습니다.



크리스마스 트리 같은 색(왼쪽)보다는 주요한 색 하나를 쓰는 것(오른쪽)이 눈에 띕니다. 사진출처



메시지가 파란색으로  활성화 중인 트위터의 하단 내비게이션, 사진출처



 목적지 각각을 어떻게 잘 설명하느냐도 내가 지금 어디에 있는지 파악하는 데 중요한 역할을 합니다. 해당 메뉴의 역할이 충분히 설명되지 않은 아이콘을 사용하거나, 텍스트 라벨이 간결하고 함축적으로 목적지를 설명하지 못하면 사용자가 한눈에 현재 위치를 파악하는 데 어려움을 겪을 수 있습니다.



아이콘이 무엇을 나타내는지 알기 힘든 Bloom.fm 앱, 사진출처



텍스트 라벨이 간결하지 못해서 발생하는 나쁜 예, 사진출처



3.따로 설명이 필요 없도록 명확하게 표현할 것


 사용자를 이끄는 매력적인 특징과 콘텐츠가 있다고 하더라도 사용자가 그것을 발견하지 못하면 아무 소용이 없을 것입니다. 그래서 하단 내비게이션은 명확해야 합니다.


하단 내비게이션은 눌렀을 때 어떤 단계를 거치지 않고도 직접 연관된 화면이 보이는 목적지로 향해야 합니다. ‘Photo’라고 하면 사진들을 모아 놓은 앨범이 아니라 모든 사진이 쭉  나열되어 있는 화면이 나와야하는 것이죠.



직접적인 화면을 보여주는 하단 내비게이션, 사진출처



그리고 가능하면 어떤 화면이든지 항상 같은 내비게이션을 노출해야 합니다. 그래야 사용자가 안정적으로 느낄 수 있고, 각각 내비게이션의 목적에 대한 이해도 더욱 쉽게 할 수 있습니다. 일시적으로 사용이 불가능한 목적지가 하단 내비게이션에 존재할 수 있습니다. 그럴 때는 내비게이션 상에서 지우는 것이 아니라, 왜 사용이 불가능한지 알려주는 화면을 보여주고 내비게이션을 고정함으로써 각 목적지의 존재감을 명확히 할 수 있습니다.      

  



모바일 웹을 디자인하고 계신가요? 앱을 디자인하고 계신가요?


좋은 하단 내비게이션은 사용자를 이끄는 보이지 않는 손과 같습니다. 사용자가 가고 싶은 길을 쉽게 갈 수 있도록 안내하고, 더 나아가서는 사용자를 움직이게 만듭니다. 하단 내비게이션으로 사용자의 행동을 디자인해보는 것은 어떨까요?



출처 : Medium, GS real design


by 수달 발자국









Posted by slowalk

우리는 앱이나 서비스를 사용할 때 다양한 시각 요소들을 마주하게 됩니다. 화면을 스크롤하거나 버튼을 클릭하여 앱이나 서비스에게 원하는 바를 전달하죠.


예를 들어 캘린더에 일정을 추가한다면,




이런 일련의 행동은 사용자와 기계가 상호작용하는 과정입니다. 기계가 의도를 이해하기 쉽도록, 그리고 기계에게 의도를 전달하기 쉽도록 시각적으로 표현된 UI를 사용하는 것이죠.


하지만 기계가 우리의 언어를 이해하고 우리와 대화할 수 있다면 어떻게 될까요? 화면을 스크롤하거나 버튼을 클릭할 필요없이, 우리가 원하는 것을 앱이나 서비스에게 “이야기"하게 될 것입니다.


예를 들어 캘린더와 대화하며 일정을 추가한다면,





이렇게 대화를 통해 기계와 상호작용하는 것을 “대화형(Conversational) UI”, “대화형 인터페이스”라고 합니다.


애플 Siri처럼 음성을 기반으로 한 방식은 이미 많이 알려졌지만, 낮은 음성 인식률처럼 극복해야 할 근본적인 문제들이 있습니다. 실제로 대화하는 것 만큼은 아니지만, 문자 메시지나 메신저를 통해 텍스트로 대화하는 것도 우리에게 매우 익숙한 방식입니다. 


어느 것이 먼저인지는 확실하지 않지만, 메신저 사용에 익숙해진 사용자들은 메신저 안에서 콘텐츠를 소비하고 공유하고 있고, 메신저들도 메신저 안에서 콘텐츠를 소비하고 공유하도록 유도하기 위해 여러 장치들을 추가하고 있습니다. 카카오톡 샵(#)검색도 그런 장치들 중 하나입니다.


직접 비교하긴 어렵지만, 개발자들이 콘솔 환경에서 명령어를 입력하듯 대화형 UI에서 텍스트를 입력하여 명령을 내리는 것에 점차 익숙해지고 있는 것이죠.


이에 따라, 텍스트 기반의 대화형 UI를 채용한 사례도 많아지고 있습니다.



Meekan Scheduling Assistant





위에서 예로 든 것처럼 캘린더와 대화하듯 일정을 관리할 수 있는 도구입니다. 슬로워크는 사내 메신저로 슬랙을 사용 중인데(관련 글: 업무용 메신저 슬랙(Slack), 슬로워크는 이렇게 사용합니다.), 일부 팀에서 Meekan Scheduling Assistant을 슬랙과 연동하여 회의 일정을 관리하고 있습니다.


Meekan Scheduling Assistant을 사용하면, 같은 채널에 있는 사람들과 함께 대화하듯 일정을 추가할 수 있는데, 여러 명이 참여하는 회의 일정을 잡을 때 일정을 따로따로 확인하는 번거로움을 줄일 수 있습니다.



쿼츠(Quartz) 모바일 앱





뉴스 큐레이션 서비스인 쿼츠의 모바일 앱은 대화형 UI로 뉴스를 제공합니다.  짧은 단문으로 뉴스를 제공하고, 사용자가 반응하면 추가적인 정보를 제공하거나 또 다른 뉴스를 제공합니다. 설정을 위한 몇 가지 기능을 제외하면, 메시지가 오고가는 대화창이 전부입니다.


이 앱이 뉴스를 전달하는 모습은 마치 우리가 메신저에서 친구들과 뉴스를 공유하는 모습 같습니다. 움짤로 마무리하는 센스까지, 정말 누군가와 대화하는 듯한 느낌을 줍니다.



Uber on Facebook Messenger





페이스북은 메신저를 활용한 인공지능 기반의 가상 비서 서비스인 M을 테스트하기 시작한데 이어, 페이스북 메신저에서 우버를 직접 호출할 수 있는 서비스를 제공하기 시작했습니다. 페이스북 메신저에서 주소를 입력하고 우버를 호출하면, 메신저를 통해 호출 정보가 전송되고 결제까지 이루어집니다.



Talyor Bot





여행 정보를 제공하는 대화형 서비스입니다. 텔레그램의 API를 통해 사용자의 위치정보, 메시지 등을 활용하여 사용자에게 필요한 여행 정보를 제공합니다.



이 외에도 레스토랑 정보를 제공하는 Luka, 문자메시지로 온디맨드 서비스를 제공하는 Magic 등 다양한 분야에서 대화형 UI를 활용한 서비스들이 출시되고 있습니다.



국내에도 문자메시지, 카카오톡을 통해 온디맨드 서비스를 제공하는 서비스가 있습니다. 
문비서는 카카오톡과 문자메시지로, 킴비서는 카카오톡을 통해, 식당 예약, 꽃 배달, 세탁, 대리 운전 등 다양한 서비스를 요청할 수 있습니다.



문비서 홈페이지


킴비서 홈페이지


Product Hunt의 #ConvComm, Invisible Apps 콜렉션에서 대화형 UI를 활용한 다양한 서비스들을 확인할 수 있습니다.


대화형 UI가 새로운 패러다임이긴 하지만 모든 것을 대체할 수 있는 것은 아닙니다. 간단한 정보나 선택지를 제공하기엔 적합하지만, 무수히 많은 정보를 탐색하는 형태의 서비스로 제공하기에는 적합하지 않습니다. 대화형 UI를 적절하게 활용한다면, 개발자 입장에서는 앱의 형태까지 필요하지 않은 간단한 서비스들이 대화형 UI를 채용하여 더 적은 비용으로 제품을 출시할 수 있게 되고, 사용자 입장에서는 새로운 인터페이스를 학습할 필요없이 친숙한 인터페이스로 더 다양한 정보와 콘텐츠를 접할 수 있게 될 것입니다.



by 낙타 발자국



참고

2016년의 키워드는 대화형 커머스

새로운 UI로써의 No-UI

Conversational commerce

Futures of text



Posted by slowalk


올해 초 스티비팀에 합류하며 편집 디자이너에서 인터랙션 디자이너로 포지션을 변경하였습니다. 스티비에서 필요한 디자이너는 웹사이트를 프론트엔드 개발자의 도움 없이도 스스로 구현할 수 있는 역량과 함께 사업 전체를 함께 고민하는 전방위 디자이너입니다. 직무 변경을 1주일 앞두고 앞으로의 업무에 대해 두려움을 느끼고 있을 때, 스티비 팀원들이 추천해주신 책들이 많은 도움이 되었는데요. 그때 추천 받은 책 3권을 공유하려 합니다.





시미즈 료(지은이) | 조지은 | 에이콘출판 | 더 알아보기



1. 생활 교양 프로그래밍 입문

스티비 팀에 합류했을 당시, 저는 CSS와 RSS의 차이도 모르는 인쇄전문 편집 디자이너였습니다. 팀을 옮기며 첫 번째로 받은 직무는 HTML과 CSS를 배우는 것, 그후 이를 활용해 이메일 뉴스레터 템플릿을 만들어보는 것이었습니다. 이때 코딩, 프로그래밍에 대한 대략적인 감을 잡을 수 있게 도와준 책이 <생활 교양 프로그래밍 입문>입니다.


<생활 교양 프로그래밍 입문>은 영어와 수식어로 이루어진 코딩을 일상생활로 대치하여 보여줍니다. 그래서 우주의 심연과 같은 모니터를 바라보기 전에 지하철/버스 시간표, TV 방송 프로그램 등 우리의 일상 중 많은 부분도 프로그래밍 되어 있다는 사실을 알려주는 책입니다. 한 마디로 프로그래밍을 편안하게 받아들일 수 있게 도와주는 책입니다. (하지만 실제 코딩은 결코 만만하게 볼 것이 아니었습니다.. 코딩.. 어렵습니다.)  


책의 저자는 프로그래밍을 한마디로 표현하면, '자기 외부의 것들을 자신이 생각하는 대로 움직이게끔 하는 방법'이라 말합니다. 이를 기획에 적용해 본다면 기획자의 의도대로 사용자의 마음을 움직이려는 행위도 프로그래밍이며, 조직에 적용한다면 조직 전체를 리더의 의도대로 움직이려는 행위도 프로그래밍이라 할 수 있다고 합니다. 이처럼 프로그래밍과 일상생활을 연관 지어 편안한 마음으로 읽어볼 수 있는 코딩 입문 책으로 추천합니다.





리아 불리(지은이) | 옮긴이(옮긴이) | 비제이퍼블릭 | 더 알아보기



2. UX 팀 오브 원 - 홀로 UX를 책임지는 디자이너를 위한 레시피

UX의 필요성을 많은 곳에서 이야기하고 있습니다. 이를 구체적으로 실무에 적용하는 방법은 사람마다 다양하며, 막상 실무에 적용하려다 보면 어디서부터 시작해야 할지 몰라, 처음부터 어려움에 부딪히기도 합니다. 특히 스타트업이나 작은 팀 안에서 UX를 책임지는 디자이너라면 더욱이 이런 어려움을 느끼셨을 텐데요. 여러분이 의지할 곳 없이 홀로 UX 담당자로 방황할 때 조용히 나아갈 길을 알려줄 좋은 책을 소개합니다.


<UX 팀 오브 원>에는 UX 디자인에 대한 막연한 내용들 보다는 사용자 경험이 무엇인지 알려주는 이론부터 다른 팀원들에게 UX에 대한 "인식"을 심어주고 회사 내부에 UX의 필요성을 전파하기 위한 방법론까지 이를 활용하고 실제로 사용하기 위한 방법을 자세히 풀어 놓았습니다. 2부 실전편에는 UX 프로젝트의 작업 계획이나 사용자 리서치, 디자인, 사용성 테스트, 검증에 이르는 실무 방법론과 전체 프로세스 방법론에서 이끌어내야 할 메시지까지 상세하게 적혀있습니다.


책은 ‘단순히 사용자를 사랑하고 배려하는 것 만으로는 홀로 UX를 책임지는 디자이너로서 성공하기에 부족하다'고 말합니다. 그만큼 UX 디자이너가 고민해야 하는 부분은 단순히 디자인이나 사용자 분석에 그치지 않는데요. 고객을 위한다는 말만 할 뿐, 정작 고객이 원하는 것이 무엇인지 알지 못하는 회사나 조직에서 홀로 UX를 고민해야 하는 디자이너에게 추천하는 책입니다.




스매싱매거진(지은이) | 웹액츄얼리 북스팀, 김종광(옮긴이) | 웹액츄얼리코리아 | 더 알아보기



3. 스매싱북 2-시간이 지나도 변하지 않는 원리

웹 디자인을 전문적으로 다루는 스매싱메거진(Smashing magazine)에서 낸 온라인 심층기사 중 독자에게 꼭 전달하고 싶은 글만 모아 만든 책, 스매싱의 두 번째 편입니다. 위대한 그래픽디자인의 원칙에서 시작해 UX 디자인, 프로토타입의 유형과 방법에 대한 조언, 웹 개발에 대한 조언, 사용자 연구에 이르기까지 광범위한 이야기를 전합니다. 그 중 웹 개발의 주의 사항을 다룬 5장을 읽다 보면 선배 디자이너의 호통치는 목소리가 바로 옆에서 들리는 느낌이 들기도 합니다.


스매싱북 2는 ‘좋은 웹 디자인이란 현란한 코드를 나열하고, 멋진 타이포와 일러스트를 늘어놓는 것을 넘어서 사용자를 이해하고 탐구해 많은 사용자의 커뮤니케이션 수단으로 자리잡아야 한다’고 말하고 있습니다. 다양한 분야의 사람들과 협력하기 위해 어떤 관점을 가져야 하는지, 사용자를 위한 디자인이 대체 무엇인지, 현재의 웹 디자인이 바라보고 나아가고자 하는 지점이 어디인지 잘 알려주는 책이기에 시작하는 디자이너들이 읽으면 좋을 책으로 추천합니다.



by 사슴발자국

 

Posted by slowalk