The Way – 6 Steps From Idea to Live Software

These are the steps we take when we want to build new a new SAAS from scratch:

1. Discovery

The discovery stage is the most important part of this whole process. During this stage we are trying to help our customers get clarity on some very important questions like:

What does this software actually do?
Who are our target users?
How is our sotware going to add value to them?
On what devices will they use it?
How much will they be willing to pay?

At the end of discovery, we should have a few things:

User Personas

We create an avatar for each of the different types of users who will be approaching the software.

Example: in a recent construction related project, we created “Hardhat Harry, a small town contractor who is 38 years old, has five employees, who works out of his truck, and who wants to get into working on higher end homes.” As we designed the software we kept coming back to this persona.

Objective List

This is a list of tasks the software should accomplish. This objective list follows the format “The USER TYPE can SPECIFIC TASK”. So for example:

The SUPER ADMIN can add new teams
The SUPER ADMIN can add courses
The TEAM ADMIN can assign courses

A list like this is invaluable because:

Your designers will use it to create screens
Your developers will use it to shape the database
Your developers and quality assurance people will use it to test project completion.

You can also use this list to define the scope of the project for billing purposes. The client will know exactly what they are paying for and the developers will know when something is asked outside of the scope that they can charge for it.

2. Low-fi Wireframe

The second step is to take the objective list and personas and make a very low fidelity, purposely ugly wireframe of the application. This can be done on paper with a fat sharpie marker, but our favorite tool for this is a software program called Balsamiq.

The purpose of this low-fi wireframe is to decide HOW the software should WORK before you decide how the software should LOOK. It helps you remove style from the equation altogether and instead focus on what the software needs to do. It also helps you identify all of the screens you will need to design and create.

It becomes an invaluable asset for both the developer and the designer. The developer can take it and begin working on the backend structure to make it work while the designer can it and work on making it look good and consistent.

3. Hi-fi Designs

Once a low-fi wireframe is settled and agreed on, we take it into software like Figma or Adobe XD and create a high-fidelity design. Basically, we decide exactly how the software will look and work together. Choosing colors, fonts, button and padding styles, etc.. If it’s a client project, we try to design a few different screen styles for them to choose from.

Then, because we already have low-fi wireframes the designer knows exactly what screens he needs to design. When this stage is over, the finished project is a mockup for every screen in the app.

4. Markup

On a brand new project, we like to let our front end developers create each screen in the design using a static site generator. When they are done, we’ll have HTML and CSS for each screen and it can be tested online, but the buttons won’t work and forms won’t send. Basically, the structure will be there and ready for the backend dev to implement.

If any step isn’t 100% necessary, it’s this one. This is just how our team likes to work.

5. Full Stack Development

As the front end developer finishes creating screens in HTML and CSS, the backend developer on the project takes them and implements them in the actuall project, making sure that buttons go where they need to go, tying screens to the database, implementing features like pagination and filtering, etc..

6. Testing

The job isn’t done until it’s tested. This is where the objective list we created in step one becomes incredibly valuable. We use it to do two types of tests:

Automated Unit Tests

As our backend developer writes the software, he uses something called Test Driven Developement. Using the objective to write a test for the computer to run and then checking that each test continues to pass as he develops the software.

Human Quality Assurance Tests

We also create a staging server and have an actual human involved on the project go through each objective before it’s marked done and make sure the software works as expected. By creating an objective list, we have a list of things to test to make sure the software is working before it goes live for the client or user to see. Once a task has been tested, and bugs have been fixed, we mark it off as done, merge it into our master branch on Github and push the code live to the public server.