Wheaton Mobile

A mobile app for Wheaton College students
UX Research, UX Design, UI Design
Jan to Jun 2020



(My very first UX project)

Wheaton Mobile is an app for Wheaton College (IL) students. 

Currently, the Student Portal is where the students and employees can get access to all the important college-related information, such as course registration, payroll, and school calendar. However, it is not optimized for mobile devices and takes multiple steps to get to relevant functions.

So for the past two years, the Student Government has been receiving requests from the student body to redesign the student portal and/or bring back the old mobile app that has been taken down from the app store two years ago

The official solution has been “Student on Tap.” It is just the front page of the portal website, and the users could save the link as a bookmark that looks like an app to their mobile device. It is an easy and low budget solution but has not solved many of the problems such as the lack of responsive design for mobile devices and inefficient navigation.


Research and design an app where the students can easily get access to the features they need the most.

My Role

This is a solo project.
Company Branding
UX Research
UX Design
UI Design


iPad Procreate
Sketch App
Adobe Illustrator


Jan, Feb, Jun 2020


It is a hypothetical project for my bootcamp, so I don't get to decide the process and methodology.

The primary purpose of this project for me was to learn all the steps of UX. The process is outlined by the curriculum I'm taking. I can't skip any step. 

1. User Research & Synthesis

What do I want to discover? – Research Questions

1. What are the undergraduate students’ opinions and experiences of the current platforms (Wheaton Portal and Student on Tap)?

2. Do students need a stand-alone mobile app? Why or Why not?

3. What are some of the top functions/features students wish to include in the potential mobile app? Why?

How can I assess the opinions of the majority users? – Quantitive Survey

The goal of the Research Survey is to access general opinions, get quantitative data, and recruit interview participants. It is a complement to the in-depth interview I would do next. 


Survey Questions


Survey Responses


Individual Comments

Quantitive Survey - Results Highlights

Almost all the students who left a comment in the survey expressed frustrations with the current platforms and hope to have an app that combines all the features they use often.

"I don’t use student on tap at all. It seems really inefficient and because it’s all just loading the portal, it seems clunky and takes a while to load each thing, and isn’t tailored well to the mobile experience. However, I used the old Wheaton mobile app ALL THE TIME. The fact that it was an actual app optimized for mobile users was great."

How do I better understand the survey response? – User Interview

I interviewed 5 users (4 in-person, and 1 remote). Each interview was about 30 min.

Sample Interview Questions

What do you use … for? Could you walk me through your process of using…? (Menu Schedule, Who’s Who, Chapel Schedule, etc.)

On the survey, you said it’s crucial to include … feature. Could you tell me why?

How do you usually access these links? From Student on Tap or somewhere else?

Do you usually use your phone or laptop to access this feature?

How do you find out about new campus events and keep track of them?

How do you check your class schedules at the beginning of every semester?

What did I learn? — Research Synthesis: Affinity Maps

In order to see trends among the qualitative information collected from different users, I made four iterations of the Affinity map.

Following are the examples of the first version and the final version. 

Affinity Map First Version

Affinity Map First Version

The notes are users’ opinions of and experiences with Student on Tap and its features.

Grouped based on interview questions, such as "Existing Student on Tap features" and "Daily campus-related activities"

Too many categories, too scattered
Not able to generate cohesive insights about the product as a whole

The second version was grouped based on users’ process of using Student on Tap, such as How did they find the info they need, How did they process the info they find, How did they keep the info they process.

Problems: Trouble defining positive or negative; Some notes could belong to multiple categories; Many in “find info” but not much in other categories 

The third version was based on modified steps for Behavior Design:
1. Cue (How did users notice the activity/feature/task?)
2. Reaction (What did users do or say?)
3. Evaluation (How did the users feel?)
4. Consequence (What did the feature/action result in?)
5. Timing (How often and when?)

Problems: Many extra notes did not fit into this model 

Affinity Map – Fourth and Final Version

This map shows the positive and negative expectations and reactions users have when they interact with Wheaton Portal and Student on Tap, including how they find, process, and keep tract of the information they need.

Affinity Map — Fourth and Final Version

What did I learn? — Research Synthesis: Empathy Map

I made the empathy map in order to visually organize the insights, observations, and quotes that I have collected from the research to better understand the user’s pain points, goals, feelings, thoughts, and behaviors. 

What did I learn? — Research Synthesis: Persona

I created a user persona that helped me to make user-centered decisions during the next steps of my design process. Even though a persona is depicted as one person, it’s actually a synthesis of the observations and analysis I have recorded of many different users.

I chose to only make one persona for now because all the users I researched have needs similar enough to be grouped together. 

Summary of What I Learned
Research Synthesis: How Might We (HMW) Statements

1. How might we help Wheaton College students find information related to campus activities easily?

2. How might we make some features more readily available and accessible on mobile devices?

3. How might we make students more aware of campus resources that they might want to use?

2. Design & Ideate

The followings are Information Architecture that I designed to better organize the app before I start designing the screens.

They're all slightly different from the final prototype that I made, but they are very helpful in providing the initial structure for the app.

What's the most essential features? — Minimal Viable Product (MVP)

A Minimum Viable Product (MVP) is a prototype that contains the essential features a user would need to complete the essential tasks but nothing else.

Based on the research result, I identified five features that are crucial to include: single sign-on, chapel seat and attendance, directory, hours, and menu.

I designed the lazy registration pattern: allowing the user to skip the sign-in process to access the app first so that they can save time, and it would also benefit visitors and first-time users since they won't be stuck behind the sign-in process. After seeing what the app offers, then they're more likely to be willing to sign in. Certain features are limited when not logged in for security reasons, such as students' contact info, whereas others do not require a login, such as looking up menu since the cafeteria is open to everyone.

How do the user complete the essential tasks? — User Flow (Red Routes)

The User Flow detailed the critical paths users will follow when using my app. I made three red routes, one for each critical feature: Directory, Chapel, and Hours. Here is one sample:

Wheaton Mobile User Flow - Directory

3. Sketching & Wireframing

Brainstorming the design — Sketches

Based on the user flow, I then made a total of 40 sketches and connected them into a clickable sketch prototype. Here are some examples.

Sketching allowed me to take a faster approach to rapid iteration.

I only designed four of the 12 potential features listed on the home page for this first release of Minimal Viable Product. The reason that I included the rest on the home page was because this layout could benefit the design of the future products, since one of the user's desires is to have a product that combines all the features.

I included some screens that are not in the key red routes, such as the sidebar menu, settings, and profile, because though they are not the shortest route for the users to complete a task, these screens are essential for the functionality of the app, such as easy navigation, log out, and change passwords. 

Examples of low fidelity sketches

Quickly validate the design — Guerilla Usability Testing

I conducted 3 short 15-min in-person Usability Tests.

Some of the issues and ways to improve include:

1. The icon and link "Profiles" on the home screen was confused with "Directory." Changing it to "My profile" would easily clear the confusion.

2. Confusion over being able to zoom in the chapel seat map. Adding a hint on the initial screen could help. It is partially because the prototype cannot show the transition from the whole map to the zoomed-in section.

3. New students who need to create a new account cannot easily find the "new student" link on the login page. Making the link more prominent and separated from the primary button could help. 

Update the Design — Wireframes and Wireflows

After modifying the sketches, I created the wireframes and wire flows the for red route. Slightly different from the user flow, for the wire flows, I decided to separate "Access Home Page" (logging in) as a different route from the rest so that it's not too repetitive. I also added a route for returning users who could sign in a lot faster than the first time users.

I made a total of over 40 wireframes and 7 wireflows (one for each use case). Here is one example of the wireflow:

Edge Cases

I thoroughly examined edge cases that a user may encounter to ensure that the user experience remains consistent in every scenario, rather than only when a user interacts with the “ideal” case described by the red routes.

Though there are endless possibilities, and it's impractical to account for every scenario, I designed for several cases that the user is most likely to encounter. Here are some examples.

4. Style Guide & High Fidelity Mockup

Brand Platform

Wheaton College already has its existing branding guideline for print and website, so I incorporated some of its official visual designs, such as logo, typography, and color. For the mobile app branding, I focused more on usability than the college's educational aspect.

Company/Product Name: Wheaton Mobile

Mission/Vision: Wheaton Mobile aims to provide a platform where users can quickly and effortlessly get access to Wheaton College related resources and information that they often use. The students’ campus experience is what we care about the most.

Brand Attributes: Official, Trustworthy, Inviting, Convenient, Sleek. 

Style Guide (Brand Guidelines)

Inspired by Google Material Design, I created the comprehensive design system/brand guideline (creating the nested symbols, specifying the dimensions and usage, designing for different interaction states...)

Though I felt it's a bit of overkill for this mobile app, it would save a tremendous amount of time for the next release where I want to include all the features listed in the main page and menu and for the website.

The logos, typeface family, and primary and secondary colors are the same as the college's official branding, but I added more color and font variations tailored to the mobile platform.

Using the atomic design methodology, I started with small components such as icons, background elevation, and list items and gradually combined them into bigger components such as navigation bars and cards.

For each component, I detailed the dimensions and other essential properties for the development hand-off. All of these components are created as symbols or layer styles in Sketch, so it speeds up the workflow later on and allows for easy modification, expansion, and collaboration.

Here is an overview and a close up.

Style Guide Closeup Example — Text Fields

Style Guide — Overview

High Fidelity Mockups

I turned all the wireframes into the high fidelity mockups. A total of more than 40 screens.

Here are some of the additional routes. "Navigation and Settings" route shows the multiple ways users can access the menu, settings, and profile, so they could easily find these essential functions. "Logged in vs. Not Logged in" route gives some examples of different features offered for users who logged in and those who did not. Enabling the user to skip login first could save their time and give them more freedom.

How do the user complete the essential tasks? — User Flow (Red Routes)

The User Flow detailed the critical paths users will follow when using my app. I made three red routes, one for each critical feature: Directory, Chapel, and Hours. Here is one sample:

High Fidelity User Flow Examples

5. Prototype & Usability Testing


I used Invision Studio to create clickable prototypes with animations, such as micro interactions and transitions. Here are some examples:

(I know that this is mobile app, so there is no be hover effect. The following three micro interactions are for web versions, which is beyond the scope of this first release)

Usability Test – First Round

I conducted 5 modulated usability tests (three in-person and two remote ones).

Objective: Uncover usability problems in the existing red routes.


All the users were able to complete the tasks eventually, though some took a lot longer than the others due to the issues described below.

1. There was no major issue with the layout and navigation, though some menu items need to be reworded.

2. All of the users chose to login first. When I showed them the not logged in screens, they were able to notice the difference and login immediately.

3. Some of the users were confused about what "Directory" and "Hours and Contact" meant.

4. Many users didn't think about using the filter in the first place.

5. It was very easy to locate settings and "my profile." Users like the multiple routes to complete the same task.

Here is the sample list of the issues by priority and before and after comparisons of the critical and major issues.

Usability Testing Findings: List of Issues by Priority

Design Iterations

Based on the usability testing finds, I made changes to the mockup and prototypes. Here is an example of two versions of the same design


What I Learned

This project was my first hands on experience applying the user centric design process from research all the way to visual design and prototype.

1. Are all the steps necessary? I should have a different solution

I didn't get to choose the approach to my problem, which was predetermined by my curriculum. Although the purpose of this project is to help me learn UX, I know there is no"One size fits all" solution.

So looking back, I wish I have approached the problem differently. For examples:

(1) Instead of conducting secondary research and interview with the user, I should have first conducted usability testings of the existing platforms ("student portal") with NEW students. In this way, I could better understand the exact usability issues of the current product. New students can uncover more issues because experienced users might be so used to the design even if it's bad design.

(2) From a business and technical standpoint, rather than creating a new mobile app, it is more realistic to redesign the existing website (such as making it more responsive to mobile screens and redesigning the hierarchy of the web structure).

2. Content Strategy/UX writing is an important part of usability testing

I can't just use placeholder text. For example, word choice affects greatly the user's understanding of the product.

3. Keep Asseccibility in mind

A visual design that looks good does not mean it has good usability. For example, when picking the colors, we need to constantly check if there is high enough of a contrast between the foreground and background. 

Next Step

If time and technology allowed, I would:

1. Partner with the school and developers to see implement some of my design.

2. Conduct A/B testing: comparing my app to the exisiting Student on Tap/Portal.

3. Design a web version.

4. Design all the features listed in the main page.


Daini Eades is a UX/UI Designer at LexisNexis

Follow Me

Web page was started with Mobirise