초기 스타트업 첫 1년 회고
UXUI 디자인의 일을 시작한지 벌써 거의 1년이 되가는 시점에서 회고를 작성해보려고 한다.
생긴 지 두 달 밖에 안됬던 극초기 스타트업에서 만드는 첫 앱 서비스 프로젝트를 진행해보면서 배우고 느낀 점들을 팀의 멤버로서 그리고 나의 직무로서 간략하게 써보려고 한다.
프로덕트 제작기간 : 8개월 (기획포함)
2022.04 ~2022.12
극초기 스타트업의 멤버로서
1. 구인 - 할 건 있는데 할 수 있는 사람을 찾아야한다.
채용은 모든 회사의 숙제이기도 하지만 극초기 스타트업에서는 훨씬 더 치밀하게 움직여야 한다는걸 보고 배웠다. “그러니까.. 여기가 뭐하는데에요?” 하는 질문에 일단 답을 해야하는 준비력도 필수이다. 취준을 할 때는 구직자 입장에서는 채용자들이 낚시를 하는 거라고 생각했었다. 채용공고 낚시대만 던지면 구직자들이 미끼를 물고 올라오는 그런 그림 말이다. 하지만 극초기 스타트업에서는 채용자들이 낚시만 하지 않는다. 따로 인사팀이나 외부인력 없이 본인들이 해녀들의 물질에 가깝게 핏이 잘 맞을 것 같은 사람들을 찾는것을 볼 수 있었다. 핏이 잘 맞는다는 것을 확인하는 방법은 사실 1:1 면접이 아닌 대화이다. 우리가 이미 조직에서 그려놓고 있는 기준으로 면접자에게 질문을 해서 가려내는 것도 중요하고 시간적으로도 효율적이지만 면접자 입장에서도 이 회사가 나에게 맞는지를 면접동안 알아야 했다. 그렇지 않고 잘못된 만남이 되면 서로 힘들어지기 때문이다. 그러다보니 면접관으로 들어가게 되면 면접이 커피챗처럼 흘러가는 그림을 늘 보게 되었다.
초기 스타트업이다 보니 마음이 잘 맞는 사람을 골라야 했고 그렇게 하다보니 1사람당 평균 1달이 걸려서 채용이 됬었다. 8개월 짧은 기간이지만 사람을 채용하는 과정에서는 다양한 변수들을 겪었다.
2. 사수가 없어요
보통 극초기 스타트업에 사수를 기대하기는 어려울 것이다. 초반에는 사수의 부재를 책, 미디엄, 브런치 글들을 통해서 많이 보려고 했던 것 같다. 특히나 초반에 뼈대를 잡는 부분에 있어서는 IT 커뮤니티에서 많이 추천하는 책들을 보는 부분이 많이 도움이 됬었다. 특히나 ‘비즈니스의 세계에 들어온걸 환영하네 ‘기본용어들을 익히는 부분에서 말이다! 하지만 어느정도 시간이 지나고 나면 특히 당신이 극초기 스타트업에서 일을 한다면… 이론적인 지식들에 대한 답답함을 느끼게 될 것이다. 왜냐하면 보통 책들은 어느정도 성장한 스타트업들을 대상으로 혹은 대기업들 등 기반이 있는 조직을 기저로 깔고 성장에 대한 이야기를 많이 하고 있기 때문에 얻은 지식들을 어떻게 나의 현실(생존으로서 성장에 더 가까운)에 적용할 것인지에 대해서 고민을 하게 된다. 슬금슬금 다른 사람들은 실무에서 어떻게 하고 있을까가 궁금해지기 시작하면서 네트워킹에 눈이 가게 됬었다. 실제로 스타트업 네트워킹은 많이 도움이 됬었다. 회사에 없는 직무를 하고 계신 분들도 만나고 다른 실무자들을 만나게 되면 좀 더 실무적인 고민들도 같이 나눌 수 도 있었다. 세계가 커진 느낌을 확실히 받으면서 커리어적인 면에서도 고무가 됬다.
UXUI 디자이너로서
1. 리서치는 막연한 인사이트를 얻기 위한 것이 아니라 가설을 검증해보기 위한 발판
처음에 MVP로서 기능을 하는 앱을 만든다 생각했을 때, 나는 기획하려는 서비스 분야에 대해서 어떤 유저들이 있는지, 그 유저들의 특성은 무엇인지 실제 유저 목소리로 제대로 파악을 해보고 싶었다. 그렇기 때문에 처음에는 그들의 프로필을 파악을 해보기 위한 리서치를 구상했었다. 서비스를 파악하는데 배경을 명확했으면 좋겠다는 점이 있었다. 내가 있는 발판이 그냥 가설로 지탱되어진 것이 아니라 실제로 유저들의 목소리로 이루어진 바닥이라는 것이 확신이 되어야 내가 두 발로 제대로 서서 디자인 작업을 할 수 있는 확신이 생길 것 같기 때문이었다. 그리고 또 이렇게 전체적으로 훑으면 우리가 간과했던 점에서 인사이트도 발견할 수 있을 것이라 생각했다. 하지만 의외로 그런 점은 발견되지 않았었다. 유저들이 우리의 가설대로 생각하고 있구나라는 확신을 얻었다는 것 의외에는 별로 새롭게 얻은 점은 없었다. 있는 리소스만 활용하고 빠르게 진행해도 될 수 있었던 부분이었다. 부끄럽지만… ‘일단 한 번 보자’라는 식으로 리서치를 하면 안된다는 점을 실감했다. 유저 리서치는 ‘어떤’ 유저의 ‘무엇을’ 그리고 ‘왜’ 알고 싶은지에 대해서 먼저 선행이 되어야 한다. 리서치는 ‘어떻게’에 해당하는 부분에 대해 답만 줄 뿐이다.
2. Use case의 중요성 (feat. 예외처리)
처음에 UX 작업을 했을 때 user flow 다이어그램 기반으로 개발자들과 협업을 했었다. 하지만 작업을 할 때, 기획자 선배로부터 이런 플로우는 사실 디자이너만 본다. 개발자들을 잘 보지 않는다. 개발자들과 협업을 할 떄에는 보통 ‘요구사항 명세서 RFP(Request for proposal)’라는 액셀 형식으로 된 리스트를 사용한다고 했다. 실제로 그랬다. 개발자분들은 (물론 이건 개발자들마다 다르겠지만) 액셀로 정리된 것을 선호했다. 우선 훨씬 필요한 부분에 대해서 찾기가 쉬웠기 때문이었다. 그리고 어떤 비고에 들어가는 사항들도 훨씬 더 보기가 편했다. 이런 면에서 엑셀로 Use case를 정리하는 것은 예외처리를 전달하는데 훨씬 효과적이었다.
Use cas에서 나눠지는 3가지 케이스 Use case에는 크게 3가지 케이스들이 있다.
1. Good case : 유저가 활짝 웃고 서비스도 웃고 있는 스무스하게 플로우가 진행된 케이스
2. Alternative case : 생각지 못한 상황으로 유저가 다른 방향으로 선택해서 발생되는 플로우
3. Error case: 서비스가 전혀 의도하고 싶지 않은 방향으로 흘러가는 오류 플로우
이렇게 케이스를 나눈 후 각 케이스마다 3단계로 나눠서 인과관계를 리스트를 했다.
- Precondition: 전제조건 - 해당 플로우가 생기게 된 상황, 조건
- Flow : 유저가 직접 프로덕트 상에서 겪는 플로우
- Message/ result : 해당 플로우에서 프로덕트 상에서 어떻게 유저에게 상태를 보여주고 유도할 것인지에 대한 부분
기획할 때 이 부분에 대해서 이렇게 구조적으로 시스템화를 해서 주었다고 한다면 개발자 분들은 일하기 훨씬 편했을 것이다. 정확히 어떻게 처리를 해야한다는 것이 명시되기 때문이다.
Task가 명확해질 수 있으니 피드백도 훨씬 빨리 받을 수 있었다. UX 의 단계에서 생성된 문서가 협업을 위해서 또 어떻게 가공을 거쳐야하는 지 알 수 있게 한 경험이었다.
3. 디자인 시스템
디자인 시스템과 디자인 정책서 홀로 일하는 디자이너로서 시스템이 있어야 내가 많은 양의 일들을 효율적으로 처리할 수 있을 것 같아서 초기부터 디자인 시스템에 대해서 생각을 해보았다. 하지만 처음에 MVP를 만드는 입장에서 처음부터 많은 요소들을 디자인 시스템에 넣고 싶지는 않았다. 최대한 최소한의 요소들과 variation이 시스템에 들어갔으면 좋겠다는 생각으로 짰다. 하지만 디자인을 하면서 다양한 피드백을 들으면서 색이던, 폰트 사이즈던 점점 그 종류가 늘어났다. 결국에는 모든 UI 작업이 끝난 후, 시스템에서 나오지 않은 요소들을 다시 찾아보고 시스템에 반영하는 단계가 생겨서 좀 애를 먹었다. 어쩔 수 없는 일인 것 같지만 처음에 작업한 시스템이 전체 시스템의 1/3 정도의 분량이었다는 걸 생각하면 조금 더 처음에 구체적으로 시스템을 짰어도 될 뻔 했다는 생각이 들었다.
4. 디자이너로서 협업
디자이너로서 협업 어떻게 하면 좋은 기획을 할 수 있을까에 대한 질문에 대한 답을 협업에서 찾으려고 했다. 실무 경험이 많아서 나의 직무에 대한 전문성과 다른 직군들에 대한 식견들이 많지 않는 나는 최대한 다른 사람들의 의견을 들어보는 방법으로 일을 하고 싶었다. 그러다보니까 디자이너이긴 하지만 이런 기획 협업에 있어서 퍼실레이터의 역할까지 하게 되었다. 1년동안 퍼실레이터를 하면서 느꼈던 점은 목적을 정확히 해야한다는 점이었다. 자유로운 분위기로 아이데이션을 만드는 것은 좋지만 효율성을 해치지 않는 선에서 하려고 조금씩 매번 기획 협업, 회의때마다 개선해나갔다. 조금씩 나아지고 있지만 다양한 의견들이 나왔을 때 더 깊은 인사이트를 도출해낼 수 있도록 잘 유도하는 역할은 앞으로 더 개선해보고 싶은 과제로 삼고 있다. UX 방법에서는 협업을 위해 다양한 방법들이 존재한다. 하지만 그렇게 정석적으로 움직이기엔 한계가 있었고 우리에겐 좀 더 빠르게 움직일 수 있게 해당 방법론들을 적용시키는 방법을 찾아야 했다. 협업을 하면서 가장 인상깊었고 의미있었다고 생각되는 협업은 두 가지가 있었다.
1. 사용자 여정 지도
2. 디자인 스프린트
1. 사용자 여정지도
사용자 여정지도는 사실상 어떻게 되다보니 머릿속에 있었던 것들을 모두 다 끄집어내는 기회가 되었다. 장점이자 단점이긴 했다. 브레인 스트로밍 형식으로 진행이 되다보니 특정 퍼소나에서 진행되는 것이 아니라 마일스톤 스케일의 모든 아이디어들을 꺼내놓았다. (당시 팀원들이 다 N이라..?) 여정지도를 기반으로 해서 치열하게 아이데이션을 하고 나서 보니 좋았던 점은 팀원들이 서비스를 어떻게 응시하고 있는지를 얼라인할 수 있다는 점이었다. 전체적으로 서비스가 어떻게 커갈 수 있을지도 스캔을 해볼 수 있어서 좋았다.
2. 디자인 스프린트
린하게 애자일하게 움직인다는 게 어떤걸까? 그 부분에 대해서 디깅을 하다보니 스프린트를 알게 되었고 자연스럽게 디자인 스프린트라는 개념도 알게 되었다. 좀 더 빠르게 의사결정을 내릴 순 없을까해서 찾아보게 된 방법이다. 저번에 브런치에 공유했듯이 원론대로 디자인 스프린트를 적용하지는 않았다. 상황에 맞게 스프린트를 적용했다. 목적 지향형 프로세스인 디자인 스프린트를 하면서 문제 해결의 스콥을 잘 정의를 할 수 있는것이 디자이너의 중요한 역할이라는 생각이 들었다. 물론 How 에 대한 부분을 디자이너가 해결하는 부분이긴 하지만 협업을 통해서 사실 다 같이 ‘How’에 대한 아이디어를 모을 수 있다. 사실상 같이 다른 팀원들과 이야기하다보면 나와 다른 관점에서 더 좋은 아이디어를 얻을 때도 많다. 이런 아이디어에서 핵심이 뭔지를 디자인적으로 고민하면서 작업하는 과정도 재밌다. 디자인 스프린트 계기로 ‘What’과 ‘How’를 동시에 생각하려고 하는 것 같다.
마치며…
1년정도 지났고 서비스가 커지는 걸 보는 건 정말 꿀잼이다. 마치 육아를 하는 것 같은 느낌도 든다. 가장 크게 실무와 부딛치면서 느낀 점은 초기 스타트업에서 일을 했을 때에는 배운대로 UXUI 작업을 할 수는 없다는 점이었다. ‘최고’보다는 ‘최선’을 선택해서 움직이는 방법을 배워가고 있다.
