디자인라이토

기술의 발전은 사람들에 많은 경험의 기회를 제공해왔다. 언젠가 사람들은 춤추는 곰을 보면 매우 재미있어 한다. 어? 곰이 춤을 추네..하하 재밌네..하지만. 곰이 춤추는 모습은 정말 심플하다. 손을 흔들거나. 한바퀴 빙글빙글 돌거나…아무도 왜 곰이 저 춤밖에 못춰! 라고 불평하는 사람은 아무도 없었다.

하지만, 춤추는 곰을 내 책상 위에 놓고 하루종일 쳐다보면 나는 욕심이 생긴다. 좀 다른 춤도 췄으면 한다. 그래서 다음에는 다른 춤을 추는 곰을 사게 된다. 나중에는 곰이 노래를 하거나 말도 했으면 한다. 그리고 더더욱 많은 필요 사항들을 열거하게 된다. 그리고 다시는 춤추는 곰을 보고 신기해하지 않는다. 지금보다 더 멋진 춤을 추는 곰이 나오는 것을 기대할 것이다.
그렇지 않고 현재의 곰과 별반 다르지 않다면 그 곰을 쳐다보지도 않을 것이다. 이렇듯 제품은 사용자의 요구 사항에 의해 개발이 되어야 한다. 하지만, 제품을 개발하는 개발자는 개발자가 갖고 있는 특권을 중심으로 소프트웨어를 개발하고 있다. 그 이유는 개발자가 갖고 있는 심성 모형으로 인해 발생된다.

개발자는 기능성에 초점을 두고 개발한다. 한마디로 기능이 버그 없이 잘 돌아만 가면 된다. 하지만 사용자는 기능을 사용하는 다양한 컨텍스트에 직면을 한다. 그래서 같은 기능이라도 사용하기에 적절한 컨텍스트가 존재하고, 적절하지 못한 컨텍스트가 존재 한다. 이 같은 사용자의 다양한 컨텍스트를 고려해서 기능을 개발할 수 있는 방법은 모든 프로세스 진행 이전에 인터랙션 디자인을 선행하는 것이다. 사용자들이 원하는 기능이 무엇인지, 기능을 어떻게 서포트 해주어야 하는지, 학습하기 쉽고, 사용이 편리하기 위해 어떤 인터랙션을 제공해주어야 하는지 등을 고려하여 소프트웨어를 개발해야만 좋은 소프트웨어를 만들 수 있다는 것이다.

예를 들어. 자동차의 보안기능은 내가 차와 원거리에 있을 경우 내 차의 보안상태를 알려준다. 하지만 누군가 내 차를 살짝만 건드려도 주위 사람들에게 많은 피해를 준다. 이는 개인적인 가치를 만족시키지만(아 누군가 내 차를 건드렸구나) 개인을 제외한 주위 사람들의 가치(너무 시끄럽다)를 만족시켜주지는 못한다. 그래서 차 보안 기능은 나를 곤란에 빠뜨리곤한다. 그렇다고 해서 내 키에 경보장치를 달 수도 없다. 정말로 위급할 때(강도가 차를 열려고 할 경우)에 자동차에서 나는 비상 경고음은 강도를 내 쫓는데 좋은 역할을 할 수가 있기 때문이다.

또한, 엘리베이터 자동문은 시간을 기준으로 문이 열리고 다시 닫히게 된다. 이는 2~3(또는 그 이상)사람의 출입에 걸리는 시간을 중심으로 문이 열리고 닫히는 기능을 제공한다. 그래서 많은 사람이 엘리베이터를 탈 경우 누군가 문 열림 버튼을 계속 누르고 있다. 즉, 자동문의 열림/닫힘 기능은 기능성에서는 문제가 없지만. 사용성에서는 많은 문제를 나타내고 있다. 시간이 아닌 다른 요소를 고려해서 기능을 만들어야 되는 것이다.

마지막으로, 현관문의 외부카메라는 방문자 발생 시 문을 직접 열지 않고서도 방문자를 확인할 수 있는 효과적인 도구이다. 하지만 사용자가 카메라와 멀리 떨어져 있거나. 너무 가까이 있거나 외부 카메라의 시야에서 벗어난 위치에 서 있을 경우 외부 카메라는 기능을 상실하게 된다. 즉. 카메라가 있어도 방문자를 확인하지 못하는 상황에 직면하게 된다. 그래서 결국은 문을 직접 열어 확인해야만 한다. 

이렇듯 우리 주위에는 사용자의 요구사항을 제대로 인식하지 못한채 개발된 소프트웨어를 쉽게 볼 수가 있다. 이제 제품의 기능성(제품이 문제 없이 잘 돌아가야 된다)은 당연한 것이다. 제품이 버그가 있으면 제품의 자격 조차 없는 것이다. 이는 기능성은 제품이 갖고 있어야할 Basic Factor이며, 이제는 기능성 보다는 사용성 내지 효율성, 유용성등을 더욱 중요하게 고려해야함을 의미한다.

인터페이스 디자인 분야보다 인터랙션 디자인 분야가 중요해지는 이유도 바로 이 때문이다.
곰과 내가 인터랙션을 하면서 더더욱 많은 니즈들이 발생을 하고.  이러한 니즈를 기반으로 소프트웨어를 개발해야지, 개발자의 직관, 기능 선택권. 프로세스 상의 우위에 의해서 소프트웨어가 만들어지면 안되기 때문이다.

이 책은 개발자의 닫힌 마인드. 미시적인 관점, 기능성 중심의 마인드 등을 꼬집고 있다. 그리고 이러한 개발자의 문제(?)들이  사용자 중심의 디자인을 하기 위해 여러 장애요인들이 된다고 말을 하고 있다. 하지만 개발자 입장에서 보면 분명 인터랙션 디자이너들도 문제는 있을 것이다. 추상적인 목표. 발산적 사고 방식등..이 책을 보면서 개발자들은 나쁜 사람들이구나라는 생각보다는 개발자들의 입장도 이해를 하는 것이 필요하다라는 점만 느끼면 될 것 같다.

이 책에서 묘사하는 개발자=정신병자, 개발자의 디자인 작업 환경=정신 병동 이라 표현하는 것은 지극히 인터랙션 디자인에 대한 우월감에 빠져있는 듯하다. 내가 인터랙션 디자이너이지만 개발자들과의 커뮤니케이션 역할 또한 인터랙션 디자이너의 역할 일 것이다. 사용자만이 목표가 아니다. 제품을 개발하는데 있어 서로 다른 관점에서 제품을 개발하고자 하는 모든 팀원들과의 효율적인 인터랙션 또한 인터랙션 디자이너의 역할일 것이다. 개발자가 no 라 말한다면 yes라고 말하도록 유도하는 것 또한 중요하다. 결코 제품은 인터랙션 디자이너만으로는 만들 수 없다. 이 책처럼 개발자=당신 정신병자야? 라고 말하는 당신이 더 우스워 보일 것이다.

부가적으로, 이 책에서 가장 재미있는 부분은 사용자 중심의 디자인을 하기 위해 제품을 사용할 핵심 퍼소나(Persona)를 선정하는 것과 퍼소나의 핵심 목표(Goal)을 설정을 해서 개발자와 공유, 또는 모든 부서들과 공유를 하여 보다 구체적인 멘탈리티를 갖고 디자인 작업을 수행하는 방법을 알려주고 있는 부분이다. 인터랙션 디자인 분야에 입문하는 모든 분들에게 권하고 싶은 책이다.

by. 라이토(laitto79@gmail.com)

이올린에 북마크하기(0) 이올린에 추천하기(0)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.