Case Study: Optimizing Website for STARS- Transfer and Re-entry students department
Background:
STARS is a department at the University of Santa Cruz that provides culturally responsive support to transfer, re-entry, veteran students, as well as students who do not have traditional family support due to experiences in the foster care system, with homelessness, abuse, parents who have been incarcerated, or other factors impacting their family life. STARS department is comprised of professional staff members, peer advisers, and mentors who are readily accessible to guide students on their academic journeys from pre-admission through their transition to UCSC, all the way to graduation and beyond. STARS staff provide holistic and humanizing counseling by acknowledging the lived experiences of students. We offer programs and activities that create a sense of belonging and invite students to be a part of our community.
Introduction
The project in question intended to lay out a set of specific guidelines for developing, basic programming, and designing a graphical user interface and user experience prototype. The project team consisted of providing the functionality to create and organize events for STARS- Services for Transfer and Re-Entry students at the University of California Santa Cruz Department. The main objective of the project was to come up with a set of guidelines to provide the event creation functionality as our main functionality in the final prototype.
Proposal Statement:
As part of the process of developing a prototype, it is indispensable to implement methods in order to develop, achieve, and succeed in any type of project. In the first stage of the method and development of our proposal, we started to research by studying what students in our university required any attention in any area that needs it. We looked at specific issues that students that need the most assistance or resources on. We decided to start looking into student finances and how students can help each other.
However soon after we turned in our Project Proposal, we decided to narrow down to a much smaller user base. Transfer students and new students who are looking for new resources and events in and around campus. In particular, we looked at the STARS program and its website. This specific department communicates constantly with students and staff via email using an amount of illustration, fliers, and posters making to spread messages, ideas, and their own message of the department. This way of communicating by STARS is a little harder to approach the best way of communicating with students and staff. As part of the research, we found their official website with a particular unfunctional website with a problem in their functionality of displaying and creating events. In fig.1 exemplifies the main functionality “STARS- Events” with an unprofessional old-style template and functionality.
Solution:
After benchmarking STARS Website, We have decided to improve the design of the STARS department website by organized the ideas and prepared our Proposal-Prototype, our website primarily was meant for new and transfer students to help find programs or events in and around UCSC, specifically through the STARS program. The extended content will provide additional information about the department as well as provide direct navigation links to the department’s subcategories. Our users would be using the website-prototype via the web, allowing the usability to access via mobile and PC platforms. The estimated number of students that would use this application is 1000 students at most.
Expert User Interview and Personas
As part of the methods of developing a prototype, it is essential to applied evaluation process concepts for our user and expert evaluation in order to create a solid prototype. During the process of finding, interviewing, and evaluating users and experts we applied procedures of experience evaluation methods in too our users and experts.
The first stage of the process was the creation of the Personas. We firstly implemented and defined a persona to be a collection of realistic representative information which can include fictitious details for more accurate characterization. Relating to the definition of the persona, we developed our four personas to be an accurate representation of real-world users for our prototype. In Fig 2. Example of our four personas.
The second stage of the process was to understand the target of our audience, we developed a way to interact with our users. The first part of our process in the stage was the process of contacting them, once we contacted them we meet with them individually. As part of the method of user experience, it is essential to demonstrate to users what was our proposal function. The next procedure was to show physically the drafts and demonstrate them the beginning functions of our website prototype, in Fig.3 there are examples of testing users of our low-fidelity prototype.
Moreover, we explain to users our target function and mainly functionalities. As part of our evaluation and interaction with the user, we develop close interaction with them making analyses and suggestions for our prototype.
The method of testing our User Interface prototype with our users, we developed and easily saturated interactive drafts as a way to communicate and exemplify our functionality, in Fig.4 example of our Low-fidelity prototype samples. We developed four drafts that exemplify each step of the process of “Creating an event” functionality which is our main prototype function.
Usability Method Chart evaluation.
Part of our usability method of the evaluation was provided an easy table chart for us to be graded in general in how is our prototype first impressions. The table provided was scored from 0 to 10 depending on how effective feel engaging our prototype at the time of their interaction. As well we developed based on user notes, opinions, and advising details for our record to give us strong precision functionalities and targets for our final prototype, In Fig.5 example of Usability Method Chart evaluation.
Finally, as our last implement method of user experience evaluation was the process we have conducted an explorative, qualitative study for our expert evaluation to investigate the challenges of integrating UX and UI practices into the different stages of the development process of our prototype. We implemented our expert user evaluation by applying the analytical concepts and controlled experiments. We obtained as a result of strong feedback, analytical, and modeling interface interaction. This process helps us through the constructional base development for our final prototype. As part of the process of the evaluation, we implemented the modeling form of our high fidelity prototype in two sections. First, we demonstrate design features based on the last exercise of the high-fidelity prototype developed in the platform tool of “Adobe XD” example in Fig.6, by strongly demonstrated and interaction with our prototype. In the second scenario combined with the structural interface design, we applied those concepts into our main high-fidelity prototype by the development of the “Home page” on the website and a functional application website for “Creating Events” Fig.7.
The web pages and the functions were developed in the platform “Adobe Dreamweaver” and “Jason” by applying basic java and HTML language. The team’s method and tools proposed to assess the User Experience were implemented to the expert evaluation process to obtain a substantial amount of information that could help us to apply new concepts, features, and techniques to our final prototype.
Competitive Analysis and Requirements
-3 Competitors
- At UCSC there exists what we call an email functional system, as students and staff at UCSC, students get notified if an event is happening thanks to the communication of emails.
- Another competitor is the flyers that are in our community, we see flyers over the UCSC campus transportation, departments, etc.
- Official Website of UCSC and departments, the website covers main events that may interest or benefit students, however not in the totality.
-Competitor functionality
One of the topics discussed in the interview with the manager at the department of STARS, He mentioned a very important topic that is a problem for the community at UCSC and the staff who work in this area. The problem is that most of the events are send via student email, to get the notification of an event, etc. However, discussing with our team and interviewer we came to the conclusion that most of the student does not read or pay attention to, due to the amount of content from what we receive in our academic email. Moreover, these events are sent with a lot of amount of information making it confused and hard to understand the main points or information that in this case I flyer can show
-Competitor Content
The flyers have plenty of content a user would need but only for single events. They don’t get a wide swathe of events available to them. In addition, they can’t take that content with them without taking the flyer, and this stops other people from getting the content and event info they need. The email system solves that problem, but if anything emails gets ignored more than flyers. The website has problems of its own. There aren’t that many events displayed. It's pretty much only the three most recent events. We want to display events chronologically and give a wide swath of events that users might be interested in.
-Competitor Design
In terms of design, the flyers are very well done. Stars actually have designers that they hire to make their posters. The issue is that when you place that one flyer on a bus bulletin board surrounded by other flyers, it tends to get lost in the crowd. They do use the flyers on the website and in the email system, however, the rest of their design is poor. The website has a very antiquated design with just a simple events page that just has a few visible events. We really wanted to increase the visibility of the events and let a user see a broad spectrum of events that are related to them.
Functional and Non-Functional Requirements
Functional:
We need 4 of each
■ The system will have the ability for Students, Faculty, and Staff to upload events (high priority). Reason: this is the main functionality of the system.
■ The system will allow users to edit events they have posted (high priority). Reason: If users make a mistake uploading their event they should be able to change it without deleting and re uploading their event. In addition, if the date has to be changed, they should be able to modify that.
■ The system will allow users to directly RSVP to posted events from the calendar (medium priority). Reason: We want the users to post events to be able to have informative feedback about the number of attendees for planning purposes.
■ The system will allow users to search for events by name or keyword(low priority). Reason: We want our users to be able to easily find what they are looking for.
Non-Functional:
■ The system will be easily readable and navigable on mobile devices (high priority). Reason: A large number of our users mainly access the internet through mobile devices.
■ The system must visually distinguish the upcoming events by type (medium priority). Reason: We want the users to be able to easily understand the events available.
■ The system should be fast and responsive (high priority). Reason: We don’t want the users to get frustrated and not use our system.
■ The system shouldn’t allow Non-UCSC users to post (medium priority). Reason: We don’t want the system to be spammed with fake events.
Key Learnings:
The agile and iterative development process was chosen for the project team. This was mainly due to the fact that although the final objective was clear, many sub-goals became known after certain phases of the project were carried out (such as the interviews with the users and experts). Definitely, the interaction stages with the users and expert evaluations allow us to implement certain characteristics in the process of our development prototype. During the different stages of interviewing our users and experts give us as a result a lot of information, characteristics to retain and implement in our prototype.
Each iterative process has pre-set iteration span lengths for the team at hand, a single iteration lasted for a couple of weeks. At the beginning of each iteration, a stand-up meeting was held between the team, where the whole team reviewed what had been done and what every team member would focus on during the following weeks. Although the process was chaotic at times due to team members switching focus rather often, the end goal was met. This jumping from topic to a topic can be explained by the core ideas of agile development processes — since new knowledge was gained after each iteration with users and also the expert, the team had to adapt to the newly found information and modify their work according to it. Additionally, simplicity was held in high regard, which means that during each weekly stand-up, all ideas that seemed to give little value for effort, were ruled out. This allowed the team to save time and resources without sacrificing the quality of the project. These meetings were held via Drupal messaging due to the fact of the ability of the time of team members. The project team was rather self-organizing, with each member contributing and proposing how assignments should be shared amongst team members.