사용자는 어떻게 사라지는가
사용자 되돌아보기
‘사용자’가 흐려지는 순간들
시스템 디자인을 하다 보면, 사용자 중심 디자인은 종종 무기력해진다.
정책, 일정, 효율, 기술적 제약, 협업의 어려움…
이런 것들을 고려하다보면 사용자는 자꾸 밀려나기 때문이다.
어디까지 사용자 관점을 지켜야 하는지,
어디서 타협해야 하는지,
그 경계가 흐려질 때, 사용자는 제품에서 사라진다.
사용자는 누구인가?
시스템 디자인의 경우 사용자는 두 레벨로 나뉜다.
내부 사용자: 제품을 운영하고 유지하는 사람들 (예: 운영자, 상담사)
외부 사용자: 서비스의 최종 결과를 경험하는 사람들 (예: 승객)
서비스 디자인 이론에서는 오래전부터 두 레벨을 모두 사용자로 본다.
내부 사용자는 단순한 관리자가 아니라,
서비스 성공을 뒷받침하는 숨은 경험의 주인공이다.
그래서 운영 효율과 업무 편의성을 높이는 것도 ‘사용자 중심’에 포함된다.
사용자가 멀어지게 만드는 패턴들
1. 내부 관점만을 최적화할 때
시스템 디자인은 대부분 ‘내부 사용자’ 대상의 제품이 많기에, 운영자의 사용성을 기준으로 구조를 잡으면, 서비스 이용자에게는 낯선 흐름이 만들어지기도 한다.
"누구에게 쉬운가?"의 기준이 뒤바뀌는 순간이다.
상담사의 업무 시간을 줄이려고 자동화를 했더니, 서비스 이용자 입장에서는 더 불편하고 답답하게 느껴진다.
더 빠르고 안전한 운영처럼 보이지만, 서비스 본연의 가치가 희미해진다.
외부 사용자가 불편을 느끼면 서비스 매력도가 떨어지고, 결국 이탈로 이어진다.
내부 사용자가 불편하면 운영 품질이 떨어지고, 장기적으로 서비스 신뢰가 무너진다.
한쪽만 중심이 되어서는 안 된다.
‘사용자 중심’이라는 말이 힘을 가지려면, 내부와 외부 양쪽의 사용자의 경험을 동시에 바라보아야 한다.
“우리가 만든 구조는, 내부의 편의만 강화한 것은 아닐까?”
2. 개발 효율에 맞춰 흐름을 맞출 때
설계는 기획자도, 디자이너도, 개발자도 할 수 있다.
그런데 설계의 주도권이 기술 쪽에 쏠리면, 개발 효율과 구조적 안정성을 우선하는 방향으로 흐르게 된다.
이 경우 디자인은 이미 정해진 기술 틀에 맞춰 진행된다.
이런 접근이 꼭 나쁜 것은 아니다.
시스템은 안정되고, 컴포넌트는 일관성을 갖게 되며, 테스트도 쉬워진다.
하지만 그 과정에서 사용자의 실제 행동과 기대는
부자연스러운 경험으로 이어질 수 있다.
“시스템은 효율적으로 변했지만, 사용자의 흐름도 함께 좋아진걸까?”
3. 도메인을 잘 아는 만큼 사용자를 덜 고려할 때
도메인 지식이 깊어질수록, 그 구조는 ‘알고 있는 사람만을 위한 규칙’이 되기 쉽다.
설계는 구조적으로 정확했을지 모르지만, 사용자는 그 구조를 뚫지 못한다.
‘맞음’은 ‘이해됨’과 다르다.
"나는 도메인을 잘 알지만, 사용자는 익숙하지 않을 수 있음을 놓치진 않았을까?"
되돌아보니, 사용자가 멀어지는 건 흔히 일어나는 몇 가지 패턴들에서 비롯됐다. 그래서 그때마다 내가 가는 방향이 맞는지, 스스로에게 자주 질문을 던질 수밖에 없었다.
사용자 되돌아보기
제품을 만드는 사람 중 일부러 사용자를 지우려는 사람은 없다.
모두가 사용자 중심을 말하고, 고려하려 한다.
하지만 현실은 다르다. 구조를 바꾸는 일은 너무 어렵기 때문이다.
일정, 이해관계, 협업…
너무 많은 것들이 엉켜 있기 때문에,
우리는 알면서도 “일단 이렇게 가자”라고 말하게 되고,
사용자는 점점 더 멀어진다.
시스템 디자인에서 ‘사용자 중심’은 출발점은 아닐 수 있다.
한 번 놓친 사용자의 흐름을 다시 복원하려는 의지에 가깝다.
그렇기에 디자이너에게 필요한 건, 이 놓쳐버린 흐름을 다시 찾고 연결하는 감각이다.
지속적으로 사용자를 되돌아보는 습관을 갖고, 디자인 안으로 다시 데려와야 한다.
사용자가 어디서 막히는지,
어떤 흐름이 단절되었는지를 감각적으로 되짚는 일은
정량화도 어렵고, 기준도 애매하다.
제품이 고도화될수록 더더욱 어려워진다.
하지만 그걸 하지 않는다면,
결국 아무도 사용하지 않는 제품만 남게 된다.
