다중형 리스트 UI 개선사례 (번역본)
UI 개선을 위해, AB테스트와 통계를 사용한 실제사례 이야기
이 게시물은 Medium, Tripaneer Tech blog의 Improving the usability of multi-selecting from a long list 이라는 문서를 번역한 게시글입니다. 맥락상 이해가 쉽도록 의역 + 수정했기 때문에 정확하지 못한 표현이 있을 수 있습니다.
원본글 링크
여러 아이템을 동시에 선택해야하는 문제
여러 아이템을 동시에 선택해야하는 리스트 형태의 UI는 항상 불편하기만 합니다. 물론 큰 해상도의 화면에서는, 이런 구조에 대한 여러가지 해결책들이 있긴 하죠. 하지만 대부분 모바일 단위의 구조에서는 동일한 방식을 사용하기가 어렵고, 사용한다해도 엉망이 되는 경우가 많습니다. 자, 이제부터 이야기할 내용은 태그 목록을 선택하는 UI 구조를 개선했던 경험담을 이야기해보겠습니다.
긴 목록과 태그 구조를 포함하는, 기존의 UI 구조들
다중선택을 위한 UI 구조를 찾아보신 경험이 있나요? 아마도 드롭다운과 검색창이 통합된 구조인 경우가 대부분일겁니다. 또한 검색된 결과값은 검색창에 뱃지 형태로 들어가게되죠.
UI 요소에 대한 예시 사이트
https://semantic-ui.com/modules/dropdown.html#multiple-selection
혹은 드롭박스 내부에, 체크박스형태의 리스트를 합쳐놓거나. 혹은 두개의 리스트 형태로 구조를 만들어, 좌측의 내용을 우측으로 옮겨넣는 구조가 있습니다.
Hybrid Dual List with Filter UI solutionhttp://doejo.com/blog/solutions-for-implementing-user-friendly-multi-select/
검색 가능한 다중선택 UI의 문제점
대부분의 경우, 이런 검색 가능한 다중선택 UI가 가지는 문제점은. 아이템의 목록이 너무 길다는 부분에 있습니다. 예를 들어 거의 300개 정도 되는 아이템 목록이 있는데, 사용자들은 여기에 전혀 익숙한 상태가 아닙니다.
영상을 통해 테스트를 해본 결과, 대부분의 사용자들은 이런 화면에서 - 리스트를 확인해보려하다가. 금방 스크롤링을 포기해버리고, 직접 검색을 통해 입력을 하게되는 경우가 대부분입니다. 어디쯤에, 무엇이 있는지를 알기 때문이죠. 실제로 다중선택 가능한 태그박스 형태의 UI 솔루션은- 해당 아이템들에 사용자가 익숙해져있을때 가장 효율적인 UI 구조입니다.
그러나 반대로 사용자가 아이템 목록에 익숙치 않은 경우라면, 여러가지 문제가 발생합니다. 원하는 목록을 찾기위해 길다란 스크롤링을 반복해야하는건 굉장히 피곤한 일입니다. 그렇기에 대부분의 사용자들은 스크롤을 통해 원하는 내용을 찾지 않습니다. 여기에 목록이 - 특정한 카테고리 형태로 나뉘어있고, ABC 순서대로 정렬되지 않은 경우라면 더욱더 그렇죠.
게다가 대부분의 사용자들은 설게된 대로 단어를 정확히 나열하여 검색하지 않습니다. 그렇기에 대부분, 사용자가 원하는 검색결과를 찾을 확률은 50%가 채 되지 않습니다. 그렇기에 몇번의 시도 끝에, 사용자들은 원하는 내용을 찾기를 포기해버리게되죠.
실제로 저희 회사의 컨텐츠 검수 팀은 - 제대로된 태그 선택이 일어나는 경우가 매우 적다는 사실을 확인했습니다. 이러한 문제는 생각보다 심각해서, 여러가지 연구와 조사가 필요한 부분이었죠.
사용성 개선을 위한 첫번째 아이디어
컨텐츠 검수 팀의 확인이 진행된 이후, 저는 하이브리드 형태의 듀얼 리스트 해결책을 사용해볼지를 고민하고있었습니다. 하지만 이 구조는 모바일을 위한 구조에는 적합하지 않은 해결책이었죠.
Hybrid Dual List with Filter UI solution그럼 대체 어떤 해결책을 찾아봐야할까를 고민하닥. Foursquare 서비스의 '맛 취향' 태그 UI 에서 그 실마리를 발견했습니다.
이 UI를 보게된 이후, 태그를 선택할 수 있는 구조를 개선할 수 있을거란 생각이 들었습니다.하지만 우리가 운영중인 내부서비스의 태그 리스트가 너무 길고, 구조화되어있지 않았기 때문에 - 완벽한 해결책은 아니었죠. 하지만 이 발견은 큰 시작점이 되어주었습니다.
UI 변경전 모습 (스크롤 바가 굉장히 깁니다)
UI 변경 후 모습 (모든 아이템들을 펼쳐저 보여주는 형태가 되었습니다)
이 사례는, 순전히 UI 형식을 개선한 사례에 불과했습니다. 백엔드의 데이터 구조나, 설계를 변경하지도 않았죠. 예를 들어 '카테고리'같은 부분을 보면, 알파벳 순서대로 정렬되지 않은 태그들을 볼 수 있습니다. 이런 부분들이 제게도 여전히 고민거리였죠. 과연 이것만으로 충분할지 의문이 들었습니다.
고객사에게 이런 해결책을 제시하기 전에, 저는 동료직원들에게 위의 두가지 버전을 건네주고. 총 여섯개의 아이템을 선택해보라고 말했습니다. 그리고 그 과정은 영상을 통해 기록하고있었죠. 그리고 그 영상들의 시간을 비교해보기로 했습니다.
기존 버전에서는 세명의 동료직원들이 검색과정에서 포기를 선언했습니다. 다른 두명은 시간을 넘기긴 했지만, 검색을 끝마쳤죠. 다만 그 방식은 Ctrl + F 를 통해, 직접 키워드를 검색하는 방식이었습니다. 이 실험의 결과는 제게 새로운 가능성을 열어주었습니다.
사용성 테스트로부터 배우게된 것들
저는 AB테스트를 통해, 고객사의 절반을 태그 클라우드 기반의 UI를 한달간 사용하게 했습니다. 그러나 여기에서는 이렇다할 개선이 일어나지 못했습니다. 제대로된 태그를 선택하는 확률이 올라가지도 않았고, 태그 선택의 속도 역시 크게 변화가 없었죠.
태그들을 노출해놓는 구조로 UI를 변경했지만, 데이터가 정렬되지 않은 상태였기에 별 효과가 없었습니다. 그렇기에 더 나은 개선방식을 찾아나서야했죠.
또다른 시도의 반복
개별 태그들을 노출하는것 방식이 잘못되었다고 생각하진 않았습니다. 그 아이디어를 유지하면서 기존보다 더 나은 방식을 찾아야했죠. 더 나은 개선을 위해서는 내부 데이터구조를 변경하는 과정까지 생각해봐야했죠. 그러나 그 과정은 너무 위험부담이 크기 때문에, 일단 좀더 작은 개선을 시도해보기로 했습니다.
그래서 일단 UI 디자인의 구조를 변경하여, 여러 태그들을 비슷한 연관태그로 묶어보기로 했습니다. 그리고 이런 아이디어를 바로 적용해보기로 했죠.
개선된 UI에서는 영역을 크게 나누고. 큼직한 타이틀로 영역을 구분했습니다. 그래서 사용자들이 일단 큰 타이틀을 보고, 원하는 내용을 찾을 수 있도록 개선을 했죠. 또한 동일한 컬럼에 리스트들이 깔끔하게 배치되도록했습니다. 반응형의 좌우너비를 퍼센티지로 잡아서, 위에서 아래로 읽을 수 있는 리스트 구조를 만들었죠.
일단, 개별 컬럼들은 flex 속성을 갖도록 만들었습니다. 그래서 리스트가 위아래로 쌓이는 것이 아니라. 좌우로 쌓이도록 만들었죠. columns-count:2 속성을 먹여서, 자동으로 레이아웃이 잡히도록 설정을 해뒀습니다. (Z 방향으로 쌓이는 것이 아니라, 반전된 N 방향으로 아이템이 쌓이게 만든 구조)
https://jsfiddle.net/zincsilla/402khwxf/
이렇게 만들어진 UI규격들 중에 일부는 기존의 태그보다 훨씬 긴 규격이 됐습니다. 이 경우 가시성을 떨어뜨릴 수 있다고 판단되었기 때문에, 데이터필드를 두개로 나누어 - 별도로 담도록 했습니다. 한 곳에 담게되었다면 4~5개의 아이템들이 더 들어갈 수 있었겠지만, 사용성을 위한 과감한 선택이었죠. 이후에 해당 내용을 적용해, 사용성 테스트를 진행하였습니다.
테스트 결과 분석하기
이번에도 AB 테스트를 진행하여, 고객사의 절반 그룹에 대해 - 태그 리스트 UI와, 자둥선택 규격을 사용하도록했습니다. 그리고 이 화면을 영상으로 녹화하여, 실제 결과를 확인해보았죠. 그 결과, 제 예상이 상당히 들어맞았다는걸 알게됐습니다.
전체 리스트 스크롤을 이용한 사용자들중 1.93 %만이 문제를 겪었습니다. 기존의 결과가 50%에 육박했던걸 생각해본다면, 매우 큰 변화였죠. 그러나 저는 이보다 좀더 확실한 데이터를 원했습니다. 사용자들이 개별 단계를 거치는데 얼마나 시간이 걸렸고. 또 어떤 문제들을 겪었는지를 확인하고싶었죠. 그러나 안타깝게도, 실험 도구의 기능적 한계로 인해, 우리가 원하는 영역을 확인하기가 매우 어려웠습니다.
수기입력으로 직접 통계 만들기
일단 개별 그룹과, 사용한 UI 타입을 구분하기 시작했습니다.
1) 기존 UI를 사용했던 그룹에 대해서는 개별 리스트를 선택하는 간격을 재기 시작했습니다. 그리고 선택된 태그의 양을 확인했죠.
2) 개선된 UI를 사용한 그룹에 대해서는, 개별 태그를 선택한 이후. 신규 태그를 찾아 선택하는데에 걸리는 시간을 재어봤습니다. 그리고 선택된 태그의 양을 확인했습니다.
이렇게 정리된 데이터는 구글시트에 직접 기록해서, 통계를 내는데 사용했습니다. 그리고 그 결과는 뭔가 잘못된게 분명했습니다. 기존보다 평균 약 1만초의 시간이 더 나왔다고 나왔던거죠. 시간으로 치면 약 세시간 정도를 더 사용했다는 건데, 뭔가 단단히 잘못된듯 했습니다.
저는 숙련된 분석가가 아니기 때문에, 데이터 통계와 분석방법에 대해서 좀더 알아보기로 했습니다. 데이터셋에서 불필요한 정보들을 제거하고, 문제가 되었던 부분을 찾아나가기 시작했죠. 그 결과 구글 시트에서 엑셀에서 사용하듯이, Trimmean 함수라는걸 사용할 수 있다는걸 알게됐습니다.
정리된 평균 계산을 위한 Trimmean 함수
https://secstart.tistory.com/1058
그래서 최대값과, 최소값을 제외하고, 평균치에 해당하는 데이터들을 남길 수 있었죠. 상위 20%와, 하위 20%에 해당하는 데이터는, 실제 평균을 위해 과감히 제거했습니다. 그리고 마침내, 원하던 결과를 볼 수 있었죠.
놀라운 통계결과를 확인하다
개선된 UI를 사용한 그룹은 원하는 결과를 얻기위해, 기존보다 33% 빨라진 결과치를 보였습니다. 또한 평균적으로 4개의 태그를 더 찾아내는데 성공했죠. 심지어 해당 목록이, 기존과 다르게, 새롭게 만들어진 목록이라는걸 생각할 때. 이 결과는 매우 놀라운 결과였습니다.
결론
UI 디자인이라는건 항상 정보의 맥락이 중요합니다. 예를 들어 사용자가 전 세계의 국가 목록들 중, 본인의 국가를 찾아내는건 별로 어려운 일이 아닙니다. 하지만 원하는 목록 하나를 찾기 위해 길다란 스크롤을 해야하겠죠.
만약 여기에서, 본인에게 익숙하지않은 목록들을 통해, 원하는걸 찾아야한다면. 차라리 그런 목록들을 모두 노출해버리는것이 낫습니다. 또한 그 목록들의 목록에 의미있는 타이틀을 붙여주고, 사용자들이 직접 원하는걸 찾게 만드는 것이 좋습니다. 이런 형식은 개별 아이템에 대한 확인과 선택에 큰 도움을 줍니다.
역자의 말
이 디자이너는 상당히 좋은 접근방식을 갖고있네요.
1) 주변 사람들에게 직접 테스트를 시켰다는 점
2) 이후 AB 테스트를 통해 정확한 테스트의 수치화를 진행하려했다는 점.
이 두가지는 UI / UX 개선을 위해 디자이너들이 꼭 갖고있어야할 습관이라고 생각합니다. 또한 요즘에는 사용자 사용성 확인 툴 같은게 많이 나와있어서. 해당 내용을 데이터화하기에도 매우 쉽습니다. 이런류의 설계 개선 사례와, 실제 테스트에 대한 내용이, UI 디자이너들에게도 좀더 익숙한 환경이 되었으면 좋겠네요.
국내 라이브 히트맵 서비스 - 뷰저블
해외 히트맵 서비스 - 크레이지 에그
이 내용은 UI 디자인 연구소 - 단톡방의 내부인원들을 위해 만들어진 자료입니다.
저희 단톡방은 잡담이 불가능한 방입니다. 단톡방에 들어오시려는 분은 - 이용안내문을 꼭 확인해주세요!
단톡방 이용안내
https://brunch.co.kr/@clay1987/113
