[UX] UI 담당자와 GUI 담당자의 역할과 업무 범위
UI 담당자와 GUI 담당자의 역할과 업무 범위를 실무적 관점에서 각자가 만들어 내는 산출물 단위와 어떤 의사결정을 누가 해야 되는지 위주로 설명했다. 이는 단순히 각자의 역할로 정의되는데 의미가 있기 보다 프로젝트 내에서 원활한 협업을 하는데 더 중요한 의미를 갖는다.
UI는 User Interface의 약자로써 앞서 UI와 UX를 구분하는 포스팅에서 그 개념을 간단히 설명한 바 있다. GUI는 Graphic User Interface의 약자로 말 그대로 시각화된 디자인을 포함하는 UI의 형태를 의미한다. 혹자들은 이게 무슨 말장난이냐고도 할 수 있을 것이다. 개념을 이렇게 주저리주저리 말로 설명을 하는 것보다는 하나의 예를 들어 설명하는 것이 더 낫겠다.
스크롤바(Scroll control)는 출력되는 페이지가 디스플레이에서 출력가능한 제한된 영역을 벗어나는 경우 벗어난 영역에 대하여 상하/좌우로 움직이게 하는 역할을 하는 interface이다. 이를 보통은 UI라고 칭하자. 여기에 좀더 시각적인 관점에서 오른쪽 그림과 같이 색상을 입힌다던지, 스크롤바의 너비를 조정한다던지, 모양을 달리 하는 등의 시각적 요소가 결합된 것을 GUI라고 할 수 있겠다.
단순히 사용자가 원하는 기능을 구현하는데는 사실 UI 컴포넌트만으로도 충분히 구현이 가능하다.(왼쪽 모양 같으면 어떻게 오른쪽 모양 같으면 어떠하겠는가? 어차피 본연의 기능인 제한된 영역을 벗어난 페이지를 이동하는데는 아무런 문제가 없으니 말이다.) 하지만 해당 기능을 사용하는 사용자가 어린이나 노인과 같은 특수한 계층이라던가 혹은 특정 국가에 국한된다고 가정해보자. 이 경우 단순히 UI 컴포넌트로만 기능을 구현한다면분명히 한계가 생기게 된다. GUI는 단순히 아름다운 것을 넘어서 UI 컴포넌트의 시인성 및 직관성, UI의 호감도 등을 높이는 역할을 담당하고 있다. (예: 중화권에서는 붉은 색상이 호감도를 높이는 색상으로 많이 사용됨.)
UI와 GUI를 설명하고 나니 그래서 뭐 어쩌란 말인가? 니가 진짜로 하고 싶은 이야기가 무엇이냐?에 대해서 궁금해 하는 사람들도 있을 것이다. 오늘 필자가 말하고자 하는 바는 'UI 담당자와 GUI 담당자가 구체적으로 어떤 일을 해야 되며, 어떤 산출물을 만들어 내고, 어떻게 서로의 업무권한을 침해하지 않으면서 협업을 잘 해나갈 수 있을지'를 규정하는 것에 있다.
이 주제 역시 현업에서 늘 경험하면서도 '도대체 UI와 GUI 담당자들의 역할과 그 역할의 경계가 어디까지일까?' 에 대한 고민없이 UI담당자(UI engineer/designer)와 GUI 담당자(GUI designer)사이에서 항상 갈등을 야기시키는 골칫거리 중 하나였다. UI 담당자는 GUI의 권한범위 내에서 의견을 내고, GUI 담당자는 UI 권한범위 내에서 의견을 내면서 얼마나 많은 마찰이 있어왔는가?
이 주제를 풀어나가기에 앞서 필자 나름의 경험을 바탕으로 UI 담당자와 GUI 담당자들이 하는 업무와 산출물, 그리고 그 업무들간의 관계와 세부 업무들에 대해서 정리를 해 보았다.
위의 그림에서 붉은색 화살표를 기준으로 왼쪽 영역은 UI 담당자의 업무와 산출물을 의미하며, 오른쪽 영역은 GUI 담당자의 업무와 산출물로 구분하였다. 참고로 필자는 UI 담당자로서 사실 GUI 담당자의 업무를 100% 이해를 못하고 있을 수 있음에 미리 양해를 구한다. (추가로 더 기술할 부분에 대한 의견이 있다면 허심탄회하게 의견을 남겨주기 바란다.)
그림을 이해하는데, 조금더 부연설명을 하자면 노란색 네모박스는 각 담당자들이 업무를 진행하는 과정에서 만들어 내는 산출물이다. 파란색 타원형 박스는 각 담당자들의 주요 업무를 의미하며, 하늘색 타원형 박스는 주요 업무와 연관된 하위 또는 상세 업무를 나타낸다. 또한 각 담당자들의 업무는 서로 연관이 있을 수 있는데, 이는 화살표로 나타내었다.
박스 하나하나에 들어가는 내용을 별도 주제로 다뤄도 될만큼 설명이 많이 필요하지만 앞서 이야기한 바와 같이 이번 포스팅의 주제가 'UI와 GUI 담당자들의 각각의 업무와 역할을 이해하는 것'에 있으므로, 이에 초점을 맞춰 설명을 제한하도록 하겠다.
UI담당자의 주된 역할은 설명하자면 사용자들이 수행할 과업을 분석하여 과업을 수행하기 위해 필요한 일련의 체계를 설계한다. 설계시, UI 컴포넌트들의 집합의 개념인 틀(Layout)을 구성하며, 각각의 UI 컴포넌트들을 어떻게 표현하는 것이 효과적인지(예: 적절한 UI 컴포넌트 선정), 사용자들이 어떻게 과업을 수행할지에 대한 Flow(예: 어떻게 네비게이션을 단순화 시킬 것인가)에 대한 고려를 하게 된다.
GUI담당자는 이를 시각적으로 사용자들에게 UI 컴포넌트를 얼마나 아름답고, 효과적으로 볼 수 있는지에 대한 것으로 시각화할 UI 컴포넌트에 대한 디자인을 고려하게 된다. 예를 들어, UI 컴포넌트를 사용자에 따라 얼마나 크게 디자인 할 것인가? 색상을 어떻게 구성하여 사용자들로부터 UI 컴포넌트의 시인성을 높일 것인가? UI 컴포넌트를 어떻게 디자인하여 직관성을 높일 것인가?(예: 적절한 메타포를 사용한 아이콘 디자인) 등에 대한 고려를 한다.
그럼 그림에 포함된 항목들을 하나씩 살펴보자.
-Scenario document는 보통 Wireframe document를 포함한다. 이 두 문서의 작성에 순서는 없지만 보통은 Wireframe document가 만들어지고 Scenario document가 작성이 되기도 하며, Scenario document가 작성되는 중간중간에도 필요한 항목이 세로 Wireframe document에 추가되기도 한다. 중요한 것은 Wireframe document와 Scenario document는 반드시 일치하도록 버전관리가 잘 되어야 한다.
-Define the font, font-size, colors, and so on 과 관련된 산출물은 전체적인 디자인 컨셉을 어필할 수 있는 페이지 시안 디자인을 요구받기도 한다. (일반적으로 디자이너가 아닌 사람들은 색상챠트만 보고, 혹은 폰트의 서체만 보고 그것을 이해하기 어렵기 때문이다.) 디자인된 페이지 시안은 반드시 이 단계에서 confirm이 되어야 한다. 이는 프로세스의 말미에 전체적인 디자인의 tone and manner를 변경하는 것만큼 비효율적이고, 쓸데없는 없는 작업은 없기 때문이다. (디자인을 잘 모르는 의사결정자들이 범하는 가장 흔한 문제들이 여기에 속한다.)
-Define Event/Action 단계에서는 각 Event와 Action에 따른 하위 Event와 Action들에 대한 정의를 요구하기도 하며, 각 동작에 따른 예외사항을 포함하기도 한다. (여기서의 Event와 Action은 프로그래밍에서 이야기하는 Event와 Action과 같은 개념으로 이해해야 한다.) 각각의 Event와 Action은 3D Effect와 같은 디자인을 요구하는 추세에 있다. 이전과는 달리 하드웨어 사양이 좋아짐에 따라 유려한 애니메이션 효과 등을 포함하는 것이 가능해졌는데, 이에 따라 GUI 업무 중에서도 Effect Design과 관련된 업무들이 더 중요해지고 있는 추세에 있다. Effect Design은 스마트폰을 통해서 쉽게 설명이 가능한데, 우리가 스마트폰이 등장하던 초창기 때를 생각해보면 현재 스마트폰들의 다양한 애니메이션 효과가 얼마나 발전했는지를 알 수 있을 것이다. 이러한 것들을 고려하는 것이 Effect Design 단계의 업무에 해당된다.
이 외에 예외 사항을 정의하는 과정에서는 각 기능을 개발하기 위해 개발자가 구현하는 수준의 예외처리를 시나리오 문서상에서 정의하지 말아야 하며, 이것을 UI 담당자의 역할로 부여해서도 안된다. UI 컴포넌트 자체의 동작과 관련된 예외사항을 기술하는 수준이면 충분하하며, 개발자 역시 개발문서에 이러한 예외처리에 대한 것을 별도로 규정하고 있어야 한다. 예를 들어, ID의 유효성을 체크하는 InputBox 컨트롤이 있다고 했을 때, 이 InputBox에서 받아들여질 수 있는 숫자를 정수형으로 할지 부동소수점 등으로 할지 등과 같은 기술적 예외사항은 시나리오 문서에서 기술될 내용이 아닌 것이다. 이는 개발문서(예: API 문서 또는 별도 매뉴얼 문서 등)에서 별도로 기술이 되어야 한다. 필자가 말하는 예외사항이란 ID의 유효성을 체크할 경우 팝업 메시지로 사용자에게 Alert를 줄지, 별도의 TextBox를 두어 잘못된 ID가 입력되었을 때, 이를 Hidden/Show를 하는 방식으로 할지 등에 대해서 기술하는 것을 의미한다.
-Wireframe document를 구성하는 과정에서 UI structure는 전체 페이지에서 사용할 UI 컴포넌트(Controls)와 동작 처리에 대한 기본적인 룰을 기술한다. 이를 UI syntax로 명명하여, UI 컴포넌트를 각 시나리오 단계에서 중복하여 기술하지 않도록 한다. 예를 들어, 스크롤 처리 등을 어떻게 할 것인지 등에 대해서 관련 시나리오가 필요할 때마다 반복적으로 기술하는 것은 시나리오 문서를 복잡하게 하고 분량이 불필요하게 많아지게 하는 주된 원인이 된다. 실제로 필자는 많은 실무 현장에서 시나리오 문서를 거의 해독해야 될 복잡한 문서로 여기는 개발자들과 기획자들을 많이 보아왔다. 이를 그들에게 매번 설명하고 이해시키는 것 또한 불필요한 커뮤니케이션 요소 중 하나였다. 우리의 본분은 설계된 UI를 통해 사용자에게 더 나은 UX를 제공하는 것임을 잊지 말아야겠다. 내부 유관부서 담당자들과 커뮤니케이션을 소홀히 하라는 것이 아니라, 더 많은 시간을 어떻하면 효율적이고, 효과적인 UX를 구현할지에 대해서 고민하라는 말이다. UI syntax 등이 정의된 UI structure는 다시 Graphic design된 형태의 완성된 틀로 구현될 수 있는데, 이를 GUI framework으로 규정한다. 이를 통해 매번 UI structure와 GUI 요소들을 재디자인하지 않고, 재사용성을 높여 나갈 수 있다.
-Define Functions은 원래대로라면 서비스나 제품을 기획하는 단계에서 이미 정의가 되어 있어야 한다. 하지만 실제로 UI 담당자들이 이를 구체화하는 단계에서 정의되는 경우가 많다. 여기서의 핵심은 기능이 구현되는 수준을 어느정도 UI 담당자가 정의할 수는 있겠으나 기능적 구현 범위에 대한 의사결정은 전적으로 기획자의 몫임을 미리 밝힌다. 이는 생산단가 및 기능에 대한 고객의 요구수준을 가장 잘 이해하고 있는 사람이 기획자이기 때문이다. 이를 게을리 하는 기획자에 의해 지금도 수많은 UI 담당자와 GUI 담당자들이 불필요한 작업을 반복하고 있는지를 생각해봐야 한다. 또한 실제로 현장에서는 기획자들이 이러한 의사결정을 제대로 못하여 UI 담당자와 개발자가 임의로 이를 구현하고, 기획자가 이를 confirm하고 또 재작업을 요구하는 이상한 일들이 수도 없이 벌어지고 있다. 기획자는 기능을 최대한 구체화하여 정의하고, 각 기능의 상한스펙과 하한스펙 등을 규정해야 한다. (제품개발방법론과 관련된 서적을 참고하면 이는 자세히 확인할 수 있다.)
-Understand/Design concepts of the function은 GUI 담당자들이 가장 싫어하는 부분 중 하나이다. 하지만 더 완벽한 UX를 사용자들에게 경험하게 하기 위해 상당히 중요하게 고려되어야 한다. 예를 들어, 볼륨을 올리고 내리게 하는 UI 컴포넌트가 있다고 생각해보자. 이를 +, -의 형태로 구현을 할지, UP/DOWN이라는 텍스트 형태로 구현을 할지, 혹은 또 다른 아이콘 형태로 구현을 할지는 전적으로 디자이너의 성향과 역량에 따라 달라질 수 있다. 그렇지만 해당 기능이 여러가지 형태로 toggle/mapping이 될 수 있다고 생각해보자. 예를 들어 때로는 해당 UI컴포넌트가 때에 따라서는 순서가 없는 세로리스트 형태의 아이템들 간 이동에도 사용이 된다면 +,-로 디자인을 하는 것이 낫겠는가? UP/DOWN 형태로 디자인을 하는 것이 낫겠는가? 기능이해도가 높은 디자이너의 경우 이를 UP/DOWN이라는 형태로 디자인을 할 것이라고 필자는 확신한다. 물론 디자이너들이 UI담당자가 개발자와 커뮤니케이션 하는데 필요한 모든 기능이나 동작에 대해서 이해를 할 필요는 없겠다. 하지만 최소한 그들이 디자인한 것이 때로는 사용자들에게 혼란을 줄 수 있다고 생각을 해본다면, 기능에 대한 이해는 디자이너가 갖추어야 할 기본 소양 중 하나라는 것에 공감할 수 있을 것이다.
마지막으로 정리를 하면서 가장 중요한 부분을 이야기 하고자 한다. 흔히 UI 담당자나 그외 담당자들은 페이지 색상이 어떻느니, 아이콘 이미지 등이 마음에 들지 않는다느니 하는 의견을 내고 이에 대한 수정을 강요하곤 한다. 해당 페이지 및 기타 요소를 디자인한 디자이너는 당신보다 색상이나 아이콘 이미지 등을 더 많이 고민하고 디자인한 사람인데도 말이다. 또한 GUI담당자나 개발자가 UI 담당자가 정의한 UI structure나컴포넌트 등을 함부로 변경하거나 바꾸기도 한다. 필자는 Wireframe 상에서 정의한 것과 달리 실제로 이를 디자인하고 개발하는 과정에서 수많은 제약사항이 발생하는 경우를 많이 보아왔다. 예를 들어 Wireframe에서 정의한 글자수가 지극히 많은데, 실제로 이를 적용한 폰트와 폰트사이즈에 따라 다 출력을 하기 어려운 경우가 있다. 또한 디자이너 관점에서의 답답한 Control 배치로 이를 변경하고 싶어하는 경우가 생길수도 있다. 혹은 개발자들은 복잡하게 구현하는 것을 피하기 위해서 임의로 레이아웃을 변경하는 경우도 비일비재하다. 그렇지만 해당 컴포넌트들이 사용자에게 어떠한 동작을 유도하고, 어떠한 시나리오가 적용되는지는 GUI 담당자나 개발자보다는 이를 정의한 UI 담당자가 더 많은 고민을 해왔을 것이다. 당신이 무심코 변경한 요소가 어떠한 복잡한 동작들과 얽혀 사용자에게 혼란을 주게 될지를 먼저 생각해보라. 그리고 그에 대한 고민은 UI 담당자와 더 긴밀히 이야기 해보면, 그들은 분명히 더 나은 해법을 가지고 있을 것이다. 또 그러라고 있는게 UI 담당자인 것이다.
"각자의 위치에서 주어진 본분과 주어진 전문성을 인정하라."는 것이필자가 경험을 통해 늘 이야기 하고 싶었던 것이다. 왜 각자의 이익에 따라서 UI 담당자와 GUI 담당자 서로 적대적인 상대가 되어야 하는가? 각각의 이익에 눈이 멀어 자신들의 고집들로 가득찬 결과물은 사용자들에게는 결코 환영받지 못한다는 것을 잊지 말아야 한다. 단순히 예쁘기만 하고, 제대로 이해할 수 없는 UI를 우리는 얼마나 많이 보아왔는가? 또한 기능적으로는 완벽하나 이를 이용하는 사용자를 배려하지 않은 UI를 또 우리는 얼마나 많이 보아왔는가? (노인들이 사용할 UI라면서 빽빽히 들어찬 글자와 보기에도 작은 글씨들을 모두 구현한 UI 담당자를 나는 결코 이해할 수 없었다.)
서로간 협업을 잘 하기 위해서는 서로를 잘 이해하는 것으로부터 출발해야 한다. 그 출발에 이 글이 조금이나마 도움이 되기를 바라며 이만 마친다.
댓글
댓글 쓰기