Introduction
This piece of evidence documents the work completed by FAC22 on Tech for Better. Artefacts (including code snippets and screenshots) are taken from Solent Mind. This project was created for an external client, and can be considered built as part of the work of Founders and Coders as an organisation.
Software Development Cycle
For this project, I was part of a team who worked in an agile way. I followed six of the seven stages of the software development cycle.
Rather than deciding exactly on what we'd build straight away, my team took feedback from our users to iterate on our prototype before making a final decision on our tech stack. I was involved in sprint planning at the start of each period of work, and reviewed my progress at the end of the sprints.
Planning
With the client, I worked through exercises in a Discovery workshop. Completing a Problem Statement, User Personas and preparing for user research meant my client had a good idea of their users' needs. I then planned a User Journey using Miro, an online whiteboarding tool, which details the steps the user will complete when using the application.
During this project, I considered how the team could build our product in a way which could be repeated for other projects, or made use of existing tools to maximise what could be accomplished in a short period of time. These included:
- Organizing architecture for a bigger in scale product and managing tasks within a larger team
- Code modularization and code reusability
- Learning to use Supabase with Next.js for the backend
- Using states more efficiently and only when needed
- Learning Tailwind CSS
- understanding how CSS customization works with the use of a framework
- adapting the framework to our needs
- Debugging code, tracing code paths and refactoring code for optimization purposes
Analysis
I completed a code planning exercise in consulation with my technical mentor during the Design sprint. Here, I went into depth on the software requirements and made notes on how the stack would be affected.
In code planning I considered:
- Who the data would come from, and how I'd approach different paths based on this
- How data could be synchronised across devices. I opted to use a database to store data so that the app would present the same data for a user on any device.
- That I wanted to build a full-stack app which could store data in a database and that any user would need to be authenticated to access their account
- How I could manage styling in a component based application. I recommended that the team use Tailwind CSS which allowed us to quickly and consistently style pages of the application.
Design
- I tried to make as many reusable elements as possible and keep an even design on all pages.
- The main characteristics are: containers with softly rounded corners, bolder borders with soft glow and a rounder font as well.
- The main elements on each page are placed in containers, whereas secondary information is left plain.
The first week was dedicated to designing and prototyping, including wireframing all main pages of the application, so I could test it with users before the build sprint began. My team used Miro and Figma for collaborative brainstorming and design.
Building
I considered the implications of storing user email addresses in a self-managed database. Instead, I opted for a solution that relies on OAuth login managed by third-party providers like Google.
Our team delegated tasks on GitHub and used the Assignee feature on each issue to mark who was working on the specific task.
Each member of our team had a specific role in the development cycle and we collaborated to ensure all our responsibilities were fulfilled. I led on Quality Assurance which included delegating test writing to members of the team; ensuring that code was written consistently by different team members; and configuring a linter for all team members to use.
My team encountered some issues when setting up Supabase and I worked to resolve these in the first week.
Testing
On this project, I looked into end-to-end testing, which checks the app behaves as expected when I emulate tasks a user would complete. As well, I considered using unit tests to check that individual parts of my application were functioning correctly.
I focused on end-to-end testing the application using Cypress. My tests closely matched the experience of a user. In the example below, you will see that I check the /livingwithpersonalitydisorder initially contains a heading and a button. When the user clicks the button which is labelled 'Book', the page renders again. The user should then see the heading 'Booking successful', and two buttons.
I was working to tight time constraints and I communicated to my team that I felt we should not focus on unit testing. I decided unit testing would not provide as much value for the effort writing them and it would not give as much insight as testing holistically using Cypress.
Deployment
I used the Vercel hosting platform for deployment, because it is developed specifically for the framework I used to build the application. It has a robust free tier and is relatively simple to work with, which was important in handing over the project to the non-technical Product Owner.
Maintenance
This is the only stage which I did not focus on for this project. The app will not be maintained by my team, but has been handing to the Product Owner with relevant documentation.
Sprint Planning
@todo
Working with a Client
The Product Owner
My Product Owner came to the team with a statement of the problem their users are facing, and I worked with them to understand this and consider how a piece of software could respond to the needs of their users.
The design process involved my Product Owner and guiding them through the design process, including creating low fidelity wireframes on paper and Miro.
I had a number of conversations with my Product Owner throughout the build to check in and keep them up to date with our progress. And they were involved in Sprint Planning and Reviews.
On completing the project, I wrote documentation for the Product Owner which included the details needed to maintain the Product beyond the scope of our engagement.
The user group
During Usability Testing, I communicated directly with our Product Owner's user group. This included writing up an introduction to the Product and how I'd be conducting the testing.
In these conversations, I kept the technical focus light and asked users to give us feedback on the prototype.
Contrasting to these, were conversations with my technical mentors. I had a number of project scoping calls and conversations around my project role. These focused on the technical aspects of the MVP and involved discussing the specific technologies, and app architecture the team would use.
The company - FAC
The team managed sprints using GitHub's project board and our Scrum Facilitator led a daily stand-up meeting. My employer, Founders and Coders use the Scrum development method and this is what I followed in my project.
I used Git and GitHub for source control, merging pull requests from the other pair and code reviewing each other's work.
Storing data
I planned which pages would require data and who that data should be visible to on Miro.
I used Miro for planning the database schema.
And considered the implications of how I'd manage and store data, which I documented in my project report.
The database was connected using the Supabase plugin for React. You can see the implementation below:
Documenting and Presenting
I documented the project on GitHub across a project report and README. Both of these documents are written with a technical audience in mind.
I also completed non-technical documentation for the Product Owner. They can use this documentation to maintain the app moving forward.
Finally, I presented the product at a showcase event. The audience here were a mixture of technical and non-technical people. My presentation included details in layman's terms as well as some analysis of my technical choices such as the Tech Stack.
