누구나 사용할 수 있는 UX 리뷰 템플릿
원문: A UX review template anyone can use
이 글은 Medium에 게시된 글을 직접 번역한 글입니다.
전문 번역가가 아니므로 대량의 오역 및 의역이 있을 수 있습니다.
원문: A UX review template anyone can use
커넥티드 프로덕트가 우리 삶의 다양한 국면에 스며듦에 따라, UX는 직관적인 경험으로 탈바꿈되어야만 합니다. -포브스(Forbes)
각 조직이 자신의 비즈니스 니즈보다 클라이언트의 요구를 충족시키는 제품을 만드는 데 혈안이 되면서 UX에 대한 수요는 보다 분명해졌습니다. 이런 조직들 중에는 거대한 UX 및 디자인 팀을 꾸리고 해당 팀으로 하여금 오직 최고의 고객 경험을 제공하는데만 집중하도록 하는 곳도 있습니다.
하지만 만약 우리가 서비스나 프로덕트를 리뷰할 능력이 있는 UX 디자이너를 고용할 수 없는 상황이라면 어떻게 해야 할까요?
이 글의 목적은 당신이 UX 디자이너이든 아니든 직접 UX 리뷰를 할 수 있도록 돕는 데 있습니다. 지금부터 알려드릴 프레임워크는 프로덕트나 서비스, 혹은 잠재 클라이언트를 위한 어떤 업무에서도 분석 툴로도 활용할 수 있습니다. 또 편견이 작용할 여지가 거의 없기 때문에, 자신의 업무를 객관적으로 리뷰하는 데도 충분히 제 몫을 할 것입니다.
(이 프레임워크는 어떤 형태의 프로덕트나 서비스에도 적용할 수 있지만, 특히 웹사이트에 특화되어 있다는 것을 감안해주시기 바랍니다.)
리뷰의 목표
리뷰를 시작하기 위해 가장 중요한 것은 목표를 정하는 것입니다. 이메일로 리뷰를 받든 프레젠테이션을 하든 상관없이, 우선 목표를 정함으로써 당신과 이해관계자(Stakeholder)들이 리뷰에 대해 같은 기대치를 가지게 할 수 있습니다.
설정할 수 있는 리뷰 목표 및 결과물에는 아래 예시들이 있습니다.
1. 기회 파악하기
2. 설계 변경에의 입증
3. 기술적 이슈 정의
4. UX 디자인 개선 논의
이런 목표들은 대부분 ‘애초에 왜 우리의 클라이언트는 우리에게 UX 리뷰를 요청했는가’와 같은 초기 단계의 브리핑과도 관련이 있죠.
비즈니스 목표
비즈니스 목표란 클라이언트가 달성하기 원하는 목표를 의미합니다.
이러한 비즈니스 목표는 쉽게 설정할 수도, 혹은 설정을 위해 추가적인 리서치가 필요할 수도 있습니다. 리서치를 하게 될 경우, 리서치는 클라이언트에 집중해야 합니다. 클라이언트의 목표는 명확할 경우도 있지만 가끔 더 심층적인 조사를 통해 그들의 진짜 욕구를 표면으로 끌어올려야 할 수도 있죠.
이런 목표들을 풀어놓는 것은 중요합니다. ‘판매 증진’이라는 목표를 예시로 들아보죠. 클라이언트는 단순히 특정 상품을 더 판매하길 원하는 건가요, 스토어 내부 트래픽을 확대하길 원하나요? 이런 세부 사항은 리뷰의 결과물을 보다 실질적이고 측정 가능하도록 만드는 중요한 요소입니다. 제대로 정의되지 않은 목표에 1000개 제품의 판매 증가를 끼워 맞추는 것보다, 특정 제품의 판매 증가를 UX 개선으로 풀어내는 것이 당연히 훨씬 더 쉽습니다. 이런 목표들은 클라이언트와 혹은 그들의 이해관계자와의 인터뷰를 통해 확인해볼 수 있으며, 또 시장조사를 통해서 부가적인 목표들도 확인해볼 수 있습니다.
마지막으로, 우리의 클라이언트에게 지금 우리가 어떤 문제를 해결하려고 하는 지를 계속 리마인드 시키기 위해서라도 이 리뷰의 목적을 공표해야 합니다.
이렇게 함으로써 리뷰가 진행되는 동안에도 이 목표를 계속 확인해나갈 수 있으며, 우리의 아이디어 역시 신빙성을 가지게 됩니다.
페르소나와 사용자 흐름
비즈니스의 니즈를 이해했다면, 이제 사용자의 니즈를 확인할 차례입니다. 사용자의 니즈를 확인하기 위해 가장 널리 쓰이는 방법은 페르소나 혹은 페르소나 시트를 만드는 겁니다. 페르소나는 그들의 삶 속에 있는 니즈, 열망, 욕구와 연결되어 있는 가상의 사용자를 의미합니다.
샌디라는 사람을 예로 들어 볼게요. 그녀는 중산층 전문직 여성으로 두 명의 가족이 있습니다. 그녀는 기술을 배우는 것, 다큐멘터리를 보는 것, 그리고 자신의 아이들과 시간을 보내는 것을 좋아합니다. 또 그녀는 자신과 자신의 아이들의 함께 가지고 놀 수 있는 장난감을 판매하는 조금 특이한 장난감 가게에서 이상적인 고객이기도 합니다.
만들기 쉽지 않지만, 그래도 페르소나는 아주 유용한 툴입니다. 페르소나는 우리 자신이나 이해관계자들이 가진 비즈니스 목표를 확실하게 이해한 뒤, 부가 리서치를 진행함으로써 설정할 수 있습니다. Shane Williams는 'Getting with creating personas - questions to ask’에서 페르소나를 만드는 것에 대해 포괄적으로 설명하고 있습니다.
일단 우리의 사용자를 알게 되었다면, 이제는 사용자들이 (프로덕트나 서비스 상에서) 자신의 목표를 달성하기 위해 취하는 단계들을 살펴볼 차례입니다. 이때 사용자 흐름 다이어그램(user flow diagrams)을 그리는 것은 도움이 됩니다. 이 다이어그램은 사용자 여정(user journey)을 보여주는 하나의 샘플인데, 때로 우리의 비즈니스 목표와 결합해서 보일 때도 있습니다.
다이어그램 예시포스트잇 활용 기법이나 온라인 툴 Draw.io 등 다이아그램을 그리는 데 도움을 주는 둘은 많습니다. 다이아그램은 이렇게 그려야 한다는 룰은 딱히 없지만, 읽기 쉽게 설계되어야 한다는 것을 잊어서는 안 됩니다.
데이터 활용하기
데이터는 좋은 UX 리뷰의 주춧돌입니다. 데이터 없이는 우리가 찾아낸 것들을 증명해내기가 쉽지 않죠. Google analytics야말로 사용자 상호작용 데이터를 얻을 수 있는 좋은 시작점일 수 있습니다.
특정 날짜에 트래픽이 떨어지는 것처럼, 의외로 단순한 데이터 포인트로 인해 문제점을 발견할 수도 있습니다. 예를 들어 (이런 트래픽 하강이) 새로운 기능에 대한 사용자의 부정 반응이거나 혹은 소셜 미디어에 올린 포스팅이 역효과를 냈기 때문임을 알 수 있는 거죠. 디바이스 정보(모바일 vs 데스크톱 트래픽) 역시 사용성 평가 시 어떤 기기를 중점으로 볼 것인가를 결정할 때 필요한 좋은 데이터가 될 수 있습니다.
제대로 셋업 된 Google Anayltics의 Event tracking 기능은 또 다른 좋은 데이터 소스가 될 수 있습니다. GA의 Event tracking 추적 기능을 설정할만한 전문 인력이나 지식이 없는 경우, GrazyEgg는 클릭과 스크롤 데이터 차트를 볼 수 있는 좋은 대안이 됩니다.
GA의 Behavior flow report 역시 매우 유용한데요, 이 리포트는 사용자들이 취하는 여정에 대한 인사이트를 흐름도 형태로 보여줍니다. 특정 사용자 경로를 강조하거나 분석할 수 있는 드롭 오프(하강 지점), 세션 등의 데이터를 담고 있죠.
Behavior flow chart 예시System Usability Scale(SUS) 역시 사용자의 피드백을 바탕으로 시스템 사용성을 특정하는 좋은 방법입니다. SUS는 프로덕트, 웹사이트, 앱 혹은 소프트웨어에서 이루어질 수 있고, 피드백의 분량과 관계없이 규모 있는 결과를 제공합니다. 또 SUS 서베이의 데이터는 사용성 리뷰에서도 유용하게 사용될 수 있죠.
마지막으로, 앞전 단계에서 만들어둔 페르소나 시트 역시 훌륭한 데이터 소스 중 하나입니다. 앞서 살펴본 여러 종류의 데이터를 검토할 때 우리 사용자의 목표를 항상 중심에 두면, 특정 지점에서의 사용자 행동 패턴이 실제 (우리가 그린) 사용자 여정과 간극이 있다는 것을 찾아낼 수 있을 테니까요.
우리 혹은 우리의 클라이언트가 언제나 데이터 분석 툴을 가지고 있을 거란 보장은 없습니다. 만약 그렇다면 활용 가능한, 의미 있는 분석 데이터를 가지기 전까지는 리뷰하지 않을 것을 권장합니다. GA는 쉽고 빠르게 설치할 수 있으며, 한 달만 있으면 의미 있는 정보를 얻을 수 있는 툴입니다.
사용성 리뷰
사용성은 웹(web)을 지배한다. 만약 고객이 프로덕트를 찾지 못한다면. 구매하지도 않을 테니. - Jakob Nelsen
‘사용성’이야말로 리뷰의 핵심입니다: 이 프로덕트는 정말 쓸만한가요?
자, 이제 비즈니스와 사용자 니즈 관점에서 우리의 프로젝트가 얼마나 사용성이 있는지에 대해 몇 가지 가정을 해 볼 시간입니다. 분석 데이터, 사용자 흐름도, 페르소나 시트를 활용해 직접 우리의 사용자가 되어봅시다. 각기 다른 OS, 브라우저, 기기를 활용해 사용자 흐름을 따라 내 애플리케이션이나 서비스를 써보는 겁니다. 열 받는 지점이나, 사용 목표 달성에 전혀 도움이 되지 않는 기능을 빠르게 찾아낼 수 있을 겁니다.
혹은 디자인 결함, 잘못되거나 헷갈리는 컴포넌트들을 우연히 발견할지도 모릅니다. 이 모든 잠재 문제사항들을 스크린 샷과 함께 메모하세요. 일단 사용자의 입장에서 이 프로젝트를 한번 훑고 나면, 이제는 다시 프로덕트 오너가 되어 같은 과정을 한 번 더 해보기 바랍니다.
다음으로 할 일은 이해하기 쉽게 피드백을 만드는 겁니다. 우리의 클라이언트는 UX나 디자인에 대한 지식이 거의 없으며, 그래서 우리는 UX 리뷰어로써 이 피드백을 간결하게 만들 의무가 있다는 것을 기억하세요. 피드백은 가급적 짧고 정확하게 쓰고 필요할 경우에만 구두로 자세한 생각을 덧붙이는 게 좋습니다. 무엇보다 중요한 건 이 피드백이 문제점들을 나열한 목록이 아니라 개선의 기회 리스트로 보여야 한다는 겁니다.
마지막으로, 성급하게 솔루션 모드로 돌입하지 마세요. 이 단계에서는 사용성 문제를 파악하는 것으로 충분합니다. 저는 주로 아래와 같은 분류로 리뷰 피드백을 구분해서 정리하곤 합니다.
1. 사용자 여정
사용자 여정과 관련 있는 어떤 문제든 여기에 해당됩니다. 만약 이 문제들과 관련해서 이해관계자들을 설득하는 데 어려움이 있다면, 그들이 사용자가 되어 보도록 만들어주세요. 이 분류에는 아래와 같은 예시가 해당됩니다.
사용자에게 주어야 할 정보가 페이지 너무 아래쪽에 있을 경우
정보 구조에서 중요한 페이지가 너무 깊숙이 숨겨져 있을 경우
제공되는 정보가 필요 없거나 사용자에게 어떤 가치도 없을 경우
구매하기 위해 너무 많이 클릭해야 할 경우
모순적인 사용자 여정
중요한 정보가 숨김 처리되어있는 경우
2. 일반
프로덕트나 서비스에서 계속해서 일어나는 문제가 있나요? (사용자) 여정이나 기기에 국한된 문제가 아닌 그 무엇이든 여기에 속합니다.
3. 디자인
이때 디자인에 대한 이해도가 있다면 매우 도움은 되겠지만, 꼭 필요한 전제 조건은 아닙니다. 리뷰 시 일반적으로 주목할 수 있는 디자인 요소들은 아래와 같은 것들입니다.
비 일관적인 디자인(예를 들어, 페이지마다 다른 버튼 디자인)
정렬 문제
빈약한 페이지 계층 구조(hierarchy)
4. 모바일
모바일 리뷰의 정확도는 테스트를 위해 사용한 모바일 기기가 무엇이냐에 따라 달라질 수 있습니다. (스마트폰이나 태블릿 모두 마찬가지입니다.) 이 항목에서는 아래와 같은 것들을 살펴볼 수 있습니다.
반응 문제(예: 모바일 친화형으로 바뀌는가?)
폰트 사이즈를 포함한 크기 문제
특정 페이지에서 핀치나 줌 기능을 요구하는지 여부
5. 데스크톱
위에서 살펴본 대부분의 항목들이 데스크톱에 해당되긴 하지만, 때 때로 데스크톱에만 해당되는 문제들도 있습니다. 또 만약 우리의 트래픽이 주로 모바일에서 발생한다면, 이 항목은 건너뛰어도 괜찮습니다.
접근성 리뷰
개발자도 디자이너도 종종 접근성 문제를 간과하곤 합니다. 솔직히 저도 그렇고요. 그러나 디지털 기반 사회로 변화해감에 따라 장애가 있는 사용자를 고려하는 것은 점점 더 중요해지고 있습니다. 빨간 버튼 위에 초록색 글씨를 올려두는 것 같은 실수는 색맹 사용자의 경험을 망쳐 판매나 리드 기회를 일게 만들 수 있죠.
접근성은 색상, 폰트 크기, 폰트 타입, 설명글, 알트 태그(Alt tag) 등으로 확인할 수 있습니다. 이런 디자인 혹은 기술적인 요소들이 사용자 경험에 영향을 미친다는 것을 고려하면, 이 역시 매우 중요한 부분입니다.
제가 웹사이트 접근성을 테스트하기 위해 종종 사용하는 툴은 Google Lighthouse입니다. Google Lighthouse는 크롬으로 사용할 수 있는 개발자 툴로, 속도, 웹 앱 기능 성능, 접근성, 웹사이트의 SEO 등에 대한 상세 피드백을 제공합니다. 이 툴은 솔루션을 제공할 뿐만 아니라 제안된 변경 사항의 효과를 입증해줌으로써 UX 리뷰어에게 강력한 무기가 되기도 합니다.
“만약 버튼에 판별 가능한 이름이 없다면, 스크린 리더(Screen reader)는 그것을 ‘버튼’이라고 할 것이고, 그 스크린 리더를 사용하는 사용자들은 그 버튼을 사용하지 않을 겁니다.” - Google Lighthouse 피드백 예시
Eightshape’s color contrast grid는 디지털 컬러 팔레트의 접근성을 비교 분석한 좋은 툴이고, Colorsafe는 보다 쉽게 좋은 색상 조합을 찾을 수 있도록 도와줍니다.
기술적 리뷰
우리의 리뷰 프레젠테이션에 기술적인 내용을 넣을 것인지 여부는 리뷰를 받는 대상이 기술적 지식을 가지고 있는지 아닌지에 달려 있겠죠.
기술적인 리뷰가 유용한 가장 큰 이유 중 하나는 작은 코드 수정 하나로 전환율이나 전반적인 사용자 경험을 크게 바꿀 수도 있기 때문입니다.
1. 퍼포먼스/스피드
웹사이트의 스피드를 측정하는 좋은 방법 중 하나는 Page Speed Insight로 알려진 구글의 툴을 사용하는 것입니다. PSI는 캐싱을 하거나 이미지를 PC와 모바일 모두에 맞게 최적화하는 것 등, 사이트 속도를 개선하기 위한 쉽고 빠른 팁을 제공합니다. 때로 너무 기술적이기도 하지만, 구글은 상세 내용이 담겨 있는 아티클 링크도 함께 제공하고 있으니 활용해볼 수 있다면 좋겠죠.
앞서 살펴본 Google Lighthouse에서도 퍼포먼스 데이터를 확인할 수 있습니다. Lighthouse는 PSI보다 훨씬 디테일한 데이터를 제공하고, 또 훨씬 최신 기술을 바탕으로 한 개선 사항을 제안합니다. (HTTP/2 표준처럼요.)
2. 모범 사례
모범 사례란 프로젝트가 주어진 장치나 매체의 표준을 따랐는지 여부를 의미합니다. 웹 사이트 사용성을 해치는, 헤드라인을 줄 바꿈으로 처리하는 웹 사이트의 인쇄 표준이 이에 해당하는 좋은 예입니다.
3. SEO
웹 프로덕트의 사용자 경험을 들여다볼 때 종종 SEO를 제외하기도 하지만, 그래서는 안 됩니다. SEO는 우리 사이트의 랭킹뿐만 아니라 검색 노출도를 의미하기도 하니까요. 만약 우리 사이트가 매력적인 제목이나 설명글을 가지고 있지 않다면 사용자를 사이트로 데려올 수 있는 기회를 잃게 됩니다. 접근성 측면에서 해결해야 할 문제 중 일부는 사이트 SEO에 영향을 줄 수도 있습니다. (예를 들어 alt tag를 좀 더 설명적으로 쓴다던가 하는 것처럼요.) Lighthouse가 대략적인 SEO 피드백을 주기도 합니다만, SEO를 더 자세히 확인하기 위해서는 Moz를 사용할 것을 추천합니다.
기회들
다음 단계는 여태까지 수집한 풍부한 데이터를 우리(혹은 우리의 클라이언트가) 사용자 경험의 간극을 메우기 위해 어떻게 사용할 수 있을지에 대한 것입니다. 이때의 제안들은 우리의 이전 리뷰를 바탕으로 하거나, 프로덕트를 사용하면서 확인한 기회들을 기반으로 제안될 수 있습니다. 아래와 같이요.
기존 페이지에 관련 있는 아티클을 더하면 사용자가 하나의 글을 다 보고 나서도 계속해서 우리의 사이트에서의 여정을 이어갈 수 있습니다
폼(form)의 길이를 줄이면 사용성이 늘어나서 리드를 확보할 수 있습니다.
이 때 ‘배너를 영역을 늘리면 트래픽이 늘어날 것입니다’와 같이 무언가를 보장하는 멘트는 조심해야 합니다. 기회란 개선 가능성을 넌지시 암시하는 것이어야지 그것을 약속해서는 안됩니다.
매트릭스
확인된 UX 문제에 대한 솔루션을 시행하는 것만으로는 충분하지 않을 수 있습니다. 그것이 성공적인지 여부를 측정하는 것도 필요하니까요. 특정 액션 포인트에 대한 매트릭스를 세팅하는 것으로 솔루션 성공 여부를 확인하세요.
좋은 매트릭스는 유형적이면서도 달성 가능해야 합니다. ‘매출 증가’는 좋은 매트릭스가 아닙니다. 정확하게 측정할 수 있으면서도, UX 변화와 연관 지어 설명할 수 있을지가 관건입니다.
매트릭스를 세분화하고, 각 매트릭스 측정 기한을 둔 뒤 다시 모아 우리의 목표와 비교하고 기회를 다시 찾아내세요.
'관련 있는 아티클’을 더함으로써 x 페이지의 이탈률을 5% 줄입니다.
폼(form)을 더 쉽게 만들어 X 페이지에서 매일 5개의 리드를 더 만들어냅니다.
우리의 클라이언트 역시 그들 자신의 매트릭스를 설정하기를 원할 겁니다. 이때 그들의 기대치를 합리적이면서도 달성 가능한 수준으로 설정할 수 있도록 하세요.
다음으로
당신이 (리뷰 이후에 솔루션을) 구현할 책임이 없다고 하더라도, 클라이언트와 다음 단계에 대해서 논의해보세요. 실행 가능한 아이템들이 없다면 리뷰는 그냥 커피 자국이 남은 테이블에 불과하니까요. 그들의 우선순위나 매트릭스에 따라 액션 아이템이나 테스크 목록을 만드는 것은 좋은 시작이고, 이해관계자들에게 그들 스스로 실행할 수 있게 도와주는 좋은 가이드가 될 겁니다.
혹시 그들의 실행 파트너나 그들 팀에 속한 UX 디자이너가 될지, 어떻게 알겠습니까?
이 프레임 워크가 여러분에게 도움이 되었기를 바랍니다.
저는 항상 매트릭스 세우는 데 애를 먹습니다. 액션 아이템까지 잘 내려놓고, 막상 매트릭스 세울 순서가 되면 말 그대로 '참 좋은데 어떻게 표현할 방법이 없네'와 같은 안타까움을 느끼곤 하죠. 다음번엔 매트릭스 세우는 법에 대한 글을 찾아서 번역해볼까 봐요.
다른 번역 글 읽기:
초보자를 위한 Customer Journey Map
디자이너가 피해야 할 유저 온보딩 함정
