I use a text wireframe tool to define the scope of the project with the stakeholders. The tool is interactive so that when we’re done the stakeholders are confident that the project specifications are captured fully. I’m no designer unfortunately, but at this point I would either take a stab at static mock-ups or the client would hire a designer to produce them.
Once the designs were approved I would build out all the front-end, JavaScript, image and CSS assets, markup, all of it. I would do it in React or Angular, complete with an API service for the data model. The only difference is that instead of actually hitting a back-end and returning live data, I would have static JSON that would get returned instead, as a mock response. This serves two very important purposes:
I can work rapidly to make sure that the stakeholders are happy with the implementation of the design, and any user interactions. This is important because most times the stakeholders don’t know and don’t care how the back-end will be developed — they only care about what they can see and touch. We want to load all the clients’ feedback up front so that they’re 100% confident that their needs are captured, and also so that we can respond to requests for changes/additions as quickly as possible. Front-end changes are way easier to do than front-end, back-end and database changes.
With the front-end mock JSON approved, I now have data contracts that I can use to write up the specifications for the database. I now know what each call to the API I have to write will receive for input, and what it should respond with for output. This means that now there is absolutely no guess-work, and because I know the stakeholders approved everything, so long as I follow the data contract I don’t need any more approvals.
As each endpoint is completed, I replace the static mock in the front-end with the connection to the live API, and test the interaction to make sure it’s still functional. Rinse and repeat for every mock in the front-end until the whole application is using live API calls.
Now all that’s left is to deploy the front-end, back-end and database to staging servers, and get final sign-of by the stakeholders, and then once that’s received deploy to the production environment.
Front-end first means we can work quickly with all the necessary checkpoints for stakeholder approval. We can build out the back-end and database with minimal feedback from the client. And, we guarantee that the user interactions are designed in the mental model of the stakeholders and end users, rather than being a byproduct of the needs of our engineers working on the back-end.
Hope that helps!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Here’s my favourite workflow for full-stack:
I use a text wireframe tool to define the scope of the project with the stakeholders. The tool is interactive so that when we’re done the stakeholders are confident that the project specifications are captured fully. I’m no designer unfortunately, but at this point I would either take a stab at static mock-ups or the client would hire a designer to produce them.
Once the designs were approved I would build out all the front-end, JavaScript, image and CSS assets, markup, all of it. I would do it in React or Angular, complete with an API service for the data model. The only difference is that instead of actually hitting a back-end and returning live data, I would have static JSON that would get returned instead, as a mock response. This serves two very important purposes:
I can work rapidly to make sure that the stakeholders are happy with the implementation of the design, and any user interactions. This is important because most times the stakeholders don’t know and don’t care how the back-end will be developed — they only care about what they can see and touch. We want to load all the clients’ feedback up front so that they’re 100% confident that their needs are captured, and also so that we can respond to requests for changes/additions as quickly as possible. Front-end changes are way easier to do than front-end, back-end and database changes.
With the front-end mock JSON approved, I now have data contracts that I can use to write up the specifications for the database. I now know what each call to the API I have to write will receive for input, and what it should respond with for output. This means that now there is absolutely no guess-work, and because I know the stakeholders approved everything, so long as I follow the data contract I don’t need any more approvals.
As each endpoint is completed, I replace the static mock in the front-end with the connection to the live API, and test the interaction to make sure it’s still functional. Rinse and repeat for every mock in the front-end until the whole application is using live API calls.
Now all that’s left is to deploy the front-end, back-end and database to staging servers, and get final sign-of by the stakeholders, and then once that’s received deploy to the production environment.
Front-end first means we can work quickly with all the necessary checkpoints for stakeholder approval. We can build out the back-end and database with minimal feedback from the client. And, we guarantee that the user interactions are designed in the mental model of the stakeholders and end users, rather than being a byproduct of the needs of our engineers working on the back-end.
Hope that helps!