When describing the technology solutions we need, it’s natural to feel like we need to “talk tech”, or describe our needs through the lens of technology.
Instead, we recommend “thinking in stories” -- user stories.
User stories are told from the perspective of a project stakeholder -- any individual or group that affects or is affected by the outcome of the project.
Sometimes the main project stakeholder may be you.
Here is the format for writing a user story:
As <a stakeholder>,
I want <to perform this task>
so that I can <accomplish this goal>.
Instead of: “how can I use a given technology or feature to solve my problem,” a user story describes the problem that you need to solve. And why.
They are written in informal, simple, natural language (not technical jargon).
User stories answer the basic questions: WHO, WHAT, WHY
Here are some examples:
As an Grants Manager
I want to share documents with outside grantees
So that I can collaborate with them effectively and securely
As a Finance Manager
I need to see invoice submissions by date and amount
So that I can prioritize client follow-ups
User stories can also be told from the perspective of a constituent:
As Program Applicant
I want to save my application in draft form
So that I can edit and make corrections before submitting it
As a website visitor
I want to choose how I filter content
So that I can easily find the materials I need.
There is no set number of user stories to create. Some projects require just a few while complex software projects may have hundreds.
The benefit is that user stories keep the focus on technology solving problems for people.