Breeze

Background

Back when I first started at UC San Diego, what I found to be significantly inconvenient was the fact that there was a lack of online resources for UCSD campus organizations. All I found was a list of currently active clubs (that was registered with Associated Students) for that particular school year. This list would especially be sparse when it's the first few weeks of the academic year because there would be some clubs that weren’t ‘renewed’ for that academic year resulting in not showing up on the list. Even if particular clubs were on that list, the amount of information that I can access about that club was very limited and skimpy. There was a need to change that. A way for students to access primary contact information for these clubs/organizations as well as the club official website or page on a social media platform were all very much needed.

Because of the lack of school resources online, students looking for a specific area of interest or finding information in clubs/organizations of their interests can be difficult.

Design Use Cases / User Stories

For this project, the foundation of all deliverables and implementations were based on the descriptions outlined by the 'Use Cases'. Each 'Use Case' is a detailed description and the steps involved with a users' interaction with the application on how it provides functionality. A 'Use Case' is needed for each complete idea implemented by the application. Some examples of 'Use Case' includes the following: Register, Login, Logout, View Page, Create Event, Edit Event, Add Events to Calendar.

In addition, 'User Stories' were used in tandem with 'Use Cases' to design and implement features of the web platform. Each 'User Story' describes the type of user, what they want and why; basically describing each 'Use Cases' from an end-user perspective. For Breeze, we divided the 'User Stories' into three different cases: Baseline General User, Student User, and Campus Affiliate User. The following list is few examples of what a typical 'User Story' would look like:

• As a general user, I want to log-in, so that I can be secure and save the preferences linked to my account.
• As a general user, I want to be able to message administrators, so that I can contact administrators with any inquiry or feedback that I have.


• As a student, I want to subscribe to affiliates so that I can keep up to date with the affiliates that I am interested in and receive their posts in my feed.
• As a student, I want to be able to search for organizations by name and by tag so that I can find organizations that cater to my interests.


• As a campus affiliate, I want to be able to modify the tags of my organization so that students of the app with matching interest will see my organization.
• As a campus affiliate, I want to maintain my affiliate page, so that students can see all my updated information compiled in one place.

Groundwork

Jumping straight into the project, our team of eleven was split into three different teams: Front-end, Back-end, and Design. Front-end and Back-end each had a Development Lead, while I took on the Design team lead. Because of the sheer amount of work that was needed to be done, the amount of time invested into the actual design process of the web platform is very little (roughly less than two weeks).

The design process was very cut-throat and simple. With four people in my team, I gave each member a 'feature page' to design in whatever method they wished, but the final deliverable would be a Figma wireframe in a week to be presented at the next general team meeting. A 'feature page' was considered as one core page of the web platform; as few examples, the 'Landing' page would be considered as one 'feature page' as well as 'Account Settings' page would be considered as one page.

Some people opted to start with sketches, while some jumped straight into Figma wireframe mock-ups. First few iterations are shown below.

During the general team meeting, we would follow the 'pitch' model; each member would 'pitch' their completed page designs. Then once we have majority vote to go-through with the design, we would 'fix-up' the design with suggestions provided by the entire team. The suggestions would cover everything from UI/UX and finest details or implementation problems that would collide with the development team. In the end, I had the final say in all designs as the Design Team Lead.

Refining

Given the classroom environment, we were bound to have varying skill levels and familiarity with other design platforms like Figma. The Design Team often had on-the-spot quick meetings throughout the week to help other members that may be less familiar with designing and design tools. Members with more experience with Figma would often give quick feedbacks as well as direction based on specifications listed out by the 'Use Cases' and 'User Stories'. The final set of wireframes of all 'feature pages' are shown below.


Landing Page

Account Settings Page for Student & Campus Affiliate and Campus Affiliate Profile Page

Calender and Upcoming Events Page

Feed & Discovery Page

Improvisation

As with any project team, our team ran into issues of varying work ethics, priorities/focus, and their willingness to 'learn'. In addition, key members of the team and myself had very different visions of the final product in addition to the quality standards for the project. The team leads and the project manager convened to sort out our development timeline, update each other on each subteam members' capabilities and quality of work that can be produced. It was clear that the project manager was not aware of the development compentency of the team members, and he had drastically different (much higher) expectations from the team. Furthermore, it was clear that this project was not within his top priorities; therefore, we made extreme decisions to make progress for the remainder of the project timeline.

We started by setting our expectations straight and update each other on the varying skill levels for all the members in the team. Then, we created gantt charts to straighten out our development plan, which later became super useful in the long run. The gantt chart would assign the members responsible for the development/implementation of a feature, it organized the order of features to be implemented as some features would be pre-requisite of others, and it provided soft and hard deadlines for the features to make sure the project meets completion on-time.

Finally, we made unofficial role changes for the team to improve efficiency, and produce results that are within expectations and reasonable. We decided to pivot the 'Design' team into a team dedicated to working solely on weekly deliverables and documentation. This was decided because the Design team is no longer designing features, and the members were composed of people who were less motivated on partaking in product development. The project manager would unofficially step down, and manage this newly pivoted team; directly managing the weekly deliverables, documentation, and future presentations. The frontend development team lead would step up as the unofficial project manager because he had the most development knowledge and was capable of mentoring other members in React. Then, I stepped up as the frontend development team lead as I was no longer leading the Design team, and took on the responsiblity to mentor other members with HTML/CSS.

However, despite the changes, the project development came down to four key members: the unofficial project manager (Edward Liang), the backend development team lead (Shih Wen Ma), the most diligent and perservering member (Hoang Nguyen), and myself as the unofficial frontend development team lead. We later dubbed ourselves as the 'Hackathon' team. It was really well fitting because the four of us would run 'Hackathon' coding sessions everyday non-stop for 6-8 hours each session over several weeks. Because the four of us spent so much time together and the three of us were the key members of the team, we were not hesitant on making quick pivoting decisions in terms of feature implementations.

Reflection

While my intention isn't to discount the contributions of other members, this whole project wouldn't had happened if it wasn't for the unofficial 'Hackathon' team. The four of us ended up in the top 10 on the final grade rankings for the course, and became really close friends working on more side projects together. We talk and help each other out on the daily basis with job search, resume building, classwork, and other personal affairs. They are one of the reasons why I enjoyed my time at UC San Diego.

From this project experience, I learned how important it is to communicate on different levels and how frequently to communicate, as we witnessed the chaos throughout the project. In the end, we all struggled on finding the best approach and handling team members that may be less motivated than others, but I am still proud of the progressions made as the 'Hackathon' team.