[UXUI] 부트캠프 UX 팀프로젝트 회고

첫 UX 프로젝트가 끝났다. 

 

엄밀히 말하면 아예 끝난 건 아니고 UT 결과와 피드백을 토대로 수정해야 하지만... 그래도 일단은 1차 MVP를 뽑았다는 데에 의의를 두기로 한다. 프로젝트를 하면서도 틈틈히 회고를 쓰고 싶었으나 팀원 개개인을 통해 배운 일들이 많았어서 공개된 블로그에 언급하기가 조금 망설여졌다. 그래서 노션에만 회고록을 적었고, 그마저도 프로젝트 마지막 1주일은 바빠서 적지 못했다. 2026년은 기록을 많이 하는 한 해로 보내고 싶었는데 신년부터 그러지 못한 것 같아 아쉽지만, 그만큼 프로젝트에 열심히 참여했다는 의미이기도 하니까 지금부터라도 다시 잘해보려고 한다. 

---

배운 점

 

1. 가설 세우기

가설은 팀원들이 같은 방향을 바라보게 하는 가이드 역할을 한다. 

 

서비스의 방향을 어디로 향할 것인지는 가설을 통해 정해진다. 그렇기에 프로젝트를 진행하는 내내 우리는 가설을 염두에 두어야 한다. 하지만 가설은 고정된 값이 아니라 프로젝트를 진행하며 검증되는 사실에 따라 바뀌어야 한다. 1차 가설을 세운 이후 설문조사를 통해 검증하고, 조사 결과에서 인사이트를 뽑아서 다시 2차 가설을 세운다. 이걸 심층인터뷰에서 또 한번 검증하고, 그 결과를 바탕으로 솔루션을 설계한다. 솔루션을 기반으로 MVP를 제작한 다음 UT를 진행하고, 3차 가설을 세운다. 이걸 2차 UT를 통해 검증하던지, 혹은 포트폴리오 말미에 '우리가 마지막으로 이런 가설을 세웠으니, 이후에는 이걸 반영해보겠다' 는 식으로 넣고 마무리해야 한다.

 

한 가지 실수한 게 있다면 설문지를 설계하기 이전에, 가설을 세운 다음 그걸 검증하기 위한 질문을 설계했어야 하는데 반대로 했다는 점. 다행히 데스크 리서치 이후 세웠던 서비스의 예상 솔루션과 설문 결과 사용자가 필요로 하는 기능이 어느정도 일치한다고 판단하여 크게 문제되는 상황 없이 기획을 진행할 수 있었다. 

 

이 밖에도 가설을 세울 때 주의해야할 점을 기록해둔다.

1) 가설은 구체적일수록 좋다. 5whys 기법을 통해 구체화 해보자.

2) 팀원들이 각각 내놓은 가설들 중 우선순위를 정해야 한다. 

 

2. 설문지 설계하기

질문을 설계할 때는 해당 질문을 통해 '무엇을 알고자 하는가?' 를 명확히 해야 한다.

 

이번 프로젝트의 주제는 '영양제 섭취' 와 관련이 있었는데, 초기 설문에 '비싼 영양제를 먹고 효과를 느끼셨나요?' 와 같은 질문이 있었다. 이 질문을 보고 선생님은 뭘 얻기 위해서 이런 질문을 한 것인지 물어보셨다. '비싼 영양제' 의 경우 가격대를 산정하는 수준은 주관적이고, '효과를 느꼈냐' 는 표현도 주관적이기 때문에 얻게 될 응답 결과가 유의미하지 않을 거라는 피드백이 있었다. 더불어 응답 결과물은 수치화할 수 있는 데이터여야 하는데, 응답이 주관적이면 수치화하기가 어려워진다. 따라서 응답자가 어떻게 느꼈는지보다, '어떤 조합으로 먹었는지' 등 수치화할 수 있는 데이터를 물어봐야 한다.

 

이 밖에도 질문 설계와 관련된 여러 피드백을 받았다.

1) 선지 답변의 다양성이 필요하다. (ex. '현재 섭취 중인 영양제 성분을 이해하고 있으신가요?' -> 해당 질문에 '예/아니오' 로 응답하게끔 설계해두었는데, '아는 것'에도 정도의 차이가 있기 때문에 '전혀 모른다/조금 안다/필요한 만큼 안다/잘 안다' 등으로 수준을 나누어서 응답을 받을 수 있게끔 설계해야 할 것 같다.

2) 용어 혼용을 지양한다. (ex. '챙겨드시는' / '복용하는' 용어를 혼용해서 쓰지 말고 하나로 통일한다.)

3) 같은 질문을 하더라도 얼마나 디테일하게 설계하느냐에 따라 얼마나 자세한 결과가 나오는지가 결정된다.

4) 어떤 데이터를 얻기 위해서 질문하느냐를 인지하고 있어야 한다.

5) 질문에 '기간의 범위(ex. 6개월)' 가 들어간다면, 왜 그 기간으로 설정했는지에 대한 근거가 있어야 한다.

6) 목적이 있다면 활용 계획도 있어야 한다. 얻은 데이터를 통해 어떤 결론을 내릴 수 있을 것인지 생각해두어야 한다.

7) 자기 몸에 대해 묻는 질문은 예민하다. 응답자가 답변할 때 어떻게 생각할지에 대해서도 고민하고 답변을 설계해야 한다. (-> 해당 피드백은 우리가 '영양제' 라는 건강 관련 주제를 다루기 때문에 나온 피드백인 것 같다.)

 

3. 심층인터뷰

인터뷰할 때도 목적이 있어야 한다. 이번 인터뷰를 준비하면서 내가 그동안 얼마나 목적성 없이 인터뷰를 준비하고 진행했는지를 알게 되었다. 

실제 인터뷰에서도 질문을 약 20여개 했는데, 질문 설계하면서 뺀 질문만 이만큼이 나왔다.

 

질문을 설계할 때부터 약간 난관이 있었는데, 인터뷰를 진행해야겠다는 생각에만 몰두해서 무작정 질문을 짜고 있었기 때문이었다. 그나마 UX 이론 공부할 때 배웠던 '(심층 인터뷰의) 주요목표, 세부목표, 그리고 핵심 연구질문'을 작성한 뒤에야 방향성을 잡을 수 있었다. 그리고 이러한 목표와 핵심 질문은 설문조사가 끝난 이후 정립한 2차 가설을 토대로 세웠다. 

 

내가 우리팀에서 첫 타자로 무려 선생님을 인터뷰하게 되었는데, 인터뷰 질문지를 작성할 때랑 실제로 대화를 나눌 때는 천지차이라는 걸 알게 되었다. 우선 우리가 설계한 질문의 흐름대로 답변이 나오지 않는 경우도 있었고, 쿠션멘트는 싹 다 빼고 질문지를 만들었다보니 쿠션어까지 덧붙이면서 다음 질문을 하는 게 여간 쉽지 않은 일이었다. 쿠션멘트는 그렇다 쳐도, 다음에 인터뷰 질문을 설계할 때는 답변을 예측해서 답변에 따른 질문 흐름을 짜보는 것도 좋을 것 같다.

 

그 밖의 피드백

1) 비슷한 카테고리의 질문을 몰아서 하기. 섭취 관련 / 영양제 구매 관련 / 성분 관련 질문이 있을 때, 각각의 카테고리 질문을 섞어서 하면 인터뷰이 입장에서 혼란스러울 수 있으니 섭취 관련 질문은 한 번에 하고 그 다음 카테고리로 넘어가는 식으로 질문 순서를 짜야 한다.

2) 질문지가 정리된 이후에 팀원들이 생각한 가설에 맞게 예상 답변 적어보기. 예상과 실제의 차이가 얼마나 날지를 판단해보는 활동으로 좋다. -> 우리는 서로가 서로한테 질문해보고 예상 답변을 적어본 다음 질문 내용이나 흐름이 어색하지 않은지 판단해보는 시간을 가졌다.

3) 인터뷰 해주신 선생님께서 '근데 이 질문들로 뭘 알고싶어 하는지 궁금하긴 하네요' 라는 말을 인터뷰 말미에 해주셨다. 그 당시에는 우리가 놀랄까봐 프로젝트가 어떤 방향으로 흘러갈지에 대한 궁금증이라고 뭉뚱그려 말씀해주시긴 했는데, 지금 생각해보면 연구의 목적이 질문에 제대로 녹여져 있지 않거나, 인터뷰를 통해 너무 많은 것들을 알아보고자 한 게 아닐지 하는 의문이 든다. 

 

4. 디자인 시스템

팀작업할 땐 디자인 시스템이 무엇보다 중요하다.

 

원래도 UI 화면을 만들 땐 디자인 시스템을 정하는 게 중요하긴 한데, 개인 프로젝트 할 때는 이정도까지 신경쓰진 않았다. 그래서 피드백으로 여백이 불안정하다는 말을 들었을 테지만.. 폰트나 컬러 시스템을 통일하는 것부터 시작해서 패딩값도 통일하고, 컴포넌트 스타일도 통일해야 했는데, 우리만의 '규칙'을 정한다는 측면에서 디자인 초안만 잡아두고도 스타일을 적용하면 금세 우리 서비스 색깔을 입힐 수 있다는 데에는 편리함을 느꼈다. 반면, 그 규칙을 정하는 데 매번 논의가 필요했으며 혼자서 일할 땐 무작위적으로 작업했던 나로서는 약간의 번거로움이 느껴졌다.

 

제일 힘들었던 파트는 컴포넌트 이름을 정하는 거였는데. 우리는 노션 시트에 각자가 정한 컴포넌트 이름을 업로드해두고 네이밍할 때 참고하는 정도로 작업했지, 네이밍 '규칙' 까지 논의하진 않았다. 이미 만들어둔 요소에 이름을 붙이며, 그 이름을 일일이 시트에 옮겨적고 있는데 처음으로 '못하겠다..' 는 생각이 들었다. 다음부터는 그런 생각이 들지 않게끔 나만의 네이밍 규칙을 미리 정해두고, 어떤 프로젝트를 진행하든 요소를 처음 만들 때부터 내가 정한 규칙을 적용해두어야겠다. 

 

5. UT

사용자의 목소리를 담아야 한다.

 

프로젝트 발표까지 이틀 정도 남았을 무렵.. 드디어 MVP 페이지를 모두 완성했고 팀장님과 함께 UT 준비를 했다. 후다닥 만든 UT를 어떻게든 최종 발표에 집어넣고 싶어서 바로 다음날 인터뷰를 도와줬던 친구에게 요청했다. 그런데... 너무 어려웠다는 대답이 들려왔다. 결국 태스크 3개 중 2개를 스킵할 수 밖에 없었다고 한다.

 

친구가 이전까지 접해보지 않은 신규 서비스이기에 어떤 기능이 어디에 있는지 정확히 알지 못해서 벌어진 결과라고 생각했다. 나야, 화면 설계자니까 익숙할 수 밖에 없어서 당연히 친구(사용자)도 우리가 정한 시나리오를 문제없이 따라올 수 있을거라 생각했던 게 큰 오산이었다. 

 

출처 : 토스 앱

오늘 핸드폰 갤러리를 뒤져보다가 발견한 토스 앱의 UT. 시나리오가 간결하고 깔끔하다. 물론 토스 앱 사용자를 대상으로 진행한 거고, 이 요청을 받은 대부분의 사람들이 토스의 기능들이 대충은 어디에 있는지 알 것이기 때문에 아예 신규 서비스인 우리와는 비교할 수 없다고 생각한다. 그치만 다음에 진행할 때는 시나리오를 좀 더 간결하게 짜보면 좋을 것 같다.

 

그리고 대망의 발표 시간.. 선생님께서 초대해주신 현업자 분께 완전 탈탈 털리고 말았다. 그 중 기억에 남았던 피드백은 화면을 왜 이렇게 구성했는지, 사용자가 이렇게 해달라고 한 건지를 묻는 질문이었다. 설문조사와 심층인터뷰를 바탕으로 기획한 페이지였음에도 그 물음에 쉽게 대답하기가 어려웠다. 현업자 분은 포폴 화면을 AS-IS / TO-BE 형식으로 구성해서, 기존 화면과 UT 후 개선한 화면을 함께 나타내면 설득력 있을거라고 말씀해주셨다. 다음부터는 MVP 를 조금 더 빨리 뽑고, 사용자의 의견을 반영해서 AS-IS / TO-BE 화면을 구성해야겠다. 왜 스타트업에서 '린' 방식으로 업무 프로세스를 진행하는지 알 것 같았다. 

 

UT 때 받은 추가 피드백

1) 질문들(가설들)을 검증해온 과정들이 구체적으로 드러나면 좋을 것 같다.

2) 필라이즈 같은 경쟁사앱 조사한 내용을 넣어보면 좋을 것 같다. 경쟁사 앱과 우리 앱의 차별점(기능, 비용 등)이 무엇인지 등

3) 페르소나 다음에 유저플로우를 넣어봤으면. 유저가 구매까지 가는 과정에서 어떤 부분에서 막혔을지, 그리고 그 막힌 부분을 우리 솔루션이 어떻게 해결해줄 수 있을지 등을 설명해주면 좋았을 것.

4) 실현 가능성을 보여줘야 함. ex. 알약 크기 데이터를 어디서 가져올건지 혹은 어떤 서비스에서 이런 데이터를 게재하고 있기 때문에 실현 가능하다~ 는 걸 보여줘야 함. 법률적으로도 문제 없는지 등 서비스에 대한 신뢰성을 보강해주면 좋을 듯

5) 사용자가 원했던 기능인지를 보여줘야 함

6) 우리 PB 상품을 구매하면 뭐가 더 좋아질지 (비용 절감, 영양수치 증가 등) 보여주면 더 좋을 것.

---

문제점, 개선해야할 점

 

1. 스케줄 짜기

스케줄을 짜면 얼타지 않을 수 있을까?

 

물론 우리 팀은 그때 그때 해야할 일들을 적어두고 작업을 진행하긴 했지만 전반적인 타임라인이 없었어서 한 가지 작업이 끝나면 그 다음에 뭘 해야할지 살짝 우왕좌왕 하는 시간이 가끔 있었다. 프로젝트마다 적용해야 할 방법론이 달라지겠지만, 프로젝트마다 보편적으로 적용할 수 있는 스케줄을 대략적으로 짜놓고 시작하면 이런 점이 조금 보완되지 않을까 싶다.

 

2. 피드백 수용하기

맞든 틀리든 일단 들어봐 !

 

우리 아부지는 항상 내게 말씀하셨지... 사람이 말을 하면 좀 들으라고... 팀 작업을 할 땐 가족이 아니라 타인이니까 당연히 말을 듣기는 한다. 그런데 가끔 감정이 상해버릴 때가 있다... 왜그럴까... 나에 대한 비판으로 받아들여서 그럴지도 모른다는 생각을 한다. 팀원의 피드백을 작업물의 퀄리티를 올릴 수 있는 기회로 바라보는 연습은 좀 더 필요할 것 같다.

 

3. 질문하기

질문은 미리미리 준비해두기. 없으면 만들어서라도.

 

선생님들께서 우리 팀으로 순회오실 때 제대로된 질문을 한 적이 손에 꼽는다. 그럴 때마다 매번 피드백 받을 기회를 놓쳐버리는 것 같아서 아쉬운 마음이 들었다. 왜 질문할 거리가 없었을까? 를 생각해보면 '내가 하고 있는 방식이 맞는 것 같아서' 라고 답할 것 같다. 혹은 '내가 틀릴 거라는 의심을 하지 않아서' 일지도 모른다. 의심을 하면 프로젝트 진행하는 데 시간이 지체되는데... 그럼에도 조금이라도 의심되는 부분이 있다면 짚고 넘어가는 게 맞는 거겠지?

 

4. 내가 경험해보지 못했다고 해서 '틀렸다' 는 생각 버리기

오픈 마인드로 의견 수용하기

 

나는 평소에 굉장히 오픈 마인드라 자부하는 사람인데... 나도 사람인지라 편협하게 생각할 때가 있나보다. 뭐였는지는 기억이 안 나는데 한 팀원이 무언가 얘기했을 때 속으로 '꼭 그렇진 않을 것 같은데...?' 라고 생각한 적이 있었다. 그런데 얼마 후 스레드에 '영양제'를 검색해보다가 그 분이 말씀하셨던 내용이랑 유사한 내용의 글이 올라와 있는 걸 보았고, 그 글에 좋아요가 꽤 많이 눌려있던 걸 발견했다. 다른 사람의 의견을 들으면 판단보다 수용이 앞서야 한다는 걸 배웠다. 판단이 앞선다면 좋은 아이디어도 묻힐 위험이 있기 때문이다.

 

5. 포트폴리오 카피라이팅

장표의 메인 메시지는 하나의 문장처럼 의미가 이어져야 한다.

 

카피 쓰다가 이렇게 창피했던 적은 처음이었다. 내 카피가 팀장님의 손에서 새롭게 탄생(?)했기 때문이다. 팀장님이 쓰신 카피는 무지 설득력있고 한 번 쓱 훑어보기만 해도 해당 장표가 뭘 말하려고 하는지 한 번에 파악되는 힘이 있었다. 이래놓고도 UX 라이팅 관심있다고 말하고 다녔던 게 정말 창피했다. 패키징이 끝나고 팀장님 카피 뿐만 아니라 다른 포폴에 쓰이는 카피들을 모조리 긁어다가 분석해볼 작정이다.

---

잘한 점

 

1. 수동적인 태도 버리기

주도적으로 하는거, 그거 어떻게 하는 건데! 그치만 맛은 봤다.

 

개인 프로젝트가 끝나고 팀 작업을 한다는 말을 들었을 때 제일 크게 걱정한 부분이었던 건 나의 '수동적인 태도' 였다. 그나마 팀장을 맡을 땐 덜했던 것 같은데 팀원으로 들어가면 항상 누가 시켜주는 일을 하는 게 문제였다. 그래서 이번에는 그러지 않도록 그 다음으로 해야할 프로세스도 먼저 제시해보고, 주도적으로 나서서 의견을 말했다고 생각한다. (물론 팀원들의 의견은 다를 수 있음...) 다른 팀원들을 보면 완전히 주도적으로 프로젝트를 이끌기에는 시간이 더 필요할 것 같긴 하지만.. 이번 프로젝트에서는 적어도 내게 일이 주어질 때까지 기다리지 않고 나서서 찾았다는 점에서 조금은 성장했다고 봐도 되겠지?

 

2. 적극적으로 팀원의 도움이나 의견 구하기

모르는 건 모르겠다고 말하기

 

내가 잘 못하는 것 두 번째... 질문하기. 나는 질문하는게 조금 두렵다. 첫 번째로 너무 당연한 걸까봐. 두 번째는 질문 받는 사람의 시간을 낭비하게 될까봐. 그리고 가끔 질문하려다가 '내가 조금 더 찾아봐야지' 하고 찾아보다가 답을 알게되는 경우도 있어서 질문거리가 떠오르면 일단 삼키고 봤던 것 같다. 그런데 이번 프로젝트는 기간이 타이트했고, 내가 답을 못 찾아서 속이 터질 것 같아서 먼저 '저 이거 이해가 안 가요!' 라고 솔직하게 털어놨던 적이 있다. 그때 팀원들은 바로 나에게 달려와주었고, 머리를 맞대니 문제 상황에서 금방 벗어날 수 있었다. 그 이후로도 몇 번 외치듯 도움을 요청했던 적이 있는데 잠깐의 토론 만으로 문제가 해결되는 걸 보고, 내가 괜히 끙끙 앓으면서 시간 낭비할 게 아니라 물어보면 금방 해결되는구나 라는 걸 알게 됐다. 앞으로 더 많이 질문해야지.

 

3. 점수 설계하기

서비스에 신뢰감 부여하기

 

우리 서비스의 메인 기능 중 하나는 사용자가 건강을 잘 챙기고 있는지의 정도를 점수로 보여주는 것이다. 추상적인 현상을 점수로 수치화한다는 아이디어까지는 좋았으나, 그 점수가 어떻게 추산되는지가 명확하지 않으면 까다로운 사용자들의 신뢰를 얻지 못할 거라고 생각했다. 실제로도 심층 인터뷰를 했을 때 어떤 분은 직접 영양성분을 엑셀 표에 정리하시는 분도 계셨고, 내 몸에 들어가는 거니까 당연히 직접 A~Z 까지 알아보고 구매해야한다고 주장하는 분도 계셨다. 

 

점수를 설계하기 위해 제미나이를 활용해서 '영양 밸런스 + 가성비 + 꾸준함 + 섭취 방법' 이라는 4가지 기준을 세웠고, 각각의 기준에 따라 점수가 합산되어 최종적으로 건강 점수를 대시보드에 띄워준다고 설정했다. 다만 아쉬운 점은 시간 부족으로 각각의 기준에 따라 점수가 어떻게 매겨지는지 구체화하지 못했다는 점이다. 예를 들어, 영양 밸런스라고 하면 어떤 성분이 기준치를 초과했을 땐 몇 점이 감점되고 ~ 이런 부분들을 자세히 설계하지 못했다. 이후에 프로젝트를 보완할 때는 이 부분을 좀 더 구체화하고 싶다. 아직 미완성이지만 '사용자의 신뢰' 와 같은 감정적인 부분을 고려했다는 점에서 '이런 게 바로 UX 디자이너..?' 하는 기분을 맛볼 수 있어서 좋았다.

---

UX 를 공부하기 시작한 이래로 처음으로 진행한 팀 프로젝트였다. 그만큼 많이 해매기도 했지만 좋은 팀원들을 만나서 이정도 결과물을 낼 수 있었다고 생각한다. 나 혼자 했더라면 또 어물쩡 넘어갔을 텐데 이번엔 결과물다운 결과물이 나왔기 때문이다.

 

이건 조금 딴 얘기지만 테니스를 칠 때 선생님과 랠리만 하면서도 '실력이 늘고 있다' 고 생각한 적이 있었다. 자신만만해서 레슨을 시작한지 얼마 되지 않은 엄마, 동생과 함께 미니 테니스 경기를 할 땐 공을 제대로 치지도 못했다. 우물 안 개구리가 되어서는 내 실력이 어느정도인지 가늠할 수가 없으니 최대한 여러 사람과 부대끼며 실력을 검증하고 키워나가야 한다. 이번 팀 프로젝트에서도 비슷한 기분을 느꼈다. 개인 프로젝트를 잘 마무리한 건 아니지만 그래도 어느정도는 UXUI에 대해 알게 되었다고 생각했는데, 팀 작업을 하니 나는 거의 아무것도 모르는 거나 마찬가지였다. 앞으로도 자만하지 말고 '난 아무것도 모른다'는 태도로 배움을 멈추지 말아야겠다.