본격적인 기획의 시작
앞에서 세운 대략적인 플로우를 가지고 프로덕트를 만들기 위한 기획을 시작하였다. 기능 기획부터, 페이지 기획, 개발 기획까지 나름대로의 순서를 정하고 차근차근 진행해보았다.
기획 단계에서 내가 따랐던 순서는 다음과 같다.
- 필요한 기능 리스트업
- 사용자 군/권한 분류
- 데이터 테이블 제작
- 전체 플로우 기획
- 와이어프레임 제작
앱에 필요한 대표적인 기능
우선 앱이 가져야 할 기능들을 최대한 많이 떠올려보며 정리해보았다. 출석이라는 기능 자체는 굉장히 단순하게 느껴질 수도 있지만, 실제 동아리 운영에서는 생각보다 다양한 상황과 요구사항이 존재하기 때문에, 그에 따른 기능도 꽤 세분화되었다.
필수 기능
- 로그인/회원가입
- 동아리 생성
- 동아리 가입
- 세션 생성 및 관리
- 출석 체크 (QR 방식)
- 출석 현황 실시간 확인
- 출석 정보 수정
- 출석 변경 요청 및 승인
- 출석 통계 확인
추가적으로 고려한 기능
- 기수 전환 (새 학기 시작 시 데이터 분리)
- 결석 사유 제출
- 사용자 초대 (링크, 코드 등)
- 권한 커스터마이징
- 알림 기능 (세션 시작, 출석 누락, 변경 승인 등)
모든 기능을 한 번에 다 구현하는 것은 어려울 수 있기 때문에, 필수 기능을 먼저 MVP로 설정하고, 나중에 점차 부가기능을 붙이는 방식으로 접근하려고 했다.
사용자 권한 분류
앞선 글에서 역할(회장, 임원진, 회원)로 사용자 그룹을 나눴었다. 그런데 실제로 기획을 하다 보니 ‘역할’보다는 ‘권한’ 중심으로 설계하는 게 더 자연스럽다는 결론에 도달했다.
예를 들어, 모든 임원진이 출석을 관리하는 건 아니고, 어떤 임원은 홍보만 담당할 수도 있다. 그런데 단순히 ‘임원진’이라는 역할 하나로 뭉뚱그려서 권한을 부여하면 실제 사용상 제약이 생길 수밖에 없다.
그래서 사용자에게는 역할 대신 권한을 매핑해주는 구조를 고민하게 되었다.
예를 들어 아래와 같은 권한이 있다면,
- 출석 체크 권한
- 세션 생성 권한
- 회원 초대 권한
- 출석 수정 승인 권한
- 통계 열람 권한
이 중 어떤 권한을 줄지 유동적으로 설정할 수 있도록 만들면, 동아리 특성에 맞게 자유도가 생길 수 있다.
물론 너무 복잡하게 만들면 오히려 사용성이 떨어질 수 있으니, 기본 권한 세트(회장, 임원, 회원)는 기본값으로 제공하고, 필요에 따라 커스터마이징 할 수 있도록 만드는 구조가 좋다고 판단했다.
데이터 구조 설계
이제 기능과 권한을 어느 정도 정리하고 나니, 이걸 어떻게 데이터로 저장하고 관리할지에 대한 고민이 생겼다.
가장 핵심이 되는 데이터는 아래 네 가지였다.
- 동아리
- 회원
- 세션(=출석 이벤트)
- 출석 기록
하지만 실제로 기획을 진행하다 보니, 한 동아리가 한 기수로 끝나는 게 아니라 계속 운영된다는 점이 중요했다. 그래서 기수라는 개념을 명확히 분리해서, 동아리 > 기수 > 세션 > 출석 형태로 연결되도록 구조를 잡았다.
동아리
└─ 기수
└─ 세션
└─ 출석 기록
회원은 동아리에 소속되되, 각 기수마다 출석 기록이 분리되어야 했고, 같은 사람이 여러 기수에 중복 참여하는 경우도 고려해야 했다.
이런 구조를 통해 나중에 과거 출석 데이터를 기수 단위로 분리해서 확인할 수 있도록 했다.
사용자 흐름 정리
데이터 구조가 정리되면 그 데이터를 기반으로 사용자가 앱을 어떻게 이용하게 될지 시나리오를 만들어야 했다.
회원의 흐름
- 앱 설치 → 로그인 → 초대코드로 동아리 가입 → 세션 참여 → QR 찍기 → 출석 결과 확인
- 누락 시 출석 변경 요청 → 결석 사유 제출
임원진의 흐름
- 세션 생성 → QR 생성 → 실시간 출석 확인 → 수동 수정 → 출석 확정 → 통계 확인
- 누락 건 승인 처리, CS 대응 등 추가 업무
회장의 흐름
- 동아리 생성 → 회원 초대/권한 부여 → 기수 생성 → 운영 관리
각 사용자별로 어떤 흐름으로 어떤 기능에 접근하는지를 하나하나 정리해서 플로우 차트를 그려보았다. 이 과정을 통해 기능의 누락을 방지할 수 있었고, 실제 UX 흐름에서도 중요한 기준이 되었다.
와이어프레임 제작
기능과 흐름을 정리하고 나서야 비로소 화면이 그려졌다.
Figma를 이용해서 각 페이지의 기본 구조를 만들었고, 사용자 역할별로 어떤 화면에 접근할 수 있는지, 어떤 정보가 보여야 하는지를 기준으로 와이어프레임을 만들었다.
처음에는 너무 많은 화면을 그리려고 했지만, 핵심만 먼저 잡고 세부적인 UI는 나중에 다듬는 식으로 진행했다.
기획하면서 겪은 고민들
가장 많이 걸렸던 부분은 권한과 액션의 연결이었다. 어떤 권한을 가진 사람이 어떤 화면을 보고, 어떤 기능을 조작할 수 있는지를 정의하는 작업이 꽤 까다로웠다
또한, 모바일 환경에서는 제한된 정보만 보여줄 수 있기 때문에, 출석 현황, 세션 관리, 통계 확인 같은 기능에서 정보의 우선순위를 정리하는 데에도 시간이 꽤 걸렸다.
모든 정보를 한 화면에 다 담는 것은 불가능했기 때문에, ‘가장 먼저 확인하고 싶은 정보가 뭘까?’를 계속 고민하면서 화면을 구성했다.
마무리하며
이 글에서는 실제 기획을 어떤 순서로 진행했는지, 어떤 고민을 했고, 어떤 결정을 내렸는지를 중심으로 정리해보았다.
사실 아직도 완벽한 기획은 아니다. 사용하면서 계속 수정하고, 더 나은 방향을 찾게 될 것이다. 하지만 지금까지의 기획은 최소한 내가 원하는 서비스를 구현하기 위한 뼈대가 되어주고 있다.
다음 글에서는 이 와이어프레임을 바탕으로 어떻게 디자인을 만들고 개발을 시작했는지, 또 개발하면서 생긴 기술적인 고민들에 대해 정리해볼 예정이다.