Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Redesign of payment UX/UI — MoneyLion

193 visualizaciones

Publicado el

Redesign of MoneyLion payment UX/UI

Publicado en: Diseño
  • Inicia sesión para ver los comentarios

Redesign of payment UX/UI — MoneyLion

  1. 1. Redesign of Payment UX/UI Developed by Jane Muder
  2. 2. Interface Features Consistency, Repetition & Familiarity
  3. 3. Interface Features I chose to take the assignment to the next level by designing an interface pattern that combines the best aspects of MoneyLion’s current visual design schema with typography and palette choices that make the interface simple to understand and use.
  4. 4. Interface Features Menus, options, and wayfinding systems are designed using the primary color palette and fonts, with clear numbers, labels and cues that signal their purpose and functionality to users. Menus change appearance when deployed or engaged. Radio buttons and other selectors change color when a choice is made.
  5. 5. Interface Features Form fields offer labels that disappear when information is entered and re-appear when information is deleted. Buttons change color depending on context. Bright, cheerful icons help users with wayfinding as they complete each section of the application, and assist again for those who return to various sections to review or edit information.
  6. 6. Interface Features • Color Palette: I drew the majority of the palette from the existing MoneyLion Dashboard color scheme. I felt that the familiarity of the existing buttons, icons, and layouts would serve users well when navigating the renewed loan application form. • Typeface (Avenir Next): The font family was selected for its readability on digital screens, and for its simple elegance in layouts. It’s legible and attractive without being too fussy. • New Icons: Playful vector likenesses of familiar concepts (banking, personal info) were developed with a nod to the existing MoneyLion style, providing visual wayfinding for users as they complete the loan application.
  7. 7. Interface Features • New Loan Application Form: The accordion-style, single-page design facilitates ease of filling out the application form. Rather than requiring the user to click the back button on the browser and potentially lose entered information, this UI schema keeps each section on one screen and makes it simple to review data before submitting. • Header and Footer: Both are drawn from the MoneyLion dashboard to provide a sense of visual continuity. The current “Apply for a Loan” form displays in a very different style, and I wanted the new design to feel connected to the dashboard. • Single-Column Design: Inspired by the existing loan application form, I selected this for its versatility across a variety of devices and aspect ratios. This is particularly vital for low-income users, whose primary internet access is often via mobile devices.
  8. 8. UX Design Planning Thoughts & Assumptions Guiding the Process
  9. 9. The UX/UI featured in this deck includes the following screens within the “Apply for a Loan” user experience: What’s Included in the UX • Personal Info Section: Updated to introduce the new UX/UI design pattern. • Pay Schedule Section: Different UIs for freelancer/self-employed users vs. regular hourly/salaried users, which reflect differing needs for determining repayment schedules. • Bank Info Section: Includes a new feature establishing how paychecks are deposited if a payday occurs on a weekend or holiday. • Pay Schedule Confirmation Screen: Enables users to review their submitted data and check it against a payday schedule generated for them by MoneyLion.
  10. 10. The UX/UI featured in this deck does not include the following screens or experiences: What’s Not Included • Work Info Section: Later in the deck, I propose updates to employment categories and show how these new categories trigger varying “Pay Schedule” experiences. • Full Confirmation Screen: My design focuses on confirming the pay frequency/schedule. A complete confirmation screen is best suited to a full re-design. • Bank-Specific Questions: According to federal law, banks may hold different types of deposits for different lengths of time, and some holds are customer-dependent. Further research is an ideal way to determine the most accurate method of gathering this information from each user and, if possible, his/her financial institution. • Schedules for Erratic Incomes: These users will be directed to loan counseling.
  11. 11. • Freelance and Self-Employed Workers may work for multiple clients and are sometimes compensated at irregular intervals. A user selecting this option in the “Work Info” section receives a unique “Pay Schedule” form enabling him/her to choose a preferred loan repayment date corresponding with the monthly date when his/her account balance is reliably robust. This design choice is informed by how the IRS handles 1099 income tax repayment installments for freelancers and small business owners. • Seasonal and Sporadic Workers require special income verification and may need extra loan counseling to review borrowing obligations. Selecting this option will trigger a notice referring the user to loan counseling to determine if s/he is an appropriate candidate, and if so, how a repayment schedule may be determined. • Users Not Currently Employed require counseling to proceed with loan applications. Design Assumptions
  12. 12. • Despite a regular pay schedule, a user may find that certain factors affect the timing of his/her paycheck deposit and loan repayment. Such factors include: a month when a payday falls outside of the established pattern, a deposit from an out-of-state bank that requires extra time to clear, or a new job where direct deposit has not yet been set up. • A subsequent iteration of this loan application form could include a mechanism for estimating time-sensitive information, e.g. the maximum time a user’s bank will hold a check before it clears. Additional fields for users who don’t have direct deposit and/or contact information for each user’s bank could be a start, but are not covered here. • Solutions for certain scenarios also depend on MoneyLion’s policies and the terms of the loan. If, for example, moving a February 28 repayment to March 1 triggers a payment default, additional assistance or a custom repayment schedule may be necessary. Design Assumptions
  13. 13. • Each user who is paid on a monthly or semi-monthly basis has the option to select “Last Day of the Month” as a pay date option. Selecting this option indicates payment is received on the 31st of January, March, May, July, August, October, and December; on the 28th of February, and on the 30th of the remaining five months. Caveat: For leap years, such as 2016, Feb. 29 is the “last day of the month.” • Many self-employed and hourly/salaried workers know how their paycheck deposits are handled when paydays fall on holidays or weekends. This design offers them an opportunity to provide this information in the “Bank Info” section of the application. • Because many users do not have a thorough understanding of how their bank holds and clears various types of deposits under various circumstances, this iteration of the UI will not display form fields for gathering such information. Design Assumptions
  14. 14. UX Design Solution A Fast, Simple Application Process
  15. 15. 1. Each section of the loan application process is displayed on the same page, enabling the user to toggle between sections for ease of use. 2. Labels are placed inside form fields. They disappear when the user enters information and reappear when s/he deletes it. 3. The “Save” button for each section is disabled until the user completes that section. 4. The loan application is placed inside the MoneyLion dashboard frame, with the “New Loan” button disabled to indicate the application is in process. Note: If this section is re-designed further, I would recommend adding some user-friendly copy between the section title and the form fields, letting users know why the information is mandatory and reassuring them that their data is safe. 1 2 3 4 Personal Info: Revamped Interface
  16. 16. 1. When information is entered into each field, the form field label disappears and is replaced by the user’s information, denoted in bold text. 2. When each section of the loan application is completed, the “Save” button changes color to indicate an active state. Selecting the button saves the information and auto-deploys the next section of the loan application form. 3. Upon selecting “Save”, the user’s personal info is saved, and the “Personal Info” accordion collapses to default view ( > ), triggering the opening of the “Work Info” accordion. Note: A re-design of the “Work Info” section of the loan application form is beyond the scope of this project; however, I have made a key re-design suggestion for that form on the next slide. 1 2 Personal Info: User Data Provided 3
  17. 17. New “Work Info” Menu Grouping users by type and frequency of income rather than personal status minimizes confusion. Retirees on Social Security may select “Government Income”, while individuals attending college or taking care of children full-time might choose “Not Currently Employed”.
  18. 18. If User Selects Full-Time: Complete standard “Pay Schedule” Part-Time: Complete standard “Pay Schedule” Self-Employed/Freelance: Complete custom “Pay Schedule” Government Income: Complete standard “Pay Schedule” Seasonal/Sporadic: Must speak with counselor Not Currently Employed: Must speak with counselor Depending on which employment status the user selects, s/he will be directed to take the next step that corresponds with that choice. This may entail completing the “Pay Schedule” form or speaking with a counselor before proceeding. “Pay Schedule” form or loan counseling? Pay Schedule3 Each user selects his/her employment status from the drop-down menu when filling out the “Work Info” section of the loan application form. Work Info2
  19. 19. 1. The “Pay Schedule” accordion section has been deployed since the user completed the “Work Info” section of the loan application form. 2. Workers who are paid on a regular schedule will see this view as default when they enter the “Pay Schedule” portion of the Loan Application form. The new design includes some brief, descriptive copy explaining the purpose of collecting the information. 3. The “How often are you paid?” drop-down menu offers no option/blank as default. Selecting the green drop-down arrow on the right-hand side of the menu enables the user to select his/her pay frequency. Available options include: ● Weekly ● Every Other Week ● Monthly ● Every Other Month ● Irregularly Most users who are paid irregularly will have been filtered out by the re-designed “Work Info” drop-down, but those who haven’t and who select this option will receive a referral to loan counseling. 2 3 Pay Schedule: Default Screen, Regular Income 1
  20. 20. 1. Here, the user has selected “Once a Week” from the payment frequency drop-down menu. This selection triggers functionality specific to that payment frequency, as shown in Fig. 2. 2. The user is instructed to select the day of the week on which s/he is paid. This section of the UI is specific to the “Once a Week” selection. 3. The “Save” button remains disabled until the user has provided all required information.1 2 3 Pay Schedule: Paid Once a Week
  21. 21. 1. The user has selected his/her weekly pay date, in this case, Wednesday. On click/tap, the selected day of the week displays with a green overlay. 2. The “Save” button is now enabled and can be clicked/tapped to save the information in this section. 3. Upon selecting “Save”, all user-entered data in this section is saved, and the “Pay Schedule” accordion collapses to default view ( >), triggering the opening of the “Bank Info” accordion. 1 2 Pay Schedule: Paid Once a Week, with Data 3
  22. 22. 1. Here, the user has selected “Every Other Week” from the payment frequency drop-down menu. This selection triggers functionality specific to that payment frequency, as shown in Fig. 2 and Fig. 3. 2. The user is instructed to select the day of the week on which s/he is paid. This section of the UI, paired with the section described in Fig. 3, is specific to the “Every Other Week” choice. 3. The user is also asked whether s/he is paid this week or next week. The answer to this question and the selection made in Fig. 2 enables us to calculate pay dates infinitely into the future. 4. The “Save” button remains disabled until the user has provided all required information. 1 2 Pay Schedule: Paid Every Other Week 3 4
  23. 23. 1. The user has selected his/her weekly pay date, in this case, Friday. On click/tap, the selected day of the week displays with a green overlay. 2. The user has established his/her bi-weekly pay pattern, in this case, stating that s/he will be paid next week. 3. The “Save” button is now enabled and can be clicked/tapped to save the information in this section. 4. Upon selecting “Save”, all user-entered data in this section is saved, and the “Pay Schedule” accordion collapses to default view ( > ), triggering the opening of the “Bank Info” accordion. 1 3 Pay Schedule: Paid Every Other Week, with Data 2 4
  24. 24. 1. Here, the user has selected “Once a Month” from the payment frequency drop-down menu. This selection triggers functionality specific to that payment frequency, as shown in Fig. 2. 2. The sample one-month calendar enables the user to chose the date of each month on which s/he is paid. Clicking (or tapping, on mobile) the preferred date provides visual confirmation that it has been selected. 3. The user may select the 31st OR the last day of the month as his/her regular pay date. Either choice will cause this checkbox to function in the same manner. 4. Since the user has not entered his/her pay date information, the “Save” button displays as disabled/deactivated. Pay Schedule: Paid Once a Month 1 2 4 3
  25. 25. Pay Schedule: Paid Once a Month, with Data 1 2 1. The user has selected his/her monthly pay date; in this case, the 1st of the month, which displays highlighted in green. Days of the week are not included on this calendar to encourage the user to focus on dates. 2. The “Save” button is enabled, and when selected, will save the user’s information for this section, triggering the “Pay Schedule” accordion to collapse and the “Bank Info” accordion to open up.
  26. 26. 1. Here, the user has selected “Twice a Month” from the payment frequency drop-down menu. This selection triggers functionality specific to that payment frequency, as shown in Fig. 2. 2. The sample one-month calendar enables the user to chose the two days of the month when s/he is paid. Clicking (or tapping, on mobile) the preferred dates provides visual confirmation that they have been selected. 3. The user may select the last day of the month as one of the two bi-monthly pay dates by clicking/tapping this box. 4. Since the user has not entered his/her pay date information, the “Save” button displays as disabled/deactivated. Pay Schedule: Paid Twice a Month 1 2 4 3
  27. 27. Pay Schedule: Paid Twice a Month, with Data 1 3 1. The user has selected his/her bi-monthly pay dates; in this case, the 15th and last days of the month. Days of the week are not included on this calendar to encourage the user to focus on dates. 2. The “Last Day of the Month” box displays as active with a check mark in the box to indicate it has been selected. 3. The “Save” button is enabled, and when selected, will save the user’s information for this section, triggering the “Pay Schedule” accordion to collapse and the “Bank Info” accordion to open up. 2
  28. 28. 1. This UI displays the pay schedule for a user who has selected Self Employment or Freelance work. The instructions inform the user that it is his/her responsibility to select the payment date that works best. 2. The sample one-month calendar enables the user to choose the loan repayment date that suits him/her best. Clicking (or tapping, on mobile) the preferred date provides visual confirmation that it has been selected. 3. The user may select the 31st as his/her preferred repayment date OR the last day of the month, which will function in the same manner. 4. Since the user has not entered his/her information, the “Save” button displays as disabled/deactivated. 1 2 4 Pay Schedule: Freelance/Self-Employed 3
  29. 29. 1. This page shows the Sample One-Month Calendar with the user’s ideal repayment date selected; in this case, the 15th of the month. Days of the week are not included on this calendar to encourage the user to focus on dates. 2. The “Save” button is enabled, and when selected, will save the user’s information for this section, triggering the “Pay Schedule” accordion to collapse and the “Bank Info” accordion to open up. 1 2 Pay Schedule: Freelance/Self-Employed, with Data
  30. 30. 1. Note the position of the accordion in Fig. 1, indicating that “Bank Info” is the active section. 2. This page shows a few design tweaks to the “Bank Info” section of the loan application form. Note the new header and icon as shown in Fig. 2. Further re-design may include descriptive copy. 3. The form fields have also been re-designed with the labels inside of them. When the user enters data into each form field, its label disappears, reappearing if the user deletes submitted data. The Routing and Account number visual guides are included in the form field labels for extra reassurance. 4. This section includes a new feature vital to the calculation of accurate pay dates, and thus, accurate loan repayment dates. The user is asked when his/her paycheck is deposited if a scheduled payday falls on a weekend or holiday, and is offered the following three options, with a radio button corresponding to each: ● Weekday Before ● Weekday After ● Not Sure 5. Since the user has not entered his/her information, the “Save” button displays as disabled/deactivated. 2 3 Bank Info: Re-Designed Screen 5 4 1
  31. 31. 1. Here, the form fields have been filled out, and the labels have been replaced with the user’s bank information. 2. The user has provided more details about the state of his/her pay when a scheduled payday falls on a weekend or holiday; here, by indicating that the paycheck is deposited on the weekday before the typically scheduled payday. 3. The “Save” button is enabled, and when selected, will save the user’s information for this section, triggering the “Bank Info” accordion to collapse and the “Payment Schedule Confirmation” screen to display. Note: A full re-design may require a more robust confirmation screen, but my goal was to focus on confirming the user’s pay schedule.1 Bank Info: Re-Designed Screen, with Data 3 2
  32. 32. 1. After completing all sections of the loan application, the user is presented with a “Paydate Confirmation” screen, offering a summary of the user’s pay information along with estimated pay dates for two months. 2. The summary section displays the user’s pay frequency, pay dates, and weekend/holiday paycheck pattern, based on information the user has submitted. 3. Two real-life, monthly calendars display with the user’s pay dates highlighted in green and federal/bank holidays highlighted in red, giving the user an opportunity to visually review his/her data. (Ideally, the displayed example would be shown for a loan application submitted in December 2015) 4. If the dates do not look correct, the user has the option to edit his/her application. Selecting the “Edit Application” link brings the user back to the “Apply for a Loan” screen with the “Pay Schedule” accordion deployed. 5. If the application looks correct, the user can select “Confirm”, and, from there, submit the final application for processing. 1 Paydate Confirmation Screen: Wrapping Up 3 2 4 5
  33. 33. Mobile Screens A Brief (Rough) Preview of the New Design
  34. 34. Thank You It was a pleasure to present to you today.

×