Getting a project off the ground and underway can be a daunting task, especially for larger and more complex builds. For sites that are particularly content-heavy, the initial considerations required before beginning development are extremely important.
I like to make use of a concept known as "user stories" when starting a project. Basically, this process takes the form of writing, or sketching out – in collaboration with the client – the goals of the project and what needs to be delivered in the finished product.
User stories are part of the agile approach to programming, a process which allows the planning and decision making phase of a project to proceed smoothly and, importantly, with the involvement of everyone.
You may already have experience with user stories. The following is only an outline of the concept, and doesn’t delve into some of the more detailed analysis of the process. However, I find that the basic principles involved are very useful when it comes to planning and executing an efficient project.
A story is very simple – by design. They are usually structured as follows:
# As *a type of user* I can *do something* to *achieve some goal*
Although the specific structure may vary, depending on preference. The purpose of that structure being to force your thought process down a specific path. Specifically, the path that your users would take when thinking about what they’d want from that specific feature.
As a rough guide, the user story should be short enough to fit onto a 3′ x 5′ index card when written with a narrow marker. This sounds somewhat arbitrary, but it serves as a good indication for whether or not a given story contains too much detail and needs broken down into smaller stories.
Also, writing these stories onto index cards is how a lot of teams located within the same physical office may implement this process. It’s a good, hands-on approach which encourages interaction.
It’s vital during the planning process to determine not only what features will be needed, but also why they’re needed, and who is going to be using them. After all, the target audience for a given app or website isn’t the client, it’s the clients users/staff/customers/visitors…. It’s not something that always comes naturally to people, and laying out stories in this way helps to channel your thought process.
So, a "real-world" example might be:
# As *an editor*, I can *add new articles with text and title* # so that *I can ensure site visitors see fresh content*
The last part, the goal, may seem redundant. But if anything, it’s the most important part. This is where your users intentions are recorded.
Imagine if, as a developer, you were to recieve a list of user stories from a client, or another department. You have no way of knowing how the customers think. After all, you’re a developer. You don’t work in the same environment as your client’s customers. You probably only know the bare minimum about their business sector – that is, until you read through the user stories. You not only have a description of a required feature, you have a specific why behind that feature. Through the user stories you gain insights into the user’s perspective.
The ‘why‘ might be obvious, it might not be. But what’s important is that it’s there.
The story can encompass as wide a range of features as required. In fact, it’s usually better to "think big" to start with. "Adding an article" is a fairly high-level function. In reality, from a developer’s point of view, it requires many more smaller tasks to be completed to get this high-level task working.
But that’s part of the process. The developer then takes the "high-level" user story and breaks it down into multiple smaller stories. These start to form the basis of the full project specification which, once complete, can be delivered to the client as a full and extremely thorough outline of all the requirements.
Another important purpose behind user stories is that they foster discussion. Without user stories, it can be hard to determine what needs to be discussed in order to properly plan out a project.
By defining features in this way, as well as defining why they need to exist, you’re actively encouraging discussion and input from everyone involved in a project, be it the developer, the client, the client’s staff or the client’s customers.
User stories invite everyone who will be involved in the project from the start and throughout its lifetime to contribute. There should be sufficiently complex discussion about each point to fully appreciate what needs to be built from a user’s perspective.
The discussion is perhaps the most important part of the whole process.
As well as the story and the discussions, an important third element of the user stories is the acceptance criteria. This takes the form of a short list of desired functional outcomes which should be brief enough to write onto the back of a post-it note or index card using a standard ballpoint pen. (again, this is purely to give guidance as to the expected length of this list. Too long, and it becomes unmanageable. Too short, and it may not be sufficiently detailed)
For example, in the above example our completion criteria might be:
# The title box accepts between 1 and 100 characters # The text box accepts any number of characters # A save button is visible to publish the article # An error message will show if either the title or the text is left empty
This is a fairly simple example, but you can see here how this defines the expected behaviour of our feature. This also allows us to define when it is complete.
By noting down the acceptance criteria, we have a 100% agreed upon definition of completeness. This can be used by the developer to build the feature, QA to test the feature and the client to sign off on the feature.
And there will be no disagreements on whether or not a task has been done. If it meets the acceptance criteria, then it’s done!
At first glance, this might seem like overkill. I’ve recieved comments before questioning this approach, and wondering why so much work is required at the beginning of a project, but if anything, it reduces the amount of work. For each hour at the start of a project I spend on user stories, this can easily save two hours of frustrating debugging and modification at the end of a project.
Now, once the project is underway, this is where the value of the process becomes apparent:
So when considered as part of a full project lifecycle, I find user stories to be an invaluable and effective tool in properly planning and scoping out a client’s requirements.
Robin is the dedicated developer behind Solarise.dev. With years of experience in web development, he's committed to delivering high-quality solutions and ensuring websites run smoothly. Always eager to learn and adapt to the ever-changing digital landscape, Robin believes in the power of collaboration and sharing knowledge. Outside of coding, he enjoys diving into tech news and exploring new tools in the industry.
If you'd like to get in touch to discuss a project, or if you'd just like to ask a question, fill in the form below.
Send me a message and I'll get back to you as soon as possible. Ask me about anything - web development, project proposals or just say hi!