Login

로그인 페이지는 사용자가 사용자 ID와 비밀번호를 입력하거나 다른 인증 방법을 사용해 애플리케이션에 접근할 수 있게 해주는 패턴이에요.

출처: Login

본문

개요 (Overview)

로그인은 사용자가 제품과 갖는 첫 상호작용인 경우가 많아요. 이 진입점 경험은 제품의 브랜드와 경험을 확립하는 중요한 순간이며 제품과의 전반적인 경험의 톤을 설정합니다.

제목(Title): 로그인 흐름의 상단에 위치해요. 일관성을 위해 제목에는 "Sign in"이나 다른 변형이 아닌 "Log in"이라는 단어가 포함되어야 합니다. 상황에 맞다면 제목에 제품 이름을 포함할 수도 있어요. 필요하면 제목이 다음 줄로 줄바꿈될 수 있습니다.
계정 만들기(Create account, 선택): 계정을 만들기 위한 URX 폼으로의 링크; 이 요소의 위치는 레이아웃에 따라 달라질 수 있어요.
필수 필드(Required fields): 사용자 ID와 비밀번호 필드는 둘 다 필수입니다. 다만 IBM의 선호 로그인 흐름에서는 비밀번호 필드가 사용자 ID에 의존성이 있기 때문에 점진적으로 공개됩니다. 사용자 ID는 보통 이메일 주소 형태입니다. 제품에 따라 이 영역에 ID 유형을 지정하는 필터가 포함될 수도 있습니다.
사용자 이름/비밀번호 잊음 링크(Forgot username/password link): 사용자를 사용자 이름 및/또는 비밀번호를 복구할 수 있는 페이지로 데려가요.
ID 기억(Remember ID, 선택): 사용자 ID를 저장하고 다음 로그인 시 완성된 입력 필드를 제시해요; 필수 필드 아래에 위치합니다. 혼란을 피하려면 무엇을 기억하는지(즉, "user ID") 명확히 하세요.
대체 로그인(Alternative logins, 선택): 순서대로 대체 로그인 방법을 표시합니다.
계속 버튼(Continue button): 기본 콜투액션에 대해 버튼 라벨은 "Continue"여야 해요. 클릭하면 이메일 주소가 검증되고 사용자를 단일 로그온 또는 비밀번호 흐름으로 라우팅합니다.
도움 필요?(Need help?, 선택): 사용자 ID 질문과 문제를 위한 특정 도움 링크예요.
배경 이미지(Background image, 선택): 제품 팀의 안내를 확인하고 그에 따라 에셋을 고르세요; 모든 제품 팀 안내는 IBM 디자인 언어를 따라야 합니다. 브랜드와 서브 브랜드 안내는 IBM Brand Center에서 찾을 수 있어요.

언제 사용할까요 (When to use)

로그인 페이지는 다음 시나리오에서 사용자에게 제시됩니다.

사용자가 앱에 접근하려 할 때.
사용자가 자발적으로 로그아웃했을 때. 확인 메시지를 본 후 자동으로 로그인 페이지로 리다이렉트됩니다.
사용자가 비활동으로 로그아웃되었을 때. 이 시나리오에서 사용자가 다시 로그인하면 로그아웃되기 전에 있던 마지막 페이지로 리다이렉트되어야 해요.

동작 (Behavior)

점진적 인증 (Progressive authentication)

IBM은 제품 로그인에 기본적으로 점진적 인증을 사용합니다. 이것은 필수가 아닌 방해 요소를 제거하고 사용자를 필요한 로그인 흐름으로 자동 안내함으로써 사용자의 인지 부하를 줄여줍니다.

아래와 같이 사용자 ID는 앞서 요청되고 "Continue" 버튼으로 진행해야 해요. 이렇게 하면 시스템이 사용자가 옵션을 읽고 선택하게 하는 대신 백그라운드에서 어떤 경로를 취해야 하는지 구분할 수 있습니다. 이 지점부터 사용자는 단일 로그온(SSO) 흐름으로 계속하거나 비밀번호 필드가 제시됩니다.

SSO

단일 로그온(SSO)은 사용자가 각 제품에 고유한 사용자 이름과 비밀번호를 사용하는 대신 하나의 인증 포털을 통해 여러 무관한 제품에 로그인할 수 있게 해줘요. 많은 기업이 직원들에게 단 한 번의 로그인으로 다양한 무관한 도구 제품군에 접근을 제공하기 위해 SSO를 사용합니다.

사용자가 SSO 이메일을 입력하고 "Continue"를 클릭하면 조직의 SSO 흐름으로 이동합니다. 백엔드에서 사용자가 SSO 이메일을 사용하는지 결정할 수 없다면 사용자를 SSO 흐름으로 데려가는 버튼을 제공하세요.

사용자 이름과 비밀번호 (Username and password)

사용자가 SSO를 사용하지 않는 이메일을 입력하면 비밀번호 흐름으로 이동합니다. 비밀번호 페이지에는 사용자가 사용자 ID를 채우면서 실수했을 때 이전 페이지로 돌아가는 방법과 "Forgot password" 버튼이 포함됩니다.

사용자가 비밀번호 페이지에서 "Log in"을 클릭하기 전까지 유효하지 않은 이메일이나 사용자 이름을 입력해도 오류를 주지 마세요. 이렇게 하면 유효한 이메일 주소와 사용자 이름이 노출되지 않도록 보호하고 제품을 안전하게 유지합니다.

다요인 인증 (Multi-factor authentication)

다요인 인증(MFA)은 사용자가 신원을 검증하기 위해 하나 이상의 자격 증명을 제시하도록 요구해요. 이 방법은 사용 편의성을 유지하면서 추가 보안 계층을 제공합니다. 여기에는 종종 비밀번호와 SMS 코드 또는 알려진 백업 코드 같은 추가 자격 증명이 포함됩니다.

Carbon은 다요인 인증에 대한 통합된 안내가 없어요. 제품들이 서로 다른 방식으로 접근하는 것이므로, 미래에 더 견고하고 중앙화된 안내를 제공하기 위해 더 많은 연구를 하고 싶습니다.

별도의 인증 방법 (Separate authentication methods)

백그라운드에서 인증 방법을 구분하는 것이 기술적으로 불가능하다면, 사용자에게 다양한 경로로 가는 버튼을 앞서 제공하세요. 플랫폼이나 제품이 제공하는 대체 로그인을 결정하려면 제품 팀의 안내를 참조하세요.

이 디자인에는 기본 텍스트 입력과 버튼을 사용해야 기본 버튼이 입력 필드 옆의 위치를 유지할 수 있어요. 더 구체적인 사용 안내는 아래 플루이드 vs 기본 스타일 입력 섹션을 참고하세요. 또한 대체 로그인의 로고를 사용할 때는 브랜드 가이드라인을 참조하세요. 흔히 사용되는 대체 로그인 몇 가지의 브랜드 가이드라인 예시:

Azure 브랜드 가이드라인
GitHub 브랜드 가이드라인
Google 브랜드 가이드라인

오류와 검증 (Errors and validation)

효과적인 오류 메시징은 훌륭한 경험을 만드는 데 중요해요. 애플리케이션에 로그인할 수 없는 것은 좌절스럽고 사용자가 과제를 성취하지 못하게 막습니다.

항상 로그인 화면에 오류 상태를 제시하고 가능하면 인라인 오류를 사용하세요. 사용하는 오류 상태는 검증이 클라이언트에서 일어나는지 서버에서 일어나는지에 따라 달라져요.

콘텐츠 가이드라인 (Content guidelines)

오류 메시지는 명확하고 간결해야 해요. 무엇이 잘못되었는지 이해하고 오류를 해결하는 단계를 주도록 도와야 합니다. 오류 메시지에서 가능한 한 구체적으로 하세요. 메시지가 완전한 문장으로 쓰이면 항상 마침표를 사용하세요. 메시지가 짧은 조각이라면 마침표를 생략해도 됩니다.

클라이언트 측 검증 (Client-side validation)

제출 전에 사용자 데이터를 가능한 한 많이 검증하세요. 이 실시간 검증은 입력 필드가 포커스를 잃을 때 일어나며 잘못된 문자와 빈 필드 같은 입력 오류를 확인합니다. 이렇게 하면 사용자가 로그인 폼을 제출하기 전에 실수를 쉽게 식별하고 고칠 수 있어요.

일반적인 클라이언트 측 오류:

빈 필수 필드
잘못된 문자
잘못된 입력 형식

로그인 흐름에서 기본 또는 플루이드 텍스트 입력을 사용하든, 인라인 오류 메시지는 필드가 포커스를 잃거나 동작 버튼("Continue" 또는 "Log in")이 클릭되면 비어 있는 필수 필드 아래에 표시되어야 해요. 오류 상태에 대한 자세한 내용은 플루이드 텍스트 입력 사양을 참고하세요. 필드가 채워지면 오류 메시지가 사라져야 합니다.

다음 오류 메시지가 제안됩니다.

Use case	Message
빈 사용자 이름 필드	IBMid or email is required
빈 비밀번호 필드	Password is required
IBMid 또는 이메일 주소의 잘못된 문자	Enter a valid IBMid or email address
IBMid 또는 이메일 주소의 잘못된 형식	Enter a valid IBMid or email address

서버 측 오류 (Server-side errors)

사용자가 로그인 폼을 제출할 때 서버 측 오류가 있다면 페이지가 다시 로드되고, 비밀번호 필드가 지워지며, 사용자가 사용자 이름 입력 필드로 돌아와야 합니다. 오류를 표시하기 위해 인라인 알림을 사용하고 사용자가 문제를 해결하는 방법에 대한 명확한 방향을 제공하세요. 여러 서버 오류가 있다면 인라인 알림이 쌓여야 합니다.

잘못된 사용자 이름 및/또는 비밀번호는 가장 흔한 서버 오류입니다. 애플리케이션은 유효성 확인 전에 사용자 이름과 비밀번호가 모두 제출될 때까지 기다려야 합니다. 잘못된 사용자 이름이나 비밀번호에 같은 일반 오류 메시지가 제안됩니다. 앞서 언급했듯이 이는 유효한 이메일 주소와 사용자 이름이 노출되지 않도록 보호하고 제품을 안전하게 유지합니다.

다음 오류 메시지가 제안됩니다.

Use case	Message
잘못된 사용자 이름	Incorrect IBMid or password. Try again.
잘못된 비밀번호	Incorrect IBMid or password. Try again.

디자인과 레이아웃 (Design and layout)

플루이드 vs 기본 컴포넌트 (Fluid vs. default components)

많은 제품 팀이 로그인과 가입 흐름에 플루이드 입력 사용에 대한 선호를 표현했어요. 위에 제시한 것은 플루이드 스타일을 사용한 로그인 패턴의 이상적인 상태입니다.

그러나 팀은 기본 스타일 입력으로 진행하기로 선택할 수도 있어요. 아래는 기본 입력으로 로그인 흐름을 보여주는 몇 가지 대체 예시입니다.

플루이드 버튼과 입력은 플로팅 컨테이너가 필요한 반면, 기본 버튼과 입력은 컨테이너 없이 페이지 위에 놓이거나 사이드 정렬 전체 박음질 컨테이너(패널과 비슷하게)에 놓일 수 있어요.

여러 대체 로그인 디자인하기 (Designing for multiple alternate logins)

위에서 언급했듯이 우리는 시스템이 UI에서 사용자가 선택하게 하기보다 백그라운드에서 취해야 할 경로를 구분하는 것을 선호해요. 그러나 특정 제품에서는 그것이 옵션이 아닙니다. 여러 대체 로그인을 앞서 사용자에게 제시하려면 디자이너는 기본 버튼이 입력 필드에 가까이 유지될 수 있도록 기본 텍스트 입력과 기본 버튼을 사용해야 합니다.

위계에 주의하고 선호 로그인 경로보다 대체 로그인을 강조하는 레이아웃을 피하세요.

여러 대체 로그인을 제시할 때 기본 버튼을 텍스트 입력에 가장 가깝게 유지하세요. 사용자 이름 입력과 기본 버튼 사이에 대체 로그인 버튼을 두지 마세요. 로그인 폼 상단에 대체 로그인 버튼을 두지 마세요.

위치 (Position)

Carbon은 로그인 패턴에 대한 모범 사례 조언을 제공하지만 더 구체적인 디자인 안내는 제품 팀에 맡길게요. 예를 들어 페이지에서 로그인 흐름을 어디에 배치할지(즉, 왼쪽, 오른쪽, 중앙) 또는 플루이드인지 기본 입력을 사용할지 같은 결정은 필드가 그리드 위에 유지되는 한 제품 팀 수준에서 내려질 수 있습니다. 디자이너는 브랜드 승인 배경 텍스처, 일러스트레이션 및/또는 마케팅 콘텐츠를 통합할지도 선택할 수 있어요. 브랜드 및/또는 서브 브랜드와 관련된 특정 안내와 승인 에셋은 IBM Brand Center를 방문하세요.

중앙 배치 (Centered layout)

플루이드 로그인 폼을 화면 중앙에 배치하면 사용자를 위한 단순한 진입점을 만들어요. 페이지에 방해 요소가 없으면 사용자는 애플리케이션이나 제품에 로그인하는 기본 목표에 집중할 수 있습니다. 로그인 페이지로 탐색함으로써 사용자는 이미 로그인 의도를 보였으므로 제품에 대한 추가 콘텐츠는 필요하지 않습니다.

이 유형의 로그인은 종종 단색 배경이나 브랜드 승인 배경 텍스처와 짝을 이룹니다. 폼이 초점이므로 이 상황에서는 복잡한 일러스트레이션이 적절하지 않습니다.

스플릿 스크린 배치 (Split-screen layout)

스플릿 스크린 페이지는 제품과 관련된 일부 마케팅 콘텐츠나 다른 시각적 처리를 포함하는 데 사용될 수 있는 대체 디자인이에요. 이 레이아웃의 로그인 부분은 중앙 배치와 같은 디자인과 동작을 사용하지만 페이지의 한 부분에 국한됩니다.

이 페이지의 추가 콘텐츠는 최소화하고 훑어보기 쉽게 해야 해요. 로그인 폼에서 주의를 분산시키면 안 됩니다. 사용자의 기본 목표는 로그인이며 그것이 페이지의 시각적 디자인과 강조에 반영되어야 합니다.

브랜드 승인 배경 텍스처나 일러스트레이션은 짝이 접근 가능하고 경험을 향상시키는 한 로그인 폼과 함께 사용하기에 적절합니다. 일러스트레이션에 색상을 선택할 때는 특정 제품이나 커뮤니케이션과의 연관성을 고려하세요. 명확한 위계를 달성하려면 IBM 디자인 언어 레이아웃 원칙과 타이포그래피 스케일에 의존하세요.

플루이드 로그인 폼은 마케팅 콘텐츠나 일러스트레이션을 위한 공간을 만들기 위해 사이드 정렬될 수도 있습니다.

이 페이지에 일부 마케팅 콘텐츠를 포함해야 할 필요가 있을 수 있어요. 추가 콘텐츠를 포함할 때는 마케팅과 로그인 콘텐츠를 분리된 상태로 유지하세요. 테스트 결과 사용자는 로그인 영역 밖에서 계정 만들기나 SSO 버튼 같은 관련 동작을 찾지 않으며, 마케팅 콘텐츠에 내장되어 있으면 그런 동작을 자주 놓친다는 것이 밝혀졌습니다.

링크와 CTA를 포함한 마케팅 콘텐츠를 로그인과 분리하세요.

간격 (Spacing)

로그인 폼은 화면의 중심 초점으로 나타나거나 스플릿 스크린 레이아웃에서 마케팅 콘텐츠와 함께 나타날 수 있으므로, 여백과 세로 간격은 맥락에 따라 달라질 수 있어요.

플루이드 스타일 로그인 폼 (Fluid style login form)

플루이드 로그인 폼은 그리드에서의 너비나 플루이드인지 기본 입력을 사용하는지와 관계없이 일관된 여백을 가져요. 비밀번호 입력이 사용자 이름 입력 대신 나타날 때 "Remember ID"와 대체 로그인 같은 특정 옵션이 사라져도 모든 공간 관계는 동일하게 유지됩니다. 이렇게 하면 애니메이션 중 어색한 크기 조절이나 점프가 방지됩니다.

기본 스타일 로그인 폼 (Default style login form)

기본 로그인 폼은 컨테이너 안에 나타날 수도 있고 아닐 수도 있으며 여백은 그리드에서의 위치에 따라 달라져요. 컨테이너와 관계없이 아래 사양의 세로 간격을 준수하세요.

팀이 "Remember ID"(선택사항)를 사용하지 않기로 선택하면 함께 24px 상단 여백을 제거해 간격을 조정할 수 있어요.

접근성 (Accessibility)

사용자가 키보드만으로 로그인 폼을 탭하며 페이지를 탐색할 수 있는지 확인하세요. 랜드마크 영역을 사용해 로그인 영역을 지정하고 스크린 리더가 입력 필드로 직접 건너뛸 수 있게 하세요. 이는 스플릿 스크린 레이아웃을 사용하거나 페이지에 추가 콘텐츠가 있을 때 특히 중요합니다.

버튼 (Button)
링크 (Link)
텍스트 입력 (Text input)

참고 자료 (References)

Raluca Budiu, Login Walls Stop Users in Their Tracks (Nielsen Norman Group, 2014)
Lee Munroe, Login vs Sign in, (2010)
W3C, Using AIRA landmarks to identify regions of a page
Susan M. Weinschenk, Ph.D., 100 Things Every Designer Needs to Know about People (New Riders, 2011)

더 알아보기 (Learn more)

로그인 페이지는 사용자와 제품의 첫 접점이라 중요해요. IBM은 사용자 ID를 먼저 묻고 백엔드에서 SSO 와 비밀번호 흐름을 자동 구분하는 점진적 인증을 기본으로 합니다. 오류는 클라이언트 측 인라인 검증을 먼저 하고, 유효하지 않은 자격 증명은 일반 메시지로 보호하세요. 중앙·스플릿 스크린 배치 중 고르고, 여러 대체 로그인을 쓸 때는 기본 버튼을 입력 옆에 두며 위계를 지키는 게 좋습니다.