Bruinwalk
As a UI/UX Specialist at Daily Bruin Online, from October 2015 to present, my largest project was a redesign of the Bruinwalk website. This website is a very popular resource for UCLA students, providing course, professor, and apartment reviews. The original Bruinwalk website was outdated, confusing, and very unintuitive, so we focused on making sure that it was the most user-friendly and intuitive that it could be. Another important aspect that we focused on was designing a mobile site, as previously it had been desktop only.
Featured Skills: Design, Research, Project Management
NOTE: This project is still in progress - pieces from the end of the process are missing.
Featured Skills: Design, Research, Project Management
NOTE: This project is still in progress - pieces from the end of the process are missing.
Research
|
Survey
The very first thing that we wanted to do was get a feel for who exactly our current users were, and how they felt about the site. Using a survey, we gathered insight on things such as what they enjoyed doing and cared about most, what things frustrated them, and demographic information about who they were and how often they used the site. |
|
Persona Creation & User Stories
Next, we created personas that we believed represented the beliefs, motivations, and needs of our users. We also thought in depth about different use cases that our users would come across and how we could create a site that would best serve as many of these as it could. We thought about all types of students, non-students, and even professors that would be potentially using our site and kept these in mind as we moved forward to design our site.
Next, we created personas that we believed represented the beliefs, motivations, and needs of our users. We also thought in depth about different use cases that our users would come across and how we could create a site that would best serve as many of these as it could. We thought about all types of students, non-students, and even professors that would be potentially using our site and kept these in mind as we moved forward to design our site.
Design
Site Map
The first design step that we took was creating a new site map. In doing so, we had to really think about the structure of the current site and figure out what could stay and what needed to change. We realized that we wanted to make a drastic change in the structure of the site to increase usability. The old site had one profile page for each professor, and it listed all of the reviews and ratings for every class that the professor had taught, with no way for a user to pick out the reviews and ratings for the particular class that (s)he was looking for. Our new site would instead have an individual profile page for each professor/class pair, as well as what we termed an "aggregate" page for each professor and course that showed an overview of all of the classes that a professor taught (or all of the professors that taught a certain class, for the course aggregate). We really felt like this would allow our users to better find what they were looking for without being overwhelmed with so much irrelevant information. Throughout the design process, our site map continuously changed as we iterated through our designs and our ideas.
The first design step that we took was creating a new site map. In doing so, we had to really think about the structure of the current site and figure out what could stay and what needed to change. We realized that we wanted to make a drastic change in the structure of the site to increase usability. The old site had one profile page for each professor, and it listed all of the reviews and ratings for every class that the professor had taught, with no way for a user to pick out the reviews and ratings for the particular class that (s)he was looking for. Our new site would instead have an individual profile page for each professor/class pair, as well as what we termed an "aggregate" page for each professor and course that showed an overview of all of the classes that a professor taught (or all of the professors that taught a certain class, for the course aggregate). We really felt like this would allow our users to better find what they were looking for without being overwhelmed with so much irrelevant information. Throughout the design process, our site map continuously changed as we iterated through our designs and our ideas.
Sketches
Once we had an idea down for the structure of our new site, we began sketching our pages. Because one of the things we wanted to focus on during the redesign was creating a mobile version, we decided to take a mobile-first approach to our designs. This also allowed us to really minimalize and figure out what information needed to stay on the site and what could be cut down, as one of the problems with the old site was that it was really busy with information. We sketched mobile versions of our pages first and then translated them into desktop versions. My UX team and I (consisting of me and two others) did all of the sketching in person so that we could constantly bounce ideas off of each other and hear each other's points of view. We also consistently thought back to our personas and user stories to check our designs. This was a stage of constant communication between me and my team members as we thought through so many possible ways to design the site.
Once we had an idea down for the structure of our new site, we began sketching our pages. Because one of the things we wanted to focus on during the redesign was creating a mobile version, we decided to take a mobile-first approach to our designs. This also allowed us to really minimalize and figure out what information needed to stay on the site and what could be cut down, as one of the problems with the old site was that it was really busy with information. We sketched mobile versions of our pages first and then translated them into desktop versions. My UX team and I (consisting of me and two others) did all of the sketching in person so that we could constantly bounce ideas off of each other and hear each other's points of view. We also consistently thought back to our personas and user stories to check our designs. This was a stage of constant communication between me and my team members as we thought through so many possible ways to design the site.
Wireframes
I was in charge of turning our very low-fidelity sketches into wireframes, and I did so using Axure RP. I iterated through the designs and found things that needed to be rethought or changed as I did it. I ultimately created a full set of medium fidelity wireframes so that we could better visualize our designs before moving on and turning them into high fidelity mockups.
I was in charge of turning our very low-fidelity sketches into wireframes, and I did so using Axure RP. I iterated through the designs and found things that needed to be rethought or changed as I did it. I ultimately created a full set of medium fidelity wireframes so that we could better visualize our designs before moving on and turning them into high fidelity mockups.
Mockups
The next step was to create high fidelity mockups so that our development team could begin implementation. We decided to use Adobe Photoshop to create our mockups, and the mockup work was split between one other team member and myself. Before we began, we looked extensively at color palettes to determine what colors we wanted to use, as well as UI kits to draw inspiration for the kind of feel that we wanted to create. We ultimately selected a UI kit in which we used some components from, but for the most part, we created our components from scratch.
We took a mobile-first approach to the mockups as well, starting with basic pages and determining the feel that we wanted and then moving on from there. We constantly gave each other feedback on our designs, tested new ways of presenting the information, and iterated through dozens of times. Ultimately, in about a month, the two of us had gone from the medium-fidelity wireframes to a full set of high-fidelity mockups that we were confident enough in to allow the frontend to begin implementation.
The next step was to create high fidelity mockups so that our development team could begin implementation. We decided to use Adobe Photoshop to create our mockups, and the mockup work was split between one other team member and myself. Before we began, we looked extensively at color palettes to determine what colors we wanted to use, as well as UI kits to draw inspiration for the kind of feel that we wanted to create. We ultimately selected a UI kit in which we used some components from, but for the most part, we created our components from scratch.
We took a mobile-first approach to the mockups as well, starting with basic pages and determining the feel that we wanted and then moving on from there. We constantly gave each other feedback on our designs, tested new ways of presenting the information, and iterated through dozens of times. Ultimately, in about a month, the two of us had gone from the medium-fidelity wireframes to a full set of high-fidelity mockups that we were confident enough in to allow the frontend to begin implementation.
Advertisements
Because advertisements are the only source of income for Bruinwalk, we had to make sure to maintain the amount of advertisements on the old site to keep a steady (and hopefully improved) source of revenue. Owned by UCLA Student Media, Bruinwalk is actually one of the main sources of revenue for the entire Daily Bruin newspaper. We had to continously check in with our ads manager and balance his requests with the needs of our users. Because we didn't want our advertisements to be overwhelming for our users, we actually ended up rethinking and redesigning entire pages based on the need for more ads. Finding this balance between business needs and user needs was actually one of the larger struggles that we faced throughout the entire redesign process, but in the end we were able to give users a site where they did not feel overwhelmed with ads as well as keep our ads manager very content with our use and placement of ads.
Because advertisements are the only source of income for Bruinwalk, we had to make sure to maintain the amount of advertisements on the old site to keep a steady (and hopefully improved) source of revenue. Owned by UCLA Student Media, Bruinwalk is actually one of the main sources of revenue for the entire Daily Bruin newspaper. We had to continously check in with our ads manager and balance his requests with the needs of our users. Because we didn't want our advertisements to be overwhelming for our users, we actually ended up rethinking and redesigning entire pages based on the need for more ads. Finding this balance between business needs and user needs was actually one of the larger struggles that we faced throughout the entire redesign process, but in the end we were able to give users a site where they did not feel overwhelmed with ads as well as keep our ads manager very content with our use and placement of ads.
Project Management and Design
Implementation
While our development team began implementation of the site, our UX team continuously reviewed the progress that was being made. There were certain things that worked on mockups that once developed, we realized were not working as well as we imagined they would, so we continued to iterate through many designs. For example, we had planned on using a form for users to submit reviews that revealed each question one at a time, with the intent of not overwhelming the user. Once seeing it implemented in this way, we realized that users needed to see future questions in order to answer and make sense of the first question. The form was not very long, so presenting it all at once was not an issue.
We used GitHub to manage our project, so creating, managing, and prioritizing issues also became one of my primary responsibilities during this stage of the project. This required me to be constantly aware of our deadlines and really helped to develop my time-management skills. It also forced me to think deeply about some of the issues and decide which were the most severe in hurting our user experience, so that we could prioritize what needed to be done.
While our development team began implementation of the site, our UX team continuously reviewed the progress that was being made. There were certain things that worked on mockups that once developed, we realized were not working as well as we imagined they would, so we continued to iterate through many designs. For example, we had planned on using a form for users to submit reviews that revealed each question one at a time, with the intent of not overwhelming the user. Once seeing it implemented in this way, we realized that users needed to see future questions in order to answer and make sense of the first question. The form was not very long, so presenting it all at once was not an issue.
We used GitHub to manage our project, so creating, managing, and prioritizing issues also became one of my primary responsibilities during this stage of the project. This required me to be constantly aware of our deadlines and really helped to develop my time-management skills. It also forced me to think deeply about some of the issues and decide which were the most severe in hurting our user experience, so that we could prioritize what needed to be done.
The Bruinwalk GitHub Repository
(We plan on making this open source once the project is further along)
(We plan on making this open source once the project is further along)
Release
After having our first planning meeting on October 16, 2015, we released a private beta version of the new Bruinwalk to our friends and certain campus organizations about three months later, on January 26, 2016. A week later, we officially launched, releasing our public beta, on February 3, 2016. Our ultimate goal from the beginning was to launch before class enrollment for Spring Quarter began (as this is when Bruinwalk's use rates peak), and we met that goal.
Development has continued since then, as we have continued to gather feedback, make changes, and finish up what we planned to do for Version 1. We have just begun the planning stages for Version 2, where we plan to implement a textbook marketplace.
After having our first planning meeting on October 16, 2015, we released a private beta version of the new Bruinwalk to our friends and certain campus organizations about three months later, on January 26, 2016. A week later, we officially launched, releasing our public beta, on February 3, 2016. Our ultimate goal from the beginning was to launch before class enrollment for Spring Quarter began (as this is when Bruinwalk's use rates peak), and we met that goal.
Development has continued since then, as we have continued to gather feedback, make changes, and finish up what we planned to do for Version 1. We have just begun the planning stages for Version 2, where we plan to implement a textbook marketplace.
Promotion
Throughout the release cycle, we also created advertisements for social media, online use, and print, in order to promote the new Bruinwalk website. I was one of the main designers on these advertisements, which were printed in the Daily Bruin as well as posted on Newsstands all over campus.
Throughout the release cycle, we also created advertisements for social media, online use, and print, in order to promote the new Bruinwalk website. I was one of the main designers on these advertisements, which were printed in the Daily Bruin as well as posted on Newsstands all over campus.
|
|
|
Research
Focus Tests
Throughout our development and release cycle, we wanted to get feedback and test the designs as much as possible. One of the ways we did this was through an informal focus test. We had about 10 people participate, during our private beta, in a group usability test. I took the lead on this. The participants came in, played with the site for a while and completed a task list during which we observed activity and noted any particular pain or pleasure points. We also had them fill out a feedback form and finished with a group discussion about the site.
I looked over the notes from the session, put together a small report to share with the team, and then worked on making appropriate changes and prioritizing issues on the site with the knowledge that I had gained.
The largest change that came out of the focus testing was a redesign of the "Archive Page". Because we changed the metrics with which people rated professors from the old Bruinwalk, we had a lot of old reviews that were no longer applicable to the new framework, but that contained valuable information for users still so we did not want to throw them away. Originally, we were using an "Archive Page" for each professor that held all of their old reviews from the old Bruinwalk. During testing, we found that people were very confused with what the archive page meant and why those reviews were separated out. We rethought the organization and design of this, and ultimately decided to change it to an "All Reviews Page" for each professor, that just showed every review for every class that the professor had ever taught, old or new. If users wanted to see the reviews for a particular class, they would just go to that class/professor profile and see the new reviews that applied to that class. We saw immediate improvement in understanding and engagement after making this change.
Throughout our development and release cycle, we wanted to get feedback and test the designs as much as possible. One of the ways we did this was through an informal focus test. We had about 10 people participate, during our private beta, in a group usability test. I took the lead on this. The participants came in, played with the site for a while and completed a task list during which we observed activity and noted any particular pain or pleasure points. We also had them fill out a feedback form and finished with a group discussion about the site.
I looked over the notes from the session, put together a small report to share with the team, and then worked on making appropriate changes and prioritizing issues on the site with the knowledge that I had gained.
The largest change that came out of the focus testing was a redesign of the "Archive Page". Because we changed the metrics with which people rated professors from the old Bruinwalk, we had a lot of old reviews that were no longer applicable to the new framework, but that contained valuable information for users still so we did not want to throw them away. Originally, we were using an "Archive Page" for each professor that held all of their old reviews from the old Bruinwalk. During testing, we found that people were very confused with what the archive page meant and why those reviews were separated out. We rethought the organization and design of this, and ultimately decided to change it to an "All Reviews Page" for each professor, that just showed every review for every class that the professor had ever taught, old or new. If users wanted to see the reviews for a particular class, they would just go to that class/professor profile and see the new reviews that applied to that class. We saw immediate improvement in understanding and engagement after making this change.
Feedback Forms
Aside from focus testing, we also had feedback forms on our website throughout the entire private and public beta phases. In order to not frustrate people who wanted to give quick feedback, but still gain detailed feedback from those who wanted to, we had two feedback options - a quick feedback form and a full experience survey. We also had a bug report form.
We gained a lot of valuable insight from all of these forms. I was in charge of staying updated with new feedback, deciding what needed to be done, prioritizing it, and assigning them to issues on GitHub. The feedback forms led to tons of small changes that overall helped our site become more intuitive and usable.
Aside from focus testing, we also had feedback forms on our website throughout the entire private and public beta phases. In order to not frustrate people who wanted to give quick feedback, but still gain detailed feedback from those who wanted to, we had two feedback options - a quick feedback form and a full experience survey. We also had a bug report form.
We gained a lot of valuable insight from all of these forms. I was in charge of staying updated with new feedback, deciding what needed to be done, prioritizing it, and assigning them to issues on GitHub. The feedback forms led to tons of small changes that overall helped our site become more intuitive and usable.
Analytics
We also used Google Analytics to track usage of the site. Using the analytics, we could see the direct effects that our changes were having on the site. We used this in many cases to see how well different things were working for our users. For example, in our review forms, we use a "tag slider," where people are able to assign tags to classes and professors that they feel accurately describe their experience in that class. It was difficult to come up with a design for this, as we had to have some way to allow a user to distinguish between saying "No," that the tag doesn't apply, and a user who just skips the question and doesn't answer. We used Google Analytics to determine what a good way to present this was. The tag slider led to very high rates of users who applied tags to their classes/professors, so we decided on that. We continue to monitor the analytics to see what is and isn't working.
After the launch of the Bruinwalk redesign, the number of reviews per day nearly doubled from the old Bruinwalk.
We also used Google Analytics to track usage of the site. Using the analytics, we could see the direct effects that our changes were having on the site. We used this in many cases to see how well different things were working for our users. For example, in our review forms, we use a "tag slider," where people are able to assign tags to classes and professors that they feel accurately describe their experience in that class. It was difficult to come up with a design for this, as we had to have some way to allow a user to distinguish between saying "No," that the tag doesn't apply, and a user who just skips the question and doesn't answer. We used Google Analytics to determine what a good way to present this was. The tag slider led to very high rates of users who applied tags to their classes/professors, so we decided on that. We continue to monitor the analytics to see what is and isn't working.
After the launch of the Bruinwalk redesign, the number of reviews per day nearly doubled from the old Bruinwalk.
