SW개발 범주에 한정지어 생각할때 UX를 디자인한다는 것은 협의로는 UI시나리오를 작성한다는 의미이고, 광의로는 GUI, SW까지를 포함하여 플래쉬등을 포함하는 PC프로토타입, 시료에 프로토타입, 양산개발까지 Follow-up하는 것을 범위로 한다. 이 중 늘 그렇듯이 외부에서 보기에 가장 애매해보이고 복잡해하는 부분은 GUI이다.
GUI는 Graphic User inteface의 개념.. SW에서 보기엔 Text로 보여주었던 MS-DOS의 기준에서 볼때, 당연히 UI를 한다고 하는 사람은 GUI를 하는 사람처럼 보인다. 그도 그럴 것이 UI의 결과를 보여달라고 하면 GUI를 입혀서 최종적으로 보기 때문에, 더우기 의사결정권자들이 보기엔 UI만 추려서 보기엔 어려움이 있기 때문이다. 실제로 UI를 하는 사람도 Review를 하다보면 UI와 GUI를 애써 구분해서 하지 않으면 헤깔리기 일쑤이니, 일반인의 범주에 속하는 사람이 구분하기엔 역부족이다. 특히나 그 일반인중 권력을 가진 사람들의VOE는 강력한 파워를 가지게 되고, 한마디로 UI부서가 이에 직격탄을 받는다. UI가 일단 VOE를 받으면 GUI에 일부를 떼서 전달하는 방식... 이게 지금의 현실임에 분명하다.
UI가 정상적인 포지셔닝을 했다는 전제하에 GUI는 UI시나리오를 바탕으로한 결과물에 정확한 pixel by pixel 이미지, Font, Moving Animation, Transition효과, 아이콘 등의 개발결과물을 만드는 것을 의미한다. 결국 UI의 결과물은 GUI와 SW Coding, 개발과의 조화로운 결합에 의해서 꽃을 피운다. UI는 단지 설계도일뿐...
By Fernando Guillen http://www.flickr.com/photos/d2clon/4402993445/
비견하여 건축을 하는 사람은 설계를 하는 사람과 시공을 하는 사람으로 나뉜다. 전자는 Order를 따서 설계도를 전달하는 것이고, 이 설계도에 따라서 시공사가 필요한 재료를 가져다가 시공을 하는 구조다.
|
by 조선일보 http://free.newsbank.co.kr/photo/views/01241986081700062666 |
by 조선일보 http://free.newsbank.co.kr/photo/views/01242008030800062636 |
건축은 좀 큰 개념이니깐... 일상생활에서 자주 접하고 있는 지하철에서의 스크린 도어를 들여다 보도록 하자. 스크린 도어를 대비해서 UI를 비교하여 보면, 스크린도어의 설치위치와 스크린도어의 뼈대구조(Frame Structure), 좌우로 열리는 방식에 대한 설계도(기구설계)를 UI에서 그린다면 스크린도어의 재질 및 겉 그래픽 시트지 및 Background 도장, 내부 조명등설치등은 모두 GUI의 영역에 가깝다. 스크린도어의 구동을 위한 프로그래밍 및 구동로직의 실 구현은 SW라고 볼 수 있다. 물론 이를 위한 Micro Processor, 전기장치, 지지대, 벽면 등은 모두 HW라고 볼 수 있다.
만약 순전히 심미적인 목적을 위해서 순금도장된 문을 사용한 나머지 문이 빠른 속도로 열리지 않으면 GUI의 문제이며, 가벼운 도장으로 처리하였는데도 문이 빨리 열리고 닫히지 않으면 기계, HW, SW문제이고, 둘다의 문제가 없음에도 문의 크기를 잘못잡았거나, 문턱을 만들어 놓아 발이 걸리거나 높이가 너무 낮아서 머리가 부딛히면 UI상의 설계의 문제라고 볼 수 있다.
문제는 역사의 모든 스크린도어가 똑같아 보이지만 Type이 여러개가 있고 그 중에 하나를 기준으로 각 역마다 시공을 한다는 것이다. 곧 이 문은 조립식이고 맞춤식이라는 것이다. 또 이 조립하고 맞추는 일을 하기 위해서는 UI, SW, HW, GUI까지 모든 Engineer가 종합적으로 고민해서 솔루션을 결정해야 하는 것이 인지상정이다.
by 동아일보 http://free.newsbank.co.kr/photo/views/A0242007101200520444
만약 우연히 문이 고장이 나면 누구의 문제인지를 알아내기 위해서는 복합적인 문제이므로, 객관적으로 조사할 수 있는 조사팀이 들어가기 각 문제점에 대해서 진단을 하기 전까지는 문제의 핵심을 알기 힘들다는 것이다.
따라서 단순히 문이 잘 안열린다의 문제가 UI의 문제인지 GUI의 문제인지 SW의 문제인지를 모르고 문제여부를 판정하기는 어려울 뿐더러, 이의 판정을 위한 판정팀도 판정을 위한 기준도 없고 장치도 없다는 것이다. 게다가 실제 시공(구축)에 참여한 인원이 아니라면 문제가 외주개발인지 내부개발인지 알기가 어렵다.
문이 안열리는 문제를 단순히 외관(UI+GUI)상의 이슈로만 놓고 보면 디자인의 문제이고, 디자인은 UI와 GUI의 구분없이 그냥 디자인으로만 보이니 소위말해서 힘없는 부서가 욕먹기가 쉬운 것이 현재의 UI를 하는 사람의 고충이다.
그렇다면 UI와 GUI는 남들이 구분하기 어려우니 통합하는게 좋은가 아니면 다르다는 것을 일일히 설명하는 것이 좋은 가? 대 고객 즉 문제를 제기한 사람들의 입장에서 보면 하나의 창구에서 해결해주면 좋겠지만, 일을 하는 입장에서 보면 분명 이에 대한 Specialty가 다른 것이므로, 요구의 창구를 다르게 해야 한다. 이 경우 문제를 제기한 사람은 이 문제가 UI의 문제인지 GUI의 문제인지를 명확히 파악할 수 있는 변별능력을 갖고 있어야 하는데... 현실적으로 전문가가 아닌 이상 이는 어려운 문제이다.
웹의 경우는 기술적 표준화가 이미 되어 있는 상황이어서 기획을 위한 기술적 진입 장벽이 낮기 때문에 기획팀이 UI를 통합하여 UI에 대한 전문성이 낮다. ...반면 GUI는 Graphic 혹은 디자인 조직에 통합되어 GUI본연의 인터랙션 업무보다는 CI나 BI의 identity에 제약조건이 많고 static한 페이지 구성이 중요한 관점을 갖는다. 문제를 제기하는 쪽이 기획쪽이라면 해당 팀내에 전문가가 있으니 구분이 쉽고 업무 의뢰를 하기도 용이하다. 따라서 UI가 기획과 통합을 한다면 이것이 UI냐 GUI냐의 문제는 사라진다.
제품의 경우는 기술적 표준화의 수준이 달라서 기획자가 개발쪽을 모두 이해하기가 힘이 든다. 그렇기 때문에 개발을 이해하고 이를 Communication을 하기 위해서는 UI담당자가 이를 모두 이해하고 정리하고 개발가능하도록 여러가지 의견조율을 담당해야 한다. 기획자는 사업영역으로부터 이를 풀어가기에도 바쁘기 때문에 요건을 내리고 이에 대해서 정리를 하고 있다.
By Meanest Indian http://www.flickr.com/photos/56252733@N00/308613980/
인터랙션이 중요한 상품의 개발입장에서 보면, 둘의 구분은 이미가 없다. 앞의 스크린도어를 UI를 따로 GUI를 따로하면 스크린도어의 사이즈를 밀폐에 적합하게 딱 2m로 잡았음에도 GUI에서 painting을 두껍게 하는 바람에 문과 바닥사이의 유격을 5mm를 두었음에도 2mm는 페인트 두께, 3mm는 온도차에 의한 문의 늘어짐현상이 있다고 치면 문이 동작하지 못하고 고장이 날 수 있기 때문이다.
UX는 거시적 조절의 노력을 하는 부서가 아니라 미시적 조정, 최적화와 사용자 편의성에 적합하도록 최적의 치수와 위치를 잡아서 제안하는 역할을 한다. 그러기에 이러한 부서들이 따로 존재하는 경우 문제가 그런데 통합의 걸림돌은 UI는 외관만을 중요시하는 디자인중심 부서에 있는 경우 힘을 잃고, GUI는 디자인중심 부서가 아닌 기획중심 부서가 있는 경우 디자인의 힘을 잃게 되는 것 같다. 그렇다면 그 둘 중 어떤 것이 더 중요한가?
나의 생각으로는 기획중심부서쪽에 있어야 한다는 생각을 하지만 그렇다고 기획부서에 있어서는 안된다고 생각한다. 그렇게 따지면 결국 별도의 조직으로 UX센터가 있어야 하며 이 조직은 어떤 쪽의 영향력 하라기보다는 고객지향적 사고나 사용편의성 및 심미적 만족도에 근거하여 평가를 받는 곳에 있어야 한다고 생각한다. 즉 GUI를 UI가 안아야 하느냐는 결국 한부서안에 있어야 한다는 논리로 설명하고 싶고, 그렇지만 그 두 영역에 대한 독립성을 인정받기 위해서는 별도의 부서로 존재하는 것이 UX가 구매시점에서의 심미적 분야에만 초점을 맞추어 본래의 목적인 사용하는 동안에 과정에 노력을 충분히 하지 못하도록 부정적인 영향을 미치는 것을 막을 수 있어야 하기 때문이다.
2011/01/25
나쌤.