디자이너가 사이드 프로젝트로 성장하는 방법

 

최소한의 기능으로 런칭한 사이드 프로젝트를 점진적으로 개선할 수 있다면 우리는 어디까지 성장할 수 있을까?

---

지난 6월 사이드 프로젝트 동아리 디프만(디자이너와 프로그래머가 만났을 때)에서 4개월 동안 디자이너로 활동했다. 워밍업과 파이널 프로젝트로 두 개의 서비스를 작업했고 다양한 분야의 유노윤호(열정적인 사람들) 들과 친해져 지금까지도 좋은 인연을 만들어 가고 있다. 서비스도 런칭했고 다양한 분야의 인재들과 인적 교류도 했으나 계속해서 디프만 활동에 어떠한 갈증을 느껴왔다.

8기 때 런칭했던 서비스는 여러 핑곗거리로 현재 사이드에 제쳐둔 프로젝트가 되었고 나를 표현하는 포트폴리오에 포함시키기엔  아쉬운 마음이 들곤 했다. 서비스 런칭 후 더 이상의 성장이 없다는 것이 가장 큰 갈증이었고, 돌이켜보았을 때 디프만은 그저 재미있던 추억에 불과했다. 그래서 이번엔 디프만 9기 디자이너이자 운영진으로 참여하기로 했다.

 

팔리는 디자이너의 자격 요건

최근 Product Designer의 채용 정보를 보면 공통적으로 우대하는 자격 요건이 있다. 그 중 왓챠의 디자이너 JD(Job Description)에 좋은 표현이 있어서 일부 내용을 발췌했다. 

'단순 GUI 쇼케이스가 아닌 기능적 플로우 설계의 논리와 그 논리가 결과물에 잘 반영되었는가?'

'풀려는 문제가 무엇인지, 어떤 방법으로 해결했는지, 왜 그 방법을 선택했는지, 결과물은 무엇인지, 결과물 반영 후 어떤 변화가 생겼는지?'

데이터의 시대가 도래하면서 객관적인 지표에 기반한 디자인, 즉 문제를 파악하고 끊임없이 개선할 수 있는 디자이너가 오늘날 디자이너의 능력이 되었다. 우리는 어쩌면 문제를 멋지게 해결하기보다 끊임없이 도전하는 역량이 필요할지도 모른다.

하지만 경력이 없는 신입은 서비스 런칭의 기회도, 런칭한 서비스를 개선하는 성찰을 하기 쉽지 않다. 이를 방증하듯 Product Designer 직군에 신입은 거의 채용하지 않는다. (디자인 직군이 대부분 그렇다) 디자이너의 자격 요건이 최소 2년에서 많게는 5년까지 신입 디자이너의 취업문턱은 굉장히 높아졌다. 필자는 사이드 프로젝트로 서비스를 런칭하고 점진적 개선을 위해 고민할 수 있는 경험을 제공할 수 있다면 경력과 신입의 경계를 실력이 아닌 경험의 차이 정도로 간극을 좁힐 수 있을 것이라 생각했다. 

 

사이드 프로젝트도 복기가 필요하다.

바둑에 '복기'라는 용어가 있다. '바둑을 둔 후 지난 경기를 검토하기 위해, 다시 처음부터 순서대로 벌이어 놓는 일'을 뜻하는 복기는 다음 바둑 경기의 승패 여부를 결정지을 정도로 성장의 발판이 된다. 사이드 프로젝트를 런칭하는 과정에도 많은 배움이 있지만 서비스 런칭 후 수집되는 데이터를 통해 문제를 발견하고 서비스 목표에 도달하는 경험은 오늘날 디자이너에게 꼭 필요한 배움이라고 생각한다. 그렇게 디프만 9기는 이전 기수 뿐만 아니라 타 IT동아리와 다르게 '운영 개선' 세션이 추가되었다.

 

디프만 9기 프로세스

 

디프만은 5년동안 모임을 지속하며 SNS 채널에 약 4,000명의 팔로워와 이전 기수를 포함해 400여 명의 멤버를 보유하고 있다. 최소 기능에 집중한 프로덕트를 런칭하고 디프만의 인프라를 활용해 서비스를 개선하는 것이 디프만 9기가 참여 멤버들에게 제공하고자 하는 목표다. 그리고 그들이 경험해보지 못한 '성장'을 느꼈을 때 우리는 디프만이라는 서비스의 목표를 달성할 수 있을 것이다.

 

모여서, 일단 만들고, 개선해서, 성장

 

 

디프만의 자랑, 가슴속 3천원

내 주변의 붕어빵 가게를 알려주는 '가슴속 3천원'은 디프만 7기에서 탄생한 디프만의 자랑거리다. 내 주변의 붕어빵 가게를 발견했을 때 사진을 찍어 위치를 등록하면 다른 사람들이 찾아볼 수 있다. 사용자 참여형인 가슴속 3천원은 아이디어도 좋았지만 전체적인 모션과 UX Writing은 ‘붕세권이라 뿌듯하고 붕어빵 하나에 기분이 좋은 감정’을 고스란히 느끼게 해 준다.

 

 

가슴속 3천원의 인기가 뜨거워지면서 7만 명이 넘는 다운로드 수를 기록했다. 이와 동시에 붕어빵 가게 사진이 아닌 목적에 맞지 않는 사진을 올리는 사용자가 생겨났다. 이러한 어뷰징을 방지하기 위해 신고 기능을 도입하고 악의적인 신고에 대응할 수 있도록 3번 이상의 기록에 대해서 자동 삭제되고 있다. 사용자는 절대 설계자가 의도한 대로 사용하지 않는다. 초기 서비스 설계단계에서 알아내기 힘든 지점을 런칭 후에도 꾸준히 살펴보았기 때문에 발견할 수 있었다고 생각한다.

마치며...

디프만 9기는 8주 동안 최소 기능에 집중한 프로덕트를 만들고 남은 5주 동안 ‘의도한 대로 설계되었는지’ 검증할 수 있다. 우리는 모든 참여 멤버들이 가슴속 3천원처럼 애정이 깃들고 지속적으로 도전을 요구하는 프로젝트를 진행하길 기대하고 있다. 단지 또래 친구들과 무언가를 만들었다는 추억이 아니라 런칭한 프로덕트를 살펴보고 증명했을 때 경험에 성장을 더할 수 있지 않을까?

디자이너와 개발자의 동반 성장을 위하는 모임, 리뉴얼 중인 디프만의 웹페이지

디프만 - Depromeet