HIG 읽기 - Accounts

2dubu·2022년 5월 3일
0

HIG 읽기

목록 보기
9/13

오역이 있을 수 있습니다! 영문 문서를 기본으로 하고 이 글은 참고하는 느낌으로 봐주시면 좋을 것 같습니다. 😊

Human Interface Guidelines - Accounts

Accounts

Ask people to create an account only if your app’s core functionality requires it; otherwise, let people enjoy your app without one. If your app requires an account, consider using Sign in with Apple to give people a consistent sign-in experience they can trust and the convenience of not having to remember multiple accounts and passwords.

앱의 핵심 기능을 위해 필요한 경우에만 사용자에게 계정을 생성하도록 요청하세요. 그렇지 않다면 사용자가 계정 생성 없이 앱을 즐길 수 있도록 하세요. 앱에서 계정이 필요한 경우 Apple 로그인을 사용해 사용자에게 신뢰할 수 있는 일관된 로그인 경험과 여러 계정과 암호를 기억할 필요 없는 편리함을 제공하는 것을 고려하세요.


Explain the benefits of creating an account and how to sign up. If your app requires an account, write a brief, friendly description of the reasons for the requirement and its benefits, and display this message on the sign-in screen.

계정 생성의 이점과 가입 방법을 설명하세요. 앱에 계정이 필요한 경우 요구 사항의 이유와 이점에 대해 간략하고 친절한 설명을 작성하고 로그인 화면에 이 메시지를 표시하세요.


Delay sign-in for as long as possible. People often abandon apps when they’re forced to sign in before they can do anything useful. To help avoid this situation, give people a chance to appreciate your app before asking them to make a commitment to it. For example, a shopping app might let people browse as much as they want, requiring sign-in only when they’re ready to make a purchase.

로그인을 최대한 오래 미루세요. 사용자들은 유용한 작업을 수행하시 전에 강제로 로그인해야 하는 경우 종종 앱을 포기합니다. 이러한 상황을 피하려면, 사용자들에게 앱에 대한 약속을 하도록 요구하기 전에 앱에 대해 감사할 수 있는 기회를 제공하세요. 예를 들어, 쇼핑 앱은 사용자들이 원하는 만큼 앱을 구경할 수 있도록 하고 그들이 구매할 준비가 되었을 때에만 로그인을 요구합니다.


If you don’t use Sign in with Apple, use Password AutoFill. Password AutoFill automatically generates and fills in passwords and security codes so people can spend less time on authentication screens. For developer guidance, see Password AutoFill.

Apple 로그인을 사용하지 않는 경우 암호 자동 완성을 사용하세요. 암호 자동 완성 기능은 암호와 보안 코드를 자동으로 생성해 입력하므로 사용자가 인증 화면에 머무는 시간을 줄일 수 있습니다. 개발자를 위한 자세한 내용은? Password AutoFill


Avoid using the term passcode to refer to account authentication. People create a passcode to unlock their device or authenticate for Apple services, so people might think you’re asking them to reuse it in your app. Consider alternative terms like password, PIN, code, pass phrase, key, or access code.

passcode라는 용어를 계정 인증에 사용하지 마세요. 사용자는 디바이스의 잠금을 해제하거나 Apple 서비스를 인증하기 위해 passcode를 생성하기 때문에 앱에서 재사용하도록 요청하는 것으로 생각할 수 있습니다. password, PIN, code, pass phrase, key 또는 access code와 같은 대체 용어를 고려하세요.


Account Deletion

If you help people create an account within your app, you must also help them delete it, not just deactivate it. In addition to following the guidelines below, be sure to understand and comply with your region’s legal requirements related to account deletion and the right to be forgotten.

사용자가 앱 내에서 계정을 생성하도록 도왔다면 비활성화뿐만 아니라 삭제할 수 있도록 도와야 합니다. 아래 지침을 따르는 것 외에도 계정 삭제 및 잊혀질 권리와 관련된 해당 지역의 법적 요구 사항을 이해하고 준수하세요.

IMPORTANT
If legal requirements compel your app to maintain accounts or information — such as digital health records — or to follow a specific account-deletion process, clearly describe the situation so people can understand the information or accounts you must maintain and the process you must follow.

법적 요구 사항으로 인해 앱이 디지털 건강 기록과 같은 계정 또는 정보를 유지하거나 특정 계정 삭제 프로세스를 따라야 하는 경우, 사용자가 유지해야 하는 정보 또는 계정과 사용자가 따라야 하는 프로세스를 사람들이 이해할 수 있도록 상황을 명확하게 설명하세요.


Provide a clear way to initiate account deletion within your app. If people can’t perform account deletion within your app, you must provide a direct link to the webpage on which people can do so. Make the link easy to discover — for example, don’t bury it in your Privacy Policy or Terms of Service pages.

앱 내에서 계정을 삭제할 수 있는 명확한 방법을 제공하세요. 사용자가 앱 내에서 계정 삭제를 수행할 수 없는 경우 사용자가 계정을 삭제할 수 있는 웹 페이지에 대한 직접 링크를 제공해야 합니다. 링크를 쉽게 찾을 수 있도록 만드세요. 예를 들어 개인 정보 보호 정책 또는 서비스 약관 페이지에 링크를 두지 마세요.


Provide a consistent account-deletion experience whether people perform it within your app or on the website. For example, avoid making one version of the deletion flow longer or more complicated than the other.

앱 내에서든 웹 사이트에서든 상관없이 사용자에게 일관된 계정 삭제 경험을 제공하세요. 예를 들어, 한 버전의 삭제 흐름을 다른 버전보다 더 길게 하거나 더 복잡하게 만들지 마세요.


Consider letting people schedule account deletion to occur in the future. People can appreciate the opportunity to use up their remaining services or wait until their subscription auto-renews before deleting their account. If you offer a way to schedule account deletion, offer an option for immediate deletion as well.

사용자가 향후 계정 삭제를 예약하도록 하는 것을 고려하세요. 사용자들은 계정을 삭제하기 전에 남은 서비스를 사용하거나 구독이 자동으로 갱신될 때까지 기다릴 수 있는 기회를 높이 평가할 수 있습니다. 계정 삭제를 예약할 수 있는 방법을 제공하는 경우, 즉시 삭제할 수 있는 옵션도 제공하세요.


Tell people when account deletion will complete, and notify them when it’s finished. Because it can sometimes take a while to fully delete an account, it’s essential to keep people informed about the status of the deletion process so they know what to expect.

계정 삭제가 언제 완료되는지 알려주고, 계정 삭제가 완료되면 알려주세요. 때때로 계정을 완전히 삭제하는 데 시간이 걸릴 수 있기 때문에, 사람들에게 삭제 과정의 상태를 알려주어 예상되는 작업을 알 수 있도록 하는 것이 중요합니다.


If you support in-app purchases, help people understand how billing and cancellation work when they delete their account. For example, you might need to help people understand the following scenarios:

  • Billing for an auto-renewable subscription continues through Apple until people cancel the subscription, regardless of whether they delete their account.

  • After they delete their account, people need to cancel their subscription or request a refund.

In addition to helping people understand these scenarios, provide information that describes how to cancel subscriptions and manage purchases. For guidance, see Helping People Manage Their Subscriptions and Providing Help with In-App Purchases.

인앱 구매를 지원하는 경우 계정을 삭제할 때 청구 및 취소가 어떻게 작동하는지 이해할 수 있도록 하세요. 예를 들어, 다음과 같은 시나리오를 이해하는 데 도움이 필요할 수 있습니다.

  • 자동 갱신형 구독에 대한 청구는 계정 삭제 여부와 상관없이 사람들이 구독을 취소할 때까지 Apple을 통해 계속됩니다.

  • 계정을 삭제한 후, 사용자는 구독을 취소하거나 환불을 요청해야 합니다.

사용자가 이러한 시나리오를 이해하도록 돕는 것 외에도 구독을 취소하고 구매를 관리하는 방법을 설명하는 정보를 제공하세요. 자세한 내용은? Helping People Manage Their Subscriptions, Providing Help with In-App Purchases


NOTE
Even if people didn’t use your app to purchase the subscription, you still need to enable account deletion.

사용자들이 정기구독을 위해 당신의 앱을 사용하지 않았더라도 계정 삭제를 활성화해야 합니다.

Face ID and Touch ID

Face ID and Touch ID are secure, familiar authentication methods that people trust. When people enable biometric authentication on their device, assume they understand how it works, appreciate its convenience, and prefer to use it whenever possible. Because people might also turn off biometric authentication, be prepared to handle this scenario too.

Face ID와 Touch ID는 사람들이 신뢰하는 안전하고 친숙한 인증 방법입니다. 사용자가 자신의 기기에서 생체 인증을 활성화하면, 작동 방식을 이해하고, 그것의 편리함을 높게 평가하며, 가능한 한 그것을 사용하는 것을 선호한다고 가정합니다. 사람들이 생체 인증도 끌 수 있기 때문에, 이 시나리오도 처리할 준비를 해야합니다.


개발자 지침 Local Authentication

Reduce the complexity of your interface by presenting a single way to authenticate. You can offer a fallback alternative — like asking for a username and password — if the initial method fails.

단일 인증 방법을 제시하여 인터페이스의 복잡성을 줄이세요. 초기 방법이 실패할 경우 사용자 이름 또는 암호를 묻는 것과 같은 대체 옵션을 제공할 수 있습니다.


Initiate authentication only in response to user action. An explicit action like tapping a button ensures that people want to authenticate. In the case of Face ID, it also increases the likelihood that the person is facing the camera.

사용자 작업에 대한 응답으로만 인증을 시작하세요. 버튼을 탭하는 것과 같은 명시적인 동작은 사람들이 인증하기를 보장합니다. Face ID의 경우, 사람이 카메라를 향하고 있을 가능성이 높아집니다.


Always identify the authentication method you offer. For example, if you display a button for signing in to your app with Face ID, title it using a phrase like “Sign In with Face ID” instead of a generic phrase like “Sign In.”

항상 제공하는 인증 방법을 확인하세요. 예를 들어, Face ID로 앱에 로그인하는 버튼을 표시할 경우, "Sign In"과 같은 일반적인 문구 대신 "Sign In with Face ID"와 같은 문구를 사용하여 제목을 지정하세요.


Refer only to authentication methods that are available in the current context. Don’t reference Touch ID on a device that supports Face ID, or reference Face ID on a device that supports Touch ID. Check the device’s capabilities and use the appropriate terminology. For developer guidance, see LABiometryType.

사용할 수 있는 인증 방법만을 참조하세요. Face ID를 지원하는 장치에서 Touch ID를 참조하거나 Touch ID를 지원하는 장치에서 Face ID를 참조하지 마세요. 장치의 기능을 확인하고 적절한 용어를 사용하세요. 개발자 지침은? LABiometryType


In general, avoid offering a setting for opting in to biometric authentication within your app. People enable biometric authentication at the system level, so presenting an in-app setting is redundant and could be confusing.

일반적으로 앱 내에서 생체 인증을 선택하는 설정을 제공하지 마세요. 사람들은 시스템에서 생체 인증을 활성화하기 때문에 앱 내 설정을 표시하는 것은 중복되고 혼동될 수 있습니다.


느낀점

사용자에게 로그인 또는 회원가입을 요구하기 전에 충분한 정보를 제공하자. 또한 가장 간편하고 신뢰도 높은 인증 시스템인 Face ID, Touch ID와 같은 생체 인증 시스템을 적극 고려해보자. (디바이스 별 지원하는 인증 시스템을 잘 확인하고 분기처리 해주는 것 또한 중요하다!)

번역하면서 몰랐던 영단어들을 quizlet이라는 곳에 정리해두었어요. HIG를 읽으면서 영어 실력까지 키우고 싶은 분들에게 도움이 됐으면 좋겠어요!

수정해야 할 부분이 있다면 알려주세요!
읽어 주셔서 감사합니다. 🙂

profile
iOS Developer

0개의 댓글