실제로 제품 개발에 관여하고 있는 엔지니어, UI디자이너, PM등과ㅓ 같이 현재 제품 개발 분야에서 일하고 있는 사람이 이 글을 읽는다면, 안타깝게도 사용하기 어려운 제품이 나오는 수많은 이야기 들과 핑계들이 매우 친숙하게 들릴 것이다.

 

사용하기 어려운 제품이나 시스템을 개발하게 되는 다섯 가지 이유

 

이유 1. 제품을 개발하는 동안, 제품의 최종 사용자보다, 보통 비용이 많이 들것 같은 시스템 자체를 더욱 중요시 한다.  무언가를 개발하는 과정에서  디자이너, 엔지니어, 프로그래머들은 일반적으로 인간과 상황에는 관심을 두지 않고 행위 요소에만 많은 강조를 해왔다.

 

이러한 불균형적인 접근 방식을 구적으로 살펴보면, 우선, 인간은 본질적으로 유연하게 대처하고 적응할 수 있기 때문에 기계가 인간에 적응하는 것보다는 인간이 기계에 적응하는 것이 더 쉽다는 가정이다. 두 번째로 개발자들은 오랫동안 인간이라는 분명치 않은 모호한 이슈보다는 시스템에 연관된 흑백의 과학적이고 구체적인 이슈에 대한 연구를 훨씬 편안하게 느끼고 있다. 세 번째로는 개발자들은 대인관계보다는 기술문제를 풀어나가는 능력에 때문에 고용되고 인정을 받아왔다. 마지막으로 최종 사용자의 요구를 무시하게 되는 가장 중요한 요인은 과거부터 디자이너들이 제품을 개발하는 동안 최종고객이 자신들과 흡사하다고 생각하기 때문에 단순히 친숙한 동료들을 연구할 이유는 없다고 생각하는 것이다. 두 번째 이유를 살펴보자.

 

이유2. 기술이 고객시장의 주류를 형성하는 동안, 고객의 주 타겟 층은 계속해서 변하고 극적으로 전환되어 왔다. 이에 반하여 개발회사는 이러한 진화에 서서히 반응하고 있다.

 

초기 시장의 컴퓨터 기반의 사용자들은 컴퓨터와 기계도구에 관한 지식이 뛰어나고, 기술을 사랑하며, 닥치는 대로 시도해보고, 어떠한 문제를 해결하는 자신의 능력에 자부심을 느끼는 해커 집단이었다. 제품 개발자들의 독특한 성격과 비슷한 점이 있다. 본질적으로 이 시기의 시스템 사용자와 개발자는 동일한 집단이나 마찬가지이다. 이러한 유사성 때문에 개발자들은 글자 그대로 개발 실험실에서 한 세대 앞서 있는 고객들을 고려하여 차세대 디자인만들어 왔다. 당연하게도 이러한 접근은 상대적인 성공을 가져왔으며 사용자들은 제품의 어려움에 대하여 거의 불평하지 않았다.

 

왜 불평하지 않았을까? 그들에게 있어서 제품을 사용하는 커다란 즐거움은 많이 만져보고 시간을 보내면서 제품을 작동하게 하며, 이러한 작동하기 어려운 제품을 작동하게 하는 자신의 능력에 대단한 자부심을 느끼는 해커 사용자들이기 때문이다. 결과적으로 기계 또는 시스템 지향의 접근방법에 거부감이 없어지고 제품 사용에 어려움을 호소하지 않은 것이다.

 

그러나, 오늘날에는 모든 것이 급진적으로 변화하였다. 전에는 기술전문가가 아니라면 전자공학이나 컴퓨터 기반의 도구들을 사용하는 것이 드문 일이었다면, 반면, 오늘날에는 평범한 사람들이 공적이거나, 사적인 공간에서 컴퓨터 기반의 제품을 사용하지 않는다는 것이 드문 일이 되었다. 업무 중이거나 혹은 집에서 쏟아지는 대다수의 제품들, 예를 들면 워드 프로세서, VCR, 혹은 지능적인 실험 도구들은 거의 기술전문가가 아닌 평범한 사람이 사용하고 있다. 오늘날의 고객들은 취미로 사용하는 제품이 아니라 도구를 원하고 있는 것이다.

 

오늘 날의 사용자들은 컴퓨터나 기계적인 장치에 관한 기술적 지식이 없는 경우가 많고, 방금 산 제품을 가지고 시간을 보내면서 참을성 있게 시도해보는 것을 싫어하는 등, 초기 시장의 사용자들과는 제품에 대해 기대 하는 것이 전혀 다르다. 더욱 중요한 것은 오늘날의 사용자는 더 이상 디자이너들과 기술, 성향, 기대하는 정도, 이외의 디자인 과정에 관련된 어떠한 속성과도 비교가 불가능할 정도로 다르다. 심지어는 고도의 기술을 보유한 엔지니어를 위한 복잡하고 분석적인 시스템을 제조하는 회사조차도 사용자들의 전문적 기술과 교육의 배경이 최근 3년에서 5년 사이에 눈에 띄게 줄어들었다고 말한다. 예전에 화학분야의 박사학위를 막 취득한 사람이 사용하였던 기능들을 오늘날에는 고등학교 졸업자가 사용하고 있는 것을 찾아볼 수 있다. 사용자와 디자이너 사이의 격차는 차세대 디자인이라는 전략을 명백히 무너트리고, 회사의 디자인 전략은 단순하고 사용 가능한 것으로 바뀌었다. 별다른 생각 없이 이전의 전략을 계속해서 이용하는 회사는 계속하여 사용하기 어려운 제품을 만들게 되는 것이다.

 

이유 3. 시스템을 사용하기 쉽게 만드는 것은 어렵고, 예측 불가능한 문제들을 계속적으로 풀어나가야 함에도 불구하고, 많은 회사들은 마치 그것이 단순한 상식만으로 해결되는 것처럼 여기고 있다.

 

시스템의 사용성과 사용성 공학에 대하여 많은 저술이 있지만, 많은 사람들 특히, 행동과학이나 사회과학에 전문지식이 없는 사람들에게 사용성의 개념은 매우 정의하기 힘들다. 예술에도 관련이 있고, 과학에도 관련이 있고, 마치 모든 사람들이 사용성과 사용성을 높이는 방법 대하여 한마디씩 하고 싶은 듯하지만, 사용성이라는 것은 무엇보다도 평가되기 전에 정의와 정확한 측정방법을 가지고 있어야만 한다.

 

이처럼 제품을 개발 시에 디자이너가 사용성 문제를 단순하게 바라보는 것은, 사용성을 높이는 것은 그들의 전문 분야가 아니라고 생각하고 다른 측면에만 관심을 갖는 것보다 훨씬 위험한 상황을 초래한다. 윌 로저스가 적절히 묘사하였듯이 우리가 모르고 있다는 것이 문제를 일으키는 것이 아니라 우리가 알고 있기 때문에 문제를 일어나지 않는 것이다.” 최근까지 많은 회사가 사용성문제는 마치 상식 이상의 어떤 것도 아닌 것처럼 생각하여 왔다. 그러나 만약 그것이 사실이라면, 어째서 사용하기 어려운 시스템과 제품이 이처럼 많은 것일까?

 

몇 년 전 행해졌던 연구조사에 따르면, 가우드와 루이스는 디자이너들이 시스템을 개발하는 데에 사용자 중심의 접근 방식에 대해서 잘못된 개념을 가지고 있고, 그 결과로 사용성 자체도 잘못된 개념을 가지게 되었다고 발표했다. 사용자를 위한 새로운 컴퓨터를 개발하고 평가하는데 어떤 단계가 필요하고 중요한지 질문을 하자, 참여자들 중 절반 이하의 사람들이 (447명의 컴퓨터 기반 시스템 디자이너) 사용하기 편리한 시스템을 디자인하기 위하여 요구되는 세 가지의 매우 기본적인 원칙(위에서 간단하게 언급하였던) 중 하나 이상을 언급할 수 있었다. 다시 말하여, 사용성에 관한 다양한 원칙들을 상식이라고 생각하는 반면, 실제 사용성에 관한 지식은 매우 부족함을 보여준다.

 

디자이너들은 사용성에 관한 최근의 강조에 영향을 받아, 과거보다 훨씬 더 사용자 중심의 원칙에 조화롭게 대처한 것처럼 보이지만, 그 동안의 나와 나의 동료들이 디자이너들과 작업한 경험으로 본다면, 가우디와 루이스의 1985년 연구결과는 현재에도 별로 변하지 않았다. 사용성에 관한 원칙은 아직도 불명확하고, 디자인 과정에 상식으로 다루어 지기 위해서는 상당한 교육, 지원, 그리고 회사적인 접근이 필요하다.

 

이유 4. 회사는 제품과 시스템 개발을 위하여 매우 전문화된 팀과 연구법을 고용하지만, 각각의 팀을 통합시키는 것은 여전히 실패하였다.

 

능률을 향상시키기 위하여, 회사는 각각 독립적으로 개발된 제품개발의 과정을 개별적인 시스템요소로 구분하여왔었다. 예를 들면, 소프트웨어 제품의 세 개의 요소는 사용자 인터패이스, 도움말 시스템, 그리고 매뉴얼이라고 볼 수 있다. 일반적으로 각 요소들은 개별적인 개인, 혹은 팀에 의해서 개발되어 왔다. 전문화 되었다는 측면에서는 나쁠 것이 없지만, 이처럼 개별적으로 개발된 요소들이 서로 조화롭게 통합되지 않고, 각 개발팀 사이의 커뮤니케이션이 어려워 질 때 문제가 생긴다.

각각의 개발 그룹은 독립적이라기 보다 거의 고립된 상태로 기능하고, 결과적을 이러한 접근법은 최종 제품에 반영된다. 도움말 시스템이 사용자 인터패이스를 충분히 보조할 수 없거나, 인터패이스를 매우 어렵게 접하게 작동시키게 될 것이다. 혹은 매뉴얼과 도움말은 상호 보완으로 사용하지 못하고 같은 내용으로 중복될 수도 있다. 매뉴얼에 사용자 인터패이스의 최신 버전이 반영되지 않을 수도 있다.

 

이러한 문제는 제품이 배포된 후에 일어게 된다. 최종고객은, 새로운 제품을 사용하면서, 그림 1.3에 보여지는 것처럼 하나의 통합된 제품으로 작동하기를 기대할 것이다. 사용자는 세 가지 요소들 사이에 특별한 구분을 하지 않는다. 그리고 하나의 요소가 다른 요소를 계속적으로 보조, 보완하며, 작동할 것이라고 믿고 있다. 제품이 하나로서 작동하지 않는 다는 것을 발견하는 순간 사용자의 기대는 무너지고, 전문화된 것으로부터 얻을 수 있었던 어떠한 장점도 필요 없게 된다.

 

더욱 흥미로운 점은, 사용성 부족의 문제가 팀간의 통합이 부족하여 일어나는 것이라는 점을 간과하고, 이를 해결하기 위해서 자주 각 요소들의 개별적인 사용성 테스트를 통하여 문제를 더욱 악화시키는 것이다. 매뉴얼은 인터패이스와 별개로 테스트하고, 인터패이스는 도움말시스템과 상관없이 테스트한다. 결과적으로 이러한 접근 방식은 무익하다. 만일 각각의 요소가 개별적으로 사용가능 하다면 거의 문제가 없지만, 세 가지 요소들이 함께 잘 작동할 때만이 사용자는 제품이 사용하기 편리하다고 느끼고 사용자의 요구에도 맞게 된다.

 

이유 5. 사용자 인터패이스의 디자인과 기술적인 실행은 다른 능력을 요구하는 행위이다. 많은 엔지니어들이 아직 사고방식과 기술방식을 기술적 실행에 두고 있는 반면, 오늘날 강조되고 필요로 하는 능력은 디자인적인 측면이다.

 

기술적 실행이 어떻게 작동하는가와 관계가 있다면, 디자인은 어떻게 제품과 의사소통 하는가와 관계가 있다. 이전에는 디자인과 실행의 차이점이 거의 알려지지 조차 않았다. 엔지니어들과 디자이너들은 디자인 전문성(예를 들면 의사소통과 인간중심의 분석) 보다, 기술적인 전문성(예를 들면 프로그래밍과 기계중심의 분석)이 요구되어왔다. 이것은 초기 컴퓨터 언어 세대가 단순히 제품을 작동하게 하는 것 만으로도 대단한 도전이 되었기 때문에 가능하였다. 만약에 당시에 작동뿐 아니라 우아한 의사소통까지 겸비하였다면 훨씬 좋았겠지만 당시의 가장 중요한 지령은 작동이었다.

 

지금은 객체 중심 프로그래밍 언어와 프로그램 코드를 자동적으로 발전시키는 소프트웨어의 출현으로 기술적인 실행이 한층 쉬어졌다. 그러나 상대적으로, 디자인에 대한 도전은 더 널리 퍼지고, 그에 대한 요구는 비지식인 사용계층에 도달하고, 그리고 고객들의 쉽게 사용할 수 있는 제품에 대한 기대가 급진적으로 증가하고 있다. 이러한 상황을 컴퓨터에 비유하자면, 주 관심사는 어떻게 작동하는가의 문제인 컴퓨터의 내부에서 어떻게 전달하는가에 중점을 둔 사용자가 속한 컴퓨터의 외부로 이동되었다[58].

 

이러한 시점의 변화는 디자이너에게 요구되는 기술을 바꾸어 놓았다. 그러나 많은 회사들은 여전히 디자이너의 인간과 관련된능력이 비하여 기계와 관련된 기술적인 실행 능력에 더 많은 가치를 두고 있다. 앞으로는 기술적인 실행보다 디자인 능력을 중요시하는 이러한 진화는 계속될 것이다. 프로그래밍과 같은 기술은 사용자 인터패이스가 디자인되는 동안에는 전혀 고려하지 않게 될 것이다.

 

이러한 다섯 가지의 이유들이 왜 사용하기 힘든 제품과 시스템을 일반적으로 많이 볼 수 있고 계속해서 만들어지고 있는지를 표면적으로 설명하고 있다. 그리고 나는 이러한 이유들을 비난하고자 하는 것이 아니다. 중요한 것은 이러한 문제와 착오가 일반적이라는 것이다; , 너무 지나치게 제품 자체만을 강조해왔다 그리고, 제품이 지녀야 할 필요가 있고 당연히 요구되는 결과는 거의 관심을 갖지 않았다. 이런 이유로 매년 짧아지며 점점 열정적으로 발전되어왔던 개발과정에서도, 계속해서 사용자가 고려되고 존중되지 않는다는 것에 놀라지 않을 수 있을 것이다.

 

디자이너들은 본질적으로 제품을 디자인한다기 보다, 제품과 인간의 관계를 디자인 하고 있다는 사실을 쉽게 잊는다. 더욱이 제품과 인간의 관계를 디자인하는 데에, 디자이너들은 반드시 인간을 과업을 하는 도구로서가 아니라 과업을 행하는 중심에 두어야만 한다. 디자이너들은 또한 유저인터패이스, 매뉴얼 그리고 도움말 시스템처럼 서로 다른 요소들 간의 소통을 원활히 하는, 다양한 제품 요소들 간의 관계를 디자인 하고 있다. 과거에 자연스러웠던 것들이 단순히 오늘날의 사용자와 테크놀러지에 적용해서는 안된다.

 

디자이너들에게는 제품에 대한 시각과 디자인하는 방법을 바꿀 수 있도록 돕는 방법과 기술이 필요하다 - 외부에서 내부로, 최종 사용자로부터의 요구와 능력으로부터 최종적인 제품이 실행으로 바꿔줄 수 있는 방법. 사용자 중심의 디자인(UCD)는 가장 최근에 이름 붙여진 접근법이다. 사용성테스트가 UCD의 틀에서 발전하였으므로 사용자 중심의 디자인을 좀더 자세히 알아보자.

 

사용자 중심의 디자인

 

정의

사용자 중심의 디자인(UCD)는 수년 동안 인간공학(human factors engineering, ergonomics), 최근에는 사용성공학(usability engineering)과 같은 다양한 이름들로 불려왔던 접근법을 설명하기 위해 만들어진 최근의 용어이다. (용어 human factors engineering ergonomics는 거의 상호 교환이 가능하다, 둘간의 가장 주된 차이점은 접근법과 실행의 차이점이라기보다는 지역적인 차이점이다. 미국에서는 human factors engineering 이 더 광범하게 사용되고 있고, 다른 나라 특히 유럽에서는 ergonomics가 더 광범하게 사용된다. 사실은 human factors society도 이러한 이유로 몇 년 전에 이름을 the human factors and ergonomic society로 바꾸었다.) UCD는 편리한 제품과 시스템을 디자인하기 위한 기술, 과정, 방법, 그리고 절차만을 이야기 하는 것이 아니라, 그와 똑 같은 중요한 관점으로 사용자가 과정의 중심에 놓여야 한다는 철학을 말하는 것이다.

 

UCD를 정의 한 것 중, 가장 설득력 있고, 간결하고, 명확한 것은 우드슨[152]의 정의로 다음과 같이 설명하였다. “…사용자가 원하는 것을 사용하고, 작동하고, 서비스를 받으며, 기타 보조적 과업을 실행하는 데에 최소한의 스트레스로 최대한의 효과를 얻을 수 있도록 제품을 디자인 하는 것이다.”이것이 UCD의 본질이다. 우드슨은  다음과 같이 덧붙였다. 면밀히 말하자면, 이것은 인간 외적인 것으로부터 디자인하는 것을 포함하며, 디자이너들이 사용자를 디자인에 맞도록 하지 않고, 반드시 디자인이 사용자에게 맞도록 하는 것이다. 우드슨의 정의는 단지 고객이 처음 제품 사용법 배우는 초기 학습 시기 뿐 아니라 사용자가 이 후에도 제품과 시스템을 실행하기 위해 행하는 모든 작용을 포함하고 있다.

 

그러나, 우드슨의 정의도 사용자가 제품의 소유주로 행동하는 전체적인 시기를 보는 것이 아니라 제품을 디자인하는 과정에만 국한되어 있다는 한계가 있다. 이상적으로는 사용자가 다른 제품을 사거나 현재의 것을 업그레이드하는 시점을 통해서, 초기 판매와 마케팅 계약으로부터 잠재가능성이 있는 고객과 소유권을 지닌 고객의 전체 기간을 통틀어 상호 교환하는 총체적 과정이 사용자 중심의 접근법에 포함되어야만 한다. 이러한 시나리오에서 회사는 선 구매자와 후 구매자의 계약과 상호작용을 포함하기 위해 사용자에 대한 관심을 넓힌다. 이상적으로는 이와 같지만, 한번에 한 단계씩 나아가기 위하여 디자인 과정에 중점을 두고 보자.

 

사용자 중심 디자인의 세가지 원칙.

 

이미 사용자 중심의 디자인(UCD)을 주제로 쓴 수많은 기사와 책이 있으며, 이 책이 이 분야를 다시 정립하고기 위해 쓰여진 것도 아니다. 그러나 독자들에게 사용성실험에 대한 이해를 돕기 위하여 UCD의 기본 원리를 이해하도록 하는 것은 중요하다. 사용성 실험이 UCD 자체는 아니다; 사용성 테스트란 단지 사용자 중심의 디자인을 확실히 하도록 돕기 위한 몇 가지 테크닉 중의 하나이다. 가우드와 루이스[49]는 인간중심의 시스템 디자인 작업에 UCD의 세가지 원리를 정하였다. 이 세가지 원리들은 다음과 같다:

 

1.    초반부터 사용자와 과업을 강조할 것. 이것은 단지 사용자를 정의하고 분류해 두는 것 이상의 작업이다. 가우드와 루이스는 개발 라이프사이클 동안 사용자와 디자인 팀간의 직접적인 접촉을 주장한다. 그러나 만약 회사화 되어있지 않다면 직접적인 접촉 자체가 문제를 일으킬 수 있다는 것을 간과하지 말아라. 디자이너들은 때때로 대인관계를 다루는 기술이 부족하기 때문에, 작전계획이 전혀 없이 사용자와 접촉하게 되면 디자이너의 선입견을 더욱 기정 사실화시키거나 또는 그들과 동료들의 인터뷰를 통해 회사적으로 정리되지 않은 다량의 문서 이상의 어떤 것도 얻을 수 없게 된다. 나의 보았던 중 가장 나쁜 기억으로, 엔지니어 팀 전체가 고객과의 접촉을 위해서 대륙을 횡단한 여행을 하고, 결국은 일만 가지의 대립된 증명자료와 정리되지 않은 보고서를 잔뜩 쌓아 두었다가 한쪽으로 치워놓는 것을 본 적이 있다. 불행하게도 이 다양한 정보와 엄청난 노력은 전혀 유용하게 사용되지 않았다.

 

고객과의 직접적인 접촉 더 나쁜 영향을 주는 경우는, 디자이너들이 단지 실행 평가 폼에 체크오프 박스를 완성시키기 위해 고객방문을 요구하고, 많은 회사에서 사용자들과의 접촉을 제도화하는 것이다.

 

이 첫 번째 원리의 중요한 점은 사용자로부터 그들에 대한 정보를 모으는 회사적이고 체계화된 접근법이다. 디자이너들은 자료 모집 회의 이전에 인터뷰 전문가들에게서 교육을 받을 필요가 있다. 전문적인 교육 없이는, 매우 잘못된 결과를 얻게 될 수 있다.

 

2.    제품 사용에 대한 경험을 측정할 것. 디자인과정의 초기부터 제품이 얼마나 배우기 쉽고 사용하기 쉬운가에 관하여 프로토타입 테스트를 통해 실제 사용자의 행위를 측정하여 얻는 것이 중요하다.

 

3.    제품을 디자인, 수정, 실험하는 과정을 반복할 것. 반복적인 디자인의 중요성은 많이 주장되어 왔다. 그러나 개발주기의 후반부에 하는 것은 좋은 조율이 아니다. 가우디와 루이스가 주장하듯이 진정으로 디자인을 반복시키기 위하여서는, 의식적 모델과 디자인 아이디어를 만드는 초기 실험에서부터 철저히 조사하고 재고하여야 한다. 만약 디자이너들이 이러한 중요한 단계를 제대로 준비하지 못한다면, 반복적인 디자인은 최소화되고 표면적인 영향력만을 발휘할 것이다. 본질적으로 디자인을 반복한다는 것은 디자인, 실험, 재 디자인, 그리고 재 실험의 과정을 통하여 제품을 만들어 나가는 것을 말한다.

 

UCD 실시하는 회사의 속성

 

사용자 중심의 디자인은 제품과 시스템의 개발에 관련하여 현재 진화하고 있는 철학이며 접근법의 하나이다. 디자인 팀과 개발회사 전반에 사용자 중심의 디자인을 포함 시키는 것을 탐색하는 것은 가치가 있다. UCD를 위해서는 회사가 사업을 하고, 제품을 개발하고, 그리고 고객을 생각하는 방법에 대한 재고가 필요하다. 아직까지는 성공하였다고 할 수 있는 판에 박은 방식이 존재하지는 않았지만, 회사가 UCD의 역할을 실행하는데 일반적으로 필요하다고 인정되는 속성들이 있다. 예를 들면 다음과 같다

 

결정이 필요한 모든 시점에 사용자의 입력과 피드백을 포함시킨 단계적 접근을 통한 개발.

 

전통적인 개발 방법에서 사용된 전형적인 단계와 달리, 사용자 중심의 접근법은 각 단계에서 다음의 단계로 넘어가기 전에 사용자의 피드백을 받거나 입력을 받는 것을 기본으로 하고 있다. 이것은 다양한 기술과 (다양한 기술 중의 하나인) 사용성테스트를 수반할 수 있다.

 

최근 컴퓨터 기반의 제품이나 시스템을 개발하는 대부분의 주요 회사는 어떤 형태이든지 사용성 공학을 포함하는 제품 라이프 사이클에 포함 시키고 있다. 약간의 다양성은 있지만, 거의 모든 제품의 라이프 사이클이 그림1.5의 단순화된 라이프 사이클에서 보여주는 과정과 단계를 포함 하게 될 것이다.

 

각 단계에 다양한 사용성 공학 활동이 있을 것이다. 그림 1.6는 어떤 한 회사에서 각각의 단계에서 필요에 의해 발생하는 사용성 공학 활동을 정의하고자하는 것을 나타내고 있다. 이 특정한 라이프 사이클은 human factors 전문가의 행위의 시점으로 적혀있음에도 불구하고, 다양한 팀 멤버들 간에 협동이 요구되는 많은 부분이 있는 것에 주목하여라. 이것은 다음에 서술할 UCD 실행하는 회사의 또 다른 속성을 보여는 것이다.

 

디자인은 더 이상 한 사람 혹은 하나의 전문분야로 풀어나가기에는 부족하다. 한명의 디자이너가 제품디자인에 관한 최후의 책임감을 지닐 수는 있지만, 그가 진행되는 방법에 관한 모든 것을 아는 것은 불가능하다. 매우 복잡한 제품을 기술에 대하여 잘 알지 못하는 최종 고객을 위해서 디자인할 때에는 고려해야 할 요인들이 너무나 많다. 사용자 중심의 디자인은 다양한 기술, 지식, 그리고 가장 중요한 사용자의 의도와 사용 습관에 대한 정보가 요구된다. 최근에는 공학, 마케팅, 트레이닝, 유저인터패이스 디자인, 인간공학, 그리고 멀티미디어와 같은 다양한 분야의 전문가들로 팀을 구성하는 것이 더욱 일반적이다.

 

UCD는 시간이 지남에 따라 마지막 제품이 만들어질 때까지 진화하는 과정이다. 디자이너들은 최상의 디자인은 계속된 시도와 실책, 발견과 개선의 과정을 통해서 획득되는 것이라는 자세를 갖춰야 한다. 어떻게 진행하는가에 관한 가설은 가설을 남기므로, 최종 사용자에 의한 평가 이전에 확실한 답이 있을 수는 없다. 최종사용자가 실행하고 선호하는 것만이 디자인을 결정하기 위한 최종 중재인이 된다.

 

사용성의 목적과 목표

 

사용성 디자인은 반드시 체계적이고 회사적이어야 한다. 추상적인 수준의 목적으로 시작하여 구체적인 목적으로 옮겨진다. 만약에 목적이 불투명하고 확신이 없다면 어떤 것도(그 목적이 사용성이던 다른 어떤 것이던) 성취할 수는 없다. 사용성이라는 용어부터도 정의되어야만 한다. 비록 사용성에 대한 정의가 대다수의 전문가들이 수용할 만큼 널리 사용되고 있는 것은 없지만, 현재 일반적으로 받아들여 지고 있는 사용성의 정의는 대부분 부트[15]가 개설한 다음의 4가지 요소들 중 하나 또는 몇 가지를 포함하고 있다.

 

1.       실용성. 실용성은 사용자가 어떠한 목적을 이루기 위하여 제품이 어느 정도 도움을 줄 수 있는가와 관련이 있고, 사용자가 제품을 끝까지 사용하도록 동기를 부여하는 정도를 평가한 것이다. 제품이 단지 선반 위에 올려져 있는 것이고 사용에 대한 아무런 동기 부여도 없다면, 다른 어떤 측정도 불가능하다. 만약 어떤 시스템이 사용하기 쉽고, 배우기 쉽고, 사용할 때 만족감을 주더라도, 특정 사용자가 그 시스템을 사용하여 특정 목적을 이루는 데에 아무런 도움이 되지 않는다면, 사용자는 그 시스템을 공짜로 거저 얻더라도 사용하지 않을 것이다. 흥미로운 것은 실용성이 연구와 실험에서 자주 간과된다는 것이다.

 

제품개발의 초기 단계에서 사용성에 관련된 요소가 고려되기 전에 제품과 시스템의 어떤 요소가 매력적이고 필요한 것인지를 확실히 하는 것은 마케팅 팀의 역할이다. 이 것이 부족하면 개발팀은 사용자의 관점을 파악하는데 어려움을 느끼고, 단순히 추측하거나 혹은 더 나쁜 방법으로 디자이너 자신을 사용자 모델로 사용하게 된다. 이러한 이유로 자주 기계 중심적인 디자인을 하게 되는 것이다.

 

2.       편이성(사용하기 쉬움). 두 번째 요소인 효율성은 보통 실행속도나 에러율에 의해서 정량적으로 평가되며, 전체 사용자의 일정한 백분율로 나타낸다. 다음은 이러한 측정의 예이다. 모든 사용자의 97%는 첫 시도에서 10분 이내에 소프트웨어를 사용할 준비를 끝낼 수 있다.”

3.       학습성. 학습성은 정해진 양을 어느 정도의 교육기간 후에 정의된 단계의 시스템을 작동시킬 수 있는 사용자의 능력을 말한다. 또한, 제품을 자주 사용하지 않는 사용자가 일정기간 후에 다시 시스템을 배우는 능력을 포함한다.

4.       태도(호감을 갖는 정도). 태도는 주로 구문이나 글을 통해 사용자에게 제품에 대한 이해, 느낌 그리고 의견에 대한 질문을 하여서 얻을 수 있다. 사용자는 필요에 따라 사용하고 만족을 얻은 제품을 그렇지 않은 제품보다 잘 작동시키는 경향이 있다. 일반적으로 사용자들이 테스트한 제품의 등급을 매기고 채점하도록 부탁하고, 얻어진 자료에 의해 발생하는 문제의 원인과 이유를 찾을 수 있다.  

 

사용성 목표와 목적은 전형적으로 이 네 가지 요소 중 하나 이상의 측정이 가능한 용어로 정의된다. 그러나 사용성이라는 것이 결코 간단히 사용한 정도나 만족에 관련된 수치를 만들어내는 것이 아님을 알아야 한다. 얻어진 수치로 제품이 작동하거나 그렇지 않다는 것은 알 수 있지만, 사용성을 높이기 위한 질적인 요소는 수치로 알아내기 매우 어렵다. 사용성에 관련된 문제를 어떻게 해결하여야 하는지 답을 얻고, 교육 받지 않은 시각으로 미묘한 잘못을 저지르는 것을 피하기 위해서는, 얻어진 데이터를 분석해 내는 능력이 중요하다. 환자의 혈압이나 맥박과 같은 중요한 증상은 누구나 측정할 수 있지만, 그러한 수치를 어떻게 해석하고 환자가 해야 할 일들을 진단하는 가에 따라서 의사의 참된 능력이 인정되는 것과 같다.

 

이제 사용성 전문가가 사용자 중심의 디자인을 확실히 하기 위하여 사용하는 몇 가지의 주요 테크닉과 방법들을 살펴보겠다.

 

UCD: UCD 기술과 적용방법에 대한 간략한 설명

 

UCD는 제품 개발 라이프 사이클의 다른 여러시점에 적용되는 다양한 기술과 방법으로 구성된다. 앞으로 설명할 주된 방법들을 검토하면서 그 중의 하나인 사용성 테스트를 이해하는데 도움이 되기를 바란다. 다음에 서술한 순서는 개발 라이프 사이클에 사용되는 순서와는 상관이 없다.

 

사용자 참여 디자인 PARTICIPATORY DESIGN[49]

적은 기술로 UCD를 구체화 하기 위한 사용자 참여 디자인은 디자인 팀 자체에 한 명 이상의 사용자 대표를 참여시킨다. 일반적으로 사내 시스템 개발에 사용되는 이 방법은 최종 사용자의 디자인에 관련된 지식, 기술, 심지어 감정적인 반응까지 자세히 듣고 프로젝트의 가장 처음부터 사용자를 디자인의 중심에 두는 것이다.

 

전문가 그룹 인터뷰 Focus group interview

전문가 그룹 인터뷰는 전형적으로 프로젝트의 초반에 사용자 대표에게 제품의 초기 컨셉을 평가하도록 하는 것이다. 어떤 경우에는 사용자 대표를 통하여 사용자 전체의 특성을 증명하고 확인하기 위하여 사용하기도 한다. 전문가 그룹 인터뷰가 다른 기술[51]과 구별되는 요인는 모든 전문가 그룹 연구는 한 명 이상의 참여자를 동시에 참여시킨다는 것이다.

 

참여자가 평가한다는 개념은 종이 설계도, 스토리 보드, 혹은 더 정교한 스크린 기반의 프로토타입, 플라스틱 모델과 같이 준비단계의 형식에서 제공될 수 있다. 전문가 그룹 인터뷰의 목적은 제품의 컨셉이 얼마나 수용가능 한지, 만약 수용 불가능하거나 만족하지 못하는 경우, 어떻게 하여야 수용 가능할 수 있도록 만드는 것인지를 알아보는 것이다. 전문가 그룹 인터뷰의 장점은 소수 사용자의 판단과 감정을 깊이 있게 탐색하고, 사용자가 어떻게 생각하고 느끼는지를 배우게 되는 데에 있다. 

 

설문 Survey

설문은 이미 존재하거나 앞으로 만들어질 제품에 관한 사용자 선호도를 넓은 기반에서 이해하기 위하여 사용된다. 설문이 전문가 집단 인터뷰에 반하여 깊이 있는 자료와 이론적 해석을 얻을 없는 반면, 전체 사용자 집단을 일반화 하는 대규모의 샘플로 사용할 수 있다. 예를 들어 현재 진행 중인 유명한 설문인 닐슨(Nielsen)의 설문은 1500명 이하의 설문 조사에 기초하여 국가적 규모의 억만 달러 비즈니스를 결정하는 데에 사용한다. 설문은 제품 라이프 사이클의 어느 시점이라도 사용 할 수 있지만, 잠정적 사용자를 잘 이해하기 위해서는 초기 단계에 주로 이용하는 것이 바람직하다. 설문에서 중요하게 고려될 사항은, 설문 문항에 사용된 언어가 확실하고 여러 번 반복하고 충분히 준비하여서 모든 설문자에게 동일한 의미로 이해되어야 한다는 것이다.

 

Walk-throughts 또는 구조적 walk-throughts

Walk-through는 제품의 초기 컨셉이나 프로토타입을 통하여 사용자가 어떻게 제품을 사용해 나갈 것인지를 알아보기 위하여 사용된다. 일반적으로 디자이너가 동료에게 실제 과업을 안내하는 동안 팀의 다른 구성원은 직면한 어려움이나 팀이 고려할 사항을 적는다. IBM에서 코드를 검토하기 위하여 만들어진 회사화된 walk-through는 효율성을 확실히 하기 위하여 참여자들에게 구체적인 역할(중재자, 기록자 등)을 가정하고 (두 시간 이상의 walk-through는 하지 않는다와 같은)뚜렷한 가이드라인을 따른다.

 

페이퍼 프로토타이핑       Paper and Pencil evaluations

사용자들에게 종이에 적힌 제품의 여러 요소들을 보여주고 질문에 대한 답을 얻거나, 혹은 다른 반응을 요구한다. 질문은 구조나 레이아웃과 같은 특정한 속성부터 특정한 추가 사항이나 정보의 유형까지 가능하다. 그림 1.8에서 보는 바와 같이, 사용자가 12가지의 과업을 실행하는 동안 워드프로세스의 풀다운 메뉴를 확인하는 질문을 하게 된다. 수집된 자료는 표로 만들어 지고 메뉴구조의 직관성과 부족함을 보여주게 된다.

 

  

종이와 연필 기반 평가는 비판적인 정보를 빠르고 저렴하게 수집할 수 있다. 그림 1.8을 보면 코드의 한 줄을 기입하기도 전에 직관적인 메뉴의 이름과 구조, 그리고 그렇지 않은 메뉴와 구조를 빠르게 확인 할 수 있을 것이다. 또한, 기술작가들은 본문의 한 단어를 쓰기 전에 목차의 직관성을 실행하기 위해서 사용할 수도 있다. 이 기법은 최소한의 자원을 사용하여 반복적으로 사용 할 수 있다.

 

전문가 평가

전문가 평가는 프로젝트에 전혀 (혹은 거의) 관계가 없는 사용성 전문가, 혹은 인간공학 전문가가 제품이나 시스템을 평가하는 것을 말한다. 전문가들은 제품을 사용할 타겟 집단의 관점을 유지하면서 사용성 공학 관련 연구결과나 참고문헌등에서 얻은 사용성 원리에 따라 평가하게 된다.

 

최근의 연구[95]는 제품에 사용되는 특정 기술에 대해서도 잘 알고 있는 사용성 전문가의 경우, 특정 기술에 대한 지식이 없는 전문가에 비하여 효과적이라고 지적하고 있다.

 

사용성 심사 USABILITY AUDIT

이러한 형태의 심사는 체크리스트 혹은 표준과 제품이나 시스템을 비교하여 평가한다. 표준은 연구 전문, 저서, 혹은 이전에 제품을 성공적으로 생산하였던 회사에서 발행한 사용성 척도를 참고하여 만들게 된다. 표준은 사용자 인터패이스, 조절판, 또는 매뉴얼과 같은 다양한 제품 요소들과 관계가 있다.

 

사용성 테스트

이 책의 중심인 사용성 테스트는 대표적인 과업을 실행하기 위해 제품을 사용하는 최종 사용자 대표를 관찰하면서 경험 데이터를 수집한다. 테스트는 대략 크게 두 가지의 접근법으로 나눌 수 있다. 첫 번째 접근법은 특정한 가정을 확인 혹은 반박하기 위한 실험으로 공식적인 테스트이다. 두 번째 접근법은 비공식적인 테스트로 주기적으로 반복하여 사용성이 부족함을 노출시키고 질문을 통해 제품을 점차적으로 완성시키는 것이다
 

필드 스터디 FIELD STUDIES

필드 스터디는 제품이 배포되기 직전에 사무실, 집 또는 어떤 곳이든 실제의 환경에 제품을 배치시키고 평가하는 것이다. 주로 친절한 고객에게 제품 평가를 부탁하고 평가에 대한 보상을 제공한다. 사용 패턴이나 사용자의 태도와 같은 자료가 수집되고 결과는 배포 이전에 제품을 좀 더 세련되게 만들기 위하여 사용된다. 보통 개발 라이프 사이클의 후반부에 수행되고, 따라서 얻어진 데이터가 향후 제품을 배포하는데 매우 가치 있는 것이라 할지라도 제품 디자인에 큰 변화를 주는 경우는 매우 드물다. 필드 스터디의 이점은 실제 제품이 작동하는 조건에서 평가를 수행한다는 것에 있다. 단점은 데이터 수집시 이에 대한 통제를 하기가 어렵다는 데 있다. 필드스터디와 같은 형태의 연구는 특정한 틀이 없는 듯 진행이 되며, “이 제품을 사용한후 생각하는 것을 알려주십시오하는 식의 질문을 통해 데이터에 미치는 영향을 최소화 한다.

 

FOLLOW-UP 스터디

Follow-up 스터디는 제품의 정식 배포 이후에 진행되는 것으로 방법은 필드 스터디와 흡사하다. 설문, 인터뷰 그리고 관찰을 통해 다음 배포를 위한 자료를 모으는 것이다. Follow-up 스터디는 실제 사용자, 제품, 환경이 모두 제공된 상태에서 서로 상호교환 하며 진행되기 때문에 회사적으로 진행된다면 가장 정확하고 진실한 평가 결과를 제공할 수 있을 것이다. 디자이너들이 2년간 실제와 동일한 상황에서 제품에 어떤 일이 일어나는지 배우면서 막대한 효과를 얻을 수 있을 것이다. 그러나 이와 같은 이유에도 불구하고 Follow-up 스터디가 드물다는 것은 무척 안타까운 일이다.

Posted by 이미지월
◀ PREV : [1] : ... [12] : [13] : [14] : [15] : [16] : [17] : [18] : [19] : [20] : ... [27] : NEXT ▶

BLOG main image
주로 모바일 관련 글들을 많이 올릴것 같습니다~ by 이미지월

공지사항

카테고리

분류 전체보기 (27)
User Experience (12)
User Reserach (3)
Usability Testing (3)
Idea 내기 (1)
퍼온글들 (2)
그냥 그런 이야기 (1)

최근에 받은 트랙백

글 보관함

달력

«   2012/05   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31