User stories are the first step in documenting requirements. It’s tempting to jump directly into thinking about how the new feature or functionality fits with your existing product and proposing UI solutions. However, at this stage, you need to resist temptation and stay focused on your users.
User stories are about what matters to the user, about what the user wants to accomplish. They are the WHAT. Until you’ve clearly, specifically, and unambiguously defined what the user wants from the user’s perspective, it’s too soon to tackle the HOW.
Pop quiz! Which one is a better user story?
User story 1: The user can change his password by clicking on the forgot-password link on the homepage, answering the security questions, and clicking on a verification link from an e-mail we send him.
User story 2: The user can easily change his password.
The thing is, User story 1 isn’t actually a user story. It’s too complicated, too solution-focused, too us-focused. Users don’t care how your system works, what works best with the features and functionality you already have, or anything else about YOU. That’s why it’s so important that you take the time in this first stage to craft user stories that about the user. You’ll have plenty of time in later stages to hammer out the HOW and design elegant integration with your existing product. During the hammering and design stages, you can refer back to the user stories as a reality check.
Your user wants to do X. How well does what you’re designing make that possible, easy, and – dare we dream – delightful?