Product Designer & Engineer2024Open Source

Standardizing password UX, one interaction at a time

How I identified a universal UX friction point, validated it in Figma (14,160+ views), and engineered it into a framework-agnostic, accessible library.

Role
Designer + Engineer

Full-stack design thinking

Timeline
3 Days to MVP

Figma → Production

Type
Interaction Design

Micro-pattern → Macro-impact

Status
Shipped & Live

GitHub + Production

14.1K

Figma Community Views

Unpromoted design validation

8.4K

Active File Usages

Real adoption across teams

Framework Compatibility

React, Vue, Vanilla, Any Stack

Experience the Work

Part 1: The Problem

The spark, a tiny friction everyone feels

It was a late-night e-commerce login on desktop. I typed a password, mistyped one character, and automatically reached for my mouse to click "show password." The interaction broke my typing flow completely.

But this happens every time I login. And I spend 90% of my time with hands on the keyboard. Why was this interaction still designed for the mouse?

The cost of this micro-friction

  • 1
    Type blind and hope

    Accept the masked password, trust your typing, handle consequences

  • 2
    Break typing context

    Reach for mouse, click, interrupt flow, return to keyboard

  • 3
    Choose weaker passwords

    Unconsciously select simpler passwords to reduce verification cost

The design doesn't respect how people actually work.

Why This Matters at Scale

Password fields appear in every authentication system, every design system. Yet they're inconsistent across products. No standard. Everyone reinvents. Most land on a weaker solution than necessary.

Part 2: Validation Through Design

Before engineering, I validated in Figma

Rather than diving straight into code, I designed the interaction in Figma first. This forced me to think through the details, test interaction states, and see if the solution actually worked before committing engineering time.

Keyboard first

Cmd/Ctrl+8 toggles visibility without leaving the keyboard. Primary interaction designed for how people actually work.

Visual feedback

Animated eye icon that changes state instantly. No ambiguity. Clear confirmation that the toggle worked.

WCAG 2.1 accessible

Proper ARIA labels, focus states, semantic HTML, screen reader support. Built in from the start, not added later.

The Figma Community response

I didn't announce it. I just shared it publicly on Figma Community. No marketing. No outreach. Just solved the problem and shared it.

14.1K

Views

Organic discovery

8.4K

Active uses

Real adoption

59+

Community favorites

User appreciation

Design validation wasn't a guess. It was proof that demand existed. Thousands of designers actively used it in their files.

The Key Insight

"People don't search for solutions to problems they've normalized. But once they experience a better interaction, they don't want to go back."

It's the airplane Wi-Fi effect. You don't know you need it until you've had it once.

Part 3: From Design to Production

Engineering for universal adoption

The Figma design proved the interaction worked. But a design file only lives in Figma. The real challenge: engineer a solution so universal, so lightweight, that developers could drop it into any project: React, Vue, vanilla HTML, doesn't matter.

Architecture principles

Framework agnostic

One JavaScript file. Works with React, Vue, Svelte, vanilla HTML, or any future framework. Zero vendor lock-in.

Zero dependencies

No npm packages. No version conflicts. No supply chain risk. Just works. Forever.

WCAG 2.1 compliant

Accessibility isn't a checkbox feature. It's the foundation. Everyone has equal access.

Implementation, intentionally simple

HTML/CSS
<input id="password" type="password" />
<button data-eye-switch="password"></button>

<script src="eyeswitch.js"></script>
<script>
  EyeSwitch.init();  // That's it.
</script>

One function call. No configuration. Works immediately. This simplicity is what enables adoption.

Why Vanilla JavaScript (Not React/Vue)?

Because real adoption only happens when adoption is effortless. A developer in a Svelte shop shouldn't feel friction downloading a React-specific library. They should add one script tag and get on with building their product.

Part 4: The Bigger Vision

Standardizing authentication for the web

EyeSwitch isn't the end goal. It's the proof of concept. One small interaction showed that thoughtful design + engineering can change how people work. Now I'm expanding that to the entire authentication experience.

Vision: Make password and authentication flows so standardized, accessible, and well-designed that they become native to the web platform itself.

1

Standardize the Password Field

In Progress

Build a modular system of password field components. Each independent but designed to work together seamlessly.

Password Visibility Toggle
Keyboard-first, accessible, framework-agnostic. Shipping now.
Strength Meter
Real-time password strength feedback
Live Validation Feedback
Length, symbols, breach detection, requirements
Error Messaging & Guidance
Clear, assistive instructions for every state
2

Propose as Web Standard

Planned

Once validated in production across real products, formalize this work as an official proposal to W3C and WCAG.

Goal, native browser support

Imagine future web development where developers write:

<input type="password" enhanced />

No JavaScript required. No external library. Just native browser support for password fields that respect how people type.

3

Standardize Full Auth Flows

Roadmap

Expand beyond the password field to standardize the complete authentication experience: signup, login, recovery, 2FA.

Sign-up flows — Guided password creation
2FA & Recovery — Accessible multi-factor auth
Password Reset — Clear, predictable flows
Biometric Integration — Seamless security

Core principle: Accessibility is not a feature. It's architecture. Keyboard users, screen reader users, everyone has equal access.

Lessons Learned

5 principles that made this work

1Solve real problems first

EyeSwitch didn't create demand, it revealed it. Everyone with a password has felt this friction. Universal problems have universal potential.

2Design before engineering

Validating in Figma first proved demand existed before committing weeks to code. It also shaped the architecture. I knew exactly what problem to solve.

3Simplicity enables scale

Complex features don't get adopted. Simple, useful features do. Zero dependencies. One function call. This simplicity is why it spread.

4Accessibility is architecture

Bolting accessibility onto existing code creates friction. Building it into the foundation means it works naturally. WCAG 2.1 wasn't a checkbox. It was the design.

5Open source multiplies impact

Sharing scales solutions beyond what one person can build. GitHub isn't altruistic, it's strategic. That's exponential impact.

Final Reflection

What this represents

EyeSwitch started as personal frustration. It became a Figma design viewed 14K+ times. It evolved into a production-ready library that developers use in real applications.

This journey represents my approach to all systems design:

  • Observe real user friction. Often invisible because it's been normalized
  • Design and validate before investing engineering effort
  • Build for universal adoption, not proprietary control
  • Make accessibility fundamental, not optional
  • Share solutions that multiply impact across communities

This is what I bring to every project:

Systems thinking, design rigor, and the craft to build things that actually matter.

Ready to see it in action?