Client
Queen's University Belfast
Project Type
Timeline
7 Months
Design Tools
Tech Stack
As part of my final year project at university, my team and I conducted research, designed, and developed the system, Unify, consisting of a mobile and web app which would 'unify' students and universities by allowing university events to be managed and data analytics to be viewed by universities, and creating a centralised place for students to view all events happening at their university and encouraging them to attend through gamification.
Queen's University Belfast is a Russell Group university in Northern Ireland, offering numerous academic degrees at various levels in a range of disciplines.
The students engaging with the university and wanting to connect with other students.
The university engaging with the students and wanting to retain academic talent.
In order to better understand the problem, we utilised design thinking principles from The Design Thinking Toolbox, using a variation of divergent and convergent thinking.
We interviewed current university students regarding their experience finding events at university pre-pandemic, joining clubs and societies as well as making friends and connecting with others during remote and hybrid-learning. We gained some insight from this.
In order to later be able to design a good user experience, we thought about and determined who our users would be, what tasks they would like to accomplish, where they will be doing this and the influence their environment may have on them, when these tasks would occur and how frequently this would happen, and how these tasks would be completed.
We contextualised the problem, looked for how we could solve it by understanding who our users would be, and then we created problem statements from this.
My team and I created user personas to discover how each potential user may interact with the system.
We first described the persona and gave them additional attributes. We discussed what tasks they do and where there may be opportunities to help them. We talked about the biggest difficulties and problems they may be experiencing, especially with existing products (or lack thereof). We also considered people and trends that may influence them.
We also discerned who our main competitors are — MSL System, Eventbrite and Ready Education — and how our system, Unify, would differentiate from them.
The COVID pandemic forced students to study from home and, post-pandemic, students are now participating in hybrid-learning, making it difficult to meet and form connections with other students, resulting in feeling isolated.
At the university, events are currently only announced through various different platforms, such as Eventbrite, Facebook and e-mails, whereas others are only known by word of mouth after joining a specific club or society, in which registration for these organisations only occur twice a year.
Clubs and societies at the university only open for registration at the start of the year. If a student misses this opportunity and finds out about the organisation later and decides that they would like to join, they would need to wait until next year.
Due to events being difficult to find information on and participate in, and with very little efforts in marketing these events to students, this has lead to reduced student engagement with the university.
During the pandemic, student loneliness and increased mental health issues arising from this, combined with reduced student engagement, is causing an increase in students dropping out.
University oganisations, such as clubs and societies or the Student Union, use multiple different platforms to communicate events happening at the university (e.g. through Facebook, Eventbrite, word of mouth etc.). This is difficult to maintain and also causes inconsistency in how events are acknowledged by students.
Although we now understood the problem, we then had to begin translating these problems into features for us to develop as part of the system.
We created 'epics' which we then prioritised and broke down into 'user stories' which we then defined acceptance tests for to determine what we would consider to be the completion of each user story.
Diving deeper into defining the completion of user stories, we first outlined our intentions with the system, then our target outcome for each intention as well as what we felt would be an indicator of success or failure for each of these intentions. From this, we were able to gain a more rounded understanding of what features our system might have based on the types of outcomes we wanted to achieve.
We created goals that we wanted our system to achieve and determined which goals depended on others in order to prioritise which aspects of the system we would like to work on first.
Once we better understood what we wanted to achieve with the system, we performed multiple variations of brainstorming sessions on aspects that we wanted to expand on — precisely what we could possibly do to achieve these outcomes.
Unique brainstorming sessions like 'negative brainstorming' allowed us to see poor outcomes which we could try to avoid.
We then took these brainstorming ideas and put them on a 2x2 matrix grid, rating them by how much value this would provide for the user and whether it would be feasible to achieve this idea within the time constraints and resources currently dedicated to this project. From this, we were able to cut out anything that was a nice to have and were able to focus much more on features that were worth exploring.
We delved deeper into the journey a user might take through our system to better understand if we've addressed each stage of the user journey.
We wanted to define a statement which would capture the essence of the impact we wanted our system to have. We looked towards examples of many other companies' vision statement for inspiration and then focused on what our hopes are for Unify, what problem we are wanting this to solve, and who we are aspiring to change.
Based on our research and conversations with students and stakeholders, we decided that our system would consist of a mobile app and web app. We first split functionality between the two. Then we had a session to put forward questions on areas we still weren't clear on yet and attempted to answer them.
From this, we were able to create wireframes to get an idea of how each app would look and flow between each screen.
We then interviewed several potential users, walking them through the flow of the wireframes and collected feedback from them.
We collated the feedback and took this on board when later designing the final concepts.
Our solution would contain a centralised database, accessed by API endpoints through a backend which would connect to two front ends which consisted of a web app to be used by university administrators and organisations, and a mobile app to be used by university students.
Both apps, although serving different users and purposes, would share data between each other through one single database to store data and one backend to serve endpoints and manage the handling of relevant data for both apps.
A natively rendering JavaScript framework for developing mobile applications for iOS and Android which was used for the mobile frontend and is an open-source framework, meeting our affordability requirements. Our main reason for choosing to use this technology was due to the nature of the ’bridge’ created between the written JavaScript code and the output of the native rendering in Objective-C for iOS devices and Java for Android devices, allowing us to work on a single codebase for the mobile app which could be used on either iOS or Android, promoting cross-OS compatibility which was integral for ensuring that the mobile app would be available to as many students as possible without the mobile phone’s operating system becoming a hindrance.
A component-based JavaScript library used for developing UI which we used for the development of the webapp frontend. Using this made it easy for us to manage and encapsulate code so that components were self-contained. As well as this, it allowed for certain logical functionality to be re-used across the both the webapp frontend and the mobile app frontend since the mobile app used React Native, saving time in overall frontend development since there was no need to adapt it to a new language.
A Python web framework which we used to create RESTful endpoints to act as an intermediary between the frontend and database, allowing the frontend to make a request and then enabling the backend to execute those requests by running the correct queries on the database and returning the relevant information when necessary in a JSON format to the frontend to be mapped. Flask worked really well for us as a backend framework due to it being quick and easy to set up and adopt in the beginning of our development, highly scalable, and lightweight with the option to import extensions as necessary allowing for the ability to extend the system in the future if required.
A secure and simple user login, registration and access control authentication and authorisation service by AWS.
This service is used to allow for the ability to verify university e-mail addresses by sending e-mail confirmation upon first registering and provides the means to give different users varying levels of access by creating User Pools, differentiating types of users on both apps (e.g. Student user on the mobile-app and Administrator and Organisation user on the web-app) as well as providing modified access to each (e.g. Administrator user has more privileges compared to Organisation user on the web-app). As well as this, AWS Cognito hashes user information, allowing for increased password security.
An object storage service by AWS that was used to store images. It works when a user uploads an image which is then passed to the backend where it is sent to S3 to be stored and can be referred to throughout the use of the system via endpoints in the backend (i.e. a GET request for the image).
An open source relational database management system which was used for Unify's database due to being free to use, meeting affordability requirements, while allowing us to develop the system based on a relational database.
Our team was working remotely due to COVID restrictions which meant that we had to find ways to collaborate online. We did this by using Microsoft Teams for video calls, which we did regularly to check in every day which allowed us to connect and get to know each other while having fun working on a project we were passionate about. We also used the collaborative whiteboarding tool, Miro, to work together on creating ideas online. For development, we utilised Jira for ticket creation and allocation so that we could keep track of what everyone was working on each sprint, and GitLab to create repositories for each aspect of our system, allowing us to work from the latest version of the system's code.
We were concerned that users may use our system with malicious intent. In order to try and combat against this, we implemented strategies such as ensuring the type of data collected is generic and anonymising data collected on students and only allowing this data to be viewed in aggregation with other students' data to ensure that no one is identifiable. As well as this, we limited inputs from students (e.g. by generating friendly usernames instead of allowing users to create their own) and adding validation as we had little resources to moderate hateful language. We also made use of authentication and verification methods as part of the user journey as well as implementing good security practices within the code to reduce the risk of malicious users attacking the system (e.g. using user IDs to verify them before connecting with an API to retrieve data from the database).
We faced the possibility of poor quality code being implemented in the application. Such code would introduced security flaws, cause functions to not work as expected, or even crash the system. We mitigated this through the extensive use of code reviews. We ensured any code pushed up and waiting to be merged in with main and develop would have to be reviewed by at least one other person in the team. This allowed us the opportunity to make comments to address any issues within the code and, at the very least, allowed for knowledge sharing and gave us an awareness of what code everyone was working on and gaining advice from others more versed in a programming language or specific technology.
By the end of our project, we had designed and developed a working mobile app and webapp prototype.
For our final year project, we were also awarded the Liberty IT prize for achieving the highest marks and excellent team collaboration.
So glad that all those hours of team calls and working together paid off!