PEERS CLINIC WEBSITE REDESIGN
GUIDED INTERNSHIP
Duration: March 2017 - June 2017
Team: 4 UCLA students
Role: Lead Mockup designer & researcher
PROJECT OVERVIEW
Problem:
-
Client wanted the website to reflect the program's warm atmosphere
-
Client wanted to improve the site nagivation
Users:
PEERS students, PEERS parents, PEERS workers
What we did:
-
Conducted user interviews with PEERS students and parents to verify if the problems the client was mentioning were actually felt by the students and parents as well.
-
Created User journey maps to understand the needs of the parents during different stages of their decision process
-
Consulted Google Analytics to see if our findings were lining up with the data
-
Created low fidelity mock ups as a way to present potential changes we could make on the website to address the issues that came up
-
Consolidated all of our findings into a report for the client
​
What we learned
About the Project
The PEERS clinic holds a program for students with autistic spectrum to enrich their relational skills. This program was founded at UCLA and is currently implemented across the world. The target audience for the PEERS Clinic website is parents of autistic children.
Client's Needs
-
The PEERS clinic wanted us to update the website to reflect the program's warm environment.
(Original site showcased on the left) -
They also wanted us to reorganize the content and easier to navigate, as the staff spent too much time answering questions that could be found on the website.
Scope of the Project
As this project was part of a UCLA class, we made it clear to our client that we would only have time to conduct user research and create prototypes. This project did not include user testing on the final prototype or final implementation of the prototype due to limitation in time.
IDENTIFYING USER NEEDS
Interviews
After our initial meeting with the CEO of PEERS Clinic, we found there were 2 main groups of users using the PEERS website: Staff and Users (including: program participants, volunteers, service providers) . Thus, we conducted separate interviews to find their pain points. We used a google form to document their responses.
​
PEERS Clinic Staff (2 staff):
Interview type: In-depth questionnaire
-
Original website design caused the staff to spend too much time answering questions that could be solved through a better designed and organized website.
-
Often received questions of answers that could be found on the resources page or on the Certified Providers page. Patients either couldn't find the page or did not know what "certified providers" meant.
-
Volunteers didn't know where to sign up
-
​
Users (5 participants):
Interview type: In-depth questionnaire & Cognitive walkthrough
-
As a consensus, participants expressed that there was an information overload and desired testimonials.
-
During the cognitive walkthrough, participants had trouble figuring out how to sign up for the program. They also did not realize there were resources available because the resources weren't really consolidated into 1 page and users were expected to find it while exploring the site. Participants also shared that they did not really know what the program was about by just reading what was on the website
Interview Takeaways
Changes Need (Staff)
-
Highlight 3 components: program information, volunteering, resources
Changes Needed (Users)
-
Clear information on registration process.
-
Add Testimonials
-
Divide up text/content so that all the content isn't presented at once.
-
Add more visuals.
Google Analytics
After we interviewed the primary users of the PEERS website (staff and program participants), we wanted to gather website traffic data and check how the website traffic would support or refute what the program participants were experiencing.
Unfortunately, the Google analytics for the PEERS website was linked to the UCLA Semel website so we were unable to pick up any useful web traffic information or patterns.
User Journey Map
Based on our findings from the user interviews, we created this user journey map to better understand the user's behavior.
​
We created 3 different user journeys based on different types of users: Patient, Providers, Volunteers. Thus, throughout the design process, we referred back to this journey map to check if we were addressing needs based on the type of users and which phase they would be at in their journey.
Open Card Sorting
Our team decided on the main sections of the site based on the interview and user journey maps.
​
As we were short on time, our team went through the card sorting ourselves, having the mindset of the potential users (patients, volunteers and providers). We discovered some features of the programs went unnoticed because the information on the original site was too cluttered. Thus we focused on highlighting those features.
(More organized result of the card sort shown below)
​
Main Changes:
-
Created a section for "Resources" that was more apparent than before.
-
Made a distinction between looking vs becoming a certified provider.
-
Added a separate page meant for volunteers
-
Consolidated "News","Events", "Media" to one tab
PROTOTYPING
Low-Fidelity Wireframes
As a team, we created sketches of the new webpages to brainstorm what content should go on each page.
​
When we were stuck on how to layout different contents of a specific webpage, we looked towards existing education sites for inspiration (ie. UCLA, UW, USC).
Medium-Fidelity Wireframes
Using the sketches as a baseline, I created a low-fidelity wireframe using Figma as a discussion point between the team members.
​
Using the low-fidelity wireframe, we were able to pin point unaddressed/new problems before creating a high-fidelity mockup. Problems such as:
-
Pages missing certain information
-
Flaw in the page/navigation flow
-
Missing pages
FINAL DELIVERABLES
High-Fidelity Mockup
I created a higher fidelity wireframes and put it into Invision so that the PEERS staff could get a full experience of the changes that we made, which would especially help them understand the page flow.
*Note, the design of the website is unpolished as the main focus was on the information architecture. Thus I did not have time to polish the design.
To get the full experience, go to Invision.
Site Mock ups:
In-Depth Report
We provided our client with an in-depth report of our processes. This report would allow the next team who takes on this project to easily pick up where our team had left off. The report included:
-
Reasons behind our design changes.
-
Recommendations on further actions that needs to be taken. (shown on the left)
LEARNINGS
Involve the users in the design decisions
-
Rather than reorganizing the website based on assumptions made using user interviews, we should have had the program participants do card sorting themselves so that we could have gotten a more accurate depiction of their thought process.
​
Spend more time in the user flow
-
Our team was too quick to move from the card sorting to creating the prototypes. If we had spent more time in understanding the user journey and utilizing real participants to do the card sorting, we may have been able to find flaws earlier in our page flows before we got to creating the Medium Fidelity Wireframes.
Interactive prototypes are vital
-
Although wireframes can help visualize the website, the client would have had a difficult time understanding the flow of the website without an interactive prototype. The interactive prototype also helped us find mistakes that we would have not been able to find otherwise. We found that certain pages were not accessible because we had not linked it at any point in the website, causing us to rethink our information architecture and readjust accordingly.
​
In-person communication is key
-
We found that communicating with the client in person was vital as information sometime would not get relayed accurately because conversations would get muddled in long email chains. Even within our team, we found that it was important to decide on major project components (ie. wireframe designs) together before breaking off into individual work. Making decisions together allowed us to see if the changes we made were actually necessary as we had to reiterate to the team members why we decided to make certain changes. The fact that we had to support our decisions allowed us to make changes that were actually important.