아직도 유저 리서치를 건너뛰고 있나요?

본문은 요즘 IT와 번역가 Yuna가 함께한 트립 캐롤(Trip Carroll)의 글 <Never skip research day>을 번역한 글입니다. 필자는 2008년부터 UX 디자인 경력을 쌓아왔으며, 현재는 네트워킹과 클라우드 등 기술 분야의 글로벌 기업 Cisco에서 4년 넘게 시니어 디자이너로 재직 중입니다. 이 글에서는 UX 디자이너에게 리서치가 왜 중요한지, 그리고 그것이 현실에서 어떻게 실행되고 어떤 변화를 이끄는지를 직접 경험한 사례를 통해 풀어냅니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

당신은 이제 서른입니다. 뚱뚱하다고 할 순 없지만, 전보다 살이 쪄서 예전 옷 중에 안 맞는 것들이 생겼어요. 별일 아닌 것 같지만, 문득 나이 들었다는 느낌이 스멀스멀 올라옵니다. 당신에겐 동갑내기 절친이 한 명 있습니다. 문제는 이 친구가 짜증 날 만큼 몸이 좋다는 것이죠. 말 그대로 그리스 조각상 같은 몸매예요. 이 친구는 운동은 생각보다 간단하다며, 몇 가지만 제대로 알고 꾸준히 하면 된다고 말합니다. 당신은 이 말을 못 들은 척하죠. 그런데도 이 친구는 계속 말해요. 급기야 책 한 권을 사줄 테니, 제발 읽기만 해달라고 제안합니다. 당신은 어이없지만, 그만 얘기하게 하려고 알겠다고 답하죠.

그런데 이 책, 생각보다 말이 됩니다. 운동이라는 게 그렇게 어려운 것도 아닌 것 같아요. 그래서 해봅니다. 그리고 무려 13kg이나 빠져 기분이 말도 못 하게 좋죠! 그런데 왜 진작 친구 말을 안 들었을까요?

방금 얘기, 혹시 공감되시나요? 제 친구 체이스는 진짜 그랬거든요. 그리고 체이스의 이야기가 제게는 유저 리서치 이야기와 같습니다.

늘 우선순위에서 밀리던 팀

저는 지난 3년 동안 디자인 시스템 팀을 이끌어왔습니다. 그동안 우리 팀은 제품에 변화를 만드는 데 정말 많은 어려움을 겪어왔어요. 그 이유는 다양한데, 일부는 다른 글에서도 다룬 적이 있어요. 최근까지 우리 팀엔 전담 엔지니어도 없었기 때문에, 시스템에 무언가 바꾸고 싶어도 리소스 부족과 바뀌는 우선순위 때문에 손을 대기 어려웠습니다.

이게 바로 디자인 시스템 디자이너들이 자주 마주하는 현실적인 문제입니다. 디자인 시스템은 매출을 직접 만들어내지 않습니다. 우리는 수익을 내는 조직이 아니라, 조직 전체를 지원하는 내부 서비스 팀이거든요. 돈을 벌기보다는 불필요한 낭비를 줄이고, 효율을 높이는 방식으로 비용을 절감하는 역할을 합니다. 우리는 엔지니어, 디자이너, PM들이 매번 바퀴를 처음부터 다시 만들지 않고도, 사용자에게 진짜 가치를 줄 수 있는 문제를 해결할 수 있도록 내부 도구를 만들죠. 우리의 일은 그들의 업무를 더 빠르게, 더 효율적으로, 그리고 훨씬 더 세련되게 만들어줍니다.

하지만 결국 우리는 제품을 파는 팀이 아닙니다. 그래서 사업 리더들 눈에는 뒷전으로 밀리기 쉽습니다. PM들 역시 1,000만 달러 매출을 올릴 수 있는 신규 기능을 우선하기 마련이죠. 접근성 이슈를 해결해 1,000만 달러 벌금을 피할 수 있음에도 그건 늘 나중에 다뤄질 일입니다.

이해는 합니다. 돈은 중요하죠. 좋은 결과물을 계속 만들어내기 위한 자원이니까요. 하지만 가파른 언덕에서 돌을 밀어 올리는 건 정말 어렵습니다. 그리고 그 돌이 다시 굴러내려 오는 걸 보고 있을 때는 정말 속상하죠. 이제는 조직 안에서 더 많은 변화를 만들 수 있는 또 다른 도구가 필요하다고 느꼈습니다.

왜 그렇게 리서치를 외면했을까?

UX 디자이너에게 가장 강력한 도구 중 하나는 디자인 결정에 사용자 리서치를 통해 근거를 더할 수 있는 능력입니다. 좋은 디자인을 만들기 위해서는 정말 없어선 안 될 요소죠. 하지만 안타깝게도 (적어도 제가 있는 조직, 특히 우리 팀에서는) 우리는 이걸 거의 쓰지 않았습니다. 

피그마 라이브러리를 재구축하고, 디자인 시스템 관련 요청을 처리하고, 엔지니어링 임원들에게 임시방편으로 시스템 짓는 건 이제 그만해달라고 설득하는 일에 너무 많은 시간을 쏟았기 때문이죠. 사용자 리서치는 기능 디자이너나 전담 리서처들이 하는 일이라는 생각에 우리 팀은 한 발 떨어져 있었습니다.

그건 정말 큰 착각이었어요. 저처럼 되지 마세요. 그 결정은 우리가 제품에 실질적인 영향을 주는 데 큰 걸림돌이 됐습니다. 하지만 다행히도, 낙타가 아무리 많은 짐을 지고 간다 해도 결국 한계는 있듯이 우리 팀도 결국 그 한계를 넘어서게 됐습니다.

더 나은 아이콘 라이브러리를 위해

우리가 주로 지원하는 제품 중 하나는 Webex 앱입니다. 메시징과 화상회의 기능을 제공하는 툴이죠. 솔직히 말하자면, 가끔은 슬랙이 그리울 때도 있지만요. 그래도 Webex도 꽤 훌륭한 도구입니다. 특히 잡음 제거 기능은 정말 마법 같아요. 세 아이가 만들어내는 소란 속에서 매일 큰 도움이 되고 있습니다.

우리 팀은 아이콘 라이브러리를 관리하고 있고, 지난 1년 동안 이 시스템에 꽤 멋진 개선 작업을 해왔습니다. 웹 엔지니어들과 협업해서, Figma 컴포넌트 라이브러리를 GitHub와 연동할 수 있는 커스텀 Figma 플러그인을 만들었죠. GitHub에서는 원본 SVG 파일이 처리되고 최적화되어, Web, MacOS, iOS, Windows, Android 등 다양한 플랫폼 팀이 사용할 수 있는 형식으로 자동 변환됩니다. 모든 결과물은 NPM으로 버전 관리됩니다.

처음 아이콘을 푸시 했을 때는 감동 그 자체였습니다.

이 플러그인이 생기기 전까지는 모든 과정을 수작업으로 처리했거든요. SVG를 일일이 다듬는 그 방식은, 돌을 깎아 아이콘을 만드는 거나 다름없었습니다. (그게 더 빨랐을지도 모르겠네요.) 우리는 각 제품 및 플랫폼 팀의 니즈를 파악하기 위해 인터뷰를 진행했고, 그 결과 하나의 파이프라인 안에 아이콘 시스템을 통합할 수 있었습니다. 덕분에 일관성 있는 관리가 가능해졌죠.

물론 모든 아이콘이 그렇지는 않았습니다.

문제는 다색 아이콘

아이콘 라이브러리의 99%는 단일 색상 아이콘으로 구성되어 있어 디자이너나 개발자가 컬러 토큰을 적용해 자유롭게 색상을 바꿀 수 있었습니다. 하지만 일부 아이콘은 두 가지 색상을 포함하고 있었고, 여기서부터 문제가 시작됐습니다.

이 다색 아이콘들은 여러모로 문제가 많았습니다. 컬러 토큰을 적용할 수 없을 뿐 아니라, 사용하는 플랫폼에 따라 제작 방식도 모두 달랐습니다. 색상 사용도 내부 아이콘 시스템의 규칙을 어기고 있었기 때문에, 가독성이 떨어지고 사용자 입장에서 혼란을 주기 쉬웠죠.

게다가 이 아이콘들은 이미 오랜 시간 동안 제품 곳곳에 사용되고 있었습니다. 우리는 제품 팀에게 단일 색상 아이콘으로 전환하거나, 다색 아이콘은 각 팀에서 직접 관리해달라 제안했습니다. 대부분의 팀은 이 제안을 받아들였지만, 모두가 그렇지는 않았습니다.

갈등의 시작

다색 아이콘을 많이 사용하고 있던 제품 팀 중 한 곳이 강하게 반발했습니다. 사용자들이 이 아이콘에 익숙해져 있기 때문에, 단일 색상으로 바꾸면 혼란을 줄 수 있다는 게 그들의 입장이었죠. 우리는 반대로 주장했습니다. 단일 색상으로 통일하면 지원하기도 쉬워지고, 아이콘 자체도 훨씬 가독성이 높고 접근성도 좋아질 것이라고요.

하지만 그 누구도 한 발짝도 물러서지 않았습니다.

결국 우리를 구한 건, 리서치였다

시스코에 오기 전, 저는 "블랙보드"(현재는 안솔로지로 불림)라는 회사에서 일했습니다. 그곳이 제 첫 UX 직장이었고, 팀 리더 덕분에 사용자 연구에 대한 교육을 받을 수 있었습니다(정말 고마워요, 켈시!). 저는 블랙보드가 만들고자 했던 새로운 데이터 및 분석 도구에 대한 아이디어를 탐색하는 팀에 속해 있었습니다. 우리는 맥락적 조사와 사용자 인터뷰를 통한 방대한 양의 정성적 리서치는 물론, 컨셉 테스팅과 설문조사를 통한 정량적 리서치도 수행했습니다. 처음부터 새로운 제품을 구축하는 데 필요한 연구를 수행할 수 있는 정말 좋은 기회였습니다.

이 경험은 리서치를 잘하기 위해 필요한 도구와 감을 모두 얻었습니다. 하지만 저는 시스코에 와서는 오랫동안 그 지식을 제대로 실천에 옮기지 못하고 있었습니다.

정말 큰 실수였죠. 제품 팀의 반발이 계속되던 어느 순간, 드디어 전환점이 찾아왔습니다. 우리는 리서치 팀에 연락해, 지금 우리가 추진 중인 디자인 방향이 실제로 타당한지 검증할 수 있는 간단한 사용성 테스트를 만들 수 있을지 물어봤습니다. 리서치 팀은 직접 테스트를 진행할 여유는 없었지만, 우리가 사용할 수 있도록 툴을 설정해 주고, 전반적인 가이드를 제공해 줬습니다.

간단한 테스트 제안서를 만든 뒤, 우리는 제품 팀과 공유했고, 리서치 프로젝트에 참여 중이던 리드 디자이너도 논의에 함께 초대했습니다. 우리가 만든 테스트가 우리 입장에 유리하게 편향되지 않았는지 확인받고 싶었거든요. 테스트는 A/B 형식으로 구성했고, 두 가지 아이콘 디자인을 비교하면서 명확성, 인식 용이성(스캔 가능성), 사용자 선호도에 대해 질문했습니다.

Webex에 익숙한 사용자들을 대상으로 테스트를 진행했지만, 결과는 너무 명확했습니다.

우리는 결과를 정리해 제품팀의 디자이너와 PM에게 공유했습니다. 놀랍게도 더 이상의 반발은 없었습니다. PM은 바로 수긍했고, 변경 사항은 Jira 백로그에 등록되었죠. 몇 달 동안 우리를 괴롭히던 문제가 그렇게 바로 해결되었습니다.

글을 마치며

UX 디자이너로서 우리가 꼭 갖춰야 할 중요한 역량 중 하나는 디자인 결정을 사용자 리서치를 통해 검증하는 실천력입니다. 저처럼은 행동하지 마세요. 리서치를 미루고, UX 프로세스를 점검하는 걸 소홀히 하지 마세요. 이건 정말 강력한 도구입니다. 조직을 올바른 방향으로 이끄는 힘이 있으니까요.

솔직히 이번 프로젝트를 끝내고 나니 마치 게임에서 치트키를 손에 넣은 기분이었습니다. ‘우리가 이렇게 강력한 무기를 왜 진작부터 안 썼을까?’라는 생각이 절로 듭니다. 지금 저희 팀원은 모두 사용자 리서치 트레이닝을 받고 있습니다. 앞으로는 이 힘을 선한 목적에만 쓰기로 다짐했죠. 물론, 세계 정복을 위해서라면 예외일지도 모르겠지만요.

<원문>

Never skip research day

©위 번역글의 원 저작권은 Trip Carroll에게 있으며, 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다