로그인, 회원가입 서비스 기획 체크리스트
온보딩 기획자가 고민해 보면 좋을 것들
모 앱서비스의 로그인, 회원가입 플로우차트앱서비스라면 사용자가 가장 처음 사용하는 기능은 보통 회원가입과 로그인입니다. 요즘 웬만한 앱서비스는 거의 대부분 소셜로그인을 지원합니다. 자동 로그인도 지원합니다. 앱 클라이언트가 핸드폰에 설치돼 있다면 로그인 세션을 계속 유지해서 사용자가 앱에 진입할 때마다 다시 로그인하지 않아도 되도록 합니다.
온보딩 서비스 기획자는 사용자가 회원가입과 로그인을 편리하게 경험할 수 있도록 고민하는 사람입니다. 회원가입과 로그인을 기획하며 어떤 것들을 고민해 보면 좋을까요?
1. 온보딩, 이용 가이드
온보딩, 이용 가이드, 회원가입, 로그인을 담당하는 기획자는 우리 서비스를 처음 사용하는 사람들에 대해 고민합니다. 온보딩은 짧게 제공하는 게 좋습니다. 사용자가 서비스를 최대한 빨리 경험할 수 있도록 유도하는 게 더 중요합니다.
앱 <듀오링고> 처럼, 온보딩에서 개인화된 경험을 제공할 수도 있습니다. 하지만 온보딩에서 중요한 것은 우리 서비스를 지속적으로 사용할 첫 번째 동기를 심어 주는 것입니다. 온보딩에서 지쳐버린 사용자가 우리 서비스를 계속 사용할 이유는 없겠죠. 다음은 온보딩과 이용 가이드 서비스를 기획하며 확인해 보면 좋은 목록입니다.
[ ] 앱을 시작할 때만 온보딩을 보여 주고 싶다. 앱 시작 기준은 클라이언트와 계정정보 서버 중에서 어느 쪽으로 정해야 할까?
[ ] 사용자는 이용 가이드를 다시 보려면 어떻게 해야 할까?
[ ] 온보딩을 스킵하고 서비스를 바로 사용할 수 있는 기능을 제공해야 할까?
기획 측면에서 괜찮아 보이는 온보딩 서비스 사례를 소개합니다.
세탁 배송 서비스 '런드리고'런드리고
- 좋은 점: '둘러보기'로 온보딩을 생략할 수 있는 조건을 제공한다.
- 눈에 띄는 점: 가장 큰 목표인 '회원가입/로그인' 액션을 접근성이 좋은 화면 우측 하단에 위치했다.
영어회화 학습 서비스 'Cake'Cake
- 좋은 점: 스플래시➡️알림 설정 후에 곧바로 메인 서비스인 학습콘텐츠를 제공한다.
- 아쉬운 점: 학습콘텐츠를 생략하고 대시보드를 바로 볼 수 있는 기능을 제공하면 어땠을까? 장점이자 단점.
2. 회원가입, 회원탈퇴 원칙
회원가입을 해야 로그인을 할 수 있겠죠. 모든 서비스에 회원가입이 필요한 것은 아닙니다. 회원정보를 저장할 필요가 있는 서비스에만 회원기능을 포함해야 합니다. 회원시스템을 넣게 되면 DB 관리도 해야 하고, 개인정보 약관 이슈도 있어서 관리할 영역이 많아지기 때문이에요. 다음은 회원가입과 회원탈퇴 서비스를 기획하며 고려해 보면 좋은 사항입니다.
[ ] 우리 서비스는 회원가입 기능이 꼭 필요한 서비스인가?
[ ] 우리 서비스는 회원가입을 해야 시작할 수 있는 서비스인가?
[ ] 회원가입은 언제, 어떻게 할 수 있는가?
[ ] 회원가입을 할 수 없는 사용자가 있는가?
[ ] 모든 사용자의 권한은 동일한가? 사용자의 서비스 이용 권한은 어떤 것인가?
[ ] 권한이 다른 사용자도 같은 회원가입 절차를 밟는가?
[ ] 회원가입을 완료한 사용자는 회원 이용약관을 어떻게 확인할 것인가?
[ ] 탈퇴할 수 없는 사용자가 있는가?
[ ] 탈퇴한 사용자의 서비스 정보는 언제까지 관리할 것인가?
[ ] 소셜계정, 또는 우리 서비스를 탈퇴한 사용자가 다시 회원가입할 때, 이전 계정정보를 새 계정에 덮어쓸 수 있을까?
[ ] 닉네임은 언제 설정하는가?
[ ] 닉네임은 어떻게 설정하는가?
[ ] 우리 서비스에서 부여한다.
[ ] 사용자가 직접 설정한다.
[ ] 닉네임은 회원 간에 중복하여 사용할 수 있는가?
[ ] 닉네임에 포함되면 안 되는 문자가 있나? 포함되면 안 되는 문자는 어떻게 관리할 것인가?
[ ] 사용할 수 없는 닉네임이 있는가? 사용자가 설정한 닉네임을 사용할 수 없는지는 언제 안내할 것인가?
[ ] 설정한 닉네임은 변경할 수 있는가?
3. 로그인의 종류
일반 로그인과 소셜 로그인으로 구분합니다. 일반 로그인은 소셜 로그인을 제외하고, 사용자가 아이디와 비밀번호를 요청 헤더에 입력하는 통상적인 방식으로 생각해 주세요.
우리가 많이 접하는 구글, 페이스북 등의 소셜 로그인은 누구나 개발할 수 있도록 인터페이스를 공개하고 있습니다. 카카오 로그인은 카카오와 이해관계가 좋지 않다면 제휴에 이슈가 있는 것으로 알고 있습니다. 다음은 로그인의 종류를 정하며, 특히 소셜로그인을 기획하며 고려해 보면 좋은 사항입니다.
[ ] 일반 로그인과 소셜 로그인, 사용자가 어떤 방법을 더 많이 이용하도록 해야 할까?
[ ] 다수의 소셜 로그인을 제공한다면 소셜 로그인의 순서는 화면상에 어떻게 배치해야 할까?
- 사용자가 최근 이용한 순서대로 개인화해서 제공한다.
- 우리 서비스 사용자들이 많이 이용하는 순서대로 제공한다.
- 운영자 또는 개발자가 수동으로 순서를 조정할 수 있도록 제공한다.
- ABC 순서대로 제공한다.
[ ] 다수의 소셜 로그인을 제공한다면 한 화면에 모든 소셜 로그인 옵션을 다 보여줘야 할까?
[ ] 앱을 iOS App Store에 게시하는 경우, Apple 로그인을 찾기 용이한가?
- 소셜로그인 첫 화면에서 Apple 로그인을 찾지 못하는 이슈는 iOS 마켓 리젝사유 중 하나입니다.
4. 로그인 정보
로그인의 종류를 정하고 나면 로그인 정책에 대해 더 깊이 고민합니다. 협업하는 팀마다 스타일이 다르니 아래의 내용을 충분히 고민해 보고 클라이언트, 서버 개발자들과 원만한 협의 하시길 바랍니다.
[ ] 사용자는 앱을 시작할 때마다 로그인을 해야 할까?
[ ] 자동 로그인을 지원한다면 로그인 만료 날짜를 설정해야 할까?
[ ] 자동 로그인을 지원하지 않는다면, 새 브라우저를 열거나 앱이 백그라운드로 갔을 때 사용자가 다시 로그인을 하게 해야 할까? 로그인 세션은 얼마나 유지해야 할까?
[ ] 로그인 세션 서버의 연결이 실패하면 몇 번이나 재시도해야 할까? 사용자에겐 어떻게 안내해야 할까?
[ ] 웹과 앱을 지원하는 서비스에서 사용자가 웹에서 로그인했을 때 앱의 로그인 세션은 어떻게 해야 할까?
[ ] 다중 디바이스를 지원하는 서비스에서 사용자가 로그아웃했을 때 모든 디바이스에서 로그아웃해야 할까?
[ ] 이미 회원가입된 사용자가 다른 소셜 계정으로도 로그인할 수 있도록 해야 할까? 우리 서비스는 사용자를 어떻게 구분해서 관리할까?
