UIpac

디자인 시스템 도입기 - 왜 필요했나

작년 초, 저희 서비스의 버튼 색상이 몇 가지인지 세어본 적이 있습니다.결과는 11가지였어요...비슷한 파란색인데 헥스 코드가 조금씩 다른 버튼이 화면마다 흩어져 있었습니다.디자이너가 3명, 프론트 개발자가 8명인 팀에서 벌어질 수 있는 아주 전형적인 일이었죠. 계기는 사소했습니다.신규 입사한 디자이너가 "이 버튼이랑 저 버튼, 색이 다른데 의도된 건가요?"라고 물어봤어요.저는 순간 대답을 못 했습니다.의도된 게 아니라, 그냥 각자 다른 시점에 다른 사람이 만들었을 뿐이었거든요.확인해보니 primary 버튼만 놓고도 코드값이 제각각이었고, 여백 값도 4px, 6px, 8px가 뒤섞여 있었습니다.이 문제를 팀에 공유했을 때 반응이 재밌었어요.디자이너들은 "그럴 줄 알았다"는 표정이었고, 개발자들은 "그게 ..

OKR vs KPI, 우리 팀에 맞는 목표 설정법

목표 설정 방식을 바꾸자는 이야기가 나오면 항상 OKR과 KPI 중 뭐가 더 좋냐는 질문으로 흘러갑니다.저희 팀도 작년에 이 논쟁을 한참 했어요.결론부터 말하면, 둘 중 하나를 정답으로 고르는 문제가 아니라 우리 팀 상황에 맞게 섞어 써야 한다는 걸 알게 됐습니다. 저희는 원래 KPI 중심으로 목표를 잡았습니다."월간 활성 사용자 10% 증가", "이탈률 5% 감소" 같은 숫자를 팀별로 나눠 갖고 분기마다 확인하는 방식이었어요.숫자로 관리하니 명확하긴 했는데, 문제는 그 숫자를 왜 올려야 하는지에 대한 맥락이 자꾸 빠졌습니다.어느 순간 팀원들이 "이탈률만 낮추면 되는 거 아니냐"면서 사용자 경험을 해치는 방식(예: 탈퇴 버튼을 세 단계 깊이 숨기기)까지 고민하는 걸 보고 아차 싶었어요.숫자를 위한 숫자 ..

MVP를 정의하는 기준, 실패에서 배운 것

MVP(Minimum Viable Product)라는 말은 다들 알지만, 실제로 "이게 MVP다"라고 딱 잘라 정의하는 건 생각보다 어려운 일이었습니다.저희도 한 번 크게 실패한 경험이 있어서, 그때 배운 걸 정리해보려고 해요. 작년에 새 기능을 MVP로 빠르게 내보내자는 논의가 있었습니다.구독형 알림 기능이었는데, 저희가 정의한 "최소 기능"에는 알림 채널 3가지(이메일, 앱푸시, 카카오톡), 세부 설정 화면, 알림 히스토리 조회까지 포함되어 있었어요.그때는 이게 최소라고 생각했습니다."이 정도는 있어야 쓸 만하지 않겠냐"는 논리였죠.결과적으로 개발 기간이 예상 4주에서 9주로 늘어났습니다.런칭하고 나서 사용 데이터를 보니 더 충격적이었어요.카카오톡 알림을 쓰는 사용자는 전체의 4%뿐이었고, 세부 설정..

리모트 협업 툴 비교 (Notion, Jira, Confluence)

비대면 근무가 늘면서 협업 툴을 새로 정비해야 하는 상황이 왔습니다.저희 팀은 Notion, Jira, Confluence를 각각 다른 용도로 써봤는데, 이번 글에서는 실제로 써보면서 느낀 장단점을 정리해보려 해요.정답은 없고, 팀 성격에 따라 맞는 조합이 다르다는 게 결론이라는 점을 미리 말씀드립니다. Notion: 유연하지만 규칙이 없으면 무너진다Notion을 처음 도입했을 때는 다들 좋아했습니다.문서, 위키, 간단한 데이터베이스, 칸반보드까지 하나의 툴에서 다 되니까 편했어요.저희는 회의록, 기획 문서, 온보딩 가이드를 전부 Notion으로 옮겼습니다.문제는 3개월쯤 지나자 나타났어요.누구는 페이지 제목에 날짜를 앞에 붙이고, 누구는 뒤에 붙이고, 누구는 아예 안 붙였습니다.검색을 해도 비슷한 문서..

AI 챗봇 페르소나 설계 노트

챗봇을 기획하면서 가장 뒤로 밀리기 쉬운 작업이 페르소나 설계입니다."일단 답변이 잘 나오게만 하자"가 우선이 되기 쉬운데, 저희도 처음엔 그렇게 접근했다가 나중에 크게 후회했어요.페르소나 없이 만든 챗봇의 말투가 화면마다 미묘하게 달라져서, 사용자 입장에서는 마치 서로 다른 사람이 응대하는 것처럼 느껴졌던 거죠. 초기 버전에서 챗봇은 어떤 답변에서는 "죄송하지만 확인이 어렵습니다"라고 하고, 다른 답변에서는 "그건 안 돼요!"라고 했습니다.답변 스크립트를 여러 사람이 나눠서 작성했기 때문이었어요.사용자 피드백 중에 "챗봇이 갑자기 반말로 답해서 놀랐다"는 항의가 몇 건 들어왔는데, 확인해보니 한 담당자가 급하게 스크립트를 추가하면서 톤을 못 맞춘 거였습니다.이 문제를 겪고 나서야 저희는 "이 챗봇은 누..

서비스 기획서 템플릿 - 내가 쓰는 방식

기획서를 쓸 때마다 매번 형식을 새로 고민하는 게 비효율적이라는 걸 느끼고, 제가 실제로 쓰는 템플릿을 정리해보기로 했습니다.요구사항정의서와 겹치는 부분도 있지만, 여기서는 좀 더 초기 단계, 즉 아이디어를 사업적으로 정리하는 단계의 기획서를 다룹니다. 1. 한 줄 요약 2. 문제 정의3. 시장/경쟁 상황4. 솔루션 개요5. 기대 효과와 리스크6. 필요한 리소스와 일정 1. 한 줄 요약먼저, 가장 위에 이 서비스/기능이 무엇인지 한 문장으로 씁니다."누구를 위해, 어떤 문제를, 어떻게 해결하는가"를 한 문장에 담으려고 노력해요.저는 이 문장을 쓰는 데 보통 제일 오래 걸립니다.한 줄로 못 요약된다는 건 아직 생각이 정리되지 않았다는 신호더라고요.막상 써보고 팀원에게 읽어달라고 했을 때 "그게 무슨 뜻이에..

데이터 기반 의사결정, PM이 놓치기 쉬운 함정

"데이터 기반으로 의사결정하자"는 말은 요즘 어느 회의실에서나 나옵니다.저도 이 말을 참 많이 하고 다녔는데, 실제로 데이터를 근거로 몇 번 잘못된 결정을 내려본 뒤로는 이 문장을 좀 더 조심스럽게 쓰게 됐습니다.이번 글에서는 저희 팀이 데이터를 잘못 해석했던 구체적인 사례들과, 그걸 겪으면서 세운 나름의 원칙들을 정리해보려고 합니다. 함정 1 - 상관관계를 인과관계로 착각하기 가장 흔하면서도 가장 무섭게 반복되는 함정입니다.저희는 한때 "튜토리얼 영상을 끝까지 본 사용자의 30일 리텐션이 그렇지 않은 사용자보다 40% 높다"는 데이터를 보고, "튜토리얼 영상을 강제로 다 보게 만들면 리텐션이 올라갈 것이다"라는 결론을 내렸습니다.그래서 온보딩 과정에 튜토리얼 영상을 스킵할 수 없게 만들었어요.결과는 ..

비대면 시대 온보딩 UX 재설계

비대면이 일상이 되면서 저희 서비스의 온보딩 화면도 다시 들여다볼 필요가 생겼습니다.기존 온보딩은 "오프라인 매장에서 직원이 설명해주는 걸 보완하는" 정도의 역할이었는데, 매장 방문 자체가 줄어드니 온보딩 화면이 유일한 첫 접점이 되어버린 거예요.이 변화를 겪으며 재설계했던 과정을 정리해봅니다. 기존 온보딩 화면은 세 장짜리 슬라이드로 되어 있었습니다."이 서비스는 이런 겁니다", "이런 기능이 있습니다", "시작해볼까요?" 순서였는데, 이건 사용자가 이미 오프라인이나 지인 추천으로 서비스에 대한 기본 개념을 알고 들어온다는 전제 위에 만들어진 거였어요.비대면으로 신규 유입이 늘면서 이 전제가 깨졌습니다.사용자 인터뷰를 해보니 "이 서비스가 뭘 해주는 건지 슬라이드를 봐도 잘 모르겠다"는 반응이 많았어요..

A/B 테스트가 필요한 순간과 필요 없는 순간

A/B 테스트를 알게 되면 한동안은 모든 결정을 테스트로 하고 싶어집니다.저도 그랬어요.버튼 문구도, 아이콘 모양도, 배너 순서도 일단 둘로 나눠서 돌려보자는 생각이 들더라고요.그런데 하다 보니 테스트가 오히려 일을 느리게 하거나, 아무 결론도 못 내는 경우를 몇 번 만났습니다.오늘은 테스트를 하는 것이 맞는 순간과 하지 않는 편이 나은 순간을 나눠서 정리해 봅니다. 먼저 테스트가 제 몫을 하는 경우입니다.첫째, 결과를 되돌리기 어렵거나 영향이 큰 변경일 때입니다.가입 과정을 통째로 바꾸거나 결제 화면의 흐름을 바꾸는 것처럼 수익이나 핵심 지표에 크게 닿는 변경은 일부 사용자에게 먼저 시험해 보는 것이 안전합니다.둘째, 팀 안에서 의견이 팽팽하게 갈릴 때입니다.서로 다른 안이 모두 그럴듯하고 근거가 비슷..

히트맵 도구 기반 개선 사례를 읽는 법

히트맵 도구를 써서 화면을 개선했다는 사례를 접할 기회가 늘었습니다.붉게 달아오른 화면 이미지는 한눈에 이해되는 것처럼 보여서 설득력이 있어요.그래서 오히려 조심해서 읽어야 한다고 생각하게 되었습니다.오늘은 특정 제품이나 사례가 아니라, 히트맵 기반 사례를 읽을 때 제가 던지는 질문들을 정리해 보려고 합니다. 히트맵은 사용자가 화면의 어디를 클릭했는지, 얼마나 아래까지 내려갔는지, 마우스가 어디에 머물렀는지를 색으로 모아 보여 주는 방식입니다.여러 사람의 행동을 한 장에 겹쳐서 보여 주는 것이 핵심이에요.그래서 한 사람 한 사람의 이유는 보이지 않고, 많은 사람이 어떤 경향을 보였는지만 보입니다.이 점을 먼저 머릿속에 두면 해석이 한결 안전해집니다.히트맵은 "무엇이 일어났나"를 알려 주는 도구이고, "왜..

페이지 하단 콘텐츠의 스크롤과 클릭 지표 읽기

긴 페이지를 기획할 때마다 하단에 넣은 콘텐츠를 사람들이 과연 볼까 하는 걱정이 생깁니다.디자인 시안에서는 아래까지 다 예쁘게 채워 놓았는데, 실제로는 절반도 안 내려간다는 이야기도 자주 들었어요.그래서 스크롤과 클릭 지표를 어떻게 읽고 하단 배치를 어떻게 판단할지 정리해 보려고 합니다. 스크롤 도달률은 방문자 중 몇 퍼센트가 페이지의 어느 지점까지 내려갔는지를 보여 주는 지표입니다.보통 25퍼센트, 50퍼센트, 75퍼센트, 100퍼센트 지점처럼 구간을 나누어 봐요.여기서 먼저 생각해야 할 것은 "도달"이 "읽음"과 같지 않다는 점입니다.빠르게 휙 내려가면서 지나쳤어도 도달로 계산될 수 있어요.그래서 저는 도달률과 함께 그 구간에 머문 시간이나 그 구간 안의 클릭을 같이 봅니다.또 하나 주의할 점은 첫 ..

퍼널 분석, 어디부터 볼 것인가

분석 도구를 열어 보면 숫자가 정말 많아요.방문자 수, 페이지뷰, 체류 시간, 클릭 수까지 다 중요해 보여서 어디부터 봐야 할지 막막해질 때가 있습니다.이럴 때 제가 가장 먼저 꺼내는 틀이 퍼널 분석이에요.퍼널은 깔때기라는 뜻으로, 사용자가 서비스에 들어와서 목표 행동까지 가는 과정을 단계로 나누고 단계마다 몇 명이 남는지 보는 방법입니다. 깔때기의 위쪽은 넓고 아래쪽은 좁아요.방문한 사람이 모두 가입하지는 않고, 가입한 사람이 모두 구매하지는 않으니까요.단계가 내려갈수록 사람이 줄어드는 건 자연스러운 일이에요.문제는 줄어드는 정도가 단계마다 균등하지 않고, 유독 많이 빠지는 곳이 있다는 점입니다.퍼널 분석의 목적은 그 유독 많이 빠지는 곳을 찾아서 "왜"를 묻는 데 있어요.숫자를 예쁘게 정리하는 게 목..