Step 1: Become A User

Every software project needs users. Otherwise, why build it?

Normally, users will be a part of your team in one form or another. Maybe it's a member of your team whose job it is to represent the user's wants and needs. Maybe you do speak and interact with actual customers often.

Since in this project we're going solo, we need to become a user when we're doing things that a user would normally do for us in a larger project.

What do users want?

Most software projects you'll build alone will normally span out of your own needs. If that's the case, you'll be the perfect user for them.

Don't be afraid to spend time just being a user of your project, and forget about being a developer for a moment. Even just sitting and thinking about this can be really helpful to come up with new ideas for your project features.

The most important thing: don't do this just once at the beginning of the project. Become a user at the start, and every time you complete a piece of work.

When I was thinking about this project I came up with these things that a user would like:

• Keep track of small journal entries
• View past entries of their journal
• Have a simple and easy way to access their journal

There's not much! But the key thing is that this allows me to get started. I promise you: as we complete functionality and produce working software, more things will come to mind.

What other software exists already?

Users will not jump to "create my own journal" first. Instead, the normal flow is to see if software already exists that allows them to do what they want to do.

Always research your competitors! That can give you ideas, inspiration, and also show you what sort of things you want to do better or differently.

At this stage we're learning, so even if something exists that is very similar to what we want to build, it's still worth building.

However, if you were building a company, you might decide to do things differently if a competitor is already doing exactly what you had thought about. And if not, you might find ways to do things better.

A lot of startups begin as a way to do things better than their competitors. Don't focus only on ideas; it's the end product that really matters when building software!

User stories

The outcome of becoming a user should be descriptions of what a user would want. I like writing these in the form of user stories:

• As a User I would like to be able to add new journal entries so that I can keep track of my programming learning over time.
• As a User I would like to be able to easily see past journal entries in a simple way so that I can remember what I've learned.
• As a User I would like to be able to access my journal using a website so that I can do so from any of my devices.

Writing user stories

User stories should look as though they're written by users. They contain a what and a why. They should never contain a how.

However, a development team often does need to keep track of how. Don't be afraid to add extra detail to each work item in your project planning tool of choice.