Courage in Profiles

(For those under 100, the source of this title.)

At least half of the student teams I coach in agile software product development have creating a user profile interface as their first or second user story. They're so used to seeing them in Facebook and elsewhere, that they assume they must have them.

Profiles are friction, pure and simple. There is no user payoff in creating a profile. How silly would an app be if all you could do with it was create a profile? Well-known sites can get away with profiles because users already know they want the services those sites provide and are willing to put up with some friction. Your fledgling app is unknown and probably not all that good yet. Users have no incentive to put up with any friction with your app.

Nor is there any value gained in early testing of a profile creating interface. No risk is reduced, because such pages are not hard to build, and no business value proposition is validated.

"Maybe so," the teams reply, "but our app has to have user profiles."

I've yet to see that actually be the case with any team.

The first argument for user profiles is usually "we need to know who the user is so that we can attach data to them." For example, if someone joins a scavenger hunt game, we have to know who they are so we can keep track of what items they have found.

This argument confuses identity with a user profile. To give someone an identity, all you need to do is give them a unique URL that they can bookmark and/or save on their home screen. Writeboard (recently retired) from Basecamp worked this way. When doing early product development, it's a way to get test users started with no friction or commitment on their part, and total control over the identity on your part.

The second argument for user profiles is so that users can specify preferences, e.g., what name they want to appear under, how and how often they want to be sent messages from the app, and so on.

This argument assumes that the only way to collect preferences is to interrupt the user's experience. How many apps have you used, from Google, Facebook, and elsewhere, where you wanted to change one thing, e.g., whether to get email reminders, and you had to go a preferences page with dozens of options to search through? Now consider the alternative: you get a reminder you don't want. It includes a link that says "don't send reminders in the future." One click. Done. Or your favorite restaurant searcher shows the places too far away, so you click adjust the radius of search and say yes when it asks if you want this radius to become the new default. Two clicks. Done.

Not only do these alternatives have way less friction, the friction is connected to immediate payoff, not some potential future benefit.

So does this mean you should never implement a user profile and preferences page? Not at all. Such pages are a great way for users to review and adjust their current settings. But such pages are just nice to have's. They aren't and should never be critical to your app or your early development process.

Have courage! Put user profiles where they belong, on the backburner, off the main line of development.