앱을 출시하려면 필요한 것들
가능하면 시간이 있을 때 미리 챙겨 보세요!
(이전 글) 이제 디자인까지 완료하고, 완료한 디자인을 클라이언트 레벨까지 입혔습니다. 이제 본격적으로 앱을 출시하기 위해 준비해 볼까요? 사실 Android/iOS 클라이언트나 서버 개발 입장에서도 할 일이 많지만, 저는 디자이너이기 때문에 디자인과 프로덕트 전체적인 관점에서 앱 출시를 위해 준비해야 할 것들이 무엇일지 간단하게 정리해보았습니다.
디자인 측면에서 준비해야 할 것들
1. 앱아이콘
각 OS별로 다양한 사이즈의 아이콘이 필요합니다. 특히 Android 런처 아이콘의 경우 리소스를 제조사 혹은 런처 앱에서 지정한 쉐입으로 마스킹하기 때문에 충분한 테스트 후 이미지를 적절하게 구성해야 합니다. 대부분 정방형에서 각을 약간 둥글린 Rounded Square 형태나, 거기서 좀 더 원형에 가깝도록 더 굴린 Squircle, 아예 사각의 형태가 남아 있지 않은 Circle 형태가 있습니다.
일일이 그려서 테스트하는 것이 번거로운 경우, 피그마에서는 커뮤니티를 통해 간단하게 테스트도 할 수 있고 아이콘도 출력할 수 있는 파일을 다운받을 수 있습니다. (https://www.figma.com/community/file/824894885635013369/App-Icon-Toolkit---iOS%2FmacOS%2FAndroid) 디자인한 아이콘을 Icon Art 컴포넌트에 넣으면 각 OS별로 적용되어 있는 화면을 미리볼 수 있고 사이즈별로도 자동으로 제작해줘서 손쉽게 리소스를 제작할 수 있습니다. (저는 그래도 안 맞는 부분이 있어서 테스트만 이 파일을 통해서 진행하고 실제로 제작할 때에는 각 OS별로 다시 그려서 제작하였습니다.)
같은 리소스를 다른 쉐입으로 마스킹했을 때 깎임 정도2. 스플래시 (런처 스크린)
스플래시는 첫 화면을 암시하는 플레이스 홀더(내용을 불러오지 못할 경우 보여지는 컨텐츠) UI나 앱 아이콘을 띄우는 고전적인 방법 중 선택할 수 있습니다. 카운트다운 앱의 경우 설문을 거친 후 메인 화면으로 이동하는 플로우인데요. 설문을 마친 후 카운트다운이 완성되면 초기화하지 않는 이상 다시 설문 화면이 띄워질 일이 없기 때문에 설문을 마친 사용자와 그렇지 않은 사용자가 보게 되는 첫 화면이 달라지게 됩니다. 따라서 모든 사용자에게 공통으로 보여줄 플레이스 홀더 UI가 없기 때문에 앱 로고를 노출하는 방향으로 정리하게 되었습니다.
각 OS별 스플래시 (런처 스크린) 가이드는 아래 주소에서 확인할 수 있습니다.
- Android : Material Design Guidelines / Developler Splash Screen Guidelines
- iOS : HIG Launch Screen
(좌) 플레이스 홀더 UI / (우) 브랜드 심볼 활용
3. 마켓 이미지
앱의 주요 화면을 스크린샷으로 등록하면 사용자가 서비스를 다운받기 전에 어떤 내용을 제공하는 서비스인지 미리 확인할 수 있습니다. 화면이 많고 복잡한 서비스일수록 가장 핵심이 되는 화면을 노출해주는 것이 사용자의 이해도를 더 높일 수 있겠죠? 뿐만 아니라 화면 그대로 스크린샷에 등록할 수도 있지만, 마케팅 문구 혹은 각 화면을 설명하는 간단한 문구와 함께 노출할 수도 있습니다.
마켓 이미지는 당연히 Android/iOS 각자 요구하는 가이드에 맞게 준비하여야 하며, 특히 iOS의 경우 디바이스와 맞지 않는 형태일 경우(예를 들어 노치가 포함된 디바이스인데, 하위 버전의 디바이스 이미지로 들어가 있다거나) 심사에서 리젝(Reject) 당하는 경우가 있으므로 최대한 가이드에 맞춰 진행하여야 합니다. 혹은 특정 디바이스를 유추할 수 없는 평범한 프레임의 형태로 디자인 하는 것도 디바이스나 OS별로 디자인해야 하는 수고로움을 더는 방법일 수 있습니다.
그리고 Android의 경우 스크린샷 말고 그래픽 이미지를 등록할 수도 있는데, 해당 이미지는 OG태그(Open Graph Tag)로 카톡이나 다른 메시징 서비스를 통해 채팅방에 링크가 공유되었을 때 노출되는 미리보기 이미지 규격과 유사하여 최적화된 형태로도 노출될 수 있으므로, 가능하면 등록하는 것이 좋겠습니다.
각 OS의 가이드를 잘 숙지해서 두세번 이미지를 작업하는 일이 없도록 꼼꼼하게 준비하는 것이 시간을 절약하는 길입니다.
- Android : Google Play Store Image Guidelines
- iOS : App Store Screenshot Guidelines
프로덕트 관점에서 준비해야 할 것들
QA(Quality Assurance)
볼륨이 큰 서비스의 경우 꼭 거쳐야 하는 단계로, 실제 사용자가 서비스를 사용할 때의 동선을 미리 다양한 시나리오로 만들어서 각 시나리오별로 오류가 발생하진 않는지, 실제로 기획한대로 잘 동작하는지 서비스의 품질을 검증하는 과정입니다. 작은 서비스라도 대표 시나리오별로 꼭 테스트 후 앱 리뷰어(앱 출시전 Google이나 Apple에서 해당 앱이 각 OS별 마켓에 적합한 서비스인지 검증하는 역할을 하는 사람)에게 제출해야 리젝을 당하지 않습니다. 앱 리젝 때문만 아니라 실제 사용자가 사용했을 때에도 모든 동선이 매끄러울 수 있도록 충분히 테스트를 거쳐 어색한 부분은 수정한 후 출시해야 합니다.
로그(Log) 정의
여기서는 간단하게 설명하겠지만, 서비스는 출시한 후 그대로 끝이 아니라 그 때부터 시작이죠! 따라서 오픈 이후에 사용자가 어떤 화면에서 어떤 기능을 많이 쓰는지, 혹은 서비스를 사용하면서 어떤 부분이 불편한지, 내가 서비스에 마케팅 이벤트를 개설하고 싶은데 어떤 사용자를 타겟으로 어느 시점에 개설해야 하는지 등의 정보를 수집하여 서비스 개선이나 마케팅 등에 활용할 수 있습니다. 이러한 정보를 얻으려면 화면별/기능별로 사용자의 발자취인 로그를 심어놔야 하는데, 요즘은 Google Analytics라는 툴을 통해 쉽게 확인하고 분석할 수 있습니다. 다만 양질의 정보를 얻기 위해서는 나중에 어떤 부분이 확인이 필요할지 미리 시나리오를 점검하여 적절한 곳에 로그를 정의하는 것이 좋습니다.
앱 기본 정보
Android/iOS 모두 앱을 심사받기 위해 제출하려면 앱의 기본 정보가 필요합니다. 잘 정돈된 기본 정보들은 마켓에 서비스를 제출할 때 뿐만 아니라 추후 내 앱을 알릴 어떤 기회가 있든 그때마다 생각할 필요없이 미리 만들어 둔 문구를 바로 전달하거나 노출할 수 있기 때문에 초반에 잘 구성해두는 것이 좋겠습니다.
일반적으로 아래와 같은 내용들이 필요합니다.
1) 서비스 소개 문구 : 간략하게 보여줄 한 줄 정도의 문구와 앱 업데이트 내용이 구체적으로 들어간 버전 두 가지를 미리 작성해두면 좋습니다.
2) 개인정보처리방침 등의 약관문서 : 일일이 문구를 만들 필요없이 개인정보보호 포털에 접속하여 필요한 정보를 입력 및 선택하면 문서를 만들어줍니다.
3) 웹사이트 : 제작자의 이력 및 간단한 소개를 보여줄 수 있는 웹사이트도 있으면 좋습니다. 저의 경우 도메인을 따고 디자인해서 사이트를 새로 만들거나 하지 않고(그 정도로 소개할 내용이 많지는 않기 때문에) 노션을 통해 간단한 문서를 만들었습니다. (아래 이미지 참고)
자, 그럼 모든 준비는 끝났습니다! 이제 심사를 위해 제출하려 가볼까요?
