The \u201cstory\u201d part is quite short. In fact, the typical story only includes the three elements I just mentioned: the user (or customer persona<\/a>), their need, and a purpose. The end!
It\u2019s a way of writing product specs that explains the reason<\/em> for a request, rather than describing a solution to that request.
For example, \u201cAs a customer service agent<\/strong>, I need to record notes after a call<\/strong>, so that my other teammates have full context<\/strong> about a complaint and we can keep the customer happy.<\/strong>\u201d\u00a0<\/p>\n\n\n\n
This user story doesn\u2019t suggest a text box in a CRM or any other UI solution around recording notes. Instead, the story communicates the need for sharing inter-team knowledge in order to boost customer success and reduce churn. <\/p>\n\n\n\n
If you need, take a moment to learn more about user stories<\/a> in general. When it comes to writing great ones, of course it\u2019s important to make sure you\u2019re wording everything in a way the developers can understand. Pick a fill-in-the-blank format for your user stories. (That\u2019s \u201cMad Libs<\/a>\u201d style for anyone who gets the reference!) \u201cAs a <\/strong>________ [persona]<\/p>\n\n\n\n I want\/need\/expect <\/strong>________ [an ability or action] to happen,<\/strong><\/p>\n\n\n\n in order to\/so that<\/strong> ________ [the end goal: what needs to get done!]\u201d<\/p>\n<\/div><\/div>\n<\/div>\n\n\n\n Using a format is helpful for a couple reasons.<\/p>\n\n\n\n The first is collaboration.<\/strong> The whole team should be able to contribute. The simple fill-in-the-blank design ensures user stories can be written by anyone on the team.<\/p>\n\n\n\n The second is comprehension.<\/strong> Formats help ensure that all user stories can be read and understood <\/em>by anyone on the team. The key points are captured and structured in a way that makes sense.<\/p>\n\n\n\n If the product manager<\/a> or developer needs more context, they can directly follow up with whoever discovered or wrote the user story.<\/p>\n\n\n\n Of course, such formats only work if everyone is filling them out in a smart, effective way! Our next tip helps with that.<\/p>\n\n\n\n Whatever comes after \u201cso that\u201d or \u201cin order to\u201d is the more important part of a user story. <\/p>\n\n\n\n If you\u2019re having trouble defining the goal, try looking at your user story through the lens of another common framework: Jobs-to-be-Done<\/a><\/strong>. It also illuminates what your competitive space actually is, both on and off the market. For example, if yours is a tool for task organization, maybe you think your \u201ccompetitor\u201d is a spreadsheet but it\u2019s actually a post-it note. That\u2019s a totally different way of getting the job done! So, this can transform how you conceptualize your tool and inform how you create new competitive solutions.<\/p>\n\n\n\n Behaviors should inform the needs, wants, and goals that you\u2019re writing about in user stories. That\u2019s why the very first element in the story \u2014 the persona \u2014 is fundamental to a successful spec! Good user stories begin with good research and discovery. That means talking to actual users, as well as collecting feedback<\/a> from the rest of the company.<\/p>\n\n\n\n Make sure you\u2019re uncovering real problems and real needs, and make sure you\u2019re understanding and representing them correctly. The risks are that you either legitimize and prioritize needs that aren\u2019t actually important, or you overlook spots where new solutions could have a valuable impact on your product and company objectives.<\/p>\n\n\n\n
But more than that, writing great user stories is about the research, thought process, and structure you apply into them.<\/p>\n\n\n\n![\"Writing](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2021\/10\/user-stories-empty-edited.png\")
<\/figure>\n\n\n\n5 tips for writing user stories<\/h2>\n\n\n\n
1. Use one specific story format.<\/h3>\n\n\n\n
Something simple and easy is usually all you need. Here\u2019s an example that works for most products:<\/p>\n\n\n\n2. Focus on the goal, rather than the need or want<\/h3>\n\n\n\n
I can\u2019t stress enough how important it is to define the goal<\/strong>. This is the ultimate desired outcome. Focusing on the goal, rather than the need or want, has a two-fold benefit.
In the writing process, it forces the person who\u2019s writing the spec to actually articulate <\/strong>what they\u2019re trying to achieve. If they can\u2019t pin it down themselves, how is anyone down the line going to understand?<\/p>\n\n\n\n
Perhaps most importantly, focusing on the outcome creates a space for developers to think creatively<\/strong> about how to reach that goal. With full knowledge of the product\u2019s technology and its purpose, dev teams can devise cool solutions that satisfy wants and needs in ways that customers and other team members (including you!) won\u2019t think of.
On that note, you don\u2019t want to send user stories that are prescriptive, e.g. \u201cI want this button.\u201d<\/p>\n\n\n\n
Allowing for interpretation and creativity is key. It\u2019s far better to pull in the expertise of other people on the team than to narrowly specify something and hope it\u2019s the right solution.<\/p>\n\n\n\n3. Spend some time with Jobs-to-be-Done<\/h3>\n\n\n\n
Identify the jobs that someone hires your tool to do. What is it that they want your tool to do for them?
This approach helps you think wider about how your tool is used and what might be your user\u2019s goal \u2014 or maybe there are multiple goals!\u00a0<\/p>\n\n\n\n4. Make sure your personas are based on behavior, not demographics<\/h3>\n\n\n\n
It\u2019s important to create personas based on user behavior<\/strong><\/a>, not customer demographics. Stick to details about how this person uses your tool and interacts with your UI. This ensures that the personas\u2019 needs are relevant to your product.
And don\u2019t forget to update these personas from time to time! As your product evolves, so does user behavior.<\/p>\n\n\n\n5. Go back to the source<\/h3>\n\n\n\n