[가르디/디자이너] 사이드프로젝트에서 UI/UX 디자이너가 해온 것들 (1) Ideation & 기획과 UX 그 사이 어딘가

나름 팀 내 유일한 100% 디자이너로서 사실 디자인 관련 주제를 회고로 쓰고싶었습니다. 하지만,, 진짜 시작했다가는 대서사가 될 것 같은 직감에 고릿짝 시절 회고를 썼으나, 피할 수 없는 압박(?)이 들어와서 써보려고 합니다.

4년의 디자인 여정을 담는건 정말 쉽지 않네요. 미리미리 써둘걸.. 싶지만 돌아가봤자 안쓸걸 알기에 후회는 하지 않겠습니다.

 

 
 
참고로 저는 그래픽을 전공하지도, 미술을 배운 적도 없는 디자이너였습니다. 그냥 평범한 정도의 미적 감각을 가진 "일반인" 입니다. 그런 제가, 4년간 하나의 앱을 (그것도 사이즈가 꽤나 큰) 디자인하면서 해 온 일들에는 어떤것들이 있는지, 그 과정에서 잘한점과 부족했던 점에는 뭐가 있는지, 써보려고 합니다.
 
본격적인 시작 전에,
이 글을 누가 볼지는 모르겠지만, 아래 내용을 꼭! 인지하고 읽어주세요.

• 사이드 프로젝트에서, "디자이너"가 해야하는 역할은 팀의 사정에 따라 다릅니다. 디자이너가 여러명이라 분업이 잘 되어있을 수도 있고, 각자의 능력에 맞는 역할을 충실히 하는게 중요합니다. 무언가를 못했을 때, 시간과 노력을 투자해서 새로운 능력을 키우는 방법도 있지만, 새로운 사람을 영입한다던가, 프로젝트의 목표를 과감히 축소시킨다던가 방법은 다양합니다.

 
 

1. 누군가 아이디어를 주면 UX를 그려내는 일

: 처음에 저는, 꽤나 수동적인 UX를 했습니다. 언니들 사이에 들어온 막둥이로서, 뭔가 제안을 한다기 보다는 시키는 일을 했던거 같아요. 아무래도 어느정도 앱의 틀이 잡힌 상태에서 들어왔기 때문에, 이미 기획된 내용을 구체화하는 일을 많이 했습니다.

프로젝트 초반이 특히 아이디에이션이 많았는데, 당시 이미지는 많이 삭제되어서 아쉽게도 어느정도 틀이 잡혀있을 때의 예시뿐인데요. 원하는 기획이나 디자인이 있는 기획자/개발자가 왼쪽과 같이 손그림으로 이미지를 주면, 오른쪽처럼 구체화 하는 일을 했습니다. 물론 그 사이에 해당 화면에 필요한 정보의 구조를 짜고, 와이어 프레임을 그리고, 디자인을 입히는 등 수 많은 과정을 거쳤습니다.

당시 잘 했던 점을 되짚어 보자면 거듭된 학습(?) 끝에 팀원들 언어 해석 능력에 능통해졌습니다. 아무래도 애정을 기반으로 프로젝트에 집중하다 보니, 팀원들의 의사 소통 방식에도 집중을 많이 했던거같습니다. 또, 백지 상태에서 시작한 첫 사이드프로젝트였기 때문에 "왜 저렇게 말해?" 라는 생각을 하기 보다는 말 자체를 해석하는데에 노력을 했습니다. 한편으로는 언니들이었기에 본능적인 쫄보모드가 나온거같기도 하지만, 뭐 덕분에 환상의 케미를 자랑하는 개발자와 디자이너가 되었으니까요.
 

 
개발자랑 디자이너가 많은 대화를 나누면 이렇게 블루투스식 소통이 가능해집니다.
 
추가로, 저는 덜렁대고 꼼꼼하지 못한 제 특성을 잘 알고 있기 때문에, 디자인 시작 전에는 (1) 화면/기능에 필요한 정보/컴포넌트들을 먼저 나열하고, (2) 함께 있어야하는 정보끼리 묶고 (3) 이를 구조화하는 순서대로 작업을 했습니다. 물론 이렇게 해도 놓치는 부분이 없진 않았지만, 중간중간 개발자와 기획자에게 검토를 받으면서 진행했던게, 꽤나 좋은 습관이었다고 생각합니다.
 

반성하는 점도 있습니다. 사실 당시에는 잘 몰랐고, 지금 돌이켜 보니 느끼는 점인데, 좋은 UX를 고민하기 보다는 개발 가능하고 문서를 쳐 내는데 더 집중을 했던거 같습니다. 그래서 실제로 QA할 때 불편한데? 라고 느껴서 뒤집어 엎었던 기억이 꽤 있습니다. 분명 고민은 많이 했는데, 좋은 UX에 대한 고민보다는, 지금 주어진 것들을 어떻게 잘 정리하고 화면 안에 구겨넣을 수 있을지에 대한 고민이지 않았나 싶습니다.
 

2. 새로운 아이디어를 내는 일

: 그래도 UX 디자이너 답게 나름 새로운 아이디어를 내기도 했습니다. 핵심 기능들에 대해서보다는, 부족한 공간을 채울만한 콘텐츠 기획이 좀 더 많았던거 같습니다.
 
개인적으로 힘들었던 부분은, 앱의 방향성이 명확하지 않다는거였습니다. 비즈니스 목적으로 하자니 깡과 확신이 부족했고, 단순히 앱 한번 만들어보자! 에 머무르기에는 3년을 약속한 장기 프로젝트였기 때문에, 계속해서 유입되는 사용자를 보고싶었거든요. 메인 기능들은 여행을 떠날 때에만 들어올만한 기능이었고, 결국 사용자를 계속 유입시킬만한 콘텐츠가 필요했어요.

여행 전, 여행 중, 여행 후에 모든 단계에 사용자가 앱에 들어올 수 있도록 새로운 기능 (ex. 투데이)을 기획하기도 하고, 앱의 구조를 바꾸기도 하고 (ex. 홈 탭 생성) 새로운 콘텐츠를 유입시키기도 했습니다. (ex. 홈콘텐츠)
 

 
여기서 잘했던 점은 레퍼런스를 보는 시선이 많이 발전되었다고 생각합니다. 처음엔 무작정 핀터레스트를 켜고 허우적며 "예쁘다"고 생각된 부분들은 일단 캡쳐하고 봤는데, 어떤 포인트에서 그 레퍼런스가 맘에 들었는지를 확실히 인지하고, "예쁨"보다도 구조와 UX에 더 집중을하면서 레퍼런스를 고르게 되었습니다. 또, 특정한 목적을 두고 레퍼런스를 찾기 보다도 일상 속에서도 이런 저런 새로운 서비스나 앱을 접하면서 '오 이런 부분은 우리 기능에 접목 시킬 수 있겠는데?' 싶은 부분을 많이 찾았습니다. (사실 이 부분은 트리브에 대한 애정이 있었기 때문이 아닐까 싶습니다.)
 

 
쓰다보니 살짝 자소서 쓰는 기분이네요. 부족했던 점은 '명확한 페르소나를 갖지 못한것' 이라고 생각합니다. 아무래도 다양한 성향의 사람들이 여행갈 때 서로의 다름을 인정할 수 있도록 돕는 앱이었다 보니, 누군가의 의견이 틀렸다고 말할 수 없었어요. 그러다보니 매 회의마다 만약에 극장이 펼쳐졌고, 의견을 모으기가 힘들었던거같습니다. 내 새끼가 모두에게 사랑받았으면하는 마음이 가득했네요.
 

3. 아이디어를 정리하고 팀의 목표를 설정

: 저희 팀에는 트친놈 (트리브에 미친놈)이 많았어요. 늘 새로운 아이디어와 의견을 가져왔기 때문에 할 일이 끊길 일은 없었습니다. 초반에는 보태보태병으로 일단 다 하다가 업데이트 시기가 밀리거나 밤을 새거나 하는 일이 잦았습니다. 기획/디자인/개발(1명)만 있을 때에는 이게 괜찮았는데, 마케팅팀과 다른 개발자들이 생기기 시작하면서 괜찮지 않더라구요. 명확한 기간과 목표를 정해야 마케팅 콘텐츠의 방향성이 생기고, 정기 회의에 참석하지 않고 개발 회의에만 참석하는 개발자들이 업무 분담을 할 수 있었어요.

당시 Figjam의 도입도 한 몫했습니다. 아이디에이션 보드인 피그잼이 등장하면서 회의에서 아이디어를 정리하고, 중요도를 판단하고, 시기를 정하기 쉬웠어요. 사실 PM이 하는 역할이지만, 팀에는 PM이 없었기도 하고, 계획 세우는걸 좋아하는 P로서 이런 부분을 명확히 하고싶었기 때문에 자발적으로 발산된 아이디어를 정리해서 계획을 세우는데에 주도적으로 참여했습니다.
 
이 부분에서는 잘한 점/못한 점 보다는 이 업무의 장단점을 써보려고 합니다.

 
사실 어떻게 받아들이냐의 차이일 수는 있는게, 단점도 어떻게 보면 팀원들의 사기를 돋고, 앱의 구조를 파악하는데에 도움이 많이 되었기 때문에 꼭 단점이라고만은 할 수는 없다고 생각합니다. 어찌됐건 단점에 비해 장점이 압도적으로 컸고 프로젝트를 열심히, 꾸준히 할 수 있었던 데에 큰 역할을 하지 않았나 싶습니다. 
 

마무리

프로젝트를 할 때에는 아이디에이션과 기획을 하는 과정을 단순히 '생각의 발산' 이라고 느꼈는데, 회고를 쓰다보니 그 과정도 점점 발전해오지 않았나 싶어서 조금 뿌듯하기도 하네요. 디자이너의 업무라고 쓰긴 했지만, 다른 역할을 맡았던 팀원들도 모든 과정에 같은 열정을 가지고 참여해줬기 때문에, 모두 고생했다고도 전하고 싶습니다. 찐! '디자이너'만의 업무는 다음 글에서 더 상세히 풀어보겠습니다.
 
그래서 추천하는 다음글은? 바로 https://triv.tistory.com/19 입니다. 그럼 안녕