When I was brought on as a Vanguard intern in June of 2021, I had the opportunity to design and develop an internal web application that would assist financial advisors in creating college savings plans for families.
Saving for college can be a daunting task. Tuition prices are continuously rising and difficult to predict far into the future. Many families are eligible for financial aid, but exactly how much aid can be frustrating to figure out. And even knowing these numbers leaves families to create a plan in order to save enough for when the time comes to send their children off to school.
Vanguard does not have an internal tool for financial advisors to reference when trying to help families predict exactly how much they will need to save for college. They do, however, have two internal APIs -- Tuition Projector (TPJ) & Student Aid Index (SAI) -- that calculate tuition far into the future and how much a family would be expected to contribute, respectively.
The following are the core problems this product aims to solve:
- Tuition is hard to predict far into the future. Tuition is continuously increasing so the ticket price today might not reflect that of the future.
- Tuition price does not always reflect expected contribution. Many families qualify for financial aid in numerous forms, so the full tuition price is not necessarily a realistic savings goal.
- Want a quick and easy way to compare different school prices. Most families don't have one school in mind and acceptances are hard to predict, so it's critical to plan for several schools.
Summer 2021
Led UX/UI design end to end
Figma
Because this web app would rely heavily on the TPJ and SAI internal APIs to do most of the calculations, it was critical to sort out exactly what information the APIs needed to work their magic. In addition, knowing what information the APIs could return would dictate what we would display to the advisors. The first step I took was setting up a meeting with the creators of the APIs to clarify the exact inputs and outputs of their APIs.
**Student aid index is how much a family is expected to pay for a specific dependent's education. The difference between the student aid index and the tuition price is expected to be covered by the government/school in the form of grants, loans, etc.
Once I was able to determine the exact inputs and outputs of this web app, it was time to start thinking about the flow of the app. Fortunately, this was not too complicated -- information would need to be inputted before it could be outputted. In addition, my IT team decided to incorporate a database to store information already inputted for previous clients. This would allow for a quicker pathway for advisors working with returning clients. I also wanted to make this calculator a cycle -- all pages could be accessed at anytime once the initial information was entered and submitted. This would allow users to update or add any information they missed before instead of having to start the process over.
Based on the user pathways, I created the following wireframes.
-Break the input page into two pages. Due to the substantial amount of information the user needs to input, I thought breaking the input process into two pages -- parent information and dependent information -- would make the task less overwhelming. This also creates a check point in the middle of the task where, as you will see later on, I incorporated error and success checking functionalities for more user feedback.
-Ditch the navigation menu. Originally I included a navigation bar so the user would know where they are within the app, but realized this was overkill. Be cause the web app only consists of three pages (aside from the log in page) I resolved to drop the navigation bar and instead communicate user pathways clearly through action buttons.
-Create an information hierarchy. I struggled to balance not overwhelming the user with too many numbers but also making sure to include all the information they needed on the results page. I tried to create a clear hierarchy of information -- the important key totals would be displayed in larger fonts in eye catching areas whereas the yearly specific numbers would be smaller and further down the page in case the user wants to reference this less important information.
Due to a lack of time and resources (I only had a few weeks to design before development needed to start), I was unable to do the user testing I would've liked to. Fortunately, I was able to work closely with a financial advisor (Tom) and a senior designer (Daniel) to see how they interacted with the designs and get some of their feedback and suggestions. Here were some of my key takeaways:
-Clarify unclear terms and required fields. After talking to Tom, I realized some of these terms were a little ambiguous, even to financial advisors. What does cash savings amount consist of? How would I calculate the projected net worth of their farm? What if the user doesn't have a business or farm? These were all things I needed to explain in the app for a smooth user experience.
-Create a more clear information hierarchy. Daniel noticed I had a working information hierarchy but encouraged me to take it a step further and give it a bit of an upgrade. I needed to really evaluate what information I wanted to highlight the most and emphasize this with elevation, larger font, borders, etc. and make sure less important information was given a more subtle styling. He also encouraged me to use headings to my advantage -- headings can guide users through the intended pathway and give them a bit more context.
-Make better use of space. I realized some parts of my design were too condensed and some parts were the opposite. My input pages could incorporate accordions to hide sections the user was not currently working on filling out. The results page could be more spread out so the information being displayed was less cluttered and the page had more room to breathe.
Returning users have the option to either update their information or go straight to the calculator results. This is because their information from their first time using the app has been stored in a database so they have option to skip the input pages. First time users, however, will be sent directly to the input pages to enter their information.
If a returning user chooses to update his/her information or a first time user logs onto the web app they will be directed to the parent input page. Here, up to two parents can be added. Error and success checking functionalities gives the user feedback. Drop downs and accordions allow for a more efficient process.
On the dependent input page, users can add numerous dependents. Furthermore both the dependent and parent input pages include tooltips to clarify ambiguous terms as well as dialogue boxes that ask the user if they actually want to delete a dependent after clicking th delete button. Users have the ability to return to the parent input page or submit and move onto the results page (assuming all the necessary information was entered correctly).
After users have entered all the necessary information, they will be taken to the results page. Here they can view the projected tuition and student aid index for each dependent, as well as the total for all dependents. Users have the option to try out different schools and see the pricing differences. They can then choose to save a new school or stick with their original.
Communication with the team developing your designs is essential to a smooth design to development transition. This was the first time I designed a UI that was actually going into development. Fortunately, I got to be a part of both the design and development team for this project. Knowing the technical details of the backend allowed me to keep constraints and possibilities in the back of my head throughout the design process. For example, knowing a database would be connected to the web app allowed me to create more efficient user pathways for returning user. Knowing the backend developers would be using pre-built company components allowed me to use these components and their limited functionalities in my designs. Constant communication with the development team ended up saving a lot of time and backtracking!
