손 때 묻은 디자인 프로세스 기록
꾸준히 반복하다 보면, 어느샌가 나도 모르게 무언가가 정립된다.
어느새 IT 업계에서 프로덕트 디자이너로 일한 지도 6년 째다. (왠지 굴러먹었다고 표현해야 할 것 같은 문장이다) B2B 개념은 커녕 api의 뜻도 모르던 내가 커머스 플랫폼 서비스를 운영하는 회사에 들어와 일한 지 1년 11개월 하고도 16일째가 되는 날이다. 이쯤 되니 '나.. 어떻게 뽑힌 거지?' 싶다. 관련 전공자가 아니라는 아무도 모르는 나만의 이상한 자격지심으로 인해, 주니어 때부터 이런저런 컨퍼런스를 들쑤시고 다니고 서점에 가서 'UXUI, 사용자, 사용성'을 검색하면 나오는 대부분의 책을 최대한 훑어보고 읽었다. 씹고 말고 할 것도 없이 일단 입에 넣고 맛도 보지 않은 채 무작정 삼켜버린 꼴이다. (그러나 이 중 가장 중요하고 또 오리지널이라 할 수 있는 서적인 '도널드 노먼의 디자인 심리학'은 아직도 다 못 읽었다는 아이러니)
여기저기서 파편적으로 습득한 지식을 어떻게 하면 업무에 적용할 수 있을까 매사 고민했는데, 어떤 것은 딱 맞는 퍼즐처럼 업무에 쉽게 적용되는가 하면 또 어떤 것은 아무리 노력해도 업무에 적용하기 힘들었다. (업무에 가장 적용하기 힘들었던 건 '휴리스틱 평가'와 '퍼소나' 방법론이었고, 실제 업무에 가장 적용하기 좋았고, 또 도움이 되었던 것은 '더블 다이아몬드' 방법론이었다.) 처음엔 방법론을 업무의 모든 과정에 녹여 수행하려 노력했다. 그러다 보니 당연히 물리적인 업무 시간이 길어지고 개중엔 '이게.. 맞나?' 싶은 결과물이 나올 때도 있었다. 시간이 쌓이면서 다양한 업무 경험과 함께 시행착오해 보니, 반드시 모든 방법론을 업무에 적용할 필요는 없으며 때에 따라서는 환경에 따라 적합하게 커스터마이징하여야 한다는 것을 깨닫게 되었다. 방법론은 물론 산업에 있어 매우 중요한 개념이지만, 결국 방법론은 방법론일 뿐이다. 의류학에서 배운 것만으로 실제 의류회사에서 행해지는 모든 것을 설명할 수 없듯 말이다. 중요한 건 원리를 이해하는 것이고, 이를 바탕으로 내가 처한 환경에 따라 적용 또는 활용하는 것이다.
생각해 보면 '컴퓨터'라는 것이 일반 사람들의 삶에 들어온 그 순간부터 'UXUI 디자이너'는 존재했을 것이고, 그들은 그때부터 지금 현재에 내가 일하며 고민하고 맞닥뜨린 문제들을 먼저 경험하고 해결해 왔을 것이다. 이런 선구자들 덕분에 지금의 나와 같은 프로덕트 디자이너들은 다양한 방법론을 통해 보다 더 빠르고 쉽게 직무에 온보딩할 수 있게 되었다는 것에 매우 감사하게 생각한다. 그리고 존경한다!
서론은 마치 내가 직접 방법론을 정립한 사람인 것과 같은 분위기로 비장하게 썼지만, 결국 내가 이 글을 통해 말하고자 하는 것은 '현 회사에서 수행하는 디자인 프로세스'이다. 용두사미라고 생각했다면 맞다.
1. PRD 이해 및 학습
내가 현재 속해있는 조직은 동일한 직무끼리 팀을 이뤄 여러 업무를 수행하는 기능 조직이다. 이로 인해 대부분 내가 수행하는 작업은 바텀 업으로 디자이너가 문제를 정의하여 올리는 것보다, 탑 다운으로 이미 상위에서 '어떠한 현상을 바탕으로 한 문제 정의'가 정돈되어 내려오는 것에서 시작한다. (간혹 디자이너가 의견을 개진하기도 함)
PO는 프로젝트에 따라 다르지만, 직접 바텀 업 하거나 사업/운영팀에서 넘어온 현상에 따라 문제를 정의하고 BRD(Business Requirements Document) 또는 PRD(Product Requirements Document)를 작성한다. 프로덕트 디자이너(이하 PD)는 PRD를 통해 문제의 발생 배경(현상)과 목표 지표, 해결해야 하는 문제와 해결방안 등을 검토하며 PO의 머릿속과 동기화한다. 이 단계에서 PD는 PO에게 추가적인 정보 또는 데이터를 요구할 수 있다. 필요에 따라 관련 크루(운영/사업부 등)와 소통을 하며 PRD를 학습하고 함께 보완한다.
커머스 서비스 플랫폼을 운영하는 현 회사의 경우, 주로 'GMV 또는 공헌이익률 증가'와 관련된 문제가 많은 편이다. 단순 사용성 개선 또는 VOC에 의한 유지보수 작업은 아주 작게 쪼개서 진행하거나, 큰 프로젝트에 함께 녹여서 진행한다.
2. 관련 레퍼런스 또는 관련 배경지식 리서치
작업/소통 효율을 위해 몇몇 도메인은 전담자가 나뉘어 있긴 하지만, 앞서 말했듯 나는 어떠한 특정 도메인에 귀속되어 있지 않은 'B2B 사이드 PD팀'에 소속되어 있다. 따라서 다양한 도메인/기능/문제 상황을 맞닥뜨릴 수 있기 때문에 관련 배경 지식에 대한 학습이 매번 요구된다. 이미 기존에 사용자가 사용 중인 기능을 개선하는 것이라면, 이전 작업물(디자인 파일, 정책 문서, 개발 환경 등)에 대한 히스토리와 사용자의 사용 맥락을 파악해야 한다. 이전에 없던 새로운 기능을 만들어 내야 한다면, 스타트업에서 신규 서비스를 런칭할 때처럼 사용자부터 시장 조사까지 서비스와 관련된 모든 부분에 대한 학습이 필요하다.
이 과정에서 가장 흔하게 행하는 것은 바로 '레퍼런스 리서치'일 것이다. 우리가 해결해야 하는 문제와 유사한 상황을 지닌 어떤 것(App이나 Web 혹은 책이나 오프라인의 그 무엇)으로부터 인사이트를 얻는 것이다.
3. UX 디자인: 유저스토리, 가정/가설 설계
현 회사의 경우 PO가 PRD를 작성하며 '배경, 문제 정의, 가설/가정, 목표 지표, 유저스토리' 등을 함께 정리해서 넘겨준다. PO는 PRD를 작성할 때 단순 개발 구현 가능성, 일정 산정뿐만 아니라 회사 전체 방향성에 부합하는 목표 지표 설정, 사업적인 성과 여부, 법무 이슈 검토, 해당 기능을 운영해야 하는 운영 주체와의 소통, 가이드라인 제시, 정책 설계 등등 매우 거시적인 관점에서 바라보기 때문에 PD는 미시적인 관점으로 실제 해당 서비스를 사용할 사용자에 입각하여 '유저스토리 또는 가설'을 정리하고 의견을 제시해야 한다.
1~3번에 대한 내용을 개인 노션에 정리하면서 온전히 이해가 되었다면, 이를 Figma에 요약하여 정리해 둔다. 이는 나 스스로의 생각을 정리해 두고 디자인 작업하는 도중에 틈틈이 확인하기 위함도 있지만, 이후 관련자들에게 디자인 리뷰를 해야 하거나 공유해야 하는 상황이 발생할 때 제법 요긴하게 사용된다.
4. UI 디자인: 와이어프레임 및 GUI 디자인
드디어 사람들이 흔히 생각하는 PD의 주된 업무인 '사용자 인터페이스 디자인' 단계에 이르렀다. 현 회사의 경우 디자인 시스템이 잘 되어 있는 환경이다 보니, 대부분 와이어프레임 작업과 동시에 GUI를 바로 디자인한다. 과거 디자인 시스템이 부족한 환경의 경우, GUI 디자인에 소요되는 시간이 많았다. (타 지면과의 디자인 통일성 고려, 타 디자이너들과 싱크, 개발 구현 관련 소통 등)
주요 화면 위주로 빠르게 디자인한 후 문제 해결에 주된 플로우를 구성한다. 플로우 구성 시, PO와 함께 플로우의 구성 방향 및 범위를 긴밀하게 소통해야 한다. 플로우의 적합성을 판단하는 데에는 '사용성'도 중요하지만, 프로젝트 진행 일정은 항상 정해져 있기 때문에 이를 작업해야 하는 '작업자'의 공수 투입 가능 기준을 고려하는 것 또한 중요하다. (필요에 따라 작업의 Phase를 나누는 이유가 바로 이 때문)
주요 화면으로 구성된 플로우(해피 패스)를 토대로 PO/FE/BE와 1차 싱크를 진행한다. 이 과정을 통해 개발 시 발생할 만한 문제 또는 엣지 케이스 선제 파악, 개발 공수 파악, 일정 산정, 문제 해결에 적합한 플로우인지 검토해야 한다. 그리고 때에 따라 기존 디자인 시스템 내 컴포넌트로 풀기 어려운 경우, '신규 컴포넌트로 추가할지 or 로컬에서만 사용하는 것으로 할지'와 같은 주제에 대해 디자인 시스템을 관장하고 있는 담당 플랫폼 디자이너와의 소통이 필요하다. 만일 신규 컴포넌트 작업이 필요할 경우, 이에 대한 개발 작업 공수 및 일정 검토가 추가로 필요할 수 있다.
5. UI 세부 디자인 및 정책 정리
해피 패스 검토가 통과되면 각 주요 화면에서 파생되는 여러 케이스에 대한 디자인 및 정책을 정리한다. 로그인 화면을 예로 들었을 때 '1)해당 화면 진입 직후 화면(=default), 2)아이디/비번 입력 후의 화면, 3)유효성에 적합하지 않은 화면, 5)로그인 버튼을 눌렀을 때의 화면, 6)네트워크 오류가 발생했을 때의 화면' 등 하나의 화면은 여러 케이스를 지닐 수 있고, 개발자가 이를 구현하기 위해서는 각각의 화면 디자인이 필요하기 때문에 세부 UI 디자인이 필요하다. (내가 개인적으로 가장 좋아하는 작업 중 하나) 요 단계는 소위 말하는 짬밥을 느낄 수 있는 부분이다. 경험이 많이 축적된 사람일수록 다양한 케이스를 경험/인지하고 있으므로 꼼꼼한 정의가 가능한데 반해 그렇지 않은 주니어의 경우 케이스 정의가 빈약할 수 있다. 만약 케이스 정의가 빈약한 것 같다면, PO/FE/BE의 도움을 받는 것이 좋다.
위의 내용과 마찬가지로 하나의 화면은 보이지 않는 많은 정책이 담길 수 있다. 위 예시로 들었던 로그인 화면을 다시 놓고 얘기하자면, ID를 입력하는 Input만 하더라도 다양한 유효성 체크 기준이 필요하다. (허나 디자인 시스템 구축 수준이 높고, 개발 환경에서 '유효성 체크 기준'에 대한 정책이 라이브러리화되어 있다면 화면마다 일일이 정의할 필요가 없다) 따라서 PD는 작게는 Input 유효성 체크 기준부터 크게는 해당 화면 내 접근 권한 또는 사용자의 상황에 따른 분기 처리 등 보이지 않는 서비스 정책에 대해 확인하고 필요에 따라 정의해야 한다. 만약 PD가 사전에 이러한 케이스/정책 정리를 하지 않을 경우, 개발자는 작업할 때마다 PD/PO를 찾아와 소통해야 한다. 이렇게 소통 비용이 늘어나면 늘어날수록 업무의 비효율이 늘어나고, 이는 결국 일정이 늘어지는 슬픈 결말로 귀결될 수 있으므로 매우 중요한 작업이 아닐 수 없다. 주니어 때에는 이런 것들이 참 막막했는데, 결국 이를 해결할 수 있는 건 경험과 시간뿐이다. 많은 케이스를 경험해 보고, 모르는 것에 주저 않고 개발자들에게 질문하여 끝내 답을 얻고야 마는 용기와 노력만이 살길이다. 이에 대한 질문을 싫어할 동료는 없을 것이다. 만약 싫어하는 사람이 있다면 그 사람이 이상한 거니 전혀 기죽을 필요 없다. 화이팅!
6. 최종 디자인 리뷰 (= FE 개발 시작 가능 상태)
모든 화면/플로우/정책 설계가 끝나면, PO가 FE/BE/QM 그리고 프로젝트 성격에 따라 그밖에 운영 부서 또는 사업부서 크루까지 모든 유관자를 초대해 'PRD'와 '디자인' 리뷰를 진행한다. 이 단계에서는 작업자뿐만 아니라 QM 또는 운영 담당자 또는 사업부 또는 법무 검토 크루 등에게 화면과 정책에 대해 설명한다. 이를 통해 QM은 TC(Test Case)를 작성하고, 운영 또는 사업부에서는 대응책을 준비한다.
7. 개발 시작 및 개발 대응
개발 시작 시점은 프로젝트에 따라 다를 수 있다. 7단계에서 해당하는 '개발'이란 대부분 'FE'의 개발에 해당한다. BE는 대부분 1단계부터 PO와 먼저 사전 작업을 시작하거나, 3단계에서 PD/PO와 함께 논의하며 스키마 및 api 설계를 시작한다. 그래야 7단계에 이르렀을 때 디자인과 api 모두 준비되어 FE가 수월하게 개발할 수 있기 때문이다. (물론 FE도 api 없이 선작업할 수 있으나, 정책이 온전히 확정된 후 FE가 투입되는 것이 효율적이기 때문)
이때 PD는 FE가 개발하는 데에 필요한 재료 또는 답변을 제공해 주는 대응 체제에 돌입한다. UI 구현 방안에 대해 논의하거나(화면 크기 대응과 같은 보이는 레이아웃 관련), 리소스를 export 하기 편하게 준비해 주거나, 미처 챙기지 못한 정책 또는 화면을 제공해 주는 등의 작업이 발생할 수 있다. 이는 앞서 작업 시 엣지 케이스 및 정책 정의를 얼마나 꼼꼼하게 챙겼느냐에 따라 여유로운 시간이 될 수도, 지옥이 될 수도 있는 시간이다.
프로젝트의 모든 단계는 모든 작업자가 함께 검토해야 하는 책임이 있으므로, 설사 놓친 부분이 많더라도 모든 것이 디자이너의 책임은 아니니 너무 자책할 필요는 없다. (주니어 때는 이때 놓친 것들이 얼마나 큰 실수처럼 다가오던지.. 정말 스트레스 그 자체였다) '그래, 모를 수도 있지! 놓칠 수도 있지! 다음엔 챙기면 되지!' 이 3종 셋을 필시 마음에 새겨 둘 것.
8. QA 진행
FE/BE 개발이 모두 끝나면, 테스트 환경에 해당 작업물을 배포하고 모든 유관자가 함께 QA를 진행한다. 조직 환경에 따라 조금씩 다를 수 있지만 현 회사의 경우 사안에 따라 간소한 규모의 프로젝트라면 별도의 QM 담당자 없이 PO/PD/FE/BE만으로 QA를 진행하기도 한다. 이때 PO는 잠시 QM으로 변모하여 간략하게나마 TC를 작성하는 등 뛰어난 대응을 선보인다. (이는 어찌 보면 슬픈 일이기도..) GUI와 관련된 대부분의 검증은 당연히 PD의 몫이다. (물론 개중에는 감사하게도 디자이너 못지않게 GUI에 대해 열혈 검증 해주시는 QM 또는 PO가 있다) PD는 구현된 결과물이 시안과 동일하게 잘 반영되었는지 매의 눈으로 살펴봐야 한다. 처음엔 '이걸 구분하는 게 가능해?' 싶다가도 막상 구현된 화면을 보면 1px, 1pt만 달라도 눈에 확 들어온다. 아마 화면을 디자인하면서 많이 보다 보니 눈에 익어서 그런 듯하다.
QA 단계에서는 평소 아무리 진보적인 사람이라도 보수적인 접근이 필요하다. 우리에게 가장 중요한 것은 물론 사용자지만, 그에 못지않게 일정을 지키는 것 또한 중요하기 때문이다. (회사로부터 돈을 받고 일하는 노동자는 먹고살기 위한 정말 중요한 문제) 이는 신뢰와 관련된 것이면서 결국 역량으로 판단되는 것이기도 하다. 따라서 QA 때 뒤늦게 발견된 문제 또는 약간의 아쉬운 부분이 있더라도, 사안에 따라 냉철하게 구분하여 생각하는 것이 중요하다. 해피패스에 치명적인 영향을 주는 문제라면 당연히 일정을 조정해서라도 수정 작업이 필요하겠지만, 그렇지 않은 사소한 것(이는 프로젝트의 성격에 따라 상대적인 기준이지만 대체로 GUI와 관련된 부분이 해당)의 경우 힘들더라도 흐린 눈을 장착해야 한다. 아니면 담당 FE가 좋아하는 것을 몰래 알아내 직접 구두로 부탁하는 친화력을 발휘하거나, 이보다 조금 더 중요해 보이는 수정 이슈와 몰래 함께 묶어 요청하는 등 한껏 융통성을 발휘해야 한다. 이 순간을 위해서라도 디자이너는 모든 작업자와 친하게 지내야 한다고 해도 과언이 아니다. 이는 반드시 디자이너에게 해당되는 것만은 아니지만, 사람은 안으로 팔이 굽는 법이다. 그러니 일도 중요하지만, 역시 그보다 더 중요한 것은 사람 관계다!
9. 배포
QA에서 발생한 모든 문제가 해결되면 비로소 실제 사용자가 사용하는 환경(일명 프로덕션)에 개발자가 작업물을 배포하는 것으로 모든 작업이 끝난다. 우리 회사는 작업물이 배포된 후 PO가 '전사공유' 채널에 이에 대한 소식을 공유하는 문화가 있다. (프로젝트 진행 배경/목표/기대하는 바, 결과물, Thanks to 등)
배포 후 데이터를 보고 의사결정을 내려야 하는 AB 테스트 같은 작업의 경우 배포 이후가 비로소 시작이지만, 대부분의 작업은 배포 단계를 통해 프로젝트가 끝이 난다. BE의 경우, 직무 특성상 해당 작업물에 대한 지속적인 체크가 요구되고 때에 따라 일부 대응이 필요할 수 있다. (그래서 연봉이 높은 것일까 싶은 수준으로..) 만약 Phase를 나눠 진행한 프로젝트인 경우, 배포 후 곧바로 다음 작업을 준비한다. 이 말인 즉 앞서 진행한 프로세스(1~9)를 또다시 반복하는 것이다.
배포 후, 일정 기간이 지나면 PO는 필요에 따라 지표를 확인하고 결과물을 정리하여 유관부서에 공유한다. 그러나 모든 일이 그렇듯 '배포=성과'로 직결되는 것은 아니다. 때로는 많은 노력을 들였는데도 성과가 부진한 경우도 있고, 많은 노력을 들이지 않았는데도 얼떨떨하게도 큰 성과가 따라오는 경우도 있다. 대부분은 전자일 것이다. 역시나 여기서도 중요한 것은 꾸준함이다. 일희일비하지 않고 묵묵히 다음 스텝을 준비하는 것 그리고 꾸준히 내가 작업한 것에 대한 시선을 유지하는 것이 중요하다. 이게 뭐 그리 어렵겠어 싶지만, 정신없이 회사에서 주어진 일을 쳐내다 보면 이게 가장 어렵다. 이 문장을 쓰는 지금도 벌써 2024년 5월이다. 엊그제 2024년 1월을 새로 시작했던 것 같은데 말이다. 오늘도 무한 배포의 굴레 속에서 정신 바짝 차리자고 다짐한다. 내일은 또 잊겠지..
글을 모두 쓰고 보니, 나의 디자인 프로세스는 총 9단계로 구성되어 있다. 크게 나눠보면, 기획(1~3) > 디자인(4~6) > 개발(7~9)이다. '디자이너는 4~6단계에서만 관여해야 하는 것이 아닌가?' 싶다면 그것도 맞는 말이다. 이전 회사에서는 기획자의 롤을 수행하는 사람이 있었기 때문에 4~6단계만 수행했었다. 프로덕트 디자이너의 역할은 회사에 따라, 조직에 따라, 프로젝트에 따라 그 역할이 다양하게 변모할 수 있다. 그러나 이익을 창출하는 곳인 회사는 적은 비용으로 높은 이익 창출을 지향하므로, 프로덕트 디자이너의 역할이 늘어나고 있는 것은 당연한 수순일 것이다. 이는 디자이너뿐만이 아니라 모두에게 해당되는 이야기다. 심지어 이제는 AI에게 대체되지 않는 인력이 되기 위해 노력해야 한다. AI를 막을 게 아니라, AI를 잘 활용하는 인력이 되어야 한다.
현 재직 중인 회사 그리고 IT 업계에서는 기획자가 넘겨준 기획안에 따라 단순히 GUI만 그리는 UXUI 디자이너가 아닌, 그 이상의 역할을 수행하는 디자이너(기획자+UXUI 디자이너+a)에 대한 수요가 증가하고 있다는 것은 갖은 회사의 JD만 봐도 쉽게 알 수 있는 사실이다. 그리고 이 수요에 부합하는 사람은 점점 늘어나고 있다. 나는 디자이너로서 어떤 +a 차별점을 키워야 하는 것인가에 대한 고민 필요성은 너무나도 당연한 사실이기에 이렇게 언급하는 것도 민망한 수준이다. 아직도 +a를 뚜렷하게 찾지 못했는데, 이젠 AI까지 신경 써야 하는 세상이 왔다. 얼레벌레 살아온 것 같은데 또 나름의 길을 찾아온 것 같기도 하고 아무튼 열심히 살아보자.
