Project Background
The main problem that we are trying to solve is the fact that many prospective students in the IHE are uncertain which course to select within the department. This could cause some problems for students, as they may select a degree which they are not satisfied with, as they did not fully understand the scope and difference between each degree. This could also potentially cause problems for the IHE, as they may get many requests from students asking to switch to different degrees, which could add unnecessary bureaucratic work. Therefore, our decision tool is aims to solve all of these problems by trying to help the students make a more informed decision about their degree, so that they make the right choice right from the beginning.
Project Goals
From a functional point of view, our goals are to produce a website that aims to give useful and correct information to prospective students to help guide their decisions in selecting a course. The website must be both quick and easy to use, meaning it should have a simple design and efficient algorithm that ensures the course search will be quick.
Additionally, we strived to improve our own technical skills and personal development by researching a variety of new technology to try and create the best decision tool possible.
Requirement Gathering
Our first step in building the tool was to create a list of requirements. This was important, as it would act as a technical specification which would help guide us when we were actually building our project. In order to create a good set of requirements, we decided to focus on two key aspects - The needs of the users of the decision tool, as well as what the client actually wanted from our project.
We recognised that the first meeting with our client would be extremely important, as it would set the scope and focus for the rest of our project. Aside from receiving the project brief, we were also told that the project would act as a 'proof of concept' to help convince UCL to implement a proper extended tool for prospective students. This was vital information, as we understood that the project should provide evidence that building a decision tool could be both feasible and useful to users. The reason this is important is that it provided a lot of flexibility for us, as we were presented with a concrete end goal, but no rigid fixed path to reach it, as we could choose whatever software or frameworks we wanted. It is for this reason that we decided to make our final MoSCoW requirements focus on functionality and deliverables rather than centering them around using a particular kind of software.
We then moved on to analysing users to try and identify their needs to try and create the set of requirements for our system. The most ideal thing to do would have been to directly contact prospective students, but due to ethical restrictions of the module, we were not allowed to do so. Instead, we reached out to current IHE students, as we found that group would best resemble actual users. We then sent out questionnaires to try and identify what choices informed their decisions to choose their current courses. It is also important to note that our own team members were once prospective students as well, meaning we had quite a good sense of what to ask and probe about to obtain the information we required.
Personae
After we conducted our research, our next step was to create user personas in order to really consolidate our understanding about the future users of the project. These personas are shown below. We created them to represent two separate groups. The first group, represented by Arnau are students who have some interest in health care engineering, but have very little information about university or specific courses. The other group, represented by Amanda, represents students who know quite a bit about what they want to study and have clear career goals, and wants to find out very specific information about each degree. These personas were very effective in developing our course decision tool, as it allowed us to code a solution that would be helpful to both groups of people - those with plenty of prior knowledge of degree information, and those without much knowledge.
After conducting our research, we moved on to create a list of MoSCoW requirements. This was very useful, as it allowed us to class our requirements into different groups based on their importance. This was extremely helpful during coding, as we prioritized the completion of our Must features, ensuring that we stayed on task and focused efforts on the most relevant areas of development. Before making the MoSCoW requirements however, we had created user personas to really consolidate our knowledge about future users and create requirements that would target their needs. Our personas can be found at the HCI section of this website.
The diagram below demonstrates the typical steps a user would take to use our tool. We are pleased to say that our tool is quite simple, which is shown by the small number of nodes in the diagram. To give a brief overview of the diagram: the first step for the users is to access our website through a Web enabled device. Next, they fill out a quick questionnaire, and are presented with
courses that correspond to their answers. The courses are presented in the form of a table, and the users can select certain courses to compare to each other (selecting a checkbox). If the users want to see extra information, such as how to apply, they can press on the links that we provide to take them straight to the course's webpage on the official UCL website. Alternatively, they could press the back button to navigate back to the questionnaire, allowing them to vary their answers and explore new results.
