Looking for Feedback on a design for the Password Component

[tonromerodxc]

Hi Team,

We've recently explored some ideas for the Password Component in our Design System, and we’re seeking your feedback on it.

We've added a tooltip with an info icon that provides additional context about the password requirements when hovered over. This is intended to make it easier for users to understand the criteria for a valid password.

A badge has been introduced to indicate the strength of the password (e.g., weak, medium, strong).

Along with the visual feedback of password strength, we’d like to suggest implementing another method for information validation like the image below.

Since this state already exists for errors where there's a red line around the text input

This could provide more granular feedback to the user beyond just the strength indicator and tooltip, helping them quickly understand what they still need to adjust.

What are your thoughts on adding an alternative validation method?
Do you foresee any potential issues with these changes, especially from a usability or accessibility standpoint?
We really value your input and want to make sure these updates are beneficial for everyone. Please share your thoughts, concerns, or any additional ideas you might have.

Thanks in advance for your feedback! 😄

[lcordobapuerto]

Hey everyone!

I've been revisiting this issue that Hanoj opened, along with the DSDR we drafted on the topic (you can find it here: Coda link).

In our original DSDR, we concluded that the component, by default, cannot anticipate whether password requirements exist or what those requirements might be. This invalidates the option to change our input's border color depending on the password strength. To address this, we proposed a design pattern tailored to this specific team's needs, which could also be applied to other teams. However, I find Ton’s proposal in this discussion quite interesting.

Essentially, we could achieve this input design without modifying the component itself—simply by hiding the label, helper text, and optional indicator, and instead constructing the header using our own components (in this case, typography and a badge or status light).

While Halstack generally recommends using the native input helper text, I think this approach adds value to the design and, most importantly, helps guide users in creating a valid password by providing real-time feedback. Additionally, I believe Ton’s solution could be combined with the pattern we previously proposed in our DSDR.

Of course, if validated, this pattern should be well-documented, as it could open the door to potential unintended uses, such as adding components unrelated to password security or strength in its header.

What do you all think?

[kukoc]

Hi Lara,

are you proposing combining Tom suggestions with this approach?

The above pattern has been implemented already in the Platform login. Are you proposing to replace the current Password strength info by the status light or badge above the input?

[lcordobapuerto]

Hey Aitor!
I don’t see any reason why we shouldn’t build a header like the one Ton suggested to replace the current password strength info. It provides more direct feedback to the user while also being more visually prominent than our current design.