Scholist is a scholarship platform designed to help students discover, apply, and keep track of scholarships. It also provides resources for students seeking help during the application process.
User Research, UX Design, Information Architecture, User Testing, UI & Visual Design, Prepare Figma Files for Dev Handoff
Understand & Define
Research
Synthesize
Iterate
Prototype
Test
Figma, FigJam, Zoom, Google Forms, Jira
3 Weeks
Scholist is a scholarship platform designed to help students Discover, apply and keep track of scholarships. Scholist app works to provide access to educational opportunities through Scholarships, fellowships, volunteer programs and conferences. Scholist aims to provide personalized scholarship recommendations, essay/resume review as well as 1:1 mentorship to help students through the scholarship application process and to ensure continued success.
We set out to build a desktop experience to help students of various backgrounds, needs, and personality types receive access to personalized scholarships and scholarship resources or services. One of our core aims in this project was to address and hopefully eliminate the stress that is often felt when applying. And many decisions that we made were downstream of this consideration. We also communicated regularly with the founder to discuss the process, ensure that we were on the right track, demonstrate our work, the basis of it, and where we were going next and what that would mean for her. We quickly determined that a key outcome was that she understood the deliverables that were being handed off and could use them to add to and scale her project without breaking consistency.
Prior to our meeting with our client, the founder of Scholist, my team and I got together to establish roles, necessary questions, standards of communication, and information about UX design for her that may aid us in our communication going forward.
In more concrete terms, we sought to establish Scholist's brand and the overall vision for Scholist, the founder's specific goals for the project/key areas of focus that we might prioritize should we need to adjust the scope, and how often and by what means she would like to communicate.
For our part, we would talk her through our standard design process so that she could have a baseline understanding of our process and what we try to accomplish by it. By talking through our client's concerns and our methods, we felt that we could establish a level of communication that would allow us to pivot if necessary despite the project's accelerated timeline.
.png)
In speaking with our client, we determined that the existing platform, while functional, left a lot to be desired in terms of UX. There were a lot of moving targets. Initial users reported that the web experience was confusing, the mentoring and coaching aspects of the platform had yet to be built, and there was a lot of work needed to build trust with future users.
Early on, these conversations were a little difficult. And conversations about our design process were had early and often. The founder had a clear vision and orientation. Anyone who has created something knows of the uncomfortability of the liminal space between one's vision and the actual thing taking shape in front of them.
So what was our client's orientation?
UI and visual aesthetics, primarily.
This was both good and bad. Truthfully, her enthusiasm was infectious and motivating. She had expended a great deal of energy preparing visual inspiration for us. And inspiring, it was!
She and I have similar sensibilities and have both moved toward an emerging design aesthetic featured on websites like Figma. Flat designs, thick borders, lots of white space, and bold typography.
But our client's focus on UI meant that we would likely have to spend a lot of time justifying discoveries about the UX we made during our research phase. Or advocating on behalf of the users. We had hoped to allude to this possibility in laying out our design process but we would discover that communicating the design process isn’t so straightforward. Even despite regular communication.
As the UX team lead for the design of a desktop platform for students to locate and apply for scholarships, I led a team of 4 designers to complete a 3-week project. As part of the research efforts we conducted competitive analysis, usability tests, and surveys before following up with interviews.
The following is representative of some of our findings:
In addition to these features, we felt that improvements could be made to the existing:
As well as the:
...the scope of our duties for the period of time that we had set aside was looming large. We performed a group MoSCoW to form a basic tier list as to what features were most and least necessary in gradations. Additionally, we performed multiple rounds of affinity mapping to determine the most glaring trends.
We knew we'd have to communicate these findings with our client and further to justify the conclusions we took based upon these findings.
Knowing that referring to users as an abstract group isn't an effective method of communicating their needs, we went about constructing two personas and detailing their stories with Scholist.
.png)
As was detailed before, our client is someone with a great deal of energy. Directional energy. And a strong intuition that she trusts. As such, part of our duty as designers was to advocate on behalf of her users and our data to guide her toward design solutions that serve the users and ultimately set her apart. Having Caden and Cameron would serve as our anchor. People who we all ought to refer to in consideration of what we’re making.
At this stage in the process and with the time that we still had, we focussed our communications with our client on features and she was mostly receptive. The features mentioned were based upon Caden and Cameron and were listed in the research section of this case study.
We spoke with our client on these suggestions with little pushback. She felt that our case was clear and was excited about the prospect.
Alongside the features, we were also working on Scholist's style and branding. To do so, there were a few baseline considerations from which we were working.
In discussions with our client, she reaffirmed these choices in her descriptions of a desirable UI. For her, this meant that her website would be:
As we were sketching, making sitemaps, and making mockups we were in frequent contact with our client. Once again, being an energetic and ambitious personality, she soaked in our ideas and had no questions about them.
In addition to this, our application tracking feature wouldn’t be possible. These were cornerstone components of our design and had received a lot of focus for a large period of our design process. We had lost a considerable amount of time and now had to reconsider the section of the website concerning scholarships and scholarship applications.
We had discussed the one-click apply feature for well over a week at this point. And the Scholist mockup website that she brought to us explicitly mentions it. “Apply to scholarships in one click!” [See the How it Works page featured above]
It was only through a particular line of questioning that we discovered what was meant by this or what her intentions really were regarding scholarship applications.
This prompted more questions surrounding Scholist. Questions like - was she working with any devs that we might be put in contact with?
The answer was no.
This posed a problem to be sure. But it was nothing insurmountable. In fact, we'd already laid down the groundwork to pivot.
Before this ever happened, we were clear on communicating with our client about contingencies as well as how to best serve her going forward regardless of how much we were able to ultimately accomplish.
We understood that this project would continue into the future with or without us and that other personnel, including devs, would likely be stepping into the fold. With this in mind, we wanted to ensure that our client could continue regardless of our inclusion and that Scholist would have a strong and documented foundation that others could build off of later. And this is where lego comes in.
Having learned more about what our client’s limitations are, what stage of the process she’s in, and who is involved in the project we had to reorient ourselves with consideration to how she would get the most mileage from our work.
To us, this meant the following:
The logic behind these choices was that what our client needed most was a foundation through which the rest of the site could be built as well as a demonstration as to how this foundation was to be applied.
During this portion of the project, I took a lead in scoping the project with teammates and communicating with our client about what she could expect from us and why. For this, I explained that what our team intended to build was akin to a lego set. We were going to be determining and manufacturing the necessary lego pieces for her website and writing up the directions as to how to construct it. Once ensuring that she understood our goals and orientation and felt satisfied with the way things were unfolding, the team and I launched into our designs.
Working from our sitemap and with our design system largely built out, the group and I began working on our pages. In doing this, we communicated with our client regularly both to ensure that she was satisfied with the direction that things were moving and to further communicate our design decisions in terms of their fidelity to the needs of our users.
While we were doing this, we continued to communicate and update our client with our progress. We always made sure to refer to our research data and our users, Cameron and Caden, to be sure that they remained accounted for in our designs. It was also our wish to keep them (and our data) as the center point of our conversations. Especially around this time.
After many iterations, we had the following:
In addition to these pages, we delivered:
In our communications with our client and throughout our design process, if it hasn’t been detailed enough until this point, we frequently found ourselves...
Being in our position, we wanted to satisfy our client and to unite the vision with the real world so-to-speak. However, our research made clear to us that there were certain components of the service/website that couldn't be diluted. In other words, we felt strongly that we needed to advocate for these services/site architecture/features etc. Oftentimes, we were met with some reluctance.
Having experience working as a music producer, this wasn't the first time I'd encountered that difficult liminal space between one's creative vision and what it looks like when made real in the world. It's never easy.
Fortunately, however, my team and I were able to shift the needle on some crucial components. Some examples include:
We validated these recommendations through additional user testing and found that the revised design and communication of the scholarship listings and the shortened onboarding process were well-received by students and significantly improved their experience and feelings of trust with the website. And ultimately, the client also came to feel as we did. That these choices were of best interest to both users and herself.
As a result of the discoveries laid out here, the company now has a clear direction for the future of their product and how they can stand out amongst the competition, rather than following in their footsteps.
In the end, my team and I delivered 13 high fidelity screens, including 7 priority features, onboarding flows, interactive high-fidelity prototype, future site map, an organized component library, and detailed style guide - all optimized to meet both the customer needs and the small business goals.
Currently, I am advising our client on additional steps she can take with her website/what features may be built out next. She is working with a developer to build out the pages our team has provided her and she and I are currently talking about the possibility that I might build out more of her site.
