LastPass Connect turned an acquired hardware login key into touchless login with the phone already in your pocket. Its public beta drew 4,930 sign-ups from one email, and 52% of users were still active in week 2.
Hero image
Company / product
LogMeIn, LastPass Connect: touchless login to your computer using your phone (an Innovation incubator project)
My role
[Your title; e.g. Product Designer, lead UX on LastPass Connect]
Team
[PM], [N engineers] from the acquired AuthAir team, [other designers or researchers]
Stakeholders
LastPass product leadership, the LogMeIn Innovation incubator, the email marketing team
LogMeIn acquired AuthAir, a hardware key that logged healthcare workers into a computer as they walked up and out as they walked away. The challenge was to turn that technology into something LastPass users would want, using a device they already carry, their phone, instead of extra hardware.
Solution
We defined a persona through a workshop and interviews, validated a prototype with people matching that persona, and then released LastPass Connect as a public beta. Your phone unlocks your computer when you sit down and locks it when you walk away. We kept the MVP lean and let usage data show what to fix.
Impact
4,930 beta sign-ups from one email campaign
52% retention in week 2 and 470 daily active users after two weeks
8.2 / 10 recommendation score from beta users
Context and problem
Business context: AuthAir made a thumb-drive-sized device for healthcare providers. Staff carried it from computer to computer, and it logged them in by proximity. LogMeIn saw parallels with its password manager, LastPass, and acquired AuthAir in March 2017. The touchless login work became part of LastPass and went to LogMeIn’s Innovation incubator.
Customer problem: Typing passwords to unlock a computer many times a day is slow and annoying. People in shared or open offices also often forget to lock their screens when they walk away. [The top frustrations from your interviews.]
Design problem: The technology worked, but it was built for one niche market and needed a separate piece of hardware. We had to figure out how touchless login could fit into LastPass using a device people already had.
“[Interview quote about unlocking or locking a computer many times a day]”
Problem statement: How might we let people unlock and lock their computer just by being near it, using the phone already in their pocket, without making setup a burden?
My role and constraints
I owned: [Confirm what was yours, e.g. running the workshop, the persona and interviews, the desktop and mobile designs, onboarding, and measuring the beta.]
I partnered on: The beta launch email and landing page with the email team; making login and logout reliable with engineering.
Constraints
New technology: Proximity login built for hardware had to work on phones, across desktop and mobile.
Incubator budget: A small team with a mandate to move fast and test a real product in the market.
Reliability: If login or logout was inaccurate, users stopped trusting the product, which hurt retention.
Platform: The beta was built for Mac. Most enterprise companies use Windows, which multiplied the complexity.
Process
Define the problem and the MVP
We ran a workshop to narrow the problem and agree on the scope of the MVP. We created a persona, “Open Office Oliver”: he works in an open office around other people, uses a computer every day, and protects sensitive work data with passwords. He wants security and convenience but has little mental space to spare.
Interviews with people like Oliver shaped how we adapted the existing technology. We then showed people with the same profile an updated prototype to check we were on the right track.
Key insight: [One interview insight that shaped the design.]
Persona
The “Open Office Oliver” persona (background, motivations, frustrations) and an affinity map from interviews.
Get it into the real world
Testing internally with a small group wasn’t giving us honest feedback. To see how people used it in their own workplaces, we worked with the email team on an announcement to current LastPass users and built a simple landing page. Together they offered an early beta of LastPass Connect.
Accept a rough onboarding, on purpose
Onboarding was our biggest worry. Users had to switch between computer and phone and go through many steps on both, sometimes jumping between apps (app, then email, then browser, then back to the app). Instead of polishing everything, we put our effort only where it was critical and let real usage tell us what wasn’t working.
Onboarding
Desktop onboarding (“Almost there!”) and mobile onboarding (“Enable location services”).
Measure from every angle
We asked for recommendation scores weekly, ran diary studies and follow-up interviews, sent surveys, and watched analytics closely. That included performance: how accurately the app logged people in and out had a direct effect on whether they kept using it.
Key decisions and tradeoffs
Which device
Options
Keep a dedicated hardware key / use the phone
What I chose and why
The phone, which everyone already carries, so the product could reach far more people than healthcare workers.
Tradeoff accepted
We depended on phone sensors and battery, and had less control over accuracy.
Who to build for first
Options
Individual users / enterprise
What I chose and why
Individual users, because we could reach them quickly through the LastPass base and learn fast.
Tradeoff accepted
Enterprise needs, like Windows, IT admin and rollout, were left for later.
How to test
Options
Keep testing internally / launch a public beta
What I chose and why
A public beta, to get honest feedback from people’s real work environments.
Tradeoff accepted
People saw a rougher product, onboarding included.
Where to spend design time
Options
Polish every step / focus only on critical moments
What I chose and why
Focus on the critical parts of onboarding and logging in, and let the data show what else needed fixing.
Tradeoff accepted
Some friction in setup stayed in the beta.
The solution
LastPass Connect uses your phone to log you into your computer when you arrive and lock it when you leave.
Desktop login
The Mac login screen greets you by name, searches for your phone, and offers “Unlock with mobile.” Typing your password is still an option.
Desktop login
The Mac login screen with “Unlock with mobile.”
One-tap approval from a notification
A notification asks to confirm the login (“Would you like to log in to Fiona’s MacBook Pro?”), so you approve it in one tap without opening the app.
Notification
The login notification on the phone.
Always know what your phone controls
The mobile app shows which computer your phone is connected to, so you can always see what it’s controlling.
Mobile app
The mobile app’s connection status.
Guided setup on both devices
Onboarding takes you through installing on your computer, pairing your phone and turning on location, with clear progress and an explanation of why each permission matters.
Demo
[GIF or short video of walking up to the computer and unlocking it, from the demo video.]
Impact and results
Beta sign-ups from one email campaign
4,930
Retention in week 2
52%
Recommendation score from beta users
8.2/10
The public beta did better than we expected. One email campaign brought in nearly 5,000 sign-ups, and more than half of active users were still using it in week 2.
From email to daily use
81K emails sent to LastPass users
43% open rate
8.7% click rate (~7K clicks)
70% of clickers signed up (4,930 sign-ups)
470 daily active users after 2 weeks
“[Quote from a diary study or follow-up interview]”
Reflection and what’s next
What happened next: We started planning for enterprise customers, which proved much harder because most enterprises run Windows, among other obstacles. Despite the strong beta, LastPass Connect was deprioritized: the core LastPass product had too many urgent issues and roadmap items to spare people. LogMeIn kept exploring touchless login for other uses.
What I learned: Shipping something rough to real users told us more than months of internal testing would have. Reliability, especially accurate logins and logouts, mattered as much as the interface for whether people kept using it.
What I’d do differently: [e.g. look into enterprise and Windows requirements earlier, so the business case would survive changing priorities.]