우리는 어디까지를 ‘디자인’이라고 말할 수 있을까? 그리고 디자이너는 무엇을 계속 배우고, 어디에 집중해야 살아남을 수 있을까? 나 역시 이 질문의 중심에 있었다. 10년 넘게 프로덕트 디자이너로 일했고, 최근 3년은 창업자로 팀을 만들어 제품을 설계하고, 고객을 직접 만났다. 그리고 깨달았다. 이미
디자인의 정의는 계속 변해 왔다. 그 변화의 속도는 점점 더 빨라지고 있다.
--- 본문 중에서

나 또한 종종 팀에서 1인 프로덕트 디자이너로 일하면서 포기하지 않고 끝까지 여러 업무를 맡아 고군분투했던 적이 있었다. 혹은 사용성을 내려놓고 제품 운영을 택하는 결정에 승복하는 것이 맞다고 판단하기도 했다. 커리어에 관한 불안감을 잠시 내려놓고 디자이너의 역할을 확장하는 결정을 내릴 수 있었던 이유는, 이런 여정을 거치면서 팀이 원하는 방향을 정확히 이해하는 것이 디자이너에게 무엇보다 중요하다는 걸 여러 차례 경험했기 때문이다.
--- 『제1장』 중에서

디자이너가 툴러로 여겨지는 현상은 단지 타인의 인식 때문만이 아니라, 우리 디자이너가 스스로 역할을 넓히는 시도와 질문을 얼마나 하고 있는지와도 깊이 관련돼 있다. 디자이너가 자신의 영향력을 확장하기 위해서는 ‘그림 그리는 사람’에서 ‘생각하는 사람’으로 거듭나려는 시행착오가 필요하다는 의미다. 그 시작은 아주 사소한 질문 하나에서부터 비롯될 수 있으니 너무 어렵게 여기지 않았으면 한다.
--- 『제1장』 중에서

반복적인, 시각 중심의 디자인은 긴 호흡에서 꾸준히 자동화되고 있었다. 인공지능은 그 흐름을 가속하는
역할을 했을 뿐이다. 디자이너의 역할은 이미 단순한 ‘디자인 제작자’에서 ‘문제 해결의 중심축’으로 차차 전환됐다. 그러니 디자이너에게 남은 일은 ‘무엇을 왜 만들 것인가’라는 본질적인 질문에 답하는 것이다. 디자이너는 이제 무언가를 만드는 사람이 아니라, 무엇을 만들어야 할지 정의하고 결정하는 사람이 먼저 돼야 한다.
--- 『제1장』 중에서

확실히 AI를 중심으로 만든 프로덕트는 그 구조부터 완전히 다르다. 기존 디지털 제품은 기본적으로 사람이 주도했다. 기획자가 흐름을 짜고, 디자이너가 구조를 만들고, 개발자가 화면을 구현하는 순차적 프로세스. 하지만 AI 기반 앱은 이 순서를 뒤집는다. AI가 데이터를 먼저 처리하고 생성하며, 템플릿은 그 흐름에 따라 유동적으로 구성된다. 인터페이스는 고정되지 않는다. AI의 응답에 맞춰 화면의 형식이나 구성이 바뀌는 것이 전제다.
--- 『제1장』 중에서

더 중요한 건, 정해진 정답을 따르기보다는 지금 내가 속한 조직의 맥락을 이해하고, 내가 어떤 강점과 취약점을 가진 인재인지 스스로 파악하는 것, 그리고 그 기반 위에서 어떤 방식으로 협업할 때 최고의 결과를 낼 수 있는지 고민하는 것이다. 결국 커리어는 ‘정답’을 찾는 여정이 아니라, 자신만의 방식으로 ‘해석’해 나가는 과정이니까. 그것이 탁월한 프로덕트 디자이너로 성장하는 첫걸음이다.
--- 『제2장』 중에서

AI는 제품 기획의 전 과정에 걸쳐, 의사결정과 실행 방식 모두 변화시키고 있다. 우리 팀 역시 기획 초기 단계에서 AI 도구를 활용해 기능 아이디어를 도출하고, 요구사항을 정리하며, 실험 설계를 보완하고 있다. 제품 기획은 이제 '팀의 아이디어 + AI의 제안'이 함께 들어가는 공동 작업에 가까워지고 있는 셈이다. 단계별로 도드라지는 변화는 다음과 같다.
--- 『제2장』 중에서

특히 디자이너에게 피드백 문화는 더욱 중요하다. 디자인이라는 결과물은 주관적인 해석의 여지가 크기 때문에, 피드백을 감정적으로 받아들이지 않고 명확한 근거와 논리를 바탕으로 수용하고 화면을 재설계하는 힘이 필수다. 반대로, 비판적인 의견을 줄 때도 사용자 관점과 제품 목표에 근거해 피드백을 구체화하는 습관이 필요하다. 모호한 피드백보다 목적 기반의 논의가 쌓일수록, 팀 전체의 학습 속도도 빨라진다.
--- 『제2장』 중에서

각 이해관계자에게 효과적으로 커뮤니케이션하는 방법은, 회의가 끝난 뒤 그들이 자리에 돌아가 어떤 우선순위를 고민할지 미리 떠올려 보는 것이다. 일종의 역지사지다. 그들이 어떤 질문을 받았을 때 집중해서 반응하고, 설득될지 상상하는 것, 이것이 팀 내에서 커뮤니케이션을 효과적으로 하는 첫걸음이다. 예를 들어, ‘특정 화면의 버튼 개선’을 제안해야 하는 상황이라고 해보자. 이해관계자별로 접근 방식은 달라야 한다.
--- 『제2장』 중에서

포스트잇을 활용했던 이유는 명확했다. 포스트잇, 화이트보드 같은 아날로그 도구를 활용하면 손으로 직접 그리고 붙이는 감각 덕분에 구조화에 효과적이라고 봤기 때문이다. 손으로 그리고 매만지면서 내용을 정리할 때 확실히 사고방식이 덜 갇힌다는 걸 경험했다. (비슷한 맥락에서) 책을 읽거나 사람과의 대화를 통해 내 생각을 구체화하고 확장하는 것도 유용한 연습이다. 새로운 자극과 정보를 통해 생각과 태도를 닫아두지 않도록 의식하는 방식이다.
--- 『제2장』 중에서

0→1 구간의 소기업에서 일하면서 프로세스만 붙잡고 있어선 안 된다. 반대로 대기업 혹은 10→100 구간에서 성장하는 회사, 제품을 두고 디자인에 급격한 변화를 주는 데 매몰되는 것도 주의해야 한다. 입사 후 고통받는, 흔한 실수다. 지금 회사와 제품의 성장 단계에서 내가 얻을 수 있는 경험치를 잘못 이해한 것과 같다. 사내에서 “너한테 기대한 건 그게 아니야.”라는 평가를 받을 가능성이 높다. 이런 판단 오류를 줄이기 위해 제품과 기업별 성장 단계에 대한 이해도를 높여야 한다.
--- 『제3장』 중에서

일각에서는 AARRR 대신 RARRA가 더 좋다고 강조하기도 한다. RARRA는 “Retention - Activation - Referral - Revenue - Acquisition” 순서다. 또 최근 일부 전문가들은 AARRR을 단순화해 매출과 고객 확보만으로도 사업 구조를 설명할 수 있다고 보기도 한다.결국 AARRR은 절대적인 공식이나 정답이 아니다. 시대 흐름과 맥락에 따라 비즈니스에서 중요하게 보는 지표도 항상 달라지기 마련이다. 디자이너에게 중요한 건, 지금 내가 만들고 있는 제품의 구조 안에서 무엇이 우선되는지, 어떻게 서비스를 영속시킬 수 있는지 AARRR 같은 프레임워크로부터 힌트를 얻는 것이다. 핵심은, 각 제품의 특성과 비즈니스 모델에 맞게 필요한 요소를 전략적으로 적용하는 디자인이다.
--- 『제3장』 중에서

결국 제품 디자이너는 ‘기능’만이 아니라, 제품이 어떻게 돈을 벌고, 어떤 구조로 시장에서 오래 살아남을 수 있을지까지 고민해야 한다. 매출 구조를 설계하는 눈을 가진 디자이너는, 제품 성장의 리더이자 비즈니스 파트너가 될 수 있다. 그러니 이제는 디자이너로서 프로덕트를 ‘새로운 눈’으로 바라보길 권한다. 우리가 평소에 쓰는 프로덕트에는 어떻게 ‘매출’의 프레임워크가 적용돼 있나? 우리가 만드는 제품 안에는 어떤 수익 구조가 숨어 있는가? 그 구조는 고객의 경험과 어떻게 연결돼 있는가? 이 질문에서 비즈니스 중심의 제품 디자인은 시작된다.
--- 『제3장』 중에서

제품이나 기능을 새로 개발할 때, 퍼널 분석을 통해 우리가 생각한 핵심 기능을 사용자가 얼마나 막힘없이 쓰는지, 내가 설계한 디자인이 정말 유려한지 확인할 수 있다. 사용자가 처음 진입한 뒤 우리가 예상했던 활성화 퍼널의 통과율을 보통 체크한다. 이때 참고하는 벤치마크 지표로 (제품의 특성에 따라 다르겠지만) 개인적으로는 유저의 50% 이상이 첫 기능을 사용할 수 있게 해야 그 뒤 실험으로 넘어갈 수 있다고 본다. 이 수치는 높으면 높을수록 좋다.
--- 『제3장』 중에서

유저 리서치 방법론 한 가지만으로는 한계가 명확하다. 서로 다른 방법을 상황에 따라 조합하는 방식이 가장 효과적이다. 예컨대 비대면으로 카드 소팅을 진행하면서 카카오톡으로 약식 인터뷰를 진행한다거나, 필드 스터디를 하면서 설문조사도 병행하는 식이다. 가안에 가까운 제품 화면을 만들어 UT를 하면서 실제로 사용자들이 우리 제품을 의도한 대로 쓰는지, 프로덕트가 그들의 문제를 해결했는지 체크하는 사전 리서치도 진행할 수 있다. 결국 유저 리서치 방식은 “유저의 문제를 정의하고, 해결할 수 있는 실마리를 찾는다”는 목적을 위해 다양하게 조합할 수 있다.
--- 『제3장』 중에서

일반적으로 비즈니스에서 유저가 큰 불편을 겪는 문제, 혹은 그 문제를 풀었을 때 고객이 많이 늘어날 것 같은 문제에서 제품 기획을 시작해야 한다고 여겨진다. 이때 전자와 후자 중 어떤 선택이 사업적으로 더 큰 임팩트를 가져올까? 정답은, 사용자가 큰 불편을 겪는 문제다. 우리가 만드는 제품이 고객에게 가치를 주는지가 언제나 관건이기 때문이다. 사용자가 실제로 어떤 문제를 겪고 있는지 살펴보고 문제의 크기를 이해할 때 프로덕트 디자이너로서 성과를 내며 두각을 드러낼 수 있다.
--- 『제4장』 중에서

뾰족한 문제의식이야말로 ‘데이터 드리븐 디자인’의 첫걸음이다. 뾰족한 가설과 디테일한 데이터 없이는, 팀은 성취감마저 잃을지 모른다. 역설적으로 요즘 같은 시대에 장인정신과 직관을 바탕으로 한 뾰족한 사
고실험이 더 중요해지고 있는 셈이다. 무조건 실험을 돌리는 것이 아니라, 진짜 사용자의 맥락을 고민하면서 문제의 본질을 꿰뚫는 직관과 실행이 더 큰 임팩트를 만들어낸다. 지표를 움직이는 GPM 또한 방향을 제대로 잡았을 때 의미 있는 액션으로 연결될 수 있다.
--- 『제4장』 중에서

사용성을 지켜내면서도 비즈니스에 맞춰 유연하게 해결책을 제시하는 디자이너. 그렇다면 이들은 어떻게 탁월한 해결책을 고안할까? 기본적인 원칙이 있다. 먼저, 해결책을 굉장히 여러 갈래로 떠올려 시도해 보고, 사용자를 만나는 걸 최우선 순위에 둔다. 유저를 만나고 프로토타입을 만드는 과정이 모든 업무 과정에 녹아있다. 그뿐만 아니라 (앞서 3장 유저 리서치 파트에 언급했듯이) AI 같은 도구를 써서도 프로토타입을 만든다. 유저를 살피고 최대한 많이 시도해 보기 위해 무엇이든 가능하다는 마인드다. 최대한 자기 자신을 사용자와 가까운 상태로 두기 위해 인풋도 많이 넣으려 한다. 해결책을 도출하는 속
도와 사용자 접점을 두루 신경 쓴다.
--- 『제4장』 중에서

역기획이든 가이드 영상을 참고하든 결국 벤치마킹은 ‘레퍼런스를 똑같이 따라 하는 것’과 엄연히 다르다. 이 차이를 인지하지 않고 벤치마킹이라는 핑계로 타 앱을 그대로 흉내 냈다가는 자칫 그 제품에 내재해 있던 문제점까지 떠안을 수 있다. 그러니 가능한 한 역기획을 해보고, 적어도 타인으로부터 계속 피드백을 받으면서 제품 벤치마킹 과정에서 본인이 놓치고 있는 지점을 파악하는 나름의 안전장치를 마련해 둬야 한다.
--- 『제4장』 중에서

소셜 기능 그 자체는 나쁘지 않은 접근이었지만, 디자이너로서 이 기능이 다소 복잡하다는 인상을 받았다. 그려야 하는 화면이 많고, 사용자가 헷갈릴 여지가 많아보였다. 이 플로우를 간단하게 그려 팀에 공유했다. 화면에 들어가는 요구사항이 너무 많아 고민된다고 의견을 전하자, 팀원들도 비슷한 의견을 주었다. 그래서 심플하게 시작하기로 합의할 수 있었다. 유저가 기분을 남긴다거나 유저끼리 기분에 답장을 다는 등 복잡한 기능을 고민하지 말고, 고양이 캐릭터가 편지를 보내주는 단순한 기능으로 솔루션이 변경됐다.