Planning · PM/UX · Product

예약 시스템 어드민 화면, 정보 구조부터 잡기

예약 시스템 기획을 하다 보면 고객이 보는 예약 화면에 신경이 먼저 가기 쉽습니다.그런데 막상 서비스가 돌아가기 시작하면 매일 가장 오래 들여다보는 건 운영하시는 분들이 쓰는 어드민 화면이에요.예약이 아무리 잘 들어와도, 어드민에서 확인하고 고치고 처리하는 일이 불편하면 서비스는 금방 외면받습니다.이 글에서는 어드민 화면을 그리기 전에 정보 구조부터 잡으면서 정리한 생각을 기록해봅니다. 처음에는 기능 목록을 그대로 메뉴로 만들었습니다.예약 관리, 고객 관리, 서비스 관리, 직원 관리, 통계, 설정 같은 식이에요.틀린 구조는 아니지만, 이대로 두면 운영자의 하루와 메뉴가 맞지 않는다는 걸 곧 알게 됐습니다.그래서 운영하시는 분이 하루에 하는 일을 순서대로 적어봤습니다.가정 예시로 동네 미용실 원장님의 하루..

고객 인터뷰 질문, 틀렸던 질문 모음

처음으로 아이템 후보를 가지고 사람들을 만나 이야기를 들어 보기 시작했습니다.기획자로 일하며 사용자 인터뷰를 해 본 적은 있어서 어느 정도 자신이 있었는데, 막상 녹음을 다시 들어 보니 제 질문이 꽤 많이 틀렸더라고요.마침 같은 시기에 고객과 대화하는 법을 다룬 책 한 권(Mom Test라는 이름으로 알려진 책)을 읽고 있었는데, 거기서 말하는 실수가 제 녹음 속에 그대로 들어 있어서 조금 민망했습니다.이 글은 제가 했던 틀린 질문들을 모아서, 왜 틀렸는지와 어떻게 바꾸면 좋을지를 책에서 배운 관점과 함께 정리한 기록입니다. 가장 많이 한 실수는 대답을 미리 정해 놓고 묻는 것이었습니다.예를 들어 이런 식이에요."예약을 전화로 받으면 많이 불편하시죠?"이렇게 물으면 상대는 대개 "네, 좀 그렇죠" 하고 ..

디자인 스프린트 5일 워크숍 후기

구글 벤처스의 디자인 스프린트 방법론을 책으로만 읽다가, 이번에 실제로 5일짜리 워크숍을 팀 내부에서 처음 돌려봤습니다.결과부터 말하면, 계획했던 대로 딱 맞게 진행되진 않았지만 얻은 게 훨씬 많았던 5일이었어요. 첫날은 문제를 다시 정의하는 데 거의 하루를 다 썼습니다.저희 안건은 "장바구니 이탈률을 낮추는 방법"이었는데, 막상 화이트보드에 사용자 여정 지도를 그려보니 이탈 시점이 저희가 생각했던 결제 단계가 아니라 배송비 확인 단계였다는 걸 처음 알게 됐어요.전문가 인터뷰 시간에 CS팀 리드를 초대해서 물어봤는데, "배송비가 갑자기 화면에 뜨는 순간 사용자들이 놀란다"는 말을 듣고 다들 조용해졌던 기억이 나요.이 하루를 그냥 브레인스토밍으로 시작했다면 놓쳤을 통찰이었습니다. 둘째 날은 크레이지 8이라..

디자인 시스템과 기획 문서의 연결고리

디자인 시스템 이야기는 보통 디자이너들의 영역으로 여겨지는데, 저는 기획자로서 이 부분에 꽤 자주 발을 담그게 됐습니다.PRD를 쓸 때마다 "이 화면에 쓸 버튼이 디자인 시스템에 있는 건가, 새로 만들어야 하는 건가"를 판단해야 하는 순간이 계속 생기더라고요.이번 글에서는 기획 문서와 디자인 시스템을 어떻게 연결해서 관리하고 있는지 정리해보려 합니다. 예전에는 요구사항정의서에 "확인 버튼을 크게 배치한다" 같은 식으로 화면을 말로만 설명했습니다.디자이너가 이걸 받아서 작업하다가 "이 버튼, 기존 시스템에 있는 Primary 버튼 쓰면 되나요, 새로 만들어야 하나요?"라고 물으면 저는 답을 못 했어요.결국 디자이너가 임의로 판단해서 작업했다가, 나중에 다른 화면과 스타일이 안 맞아서 다시 고치는 일이 반복..

AI 스피커/보이스 UI 기획 시 고려사항

올해 초 AI 스피커 연동 토이 프로젝트를 맡으면서, 화면 기반 서비스만 기획해오던 저에게는 완전히 새로운 감각이 필요했습니다.화면이 없는 인터페이스를 기획한다는 게 처음엔 막막했는데, 프로젝트를 진행하면서 몇 가지 중요한 원칙들을 배우게 됐어요.이번 글에서는 보이스 UI를 처음 기획하는 분들이 참고할 만한 고려사항들을 정리해봤습니다. 화면 UI에서는 사용자가 버튼을 보고 "이걸 누르면 되겠구나"를 스스로 판단할 수 있습니다.보이스 UI에서는 이게 불가능해요.사용자가 "무엇을 말해야 하는지" 스스로 알기 어렵기 때문에, 매 순간 다음에 무엇을 말할 수 있는지 안내해줘야 합니다.저희가 초반에 만든 프로토타입은 "무엇을 도와드릴까요"라고만 물었는데, 실제 사용자 테스트에서 절반 가까운 사람들이 몇 초간 침묵..

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

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

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

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

이탈률을 낮추기 위한 점검 포인트

이탈률이 높다는 말을 들으면 마음이 급해져요.뭔가 크게 잘못된 것 같고, 당장 화면을 갈아엎어야 할 것 같은 기분이 들거든요.하지만 이탈률은 증상일 뿐이고, 원인은 여러 군데에 있을 수 있어요.그래서 저는 이탈률이 높은 화면을 만나면 늘 같은 순서로 점검하는 목록을 따라가 봅니다.오늘은 그 목록을 정리해 볼게요. 먼저 이탈률이 무엇을 가리키는지 확인해야 해요.분석 도구에 따라 한 페이지만 보고 나간 비율을 말하기도 하고, 해당 페이지에서 서비스를 떠난 비율을 말하기도 해서 정의가 다를 수 있어요.정의를 모르고 숫자만 비교하면 엉뚱한 결론이 나옵니다.또 이탈률이 높다고 늘 나쁜 건 아니에요.전화번호나 영업시간처럼 정보 하나를 찾으러 온 사람은 그걸 보고 바로 떠나는 게 목적 달성이거든요.반대로 가입 폼이나..