소규모 클래스 신청·정원 관리 서비스 — 사용자 흐름

이런 상황을 상상해봅시다. 클래스 소개를 읽고 신청 버튼을 눌렀습니다. 화면에는 “완료”라고 뜹니다.

그런데 운영자의 명단에는 내 이름이 없습니다. 남은 자리도 그대로입니다. 이 상태를 신청이 끝났다고 볼 수 있을까요?

지난주에는 메시지로 신청받는 소규모 클래스 운영자의 문제를 좁혔습니다. 신청·취소 내용을 별도 명단에 옮기고, 현재 참여자와 남은 자리를 확인하려고 대화와 명단을 다시 대조하는 일이 문제 가설이었습니다.

이번 주에는 그 문제를 해결할 사용자 흐름을 설계합니다. 버튼이나 화면을 먼저 나열하는 대신, 누가 무엇을 하면 어떤 결과가 이어져야 하는지 살펴봅니다.

사례는 지난주와 같은 가상의 공방입니다. 운영자 한 명이 정원 6명의 클래스 하나를 열며, 온라인 결제 없이 신청 완료 시 자리를 확보하는 조건으로 시작합니다. 아래 흐름은 실제 인터뷰나 사용 시험을 마친 결과가 아니라, 문제 가설을 바탕으로 만든 설계안입니다.

1. 사용자가 서비스를 찾는 순간부터 시작합니다

운영자는 단순히 명단을 보고 싶어서 서비스를 찾는 것이 아닙니다. 클래스 모집을 시작하고, 신청과 취소가 생길 때마다 현재 참여 인원을 정확하게 확인해야 합니다.

신청자는 클래스 소개를 보고 참여하고 싶어졌을 때 접수 과정에 들어옵니다. 이 사람에게 중요한 것은 버튼을 눌렀다는 사실보다 자신의 신청이 받아들여졌고 자리가 확보됐는지 아는 것입니다.

지난주에 정한 핵심 사용자는 운영자입니다. 신청자도 함께 살펴보는 이유는, 신청자의 접수 행동이 운영자의 명단으로 이어져야 수동 반영을 줄일 수 있기 때문입니다. 두 사람의 시작은 다르지만, 접수 결과는 이어져야 합니다.

운영자의 시작과 끝

클래스 모집을 시작하거나 접수 상황을 확인할 때 서비스를 사용합니다. 확인을 마쳤을 때는 누가 참여하고, 몇 명을 더 받을 수 있는지 알 수 있어야 합니다.

신청자의 시작과 끝

클래스 소개를 읽고 참여하고 싶어졌을 때 접수에 들어옵니다. 신청을 마쳤을 때는 자신의 신청이 받아들여졌고 자리가 확보됐는지 알 수 있어야 합니다.

이렇게 시작과 끝을 먼저 잡으면 흐름의 기준이 생깁니다. 신청자는 완료 안내를 봤는데 운영자는 다시 이름을 옮겨 적어야 한다면, 지난주에 줄이려던 행동이 그대로 남아 있는 것입니다.

2. 두 가지 접수 흐름을 비교해봅니다

처음에는 기존 방식을 조금 편하게 만드는 흐름을 생각할 수 있습니다.

메시지로 신청 → 운영자가 내용을 확인 → 서비스에 신청자를 직접 등록 → 참여자와 잔여석 확인

명단과 잔여석을 한곳에서 볼 수는 있지만, 메시지 내용을 읽고 옮겨 적는 행동은 남습니다. 운영자가 바쁠 때 등록을 미루면 대화와 명단 사이에 다시 차이가 생길 수 있습니다.

다른 흐름도 생각해봅시다.

신청자가 접수 링크에서 신청 → 서비스가 접수 결과를 반영 → 신청자가 완료 확인 → 운영자가 같은 결과 확인

이 흐름은 신청 결과를 운영자가 다시 입력하지 않아도 된다는 점에서 문제 가설과 더 직접적으로 연결됩니다. 그래서 이번 설계안에서는 두 번째 흐름을 기준으로 삼습니다.

다만 링크를 만들었다고 신청자가 사용한다고 볼 수는 없습니다. 신청자가 계속 메시지로만 접수하려 하거나, 운영자가 결국 모든 신청을 대신 입력해야 한다면 기대한 변화가 생기지 않습니다. 접수 경로를 바꿀 수 있는지도 실제 운영에서 확인할 조건입니다.

메시지는 클래스 소개를 전달하거나 문의에 답하는 경로로 남을 수 있습니다. 이번에 바꾸려는 것은 모든 대화가 아니라, 신청 의사가 접수 결과로 기록되는 과정입니다.

3. 신청자와 운영자의 흐름을 연결합니다

선택한 방향을 행동과 반응으로 풀어봅시다. 아래에서 ‘서비스 반응’은 구현된 동작이 아니라, 이 설계안에서 필요한 반응을 뜻합니다.

첫째, 운영자가 모집을 준비합니다.

운영자는 클래스 일정·장소·정원을 정하고 접수를 엽니다. 서비스는 해당 클래스의 안내와 접수 경로를 제공합니다. 운영자는 신청자에게 공유할 경로가 준비됐는지 확인합니다.

둘째, 신청자가 참여할 수 있는지 판단합니다.

신청자는 공유된 링크에서 클래스 내용을 확인합니다. 서비스는 일정·장소와 현재 접수 가능 여부를 보여줍니다. 신청자는 자신의 일정에 맞는지, 지금 신청할 수 있는지 판단합니다.

셋째, 신청자가 정보를 제출하고 접수 결과를 확인합니다.

신청자가 필요한 정보를 입력하고 신청하면, 서비스는 입력 내용과 접수 가능 여부를 확인합니다. 접수가 성립한 경우 명단과 잔여석에 반영하고 신청 완료를 안내합니다. 신청자는 자신의 신청이 받아들여졌는지 확인합니다.

넷째, 운영자가 같은 접수 결과로 현재 인원을 확인합니다.

운영자가 접수 현황을 확인하면, 서비스는 앞에서 성립한 접수 결과를 기준으로 참여 명단과 잔여석을 보여줍니다. 운영자는 신청 내용을 별도로 옮겨 적지 않고 현재 참여자와 남은 자리를 파악합니다.

여기서 중요한 것은 마지막 두 단계의 연결입니다.

신청자에게 완료를 안내하려면 실제로 신청이 접수되어야 합니다. 그 접수 결과가 운영자의 명단과 남은 자리에도 반영돼야 합니다. 완료 안내만 따로 존재해서는 두 사람의 결과가 이어지지 않습니다.

화면 구성은 아직 정하지 않아도 됩니다. 지금은 신청자의 행동이 어떤 반응을 거쳐 운영자의 판단에 연결되는가를 확인하는 단계입니다.

4. ‘완료’는 버튼이 아니라 결과로 정합니다

정원 6명 중 5명이 신청한 상황을 가정해봅시다.

새 신청자 한 명의 접수가 성립하면, 그 사람에게 신청 완료가 안내되어야 합니다. 운영자가 확인하는 현재 참여자는 6명이고, 남은 자리는 0이어야 합니다. 다음 신청자에게는 자리가 있는 것처럼 안내하면 안 됩니다.

이 예시에서 기대하는 핵심 경험은 두 가지입니다.

• 신청자: 운영자의 별도 답장을 기다리지 않고 자신의 접수 결과를 확인한다.

• 운영자: 신청 내용을 다시 옮겨 적거나 대화와 대조하지 않고 현재 참여자와 잔여석을 확인한다.

첫 번째는 접수에 대한 확신이고, 두 번째는 수동 반영과 재확인의 감소입니다. 둘 중 하나만 충족하면 지난주 문제의 일부가 남습니다.

그렇다고 운영자가 신청할 때마다 화면을 열어봐야 하는 것은 아닙니다. 운영자가 확인하는 시점에 최신 접수 결과를 볼 수 있어야 한다는 뜻입니다. 자동 알림이 필요한지는 이 경험을 실제로 확인한 뒤 별도로 판단할 수 있습니다.

5. 취소와 마감에서도 흐름이 끊기지 않아야 합니다

정상 신청만 그리면 흐름이 매끄러워 보입니다. 하지만 지난주 문제에는 취소 반영과 잔여석 확인도 포함돼 있었습니다.

이번 최소 흐름에서는 신청자가 운영자에게 취소를 요청하고, 운영자가 해당 신청을 확인해 취소 처리하는 경로를 먼저 잡습니다. 취소 요청이 도착한 것과 실제 취소가 반영된 것은 구분합니다.

운영자가 취소를 확인하는 일은 남지만, 처리 결과를 다른 명단에 다시 옮기거나 잔여석을 따로 계산하는 일은 줄이려는 흐름입니다. 신청자가 직접 취소하는 방식은 본인 확인과 처리 조건을 함께 검토해야 하므로 이번 흐름에서 먼저 확정하지 않습니다.

취소 요청이 들어왔을 때

운영자가 해당 신청을 확인해 취소 처리하면, 서비스는 참여 명단과 잔여석에 함께 반영해야 합니다. 운영자는 반영된 결과를 확인한 뒤 신청자에게 안내합니다. 이 연결이 빠지면 취소했다고 답했는데도 명단과 잔여석은 그대로일 수 있습니다.

정원이 마감됐을 때

서비스는 새 신청이 접수되지 않았다는 결과와 마감 상태를 알려야 합니다. 자리가 없는데 완료를 안내하면, 신청자는 자리를 확보했다고 생각하지만 운영자는 받을 수 없는 상황이 생깁니다.

같은 신청이 반복됐을 때

서비스는 이미 성립한 신청인지 확인하고, 중복 접수로 자리를 더 차지하지 않도록 결과를 안내해야 합니다. 이 확인이 빠지면 한 사람의 반복 신청이 여러 자리로 계산될 수 있습니다.

접수 결과가 불확실할 때

서비스는 결과를 확인하기 전까지 신청 완료나 실패로 단정하지 않아야 합니다. 신청자가 자신의 접수 결과를 확인할 수 있는 경로도 필요합니다. 그렇지 않으면 신청자가 다시 시도해 중복되거나, 접수되지 않았는데 완료됐다고 생각할 수 있습니다.

반복 신청을 구분하는 기준과 접수 결과를 다시 확인하는 방법은 세부 설계가 필요합니다. 지금은 특정 인증 수단이나 화면을 정하는 대신, 같은 신청의 현재 접수 상태가 일관되게 안내돼야 한다는 흐름의 조건을 남깁니다.

마지막 한 자리에 여러 신청이 겹치는 경우도 같습니다. 처음 안내를 봤을 때 자리가 있었더라도 실제 접수 시점에는 마감됐을 수 있습니다. 따라서 신청 행동 뒤에 접수 가능 여부를 확인하는 반응이 필요합니다. 이를 어떤 방식으로 구현할지는 4주차에서 다룹니다.

이 예외들은 서비스를 크게 확장하기 위한 가지가 아닙니다. 우리가 선택한 접수 흐름이 어디서 끊기는지 확인하기 위한 점검입니다.

6. 처음 흐름에서 무엇이 달라졌을까요?

처음 흐름은 운영자가 메시지를 읽고 명단에 반영하는 방식이었습니다. 이번에는 신청자가 접수 경로에서 행동하면 그 결과가 운영자의 명단까지 이어지는 방식으로 바꿨습니다.

남긴 것은 모집 준비 → 신청 → 접수 결과 확인 → 운영 현황 확인, 그리고 취소 후 명단과 잔여석을 함께 바꾸는 연결입니다. 결제 없이 신청 완료 시 자리를 확보하는 제작 조건도 유지했습니다.

여러 클래스 탐색, 결제, 대기자 등록처럼 별도의 사용자 목적과 처리가 필요한 흐름은 이번 기준 흐름에 붙이지 않았습니다. 접수 결과가 정확하게 이어지는지 먼저 확인하기 위해서입니다. 필요한 화면과 세부 기능의 범위는 다음 주에 이 흐름을 기준으로 정하겠습니다.

실제 확인에서는 “사용하기 편했나요?”라는 질문만으로 끝내지 않습니다. 신청자에게는 접수 결과를 어떻게 이해했는지, 운영자에게는 신청 내용을 다시 입력하거나 대화와 명단을 대조한 일이 있었는지 확인합니다. 취소 뒤에도 다른 명단을 고쳐야 했다면 흐름이 충분히 연결되지 않았을 수 있습니다.

기존 폼만으로 같은 결과를 충분히 얻고 있다면 새 서비스의 필요성을 다시 검토해야 합니다. 실제 운영 방식이 입금 확인 후 자리 확정이라면, 신청 완료를 접수의 끝으로 정한 조건부터 재검토해야 합니다.

7. 여러분의 아이디어도 행동과 결과로 적어보세요

자신의 아이디어나 본문 사례를 살펴볼 때도 사용자 한 명과 상황 하나에서 출발합니다. 흐름은 다음 네 가지로 풀어볼 수 있습니다.

1. 계기: 사용자는 어떤 상황에서 이 서비스를 찾는가?

2. 행동: 사용자는 무엇을 하는가?

3. 반응: 그 행동을 받은 서비스는 무엇을 확인하고 바꾸는가?

4. 결과: 사용자는 무엇을 보고 자신의 일이 끝났다고 판단하는가?

예를 들어 “신청 기능이 필요하다”를 다음처럼 바꿀 수 있습니다.

클래스에 참여하고 싶은 사람이 신청 정보를 제출한다. 서비스는 접수 가능 여부를 확인하고, 접수가 성립하면 명단에 반영한다. 신청자는 자신의 신청이 완료됐음을 확인한다.

관련 사용자가 있다면 결과를 한 단계 더 연결합니다. 이번 사례에서는 신청 완료가 운영자의 현재 참여 명단으로 이어집니다.

정상적으로 끝나지 않는 상황에서도 결과가 이어지는지 살펴봅니다. 자리가 없거나, 같은 요청이 반복되거나, 처리 결과를 알 수 없을 때 사용자가 무엇을 확인할 수 있는지 점검합니다.

버튼을 누른 뒤에도 사람이 같은 일을 다시 해야 한다면, 어느 연결이 빠졌을까요?

이번 주에 남긴 것

이번 주에는 화면 목록 대신 다음 흐름의 기준을 남겼습니다.

• 시작: 운영자는 모집을 준비하고, 신청자는 클래스 참여를 결정한다.

• 신청 흐름: 접수 정보 제출 → 접수 가능 여부 확인 → 성립한 신청을 명단·잔여석에 반영 → 신청자에게 결과 안내

• 운영 흐름: 운영자가 같은 접수 결과를 바탕으로 현재 참여자와 잔여석을 확인한다.

• 취소 흐름: 운영자가 요청을 확인해 취소 처리 → 명단·잔여석 반영 → 처리 결과 확인 후 신청자에게 안내

• 끊김 점검: 마감·중복·불확실한 결과가 완료로 잘못 안내되지 않는가?

• 검증할 변화: 운영자의 옮겨 적기와 재대조가 줄고, 신청자가 자신의 접수 결과를 이해하는가?

이 흐름은 아직 검증 전 설계안입니다. 접수 링크를 실제로 사용할 수 있는지와 운영자의 일이 줄어드는지는 사용자 확인이 필요합니다.

다음 주에는 이 흐름을 첫 MVP의 기능 범위로 바꿉니다. 각 단계를 성립시키는 데 필요한 것과, 없어도 첫 검증이 가능한 것을 나눠보겠습니다.

이번 주 한 장 실습

어떤 흐름이 끝까지 이어져야 할까요?

내 상황이나 본문의 가상 클래스 사례 중 하나를 골라 아래 세 칸을 채워보세요. 앞에서 살펴본 사용자 흐름을 한 장에 정리하는 실습입니다.

1. 시작과 완료: 누가 언제 시작하고, 무엇을 확인하면 자신의 일이 끝났다고 판단하나요?

2. 최소 흐름: 계기 → 행동 → 서비스 반응 → 확인 결과를 연결해 적어보세요.

3. 끊김과 보완: 헷갈리거나 끊길 상황 하나와 보완 생각을 적어보세요. 아직 모르면 ‘미확인’과 다음 확인 질문을 남겨도 됩니다.

본문 사례를 선택했다면 신청자의 완료가 운영자의 명단·잔여석에도 이어지는지 함께 살펴보세요. 가상 사례를 바탕으로 만든 설계안이므로, 실제로 검증한 결과와 구분해 적습니다.

막히면 ‘정원 6명 중 5명이 신청한 상황’을 골라 새 신청자 한 명의 접수가 끝난 모습부터 적어보세요.

첨부 된 PDF를 인쇄하거나 태블릿에서 필기해보세요. 시작과 완료가 분명하고, 행동 뒤 서비스 반응과 확인 결과가 이어지며, 끊김 하나에 보완 생각 또는 다음 확인 질문을 남겼다면 이번 실습의 초안이 완성됩니다.

여러분이 이 클래스에 신청한다면, 무엇을 확인해야 “내 자리가 확보됐다”고 안심할 수 있을까요? 완료 문구, 신청 내역, 잔여석 표시 중 가장 중요하다고 생각하는 하나와 이유를 댓글로 남겨주세요. 워크북에 적은 판단을 한 문장으로 공유해도 좋습니다. 🙌