Product Designer
Authentication UX
2024
Three fragmented logins. One unified authentication experience.
A client operated three sites with separate registration processes, logins, and data models. I designed the authentication experience for a unified Keycloak layer, with SSO and VTEX integration, collaborating with engineering and legal teams to balance security, privacy, and usability.
Authentication · Keycloak · SSO · Design Systems
Product Designer
Authentication UX
2024
Three fragmented logins. One unified authentication experience.
A client operated three sites with separate registration processes, logins, and data models. I designed the authentication experience for a unified Keycloak layer, with SSO and VTEX integration, collaborating with engineering and legal teams to balance security, privacy, and usability.
Authentication · Keycloak · SSO · Design Systems
Product Designer
Authentication UX
2024
Three fragmented logins. One unified authentication experience.
A client operated three sites with separate registration processes, logins, and data models. I designed the authentication experience for a unified Keycloak layer, with SSO and VTEX integration, collaborating with engineering and legal teams to balance security, privacy, and usability.
Authentication · Keycloak · SSO · Design Systems
Context and problem
The three products had been built independently. People using more than one site had to manage separate accounts, passwords, and registration sequences. Error states and social login paths also varied.
The previous pop-up login was fast, but limited validation, visual consistency, and identity management across sites. A compliance review identified gaps in consent mechanisms and traceability. The project needed to support the privacy requirements defined with the legal team, without assuming that a platform alone guarantees legal compliance.
Evidence
I mapped nine flows: registration, returning-user login, and social login on each of the three sites. The mapping exposed structural differences, beyond visual ones, in registration sequences, errors, and levels of friction.
Benchmarking covered Carrefour, Stix, and Santander Esfera. The analysis helped compare dedicated authentication pages, identity patterns, and recovery. It served as a design reference, rather than proof that a login format is inherently secure.
Constraints and architecture
Keycloak uses authentication themes that needed to respect the elements rendered by the platform. I collaborated with engineering to understand what could be customized in the templates and which behaviors belonged to the infrastructure.
The three brands required distinct identities. The solution separated shared structural patterns, such as layout, validation, and error states, from visual styling by realm. VTEX integration and legal review were also part of the technical context.
Decisions and solution
1. Share structure and preserve the brands
I created reusable patterns for authentication flows, with brand-specific visual styling. This avoided redesigning the structure for each property and maintained consistency while preserving its identity.
2. Validate at the point of interaction
Fields gained progressive feedback and recovery guidance. Email format validation helped identify errors before registration was complete; confirming ownership of the address remained the responsibility of authentication.
3. Make consent and privacy explicit
The consent interface was designed and reviewed with the legal team. The material records acceptance without revisions on the first submission. That approval applies to the flow presented and does not certify the client’s entire operation.
4. Document paths and states
I specified registration, returning-user login, and social login flows, including loading, errors, and recovery. The aim was to make the identity infrastructure understandable to people using a consumer product.
Documented impact
The three fragmented systems were replaced by a consolidated authentication experience. The shared model with branding by realm created a reusable foundation for new properties. Legal approval of the consent mechanism is recorded in the case study.
No metrics for conversion, support ticket reduction, or implementation time are presented. The documented impact concerns structure and delivery, without claiming the complete elimination of security or compliance risks.
My role and collaboration
I mapped journeys, conducted benchmarking, and designed interaction patterns, components, states, and brand styling. I documented the flows for implementation. Engineering handled architecture and integration; the legal team assessed the requirements and consent interface.
Reflection
Identity systems require clarity in both available actions and error recovery. Separating the shared structure from visual identity helps the system evolve. In future projects, I would add instrumentation at each step to assess drop-off, recovery, and use across properties.
Evidence
I mapped nine flows: registration, returning-user login, and social login on each of the three sites. The mapping exposed structural differences, beyond visual ones, in registration sequences, errors, and levels of friction.
Benchmarking covered Carrefour, Stix, and Santander Esfera. The analysis helped compare dedicated authentication pages, identity patterns, and recovery. It served as a design reference, rather than proof that a login format is inherently secure.
Constraints and architecture
Keycloak uses authentication themes that needed to respect the elements rendered by the platform. I collaborated with engineering to understand what could be customized in the templates and which behaviors belonged to the infrastructure.
The three brands required distinct identities. The solution separated shared structural patterns, such as layout, validation, and error states, from visual styling by realm. VTEX integration and legal review were also part of the technical context.
Decisions and solution
1. Share structure and preserve the brands
I created reusable patterns for authentication flows, with brand-specific visual styling. This avoided redesigning the structure for each property and maintained consistency while preserving its identity.
2. Validate at the point of interaction
Fields gained progressive feedback and recovery guidance. Email format validation helped identify errors before registration was complete; confirming ownership of the address remained the responsibility of authentication.
3. Make consent and privacy explicit
The consent interface was designed and reviewed with the legal team. The material records acceptance without revisions on the first submission. That approval applies to the flow presented and does not certify the client’s entire operation.
4. Document paths and states
I specified registration, returning-user login, and social login flows, including loading, errors, and recovery. The aim was to make the identity infrastructure understandable to people using a consumer product.
Documented impact
The three fragmented systems were replaced by a consolidated authentication experience. The shared model with branding by realm created a reusable foundation for new properties. Legal approval of the consent mechanism is recorded in the case study.
No metrics for conversion, support ticket reduction, or implementation time are presented. The documented impact concerns structure and delivery, without claiming the complete elimination of security or compliance risks.
My role and collaboration
I mapped journeys, conducted benchmarking, and designed interaction patterns, components, states, and brand styling. I documented the flows for implementation. Engineering handled architecture and integration; the legal team assessed the requirements and consent interface.
Reflection
Identity systems require clarity in both available actions and error recovery. Separating the shared structure from visual identity helps the system evolve. In future projects, I would add instrumentation at each step to assess drop-off, recovery, and use across properties.