5년차로 처음 이직하고 수습 기간을 거치고 있어요.
이직할 때 제일 망설여 지는 부분이 '이전 회사에서 업무 하던 방식과 스킬이 타회사에도 통할까?' 라는 점 아닐까 싶어요. 특히 경력직이라면 신입과 달리 a. 지식이나 스킬의 정도가 높고 b. 빠르게 성과낼 수 있는 부분을 찾아야 한다는 강박아닌 강박(?) 이 있지 않을까 싶어요. 물론 회사에서도 그 부분을 기대하고 더 많은 리워드를 주면서 경력을 뽑겠죠. 흑.
결과적으로 프로덕트 디자이너에서 UX디자이너로 이직했고 (아마 마지막에 커피챗 했던 UX 멘토분의 영향이 컸던것 같기도 합니다.), 연차는 그대로 인정받았습니다. 다만 실제 업무는 결국 프로덕트 디자이너로 비슷한듯 해요. 그래서 업무 성격 자체는 굉장히 만족하고 있습니다. 제게 자유도가 높기도 하고요.
5년차 프로덕트 디자이너에서 UX디자이너로 이직하기
2024/03/01
1. 이직 결정 후 고민과 해결
이직을 준비하면서 비슷한 기간에 3군데 정도 합격을 하였고 고민 끝에 지금의 회사로 결정하게 되었습니다. 추후에 기회가 된다면 이직준비나 면접이나 사전과제 대응에 대해 이야기 해보겠습니다. 아무튼 처음 신입으로 입사 했을 때 만큼 마냥 해맑거나 다 해낼수 있다는 믿음보다도 걱정이 조금 앞섰어요. 해당 회사에 입사 전에 고민이 되었던 부분은 아래와 같아요.
[고민 점]
- 직군이 명확하지만 산업이 완전 바뀜
- B2C에서 B2B로 폭넓고 다양한 VOC 수렴이 불가
- 스타트업에서 워터풀의 체계나 보고 시스템을 겪어 보지 못함
특히 2번에 관해서 많은 고민이 되었습니다. 저는 이전회사에서 VOC가 들어오는 창구들이 다양했고, 기획이나 디자인 결정을 내릴때에도 많이 참고 했었고요. 마케터와 거의 한 팀처럼 일할정도로 업무 긴밀도나 친분이 높았어요. 이 점이 매우 걱정이 되었습니다만 이미 결정은 내렸고 문제를 해결할 방법을 찾아야죠...(아자!) 그리고 다행히도 한 달이 지나고 어느정도 가닥을 잡았습니다.
[입사 후 해결 방식]
- 바뀐 산업을 시간 내어서라도 공부
예) IT 독서 및 산업처리기사 필기 공부
- 유관 부서에게 긴밀한 협조 요청
예) 소프트스킬로 친분을 쌓고, 열린 마음으로 대응
- 다행히 결제/승인이 어려울뿐 보고 방식의 체계는 비슷함
예) 결제 요청은 어렵지만 업무 보고는 쉬움
첫주에는 사람들과의 적응, 어색한 회사 자리 적응, 업무 내용 파악에 머리가 아팠지만, 지금은 조금은 적응 했습니다. 애초에 퇴사 자체에 대한 후회나 이직 자체에 대한 후회도 없고요. 특히 팀원 분들이 적응에 많이 도와주셔서 감사했습니다. 그리고 같이 협업 하는 분도 제가 곤란해하는 점들을 해결 하려고 같이 노력해주셔서 감사했어요.
첫 번째, 첫주에 적응 되어서 둘째주부터는 주말에도 계속해서 개발공부를 해오고 있습니다. 되도록 올해 내에 산업기사 자격증을 따고 싶네요. 그나마 다행인점은 전회사에서 프론트엔드 지식이 필요해서 플러터나 뷰 공부하며 백엔드 지식을 어깨너머로 배웠던 점. 저는 지식 쌓는걸 좋아해서 공부할 내용이 생기는게 즐겁다는 점. 그래도 어렵긴 어렵네요.
두 번째, B2C의 소비자는 없지만 결국 누군가가 사용하기 위해 작업 한다는 점. 그분들은 결국 회사 내부인들 이였어요. 사실 UX에서도 그렇지만 100만명의 서비스라고 100만명을 조사하는게 아니듯 (이론상 5명이면 충분하다 합니다), B2B에서도 5명의 내부자면 충분히 반영이 가능하다고 느꼈습니다. 다음 주부터 그분들에게 언제든 당신의 문제를 들을 준비가 되어있다 어필하러 갑니다!
세 번째, 시스템은 해당 회사에 맞춰 적응 하면 된다. 특히 보고의 방식이 비슷해서 다행이었습니다. 제가 의미없는 페이퍼 작업을 선호하지 않는 편이라 바로 본론으로 들어가야하는 보고가 좋았습니다. 물론 더 윗 상급자에겐 조금의 페이퍼 워크도 필요할 수 있겠습니다만. 빠른 피드백과 진행 방식이여서 한결 마음이 놓였습니다.
2. 2월 주요 업무 내용
2월 주요 업무내용은 a.디자인 시스템 b.내부 백오피스 이 두가지 였어요. 특히 디자인시스템에서 개인적으로 배웠던점이 많았습니다. 이전 회사의 마지막 디자인 시스템 작업에서 1년 간의 공백기가 있어 그간 피그마 시스템이 완전 변경되어서요. 특히 다크 모드로 바꿀 수 있는 theme 설정과 variant 양식 변경으로 거의 다시 공부했습니다. 흑흑. 피그마 툴 자체의 학습 장벽이 굉장히 높아졌다고 느끼면서도 학습만 된다면 공수가 굉장히 적게 드는 점에 놀랐습니다.
[디자인시스템]
- 디자인 시스템 다크 모드 추가
지난 해 가장 센세이션 했던 디자인 시스템 다크모드 활용 법. 예전에는 다크모드를 만들기 위해선 똑같은 콤포넌트의 세트를 하나 다시 만들었어야 했죠. 그리고 일일히 색을 지정해줘야 했구요. 이번 업데이트를 통해 미리 지정해둔다면 그대로 프레임에서 다크모드로 전환하게 되었습니다. a. 라이트 모드 <-> 다크 모드 간 컬러 elevation 매칭 이 중요해졌습니다.
- 디자인 시스템 variant
variant에 nested 기능이 추가 되었습니다! 이전에도 콤포넌트 안에 콤포넌트를 넣는 nested 기능을 사용하긴 하였습니다만, 정식 기능으로 나오게 되어서 더 편하게 인스턴스간 스왑이 가능해 졌습니다.
가장 헷갈렸던 부분은 boolean 부분 이었는데요, 두가지 방식이 있습니다.
[boolean 만들기]
a. 콤포넌트 props 정의에서 스트링으로 True, False 로 적어 만들기
b. 콤포넌트 props 자체를 boolean으로 미리 정의 하기 > 콤포넌트와 레이어를 각각 boolean과 nested에 연결해주기.
물론 결과 값은 둘다 boolean처럼 pannel에서는 UI가 생겨서 같습니다만, 속성이 달라요. 이부분에서 한 참을 헤매었던것 같습니다. 여기까지 활용할수 있다니 피그마 제작자들은 똑똑한것 같아요. 일주일 간 야근하며 어느 정도 완벽 학습되어서 뿌듯합니다.
[내부 백오피스 사이트]
전담하게된 사이트 인데요. 간략하게 문제를 말씀 드리자면 a. 메인 기획자나 PO가 없음 b. 사용성 문제 이 두가지 입니다.
a. 메인 기획자나 PO가 없음
가장 큰 문제는 인수인계 문서가 없고, 기능에 대해 100% 아는 사람이 없습니다. 이에 대해선 기능에 대한 정의를 기록으로 남겨두고, 회의록을 작성하고, 자주묻는 질문 리스트를 만들 예정입니다. 물론 디자이너인 제가 매뉴얼을 만들 필요야 없지만, '나'를 위해서 또는 이 일을 맡게될 '후임자'를 위해서 작성하면 좋을거란 생각이 들었습니다. 우리의 기억은 짧고 휘발되기 싶고요. 매번 기능을 실제로 돌려보면서 알기보단 문서로 정돈되는게 좋을것 같습니다. 그리고 아마 로직을 변경 요청 드릴일도 있을것 같아, 로직자체에 대한 기록도 필요하다 생각이 들었습니다.
[해결 방식]
- 질문 리스트 만들어서 공유
- PRD 작성시 기능 상세 설명
- 회의록 작성
b. 사용성 문제
제가 이 프로젝트에 조인하게된 주요 이유입니다. 기능적으론 70~80% 완벽하게 구현이 되어있지만 비개발자가 쓰기엔 아주 사용성이 떨어져요. 제품 자체가 비개발자가 이해하기 어려운 제품을 비개발자들을 위해 만들어 졌지만 결국 사용성이 떨어져 비개발자들에게 외면을 받는 듯합니다. 개발자들에게는 굳이 이 제품을 쓸 이유가 없고요. (그냥 터미널에 들어가서 개발 코드를 수정하면 되니까요) 사용성이 떨어지는 이유는 다양합니다.
[사용성 문제가 생기는 이유]
- (기획) 유저 시나리오를 고려하지 않음
- (개발) 기능의 완벽도가 떨어짐
- (운영) VOC 수렴이 잘 되지 않음
- (디자인) 디자이너가 만들지 않음
전반적으로 제게 수정할 권한이 주어져서 다방면으로 고민하고 있습니다. 처음엔 기능적으로 완벽한줄 알았는데 기능적으로도 보완할 부분이 있더라고요. 잠깐 충격은 받았지만 이전회사에서도 기능에 대해서 수정한 경험도 있으니 잘 활용해 보겠습니다. 비개발자가 쓰기에도 편한 개발 소프트웨어를 만드는것! 업무의 최종 목표입니다.
3. 적응해가고 있지만 그럼에도...
아직은 동료의 신뢰관계나 업무 내용에 대한 100% 이해가 아니여서 확신있는 발언이 어려운것 같습니다. 아무래도 이전회사에서는 5년간 프로덕트를 보면서 꿰고 있다보니 서비스들의 연결 지점을 정확하게 이해하고, 팀간의 협력을 빠르고 우호적으로 이끌어 낼 수 있었거든요. 또한, 신뢰관계가 없는 상태에서 제가 잘못된것 같은 사항에 대해 발언을 하면 수정의견이 아닌 공격으로 느껴질 수도 있으니까요. 레거시 코드는 그 당시에 이유가 있기에 만든거라 생각합니다. 충분히 전임자를 존중하면서도 개선을 이끌어내야하고요. 제가 잘하는 스킬 중에 하나가 논리적인 구조를 짜는 것이라 생각했는데, 어찌보면 이전회사에선 제품에 대한 이해도와 언제든 협력을 얻어낼수 있는 환경이 더 좋은 결과를 만들어 주지 않았나 싶습니다.
이직한 곳에서도 퍼포먼스를 100% 낼 수 있도록 좀 더 구조파악이나 소프트스킬에 노력해야겠습니다.
퇴사를 할때 쯔음, 이전 회사의 팀 빌딩이 너무 좋았던지라 다시 또 내게 이전 처럼 학습에 대한 열정이나 동료들과 즐겁게 일할 기회가 있을까? 매우 걱정했습니다. 이직 당시에 채용 시장의 한파도 절실하게 느꼈고요. 그러나 어딘가에는 내 능력을 필요로 하는 곳이 있고, 몰입할 정도로 즐겁게 업무를 할 수 있는 환경이 있다는걸 깨달았습니다. 일단 시간이 빠르게가요ㅎㅎ
이전 회사에서 일을 대하는 프로로서 가치관에 대해 동료들이 해주었던 말을 최대한 새기려 합니다.
- 열심히 보단 잘 해야한다.
- 돈을 받는 이상 프로로 일하자.
- 일하는데 있어 감정을 섞지 말자.
- 내가 무엇을 하고 있는지 상급자에게 정확하게 전달하고 한 발짝 미리 전달드리자.
- 주어진 것에 항상 감사하자.
3월에도 회고로 돌아오겠습니다. 이상입니다. :)