Scholist

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.

Role

User Research, UX Design, Information Architecture, User Testing, UI & Visual Design, Prepare Figma Files for Dev Handoff

Approach

Understand & Define
Research
Synthesize
Iterate
Prototype
Test

Tools

Figma, FigJam, Zoom, Google Forms, Jira

Timeline

3 Weeks

Project Overview

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.

Design Sprints: Goal Setting and Prioritization

It's all a matter of communication.

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.

Off and Running! Or perhaps not...

Now with the question of UI answered...

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. 

"Yes, that's all very interesting. So, anyway..."

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.

Figma's bold, modern aesthetic

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.

And so we begin!

Q1: How do students feel about applying for scholarships? 

Q2: Right. So...what do they need?
...
Q3: What do WE need?

Research

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:

Research-based feature recommendations: 

  1. A LinkedIn style one-click apply.
  2. An onboarding quiz to log basic information allowing the possibility of both recommendations and the aforementioned one-click apply.
  3. A community feature akin to Reddit or Facebook Communities. (This would include the ability for users to create their own communities on Scholist akin to Reddit's subreddits.)
  4. A services and mentors page akin to Fiverr.
  5. A page of resources including items like essay and resume templates.
  6. The ability to view available scholarships prior to signing up for the website.
  7. A student dashboard where they would have access to features and information like recommended scholarships, outstanding applications, applications in progress, saved applications, saved mentors, saved templates, communities, calendar, and the onboarding quiz (if not completed/or wish to edit)

In addition to these features, we felt that improvements could be made to the existing:

Home

How It Works

Testimonials

As well as the: 

  • Dashboard
  • Applications Section

Having considered all of this!

...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.

From this, what is obvious to our users became obvious to us. 

Designing for the user

Account for existing pain points, yes. But further, how do we ENSURE that Scholist helps to ease users' anxiety? Through accomplishments made on the website as well as the UX itself?

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.

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.

This green light was extremely fortunate given the fast pace of our project.

Style, branding, and...

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.

Fortunately these concerns were easily synthesized.

Blue eases anxiety and increases feelings of trust.

Nielsen's 8th Design Heuristic. Aesthetic and minimalist design. Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility and stresses the user.

Utilize a typography that is at least somewhat lighthearted in appearance. To make an old joke - not comic sans. But not something so formal as Times New Roman either.

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:

  1. "Clean" - lots of white space.
  2. "Techy" - in line with emerging trends featured on sites such as: Fishbowl, Figma, and Untapped.

Right, so what was it that I lead off with? Style, branding, and...?

...a major roadblock.

If every good story has a takeaway...

Ours was communication.

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.

However...

We were having a meeting w/regard to the scholarships and applications pages when suddenly it became clear that

The one-click apply feature was not an option.

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.

Why hadn't this come up earlier? 

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.

It was her intent that upon clicking to apply for a scholarship, the user was redirected to the website hosting the actual scholarship.

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.

What can legos tell us about client deliverables? 

Communicating about scope, deliverables, and building our style.

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.

What is it that Lego does that empowers people of all ages to build incredible, complex structures?

  1. They provide all of the necessary pieces for the structure. This is known to builders.
  2. They provide clear and detailed documentation as to how these pieces form the intended structure.
  3. Most importantly, each individual piece snaps together. It's already the right color. It's already the right size. It's already the right shape. The builder merely needs to follow the guidelines. Which are clear and comprehensive.

This was to be our model for delivery.

Reorientation, serving the users, and also serving the client.

Leveraging the atomic design methodology.

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: 

  1. Heavy documentation regarding design decisions.
  2. A clear, detailed style guide.
  3. Focus on components and organization.
  4. Building the most necessary pages and connecting their formation to the style guide and existing component parts.

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.

To do this, we applied the atomic design methodology.

What does this mean?

  1. Building our atoms, molecules, organisms, templates, and pages.
  2. Providing each as separated components with high organization.
  3. Demonstrating each of these can be leveraged by any designer or dev to continue building out the website while maintaining consistency.

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.

Iterating, iterating, ITERATING...

If this title is your idea of "clever", I'm open for hire!

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 the pages featured here, we also delivered the following pages: 

  1. Scholarship Profile Quiz
  2. Onboarding
  3. Dashboard Variations (dependent on completion of the profile quiz)
  4. Services Page

In addition to these pages, we delivered: 

  1. Style Guide
  2. Components - Organized and listed in terms of atoms, molecules, and organisms.
  3. A report detailing our process, research, findings, and methodology behind our design decisions.
  4. Results of usability testing and changes made based upon them.
  5. Sketches/low fidelity mockups for future pages with the understanding that these could be built out using the style guide and components.

Reflection: Communication and Advocating for the User

Reflecting on the difficult process of uniting a founder's unique vision with the tangible needs of users.

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...

...standing between the clashing preferences of the founder and the users for whom we were advocating...

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.

Conclusion & an Update

All said with a note of gratitude for my team, our client, and all participants in our research and testing.

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.

Thank you for reading!

Related Work