How to write a user story with great UX in mind If your typical user story looks like: “As a new user, I want to create an account to have an account,” then you might have a problem. As a recent viral Twitter thread from user evangelist and UX pro Laura Klein pointed out a big issue in the QA community: how to write a user story. Product owners are trying to create and execute as many user stories as possible to define requirements and establish acceptance criteria. But if they don’t take the time to create a thorough “user” in the user story, who are they assuring quality for in the first place? Product and development teams need to think about the specificity of users and their intentions in order to create accurate conditions of satisfaction, user profiles, and test cases. At the heart of good UX is defining a specific user base and catering to them. We, and many others, suggest you start with these three tips to create a good user story. Dig into the user profile before writing a story A typical user story formula briefly describes all aspects of your user and their interaction with the app in the test case. You know the formula, it looks something like: As a [description of user], I want [functionality/feature] so that [benefit]. As a [role], I want [goal], so that [gain]. But what about thinking outside these boxes to write your user story. There is no default user with the same profile, intentions, and UX needs. Additionally, most of the time you are not your user, and probably don’t see things in the same light they do. To get around these realities, ditch the formulas and focus on understanding the user’s problem, desires, and capabilities in order to build hyper-specific user profiles that solve a legitimate problem. With that logic applied, the process of defining a user and creating a user profile may sound a bit more complicated than it has to be — especially if you follow a set of queries. To simplify, Klien suggests focusing on succinct questions. Here are seven questions for how to write a user story: Is this a new or occasional user? Daily user? Is this profile representative of your user base? Or targeting a minor audience? Is this an internal user or external? Do they have any specific behaviors? What are their demographics? It’s not that each of your user stories needs to be paragraphs long, nor do they need to be so detailed that executing them is impossible. Rather, devs, designers, and engineers need to be more qualitatively aware of the user base they’re designing for in order to design with intentionality. Not doing so can result in churn later, or even Pied Piper type scenarios. Think like a user. What are their true intentions? Now that you’ve identified your user’s demographics and familiarity with your product, it’s time to advance toward the next tier of UX understanding: what does that user want? Klein made a good point when she poses the following four questions about user intentions: Why do these users want to do the thing you claim they want to do? Are they only doing it because we have trained them to do it? What is their actual intent or end goal? How do we know they want to do this? Is this based on research or optimism or vibes? Take the time to think like a real user of your web or mobile app. No, users probably do not want to create an account because they just really want one — they “want” to create an account because you told them that’s the only way to either solve a problem or take advantage of an opportunity they have. For example, the raw intent behind creating an account may actually be to pay a bill. A user who wants to pay a bill (not fun) but must first create an account (cumbersome), and so a simple login form, limited field requests, and an intuitive interface design is probably the best route to get them where they need to be, even if it doesn’t cover every data point you may want to gather in the moment. Put the user first. The rest comes in time. To pile on to this concept, developing a good user story relies on understanding the individuality of your user base and working that into test cases through user stories. If you’re outsourcing software testing and UX to a third-party company, this work is even more important (something we know first-hand at Testlio). All that the tester knows is what’s on the device in front of them, and so it’s paramount that the product and development teams know the user they want to target and why they must improve or QA a specific feature. Communicate and build that insight with your software testing partner. As the product owner, you know the user base best. Reimagine user story acceptance criteria Stop focusing on the requirements of a user story. That might sound weird, but hear me out. If your team wants to truly put the user at the heart of UX and QA, center the “definition of done” on what the user will be able to do, and why. Generally, creating the definition of done relies on functionality. The log-in page works, or a form can be submitted, for example. As a [description of user], I want [functionality/feature] so that [benefit]. This type of done actually leaves the user out of the equation almost entirely. As a new user, I want to be able to log in so that I can do, what exactly? Pay my bill? See my orders? Claim my coupon? UX is completely left out of the above equation — it doesn’t take into account intuitiveness, accessibility, ease of use, and the critical need for stickiness and expideincy early in the user journey. The better alternative is to create conditions of satisfaction that look something like this: As a [description of user], I want to be able to [clear outcome] [how they complete it]. Using this more holistic formula, your team can easily see what the user wants to be able to complete, and how. Perhaps a large part of your user story acceptance criteria touches on accessibility and you want to QA text to speech interface. Your user story should reflect that clearly (and again, make sure the test team is synced with those insights!) Ultimately, creating a formulaic user story with 10 words is just a springboard for defining specific user profiles, wants and needs before a build. User stories on an index card are not elaborate enough to direct a full team into the nuances of a product or feature. Instead of pushing off questions and conversations about the spec until after the build, create a focused and thorough user story to create better UX from day one.