단순함은 좋은 걸까?
단순함을 둘러싼 욕망을 통제하는 디지털 제품을 리딩 하기
자꾸 디자이너에게 단순함을 묻는다...
디자인을 하다가 보면, 단순함에 대한 여러 가지 이야기를 듣게 된다.
단순하게 해주세요.
간단하게 해주세요.
미니멀하게 해주세요.
간결하게 해주세요.
쉽게 해주세요.
맥락에 따라 수십 가지의 단순함에 대한 요청이 쏟아진다. 나의 경험을 기준으로 이 모호한 말들을 대강 번역을 해보면 이렇다. 경우에 따라 다르지만...
빨리 해달라고 하거나,
익숙한 형태로 해달라고 하거나,
화면이 복잡하지 않지만 전달하고자 하는 바를 분명하게 전달 해달 라거나,
여백을 사용하여 아름답게 해달 라거나,
어려운 문장이나 아이콘, 레이아웃을 사용하지 말아달라거나,
태스크를 완료하기 위한 절차를 줄여달라는...
말로 번역되기도 한다.
그런데 언젠가부터 디자인이 아니라 서비스 전체를 평가할 때,
"단순함을 추구하며 그렇게 만든 서비스입니다."
라고 말하는 것이 일상인 세상이 되어 버렸다.
단순한 전등 스위치. 하지만 추가적인 정보 없이 스위치만 보면, 켜졌는지 꺼졌는지 알 수 없다.기능이나 화면이 아닌 서비스 전체를 단순하게 만들었다는 것은 쉬운 문장이지만, 이해하기 어려운 문장이다. 서비스는 항상 복잡하기 때문이다. 서비스가 단순한 것이 무엇인지 설명하지 않는다면, 단순한 서비스를 지향했다는 말은 꽤 모호하다.
어떤 경우는, 서비스의 목적을 이해하기 쉬운 것을 단순하다고 한다.
어떤 경우는, 서비스의 구조가 복잡하지 않은 것을 단순하다고 한다.
어떤 경우는, 서비스의 기능이 적은 것을 단순하다고 한다.
디자이너는 단순한 고래들 사이에서 미쳐간다.
하지만 현실에서는 회사에서는 수익이나 기타 지표를 위해 기능 변화와 배너, 이벤트를 사용자에게 밀어 넣고 싶어 하고, 사용자는 개성 넘치는 불특정 한 콘텐츠를 서비스에 밀어 넣고 싶어 하며, 회사가 보여주는 기능 변화에 분노하거나, 상업용 프로모션을 회피하려고 한다.
양쪽의 압력이 꼭짓점으로 만나는 한 점에 디자이너가 끼어 있다.
디자이너 역시 욕망이 있다. 대부분의 디자이너는 통제되고 일관된 방향성이 있는 디자인을 하고 싶어 한다. 디자이너의 개성에 따라 재미있거나, 캐주얼하거나, 동적이거나, 정적이거나, 미니멀하거나, 안정된 디자인을 하고 싶은 욕망이 있다. 그리고 보편적으로 통제할 수 있는 정제된 콘텐츠와 기능을 원한다. 계층적인 문서 구조, 정확한 텍스트의 글자 수, 일관된 사진을 갖고 일하고 싶어 한다.
어느 순간, 아무리 디자인을 애써봐야 전체 제품을 단순하게 만들 수 없다는 사실을 깨달았다. 서비스의 평가는 스크린에서 시작되기 때문에 디자인은 사용자 측면에서는 서비스 평가의 첫 단계지만, 회사 측면에서는 모든 것이 완료된 후의 마지막 단계였기 때문이다.
서로의 상반된 요구가 절충되지 않는 기이한 틈새에 끼어있다는 것을 알게 된 후, 단순함에 대해 알아보기 시작했다.
목적, 구조, 기능이 단순한 서비스는 없다.
사용자에게 전달되는 서비스는 최소 3종류 이상의 스마트 디바이스, 3종류 이상의 웹브라우저, 2종류 이상의 데스크톱 OS와 스마트폰 OS를 통해 사용자에게 제공된다. 서비스에 따라 결제, 물류, 배송, 고객 대응 등의 모듈이나 서비스와 연계된다. 대부분의 서비스가 구체적이고, 명시적이고, 수많은 단계를 거쳐 제공된다.
그러나 어느 순간, 서비스 전체가 간단한 일을 여러 단계에 걸쳐 수행하는 골드버그 장치처럼 변하기도 한다.사람들은 시계를 볼 때, 시간을 본다. 시계가 어떻게 움직이지는지 궁금해하지 않는다.
사용자에게 간단할수록 그 복잡함은 만드는 사람들에게 부과된다. 복잡해질수록 제작과 유지보수의 효율이 떨어진다. 많이 테스트해야 하기 때문에 전체 제작기간이 길어진다. 궁극적으로 모든 장애물을 뚫고 이상적인 단순함 단계에 제품을 올려놓으면 확장하기가 쉽지 않다.
회사의 경영자들은 확장하기 쉽지 않은 구조의 서비스를 좋아하지 않는다. 거의 무한할 정도의 확장이 그들 마음속에 있기 때문이다. 때로는 횡으로, 때로는 종으로, 때로는 층으로 확장하고 싶어 한다. 그리고 이것저것을 더 해볼 수 없냐, 더 붙일 수 없냐고 끊임없이 요구한다.
서비스를 단순함으로 평가해서는 안된다.
단순함은 좋은 걸까? 아니다. 단순한 회사, 단순한 서비스가 없기 때문이다. 실제로는 대부분의 복잡한 것이 당연하다. 서비스를 단순함만으로 설명하게 되면, 사용자 측면에서 간단하고 편리한 다른 서비스와 구분하기 힘들다.
복잡한 것은 나쁜 것이 아니다. 도널드 노만은 책에서 이렇게 구분한다. '단순함은 정답이 아니다.(Living with complexity), 2012'
복잡함(complexity)과 혼돈스러움(complicated)은 구분돼야 한다. 복잡함은 이 세상의 상태이고 혼란스러움은 마음의 상태에 부차적으로 '어렵다'를 더 한 의미이다.
- 복잡함: 이 세상과 다양한 도구들의 상태를 묘사할 때 사용한다.
- 혼란스럽다 혹은 어지럽다: 세상의 무언가를 이해하고, 사용하며, 상호작용하는 과정에서 사람들이 느끼는 심리 상태, 헛갈리게 하는 복잡함.
UX 디자인을 누구나 아는 시대이기 때문에, 거의 모든 서비스가 사용자에게 편리하고 쉬운, 단순함을 추구한다. 그래서 서비스를 이야기할 때는 무엇을 편리하고 단순하게 만들고 있는지 이야기해야 한다.
단순함은 도구일 뿐이다.
음료를 파는 회사에서 빨대를 자랑하는 경우는 없다.(하지만, 세상에 절대란 없다. 빨대를 자랑하는 경우)
실무자의 욕망을 통제하는 리딩이 필요하다.
밑바닥에서 말도 안 되는 제작 과정에서 갈려가면서, 회사와 사용자 모두를 만족시키는 이상적인 제작 절차를 항상 고민했다. 제작을 하는 실무자는 항상 제각각의 욕망을 갖고 있다. 적게 일하기부터 일찍 집에 가기... 같은 욕망부터 나만의 작품 만들기, 완전무결한 코드 만들기, 모든 오류에 대응하기, 모든 기기에 대응하기 등등... 이러한 욕망을 통제하기 위해서는 명확한 기준이 필요하고 그 기준에 대한 동의를 받는 것이 필요하다는 생각을 하게 되었다.
첫 번째, 핵심 문제에 대한 개념을 새로 세우는 것이다.
통화가 다이얼패드를 누르는 것이라고 하면, 다이얼패드를 디자인하게 되지만, 통화를 음성과 문자, 혹은 이 모지, 동영상 등으로 상대방, 혹은 친구들과 공유하며 이야기하는 것으로 생각하면 여러 가지 변화가 생긴다.
두 번째, 제작의 목표와 목적을 공유하는 것이다.
제품을 만드는 목표가 공유되지 않으면, 제품은 각자의 사람들이 편리한 방식으로 제작되고, 그 부하는 결국 사용자에게 부과된다. 일정 이상의 목표가 설정돼서, 누가 무엇을 왜 하는지 알아야 한다.
세 번째, 파티션이 낮아야 한다.
좋은 제품을 만들기 위해서는 누군가 문서에 기술된 것 이상의 희생을 해야 하는 경우가 있다.
아무리 멋진 계획을 세워도, 팀 간의 벽이 있으면, 서로에게 미루는 일이 생긴다. 그것이 약관 동의의 개수, 체크박스의 용도, 확인 및 돌아가기, 에러 처리, 서비스 장애, 고객 CS 절차 등등. 모호한 경계에서 일어나는 문제가 많다. 디자이너가 프로그램을 모르고, 프로그래머는 디자인에 신경 쓰지 않는 경우가 많은 환경에서 제대로 된 경험을 만들려면, 누군가는 파티션 사이로 열심히 돌아다니거나, 파티션 자체가 없어야 한다.
어떤 경우에는 프로그램의 말대로 UI 컴포넌트의 흐름을 구성해야 한다. 어떤 경우에 단순함은 '자동화'에서 오고 자동화될 구조를 가장 잘 알고 있는 사람은 프로그래머이기 때문이다.
어떤 경우에는 디자이너 말대로 화면 흐름을 구성하는 것이 효과적일 때가 있다. 어떤 경우에 단순함은 비주얼 디자인에서 오고, 그걸 가장 이해하는 것은 디자이너이기 때문이다.
결론
사용자와 회사의 단순함의 기준이 다르기 때문에 단순함은 제품의 개성이 될 수 없고 오해만 일으킨다.
디자인을 단순하게 만들기 위해서는 모호함과 혼돈, 그리고 복잡성에 대한 이해가 필요하다.
단순함은 좋은 제품을 만들기 위한 도구이며, 단순함으로 모든 것을 설명하거나 대변할 수는 없다.
좋은 디자인을 하려면, 디자이너도 서비스와 사업, 회사에 대한 이해가 있어야 하며, 협력해야 한다.
