[UXUI] 부트캠프 리디자인 프로젝트 회고

플젝 시작한지 얼마 안 된 것 같은데 벌써 끝나버렸다 ...

 

2월 2일부터 시작했고 3월 6일에 끝났으니까 한 달 하고도 4일간 진행했던, 부트캠프 마지막 프로젝트가 끝났다. 지난 겨울이 어떻게 지나간지도 모르겠고 10월부터 시작했던 부트캠프도 이제 막바지를 향하고 있다니. 아쉬운 마음보다는 '아 이제부터 시작이구나' 하는 부담감이 조금씩 커져오고 있다.

 

그치만 이게 시작이라면 오히려 좋은 걸 ! UI 프로젝트에서 만난 팀원들은 무슨 말을 하든 의견을 존중해주시는 분들이어서, 나도 스스럼없이 이런 저런 아이디어를 꺼낼 수 있었다. 오히려 내가 팀에서 제일 의견 존중 안 하는 사람이었을걸... 플젝하면서 나답지않게 'T' 같다고 느껴진 적이 한 두 번이 아니었는데, 그럴 때마다 팀원들에게 상처주진 않았을까 하는 걱정이 앞서면서도 다음 날 되면 다시 싸갈스 바갈스로 변해서 굉장히 미안했다..

 

그래도 스스럼없이 의견을 마구 낸 탓에 처음으로 프로젝트의 전 과정에 내 의견이 담겨있다고 느껴졌고, 팀원들과 토론하는 과정에서 내 의견을 타당성있게 설명하는 방식도 배웠고, 아닌 건 아니라고 눈치보지 않고 말할 수 있는 용기도 배웠다. 그리고 또 처음으로 ! 업무를 주도적으로 하는 게 어떤 건지 알 것 같다는 느낌이 들었다.

 

회사에서든, 다른 팀플을 하든 나는 목소리 큰 사람이나 해당 분야를 잘 알고있다고 생각하는 사람의 의견을 무지성으로 받아들이는 편이었다. 한마디로 상사가 까라면 까는 소극적이고 수동적인 사람이었던 것이다. 그런데 이번 프로젝트에서는 달랐다. 나보다 뛰어난 분들과 함께 하면서도 그분들의 말을 곧이 곧대로 받아들이는 게 아니라, '그게 진짜 맞을까?' 하고 한 번 더 생각해본 것이다. '자아'를 갖게 되니까 팀원들과 부딛히는 일도 많아졌지만, 오히려 그 과정을 통해 더 탄탄한 결과물을 만들 수 있었다고 생각한다. 

그럼 더 까먹기 전에 회고를 해두어야겠다. 다른 프로젝트 혹은 회사에서 맡은 업무를 하면서도 이번 '틱톡 리디자인 프로젝트'를 했을 때와 같은 열정 넘치는 감정을 다시 느끼면 좋겠다. 

 

-

 

1. 애자일한 프로세스

 

이번 프로젝트에서 정말 잘했다 ! 고 생각한 부분 중 하나는 '애자일' 방식을 택했다는 거다. 덕분에 UT를 3차까지 할 수 있었다. UT를 3차까지 할 수 있어서 좋았던 이유는 우리가 가는 방향이 맞는지 확인받을 수 있는 기회가 많았던 것이다. 

 

나는 원래 무슨 일을 하든 신중하게 생각하고 판단내리는 편이었는데, 이번 일로 무작정 오래 시간을 끈다고 해서 더 나은 결과물이 나오는 건 또 아니라는 걸 느꼈다. 어차피 서비스를 써야할 대상은 우리가 아니라 사용자인데, 우리 머릿속에 있는 생각을 뱅뱅 돌리는 것 보다는 그 시간에 사용자 한 명이라도 더 만나서 이야기를 들어보는 게 효율적인 것 같다.

 

프로세스를 애자일하게 이끌 수 있었던 이유 중 하나는 매일매일 일정표를 들여다봤던 게 아닐까 싶다. 

 

 

프로젝트 시작할 때 팀장님께서 이번에는 UT를 3차까지 해보면 좋겠다고 말씀해주셨다. 그 목표에 따라서 일정을 잡고, 설령 부족한 부분이 있더라도 일정을 맞추기 위해 어느정도는 타협하고 넘어가며 유도리있게 진행됐기 때문에 일정에 맞춰 프로젝트를 마감할 수 있었다. 위 일정표는 초기에 작성한 거였는데, 프로젝트가 끝날 때 쯤의 일정표와 거~의 비슷하다. 그만큼 우리가 일정을 중시하고, 업무를 탁탁 맞춰 진행했다는 걸 알 수 있었다.

 

2. 초기 가설 설정 명확하게 하기

 

첫 번째 프로젝트 때에는 가설 설정을 다소 모호하게 했던 게 아쉬웠다. 그러다보니 이미 나온 결과를 바탕으로 가설을 역으로 작성하다보니 방향성이 흐트러지곤 했었다. 반면, 이번에는 데스크리서치할 때부터 가설을 명확하게 정의내리고, 그걸 팀원 모두가 동의하고 나서 다음 프로세스를 진행하다보니 모두가 같은 방향을 보고 있다는 게 느껴졌다. 그리고 시간이 흐른 뒤에도 '우리가 가고 있는 방향이 맞나?' 라는 의구심이 느껴질 때 가설을 되새겨보며 진단하니 한결 마음이 편했다. 

 

 

이런식으로 <우리의 방향성> 이라는 카드를 하나 만들어놓고, 거기에 팀원들이 동의한 내용에 맞게 가설 + 방향성을 붙여 넣었다. 덕분에 사소한 것 하나 결정할 때도 이게 우리 목적에 맞는 일인지 이걸 보면서 고민할 수 있었고, 내 의견이 맞다는 걸 증명할 때에도 가설을 들고와서 말하면 되기 때문에 설득력이 더 높아질 수 있었다.

 

3. 사전 설문조사

 

우리가 '다크패턴 없애기' 를 대주제로 정하고 나서 주제를 좁혀들어가기 위해 선택한 방식은 '사전 설문조사'를 돌리는 거였다. 틱톡에서 나타나는 다크패턴을 6종류로 분류한 다음, 각 항목별로 질문을 만들어 부정적인 응답이 높은 다크패턴을 골라 개선하기로 한 것이다.

 

 

다크패턴을 항목화한 것 까지는 좋았으나, 각 항목별로 들어간 질문들의 체계가 조금 부족하다는 느낌이 들었다. 우선 항목별 질문의 수가 일정하지 않았고, '부정 응답이 높다' 를 판단하는 기준이 명확하지 않았다. 예를 들면, '틱톡이 AI 생성 콘텐츠를 엄격히 필터링하지 않는 데에 거부감을 느끼나요?' 라는 질문에 대한 부정응답이 50%를 넘어가는 순간부터 '확실히 부정적인 응답이 높다' 라고 판단할 건지, 상대적으로 다른 문항보다 부정응답 비중이 높으면 '부정적인 응답이 높다' 라고 판단할 건지 정하지 못했다. 

 

내가 분석할 때는 초기에 50% 가 넘어야 '확실히 부정적이다' 라는 응답으로 받아들였으나, 결과적으로 과반수 이상 부정응답을 한 문항이 그렇게 많지 않아서 상대적으로 높은 응답을 부정응답으로 간주하고 넘어가기도 했다. 

 

실무에서도 이정도의 유연성은 보이지 않을까? 싶기도 했지만, '데이터를 다룬다'는 느낌을 받기 위해서는 분석 방식도 체계화될 필요가 있겠다고 생각했다. 

 

 

그리고 미처 확인하지 못한 치명적인 오류도 있어서 체계적으로 분석하기가 더 어려웠는데. '전혀 불편하지 않다' 척도 다음으로 '불편하지 않다' 가 나왔어야 했는데, '약간 불편하다' 가 나왔다는 것이었다. 의도한 바로는 불편함의 정도가 '보통이다' 보다 낮아야 하는데, 약간 '불편하다' 는 워딩 때문에 느낌상으로는 '보통이다'와 '불편하다' 사이에 있어야 할 것 같은 정도가 되었다. 팀원들과도 이 응답을 분석할 때, 응답자들이 '불편하다' 생각하고 해당 선지를 골랐을 것이다 VS 아니다, 선지를 그렇게 자세히 읽지 않고 위치 상으로 봤을 때 '보통이다' 이하의 수준으로 판단하고 골랐을 것이다 -> 사이의 논쟁이 있었다. 설문을 발행하기 전에는 검토를 더욱 꼼꼼히 해야한다는 걸 다시 한 번 느꼈다. 

 

 

해당 질문에도 오류가 있었다. 해당 설문 자체가 '틱톡을 사용하는 사람'인데, 또 한 번 '틱톡을 사용하는지'를 물은 것이나 마찬가지다. 그런데, 이론상으론 틱톡을 사용하는 사람만 해당 질문에 응답했어야 하니, '틱톡'을 고른 사람이 전체 응답자인 48명이 되어야 하는데 28명밖에 되지 않는다. 아무래도 응답자 전원이 틱톡을 사용하진 않았던 것 같다. 이러면 유효응답이 줄어들 수 밖에 없는데... 물론 이후에 응답자가 더 모여서 유효 응답 수가 해당 자료를 '정량적 자료'로 쓸 수 있을 정도로는 모였지만, 이렇게 되면 데이터가 희석되어 정확한 판단을 내리기 어렵게 만들 것 같다. 

 

4. UT 제작

 

이번 프로젝트에서 UT를 3번이나 진행한 만큼 가장 많은 인사이트를 얻은 파트도 이곳이다. UT를 직접 진행해봤을 뿐만 아니라, 다른 조 분들의 UT에 응답자로 참여하기까지 해서 더 많이 배울 수 있었다. 

 

[3번의 UT 진행 방식]

1차 UT - 기존 틱톡에서의 불편함 발견 / 응답자의 기존 틱톡 화면을 공유하여 태스크를 읽어주고, 실행하는 모습을 직관함

2차 UT - 1차 리디자인 틱톡에서의 기능 검증 / 메이즈를 제작하여 응답자의 화면 공유 후 UT 진행

3차 UT - 2차 리디자인+리브랜딩 틱톡에서의 기능 및 인식 검증 / 메이즈를 제작하여 응답자의 화면 공유 후 UT 진행

 

 

1) UT 진행 전에 답변 양식을 만들어두기

 

질문에 맞게 팀원 분이 답변 양식을 만들어주셨다. 처음에는 해당 양식이 있어 단순히 인터뷰 내용을 받아 적기에 편리해졌다고만 생각했는데, 이후 응답을 분석하는 과정에서 한결 수월하다는 걸 알게 됐다. 왜냐하면 답변 별로 참여자들의 응답을 분류하는 작업을 거칠 때, 해당 양식 없이 진행했던 2,3차 UT에서는 AI를 이용해 응답을 한번 더 필터링하는 작업을 거쳐야 했기 때문이다. 처음부터 답변을 질문별로 나누어 작성했다면 필터링 과정이 더 수월했을 거라고 생각한다.

 

2) 질문 리스트를 따로 만들어두기

 

이것도 후에 AI를 사용해 분석할 때 필요한 자료다. 메인 질문과 하위 질문을 함께 병기해두니, 총 몇 개의 질문을 하는지 파악이 되지 않았다. 질문 자체를 검토하는 시간도 첫 번째 프로젝트보다 짧았는데, 그래서인지 실전 UT 를 진행하면서 '이런 것까지 꼭 물어봐야 하나?' 싶은 질문도 있었다. 팀원들과 함께 논의해서 만든 질문이기에 질문지에 있는 내용은 무조건 다 물어보긴 했으나, 진행자 입장에서는 프로페셔널하지 못하다고 느껴졌다. 물론 실무에 뛰어든 적이 한 번도 없는 내가 벌써부터 프로를 따라하려는 것 자체가 웃기지만, 응답자를 피곤하지 않게 배려하는 것도 진행자의 일이라고 생각해서다. UT 경험을 더 많이 쌓아서 꼭 필요한 것만 물어볼 수 있도록 질문 짜는 능력을 개발하고 싶다.

 

3. 척도를 넣은 질문은 한정적으로 하기 

 

정성적 응답을 정량 데이터로 바꾸기 위해 어떤 느낌에 대한 정도를 1점부터 10점까지로 매겨서 응답해 달라는 질문이 꽤 많은 프로젝트였다. 그럴 수 밖에 없다고 생각한 건, 응답자들이 생각하는 난이도나 신뢰도 따위의 추상적인 느낌을 그나마 객관적으로 전달받기 위해서는 점수를 통해 나타내달라고 요청하는 방법밖에 없다고 생각했다. 1차 때는 약 7개, 2차 때 10개, 3차 때 8개의 척도 질문이 있었다. 특히 2차 때에는 한 테스크에 3개의 척도 질문이 연달아 나와서 응답자들이 곤란했을 것 같다.

 

척도 질문을 한정적으로 해야한다고 주장하는 이유는 역시 응답자들의 피로도를 줄이기 위함이다. 실제로 지인에게 UT 를 진행하다가 척도 질문을 연달아 하면서 '이번에도 점수로 나타내주면 좋겠는데~' 라고 운을 떼자, 살짝 곤란해하는 표정으로 '아, 이것도?' 라는 반응이 돌아왔다. 그때 처음으로 응답자들이 추상적인 걸 점수로 나타내는 걸 어려워하겠구나 하는 생각이 들었다. 그러고보니 나도 다른 팀의 UT 참여자로 질문을 받았을 때, 점수를 매겨달라는 질문 앞에서 꽤 오랜 시간 고민하기도 했다. 

 

그래서 이번 프로젝트의 가장 큰 지표였던 '신뢰도' 와 '난이도' 를 제외하고는 되도록 척도 질문을 넣지 않았어야 한다고 본다. 실제로 척도형으로 질문을 하고 데이터를 수집한 다음에 유의미하게 사용된 질문은 일부였다. 사용되지 않은 질문들은 굳이 척도형으로 응답을 수집할 필요가 없었다고 생각한다. 물론 데이터를 분석하다보면 프로젝트가 진행됨에 따라 필요한 지표가 바뀌기도 하기 때문에 되도록 많은 데이터를 수집해둘 필요도 있다고 생각한다. 그럼에도 가능하다면 경험을 많이 쌓아, 깊은 분석이 필요할 것 같지 않은 데이터들은 사전에 질문 형식을 간소화해서 응답자들의 피로도를 낮출 수 있으면 좋겠다.

 

4. UT 응답을 보며 팀원 모두가 아이디어 내기

 

 

UT를 마친 이후에는 질문별로 응답을 모아서 함께 분석하는 시간을 가졌다. 나는 프로젝트를 통틀어서 이 시간이 세 손가락 안에 드는 중요한 일이었다고 생각한다. 이전 프로젝트에서는 설문 응답이나 UT 응답을 제대로 살펴볼 기회가 적었었던 게 아쉬웠다. 열심히 UT를 했음에도 결과물을 보면 '여기에 사용자들의 의견이 반영된 게 맞나?' 하는 의문이 들었기 때문이다. 

 

그치만 이번에는 달랐다. 설문조사든, UT든 매번 사용자의 목소리를 듣고 온 이후에는 팀원들이 모두 모여 인사이트를 나눴고 그 결과를 바탕으로 리디자인할 요소를 정했고 기능을 업그레이드했다. 첫 번째 프로젝트에서 사용자 응답 사용률이 40% 정도였다면, 이번에는 80%까지 끌어올렸다고 할 수 있다. 

 

나머지 20%는 UT 참여자가 테스크를 수행하기 위해 터치하는 요소들의 순서를 녹화본을 보고 조금 더 분석해봄으로써 멘탈모델에 대해 더 알 수 있지 않았을까 하는 점이 있다. 그리고 절대적인 시간이 부족했기 때문이지만 응답하거나 테스크를 수행할 때 참여자의 표정이나 말투에 관해 조금 더 생각해봤더라면 기능을 사용할 때의 유저들의 감정을 조금 더 알 수 있지 않았을까 하는 아쉬움이 따른다. 그치만 그것까지 하려면 시간이 좀 더 충분했어야 했고, 자료조사도 논문 찾아보면서 더욱 세밀하게 했어야 했기 때문에 한 달이라는 한정된 시간 안에 80% 채운 것으로 만족한다. 

 

5. 신뢰도는 검증된 질문으로 묻기

 

마지막 날에 실무자 분 앞에서 프레젠테이션을 하고 받은 피드백 중 하나는 전혀 예상치 못했던 데 있었다. 바로 '신뢰도' 를 측정하는 문항이 공식적이지 않았던 것. 단순히 비공식적인(우리가 만든) 문항을 사용해서가 아니라, 신뢰도와 같은 추상적 개념을 측정할 때에는 이미 연구를 통해 검증된 질문들을 사용하는 게 더 설득력있게 보일 수 있다는 것이다. 

 

그 피드백을 받고 나니 알 것 같았다. '이 브랜드에 대해 신뢰하시나요?' 라는 질문이 정확히 브랜드의 어떤 면을 신뢰한다는 건지 사용자 입장에서는 모호하게 느껴질 수도 있겠다는 거였다. 그래서 우리 팀은 공신력 있는 지표를 활용해 만든 설문조사를 다시 한 번 UT 참여자 분들께 돌리려고 한다. 원래 SUS(System Usability Scale) 지표를 활용하려고 했으나, 우리 팀의 북극성 지표는 '신뢰도' 이기에 브랜드 신뢰도와 관련된 지표를 찾아보려 한다. (찾은 후 업데이트 예정) 

 

6. Maze는 최대한 단순하게 제작하기

 

우리팀은 UT를 3차까지 했고, 더 넓은 타겟을 대상으로 한 매스테스트까지 진행했기에 메이즈 파일이 4개나 된다. 매스테스트는 틱톡을 이용해본 사람과 이용해보지 않은 사람을 나누어서 정보를 수집했기에 총 2개의 파일을 만들어 진행했다. 

 

이렇게 여러 파일을 만들고, 다른 팀 분들의 UT에 참여하면서 느낀 점을 정리해본다.

 

1) UT 테스크는 간단해야 한다

테스크가 길어지면 그걸 다 읽고 이해하는 데 시간이 오래 걸리더라. 겨우 다 읽고 테스크를 진행하려 하면서도 테스크가 뭐였는지 계속 상기하게 되어서 정작 중요한 화면에 집중하지 못하는 날 발견했다. 

 

2) UT 질문은 최대한 직관적으로, 추상적인 개념을 묻는 질문은 최소화한다

우리팀의 북극성지표가 '신뢰도' 였기 때문에 UT 때 신뢰도를 묻는 질문이 필수로 들어가야 했는데, 난 항상 질문'하는' 입장이었으니 거기에 답변해야 하는 사람의 입장을 미처 헤아리지 못했다. 내가 인터뷰이로 참여했을 때 비슷한 질문을 받았는데, 뭐라고 대답해야할지 자꾸 고민하게 되었다. 물론 신중하게 생각해야 유의미한 답변을 해줄 수 있다는 점에서는 나쁘진 않지만, 그렇게 신중히 생각해야하는 질문 수가 늘어나면 인터뷰이 입장에서는 에너지를 많이 써야할 것 같다는 느낌이 들었다. 

 

3) 화면에 관해 질문하려면, 화면을 보여주면서 해야 한다

질문 중에 '아까 보신 ~화면에서 ...' 로 시작하는 것들이 있었는데 참여자가 화면을 잘 기억하지 못할 것 같다는 게 내 생각이다. 왜냐면 내가 인터뷰이로 참여할 때 그랬으니까...^^ 그래서 이미지로 화면을 다시 보여주던지, 아니면 질문용 테스크를 따로 파서 화면을 탐색하면서 질문을 받을 수 있도록 하면 좋겠다고 생각했다. 

 

(쓰다보니 너무 길어질 것 같고 바빠서 지금 당장 다 쓰지도 못할 것 같아서 계속 내용을 덧붙이려 한다)