Paving the Cowpaths – Log in how you like
We noticed a pattern recently.
People were resetting their passwords a lot, sometimes two or 3 times in a row. We couldn’t figure out why people were struggling to get in, but when we looked a little deeper, we realized that a good 30% of users were logging in with their email address.
Now, what’s wrong with that, you ask?
It turns out that some flip decision we made in the early days of ProdPad resulted in us requiring the use of a username instead of an email for logging in. For a while, we thought nothing of it, until we started seeing the pattern and it’s effects.
When we saw the 30% figure, our eyes bulged: We were kicking off error messages for nearly every third person who came back to use ProdPad, and in many cases, losing their attention as they got stuck into the ‘Reset Password’ flow.
We had a couple options:
1) Make it clearer that the username is to be used at login, not the email address.
OR
2) Pave the cowpath.
We decided to pave the cowpath.
Desire lines in User Behaviour
A (traditional) cowpath is the line in the grass that cows make as they forge their way through the field in a particular route. A herd of cows, like your users, will try to take the easiest path they can see, even if it means trampling the grass or cutting corners.
It leaves you with an unsightly line in your lawn… or in our case, unsightly drops in usage at the point of logging in! The path that they choose to take, in UX terminology, is often called a desire line or a cowpath.
Paving the cowpath, then, refers to changing or improving your app design to allow people to go the direction they were trying to go anywhere. Don’t penalize your users! Instead, help them get to where they wanted to go with as little hassle as possible.
Finding a Desire Line
If a user gets something wrong, I generally assume it’s something wrong with the app, not with the person.
In our case, even if the login page was technically working to spec, it still wasn’t right. It wasn’t working in a way that users were able to use consistently and without error, and so we took the approach to assume it needed to be updated.
Never underestimate the power of adding a little bit more tracking, as it proved very useful when it comes to troubleshooting. In our case, we used Papertrail to dig through the log files and ping us when something went wrong.
From there, it was just a little pattern recognition and common sense (the type of thing Product Managers are great at!).
Following the fix, we’re seeing significantly fewer login errors, fewer customer inquiries about login issues, and have freed up a chunk of time to focus on finding and improving other metrics.
Have you ever found and paved a cowpath? Let us know in the comments!
Sign up to our monthly newsletter, The Outcome.
You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.
2 thoughts on "Paving the Cowpaths – Log in how you like"
Comments are closed.
Paving the Cowpath is a rather silly term. Cows hate paving. It is bad for their hoofs.
Maybe you should rename this “Backing out a silly decision” as email is the default user ID of the Internet, you tried to change default behaviour. A good user interface developer will always tell you that the learning curve should be about using your product, not about getting your product going.
Unfortunately, I can’t take credit for the term “Paving the cowpath”, whether or not cows like the idea. It’s a classic ‘UX’ term that’s been running around for years now: https://www.google.com/search?q=paving+the+cowpaths
When we started building ProdPad years ago, the end user in mind was vastly different. We were building a tool to use internally, within our own companies (I was Head of Product at BraveNewTalent, Simon was Head of Product at PeerIndex, and we needed tools to help us do our ‘day jobs’ at each startup). We didn’t give a second thought to how the log in worked, considering there was no sign up form and our teams were the only users!
As we started rolling this out as a SaaS tool for other product teams, we’ve had to re-evaluate all sorts of decisions that were shaped around our initial use case. We’ve posted about some of these in the past, (https://www.prodpad.com/2012/07/a-little-something-to-welcome-our-users/), and will continue to talk about what we’re learning (obvious or not!) in this Product Lab.
Hopefully we can shed some light on the product management process as a whole, by scrutinizing our own decisions and actions, and help out other product teams who want to avoid running into the same issues.
Thanks for your feedback, Rural – I’d love to hear about what you’re building and what you’ve learned along the way!