Before starting work on a brand new project I like to plan what I'm going to build and how I'm going to build it. In this post, I'll give a brief overview of the process I use to get started.
When building a startup it's very likely your intended product will have quite a number of features - regardless of how lean your MVP might be (at least from a developers perspective). Starting from scratch can be daunting and it's not uncommon to ask yourself - where do I start?
In my experience, I find it most useful when I can visualize what it is I'm going to build. Assuming I'm the domain expert on the given project, I'll have a good idea of how the site should look like. Therefore I'll usually start with creating a set of mockups to turn my ideas into something more tangible.
As a first step, I'll use Balsamiq to create low-fidelity mockups. I believe creating hi-fidelity mockups with Photoshop is overkill, since we can just go straight to HTML/CSS if we want to go into more [unecessary] detail. The product design sprint in which you design your mockups can be a whole topic in itself.
Below is an example of a Balsamiq mockup for a photo-sharing application I'm about to start building:
The above wireframe took me no longer than 10-15 minutes to make, hence why low-fidelity prototyping kicks butt for customer-driven design.
Now that we have a goal or vision in place, we need to figure out the required steps to achieve this outcome. Enter Trello.
Trello is a project management tool that let's you organize anything, for free. It's incredibly flexible and fast and we'll use it to create user stories in an attempt to structure our product development process.
Here's a screenshot of the Trello board I set up for the photo-sharing application:
I've taken the above layout from Thoughtbot, which you can read more about in their playbook. As you may be able to see in each 'board', I've created cards containing tasks. Most of the tasks listed are user stories - a sentence used to define a feature for our application.
When writing user stories I apply the following pattern:
As a [role], I should be able to [feature] so that [reason]
As a Visitor I should be able to see a homepage.
Pretty straightforward. The example above is the same user story I have placed in my 'In Progress' board as it's the first story I'm going to tackle. Note I didn't state the reason in the story since it's self-explanatory.
Using this approach of creating low-fidelity mockups followed by user stories, you are able to break up your application into smaller, more attainable goals based directly on what you envision your application to be.
Tip: Remember to celebrate small wins - each user story marked as complete means you're one step closer to building your startup!
The above is a fairly simplistic approach which highlights two very important tools for me when starting a new project. I have found the ability to visualize and break down the project into manageable pieces to be quite effective, and recommend you to do the same.