Whisper To a Shout, UX Case Study.
Redesigning The YELL Web Presence
RED Academy, November 2016
Challenge:
YELL is the young entrepreneurial leadership launchpad. It’s a curriculum that is implemented in Vancouver public schools with hopes of stretching across Canada. Its previous web presence was made in haste and was lacking quality. Too many dead ends, improper spacing, and hiding of important information held the experience back. The team and I had three weeks re-design the weyell.org website for web and mobile use.
From the get-go, we knew our design must allow all users to gain access to forms and details relating to their needs. Help develop the website as a tool for the YELL staff to manage applicants and requests. Create a new feeling of energy and excitement for the brand and the entrepreneurial mindset, while being attractive on any screen.
Research:
And we were off! We dove into our research phase and immediately were faced with some major challenges. One being access to our eventual end users. Seeing our domain was in education and sponsorship, not every user was able to talk us due to their status as a minor and our lack of time to complete a security background check. Although this held us back we still gathered a sizeable amount of data by reaching out to your own networks within the domain. Alongside the interviews, we created a survey and sent it to high school students on Reddit. Then analyzed the essence of competing organization and comparing them to YELL.
Knowing we wouldn’t have direct access to students, we had to get creative. We had to reach out to our own networks for data. Past high school teachers, friends, family members, donators to non-profits and known entrepreneurs to interview.
Although not our end user the data discovered from it was invaluable. Sure, they haven’t heard of YELL, but they would be just like anyone of our users discovering the organization for the first time. Therefore, capturing the mental model of a new user was paramount to our design. Gathering “discovery” user data helped generate our personas and filled the niche of the new user, we called it “outside data”.
But what about the “inside data”? The actual students and sponsors? Through our heuristic analysis of the previous YELL website, we stumbled upon many press articles, testimonials and a lucrative annual report produced by the YELL team. This data alongside the independent survey we conducted gave us a great deal of internal insight into our hard to reach users.
Due to a lack of an ideal direct access approach to data, our research phase took far too long and was the thorn of the rose. We learned to always create a backup plan for any task. A “what if” mindset to all tasks to complete so that we could reliably capture data or complete tasks on time.
Planning:
Congregating our research, we took up a stretch of the whiteboard and made a post it for each note of data, then grouped the similarities into an affinity diagram. This allowed us to see everything we would need to use to create our design and any common moods or trends.
At this stage in the project, our design took shape and made it stand out from the previous platform. Our research gave us the in-depth consideration and understanding of user behavior and goals that the outgoing site was missing.
To help generate our creative ideas and still capture the goals of the project, we made two key questions that the design would answer;
“Why should I care about YELL?”
“Now that I do care, how do I get involved?”
We found if each feature, button, picture, block of text and attribute of our design could answer at least one of these questions then the design will work for anyone visiting the site. It helped us weed out any unnecessary ideas or functions, helping keep the design light but still powerful.
With those key questions present in our minds, we took existing features on the site and added some additional ones born from research into a prioritization exercise. We did the exercise per user in mind, including the staff of YELL to help further the utilization of the site.
By grouping each feature or element into three categories of;
“Must have” Green dot
“Nice to have” Blue dot
“Not needed” No dot
Then adding a dot corresponding to the location of the feature we could understand which users would use the features the most and where users would overlap in feature usage.
After completing each user’s prioritization, the dotted features where put into a prototype sitemap. Thus, developing the routes individual users would travel through the site to learn and feel confident enough to become involved.
Through this flow routing, it filtered the users to respective pages of information and forms more effectively. Not only satisfying the needs of the users but also creating a more understandable data stream for the staff of YELL. In turn, lowering the staff’s frustrations of data delivery from users requesting involvement.
The rest of our planning came directly from this revelation of a win-win situation we could create. Including our two personas. Though capturing to different types of mindsets, the goals and frustrations were very similar and simply put;
Goals:
-Learn why YELL is different and important.
-Become involved with the YELL program.
Motivations:
-To give back to the community
-To explore the entrepreneurial mindset
Frustrations:
-Limited access to meaningful resources of the site.
-Confusing and difficult to complete application forms.
This is Jacob, he personifies our students coming to the site and is born from our data.
He was one of the biggest reasons we needed to create this platform responsively, for high school students are very keen on web usage on mobile devices.
Our design was influenced by research articles done on behaviors of a teenaged user to address this major contributor to site traffic. The main point of consideration was navigation and calls to action being immediately apparent on landing on a new page, for they rarely scroll up and down pages but rather click through to the end of a route.
Meet Donna, she was the user that could capture the rest of what Jacob would miss on the site. She helped solidify the backbone of the site and gave an interesting chance to link the users together. Not only was she in the mentality of a sponsor or mentor, but also one of a parent.
Which is a major influencer of a student coming into the YELL program, an interesting revelation found in our research phase.
Imagine this, Jacob hears about YELL at school. On his lunch break, he goes to the weyell.org site and he learns about what he could get into. He then decides to get involved and becomes a YELL student next year by sending a request via the website. His parents would probably like to know what he’s learning next year right? That is where Donna steps in, she wants to know what her son will be doing next year. So, she visits the site as well to learn everything her boy will do in school. Along the way finds out that her history of a small business ownership might be something she would like to express. She finds out she can become a guest speaker during the semester and help students like her son become productive professionals after leaving the program.
However nice this scenario sounds, designing it was a nightmare. But by understanding the mindsets of both personas at once and the feature prioritization helped us spring board into the actual visual design and flow of the platform.
Design, Prototype, Test and Repeat:
To create a new flow and mood within the platform we looked back to our dotted feature sitemap. It helped us create pages due to a must have a basis, then incorporated the nice to have features later. Thus, the minimum viable product was always present and the rich nice to haves made the pages clean, clear and comfortable.
The first step was to draw our ideas on the board, allowing each feature, persona, goal, and project team member to be acknowledged and understood.
These first initial sketches were so exciting to see. Due to our approach to planning and research, we knew that each page would be so inclusive for anyone interacting with the site, user or staff.
Leaving low-fidelity, we digitized the sketches into greyscale wireframes. After completing our first prototype we had our first major iteration.
The majority of images and text in this prototype where placeholders. So, when testing we found testers would be lost and unsure of what they were interacting with.
The completion rate of this prototype was very poor so the first big change was plugging real content that would actually be used in the prototype.
After this, our completion rate skyrocketed and testers had very little problems testing.
We tackled the responsive design goal by choosing to design mobile first. The mentality here is if the product works and looks great on a smaller screen it will be even better when there is more space to work with on a larger scale. Progressive development over graceful degradation.
After coming to a point in mobile testing where there was little to no iteration needed, we transferred and stretched the design into its desktop format. Although the design could now breathe and be freer, it was still held back by its mobile beginnings.
For instance, when testing desktop versions, we found users were lost when performing the “slam” (scrolling to the bottom of a page way too soon and missing any call to action or piece of information, a habit built from today’s social media). They had nowhere to go after slamming because the calls to action were now passed by and there was no footer on the bottom of the page.
After implementing the footer to all desktop pages, we then had to go back to our mobile prototype and add a shrunken version to keep the consistency between platforms. Interestingly enough, we found our mobile tester were now using the footer as well. All I can say from that is, “if you build it they will come”.
One of the most important features of our design is something we named the “split”.
Its origins came from a need to literally split the user base off into their respective route.
Rather than hoping the user finds what they were looking for, we left many calls of action lead to this split that started the user’s specific route in the site.
Allowing them to learn what’s specific to their interests, reach the application form suited for them and help the staff of YELL understand who is trying to contact them by seeing where they came from.
Although this idea of making the user choose their identity before even becoming it seems abrasive. The way we choose to word the options helped eliminate that stigma of commitment before action.
Summary:
YELL had a need for a site, a more powerful site. Powerful in terms of what it spoke to the user, and what the staff of YELL could achieve with it. Going forward with this prototype we aim to achieve those terms.
Our process wasn’t as straightforward as we were hoping, but making those backup plans and learning to think ahead allowed us to complete the project on time and with high praise from the client and audience we presented to.
Our thoughtful approaches to research, planning, designing and testing allowed us to complete so much in so little time. The work the team and I had in this project will stay with me. We all learned so much about fast-paced design, how a well-structured team can perform under stress and how to have an enormous amount of fun doing so.
Looking forward to looking back on this project, it was the most fun in school I’ve ever had.
Want more?
Visit my portfolio!
