work | thi nguyen

CashFlowTool Summary Page

Background

The challenge

CashFlowTool is a cash flow management service aiming to help small business owners and accountants manage the cash flow of a business. The software offers various powerful features that analyze financial data to efficiently present current cash metrics, transactions, KPIs and forecast future cash activities.

When I joined the CashFlowTool team at Finagraph, the team was in the midst of developing a new key component of CashFlowTool called the Summary page. By adding this new component to CashFlowTool, the team aimed to provide users with a quick and easy way to take a glance at their businesses' financial health.

My role

Joining Finagraph's lead UX designer in September 2019, I led the design aspect of the Summary screen project, working alongside a product manager, our Sales VP, and a front-end developer. During the design process, we also got consultation from other stakeholders including our Director of Engineering, CFO, and CEO.

The CashFlowTool Summary page feature launched on October 14, 2019.

Process

Discovery & Research

The idea of a summary screen first got inspired by CashFlowTool users’ frequently busy schedules as business owners and accountants. From our communications and interviews with customers, we learned that a majority of our users had to handle multiple types of tasks daily and were looking for an efficient way to quickly figure out whether their businesses were doing well in terms of cash flow.

This discovery prompted us to build a tool which offers a quick at-a-glance overview of a business's cash flow during the near past and future. We saw an opportunity in this tool to help business owners and accountants:

Quickly track the financial health of a business without having to check financial data daily
Make well-informed decisions based on reported cash activities
Avoid costly surprises

Ideation & Execution

Through brainstorming sessions, I generated ideas and whiteboarded rapid sketches with a product manager and our Sales VP. We arrived at the decision to include a condensed version of our existing cash flow chart and a notification system in the screen.

The notification system is central to the screen's functionality, as it offers a tool that analyzes a business's cash flow data to sort out the most important information and alert business owner or accountant. This concept was later developed to become a service called CashGuardian™. The main challenge of the Summary screen project was to design this system.

With the design assets from the existing CashFlowTool product, I was able to start creating wireframes at high fidelity. The team met daily and occasionally consulted with stakeholders across divisions to discuss design iterations. Thanks to these meetings, we were able to gather feedback and continuously refine the wireframes, which gradually transformed into more polished mockups.
Notably, several conversations surrounded the communicativeness of the notifications, which include icons and text conveying activities, metrics, and alerts related to a business’s cash flow. These components bear crucial information to a business, yet have to be as intuitive and simple as possible. Therefore, we dedicated lots of consideration and experimenting to craft the best solution.

Eventually, we settled on a final design, which was presented to stakeholders one last time for approval before getting handed over to development.

Implementation, Outcome & More Iterations

During the development process, I worked closely with our lead front-end developer to make sure the design was properly implemented. We made sure to transfer all elements of the design such as colors, typography, and iconography as accurately as possible.
After the screen got released into production, the team was happy to witness a positive reaction from our user base. The Summary screen offers a quick overview-at-a-glance of business for the last 7 days and the next 7 days. With the help from CashGuardian™, the new screen provides a tool that automatically sift through all cash flow data and reports what matters most to a business.

The final CashGuardian™ interface design features a structured, visually pleasing and intuitive system with iconographic and textual elements that clearly display data and indicate various types of notifications. At a glance, a user can easily detect important cash flow information from the last 7days and in the next 7 days, including the amount of cash in, cash out, notable invoices, bills, and so on. This way, one can be assured of a business's cash flow situation or take needed actions accordingly.

The Weekly Cash Flow Chart on the Summary screen is a condensed version of our original Cash Flow Chart, with an additional interaction that allows the viewing of each week's details. This chart shows the last 12 weeks of actual data and the next 4 weeks of forecasted transactions. At a glance, a user can see how the cash balance, cash-in and cash-out amounts are trending over time. By clicking each week in the chart, one can drill down and see additional details for that specific week.

We didn’t forget to gather feedback on the new features by reaching out to customers and watching user session recordings. This way, we were able to observe users’ understanding and adoption of the new Summary screen. These efforts helped us identify technical bugs and design flaws affecting the new features’ user experience. From these discoveries, we timely devised solutions to fix the problems.

Takeaways

This was my first project at Finagraph, which gave me an amazing jumpstart as part of the CashFlowTool team. Overall, this was a fulfilling project to me, not only because it provides a powerful financial tool that helps small businesses thrive, but also because it taught me a lot on achieving an efficient workflow, the importance of iterations, and effective visual communication. Moving forward, the team will keep looking for ways to improve the Summary screen and the CashFlowTool application as a whole to bring an even better experience to our users.

Issue Reporting App for College Residential Communities

Overview

This project presents a design concept of an issue reporting mobile app for a college residential community. Having lived in dorms all through my 4 years in college, I have witnessed my own and my peers' experience with maintenance, most of which was unfortunately inefficient and sometimes painstaking. This inspired me to research and design a system for a college residential community, which allows users to report issues and track the progress on resolutions.

Constraints

To keep the project more manageable, I mainly focused on the residents’ side of the product’s experience. I designed the experience with an intention of it being a larger, cohesive system that connects residents with management and maintenance; however, for this exercise, I focused on mainly the residents, to narrow my users down to one single type. More details regarding my intended system could be found in my stretch goals, which I will be discussed at the end of this case study.

I also approached this exercise primarily as a mobile application. This constraint was decided using my findings during the research phase (discussed in the next section). I found that most target users need a rapid and fussless way to report an issue. This is generally more easily achieved with a mobile application as opposed to a webapp, and also more suitable for such a type of user as young college students, who are avid cellphone users.

Discovery & Research

User Interview

I started by gathering information about my target users. To do this, I first conducted user intervews on the experience of reporting issues regarding maintenance or safety in college residence halls. The interview questions were about the frequency at which a student has to report an issue to management, common reported issues, and the intuitiveness of the process from starting a report to having an issue resolved.

I conducted interview sessions with 5 students at my school - Howard University. Based on the responses, I observed common patterns, pain points, needs, and behaviors, which I sorted out using an affinity map approach. From these findings, I was able to deduce valuable conclusions about the goals for the system.

From the interviews, I was able to narrow down the following common problems:

It’s easy to report an issue but hard to track the progress.
Some students would prefer to call their residence assistant or front desk rather than filling out a long form.
Most students usually encounter issues related to damaged facilities or fire hazards.

Competitive Analysis

Along with interviewing target users, I also conducted a competitive analysis on similar products to get a better insight into how the experience of community issue reporting is designed and executed. I explored 3 mobile apps: Spotlight, Bos:311, and SeeClickFix.

This analysis helped me form a general idea of what is expected in an issue reporting app, how such an app should be structured, as well as certain flaws I’d want to avoid in my design of this experience.

Define

Problem Statement

From the interviews and the competitive analysis, I was able to define a problem statement:

Residents of college residential communities needs a way to conveniently report an issue and track its resolution, because communication from management is often lacking and the reporting process is inefficient.

To solve this problem, I define 3 major goals:

Provide a quick and easy way for residents to report an issue.
Present residents with sufficient details to track the progress of an issue’s resolution.
Efficiently connect residents with management and maintenance workers.

Personas & User Journey Map

Using the findings from my research, I developed 2 main personas and journey maps for my application: an active user and a conditional user.

Lisa Thomas - Active User

Lisa is an active user who generally pays more attention to her surroundings and living environment. She would take matter into her own hand to report an issue, and often would do so promptly.

Chris Anderson - Conditional user

Chris is a conditional user who doesn’t actively feel responsible for issues that don’t directly affect him. For issues that personally interest him, Chris would not always promptly take action, unless the issue requires urgent help.

Using these personas, I mapped out two user journey maps for each persona. The journey maps helped pinpoint the target users' key interactions with the app, their behaviors, and opportunities to solve their pain points, as these users go through each step of the issue reporting task.

These personas and journey maps were significantly helpful during the next step of brainstorming and ideation, as they helped revealing major pain points and the application’s potential opportunities to address those difficulties.

Brainstorming & Ideation

Using my synthesized research findings, I started brainstorming possible solutions, first by whiteboarding ideas and rough sketches to form rough ideas of how a user would interact with the app and complete a task. After a few rounds of iterations, I was able to start forming the features list and user flow of the application.

Since the application revolves around the one experience of reporting an issue, I opted for a bottom navigation with 3 main views, with the reporting form being the action of the FAB:

Reports (the default home view): a list of reported issues
Create new report: a report form to fill out and submit.
Profile: an overview of the user’s information.

After deciding on the features list and user flow, I started wireframing to determine the layout and step of the app's key screens. I first sketched on paper, then moved onto creating mid-fidelity digital wireframes.

I purposefully went with a layout inspired by Material Design, as I saw that this design system would help me easily achieve my intended look, feel, and function for the app: a clean, friendly and straightforward experience. Below is the final lo-fi wireframes after rounds of iteration in Sketch.

Using the mid-fidelity wireframes, I created a rapid prototype, which was used to conduct a few usability testing sessions to evaluate the overall user flow and test my assumptions. I had 5 students complete certain tasks related to reporting issues and viewing reports, and interviewed them throughout the tests. These sessions proved to be significantly helpful, as I discovered lots of opportunities and flaws with the then-current design.

Overall, the test users were able to grasp the application’s features and had little to no problem completing tasks. However, they did encounter certain types of frustration along the process. Some major flaws were involved with a user’s confusion with the tags that convey an issue’s type and progress, and the inability to quickly filter through a list of reports.

High-fidelity Mockups

Taking into consideration these findings, I started iterations on the wireframes and gradually added layers of higher-fidelity elements. After a few iteration rounds, I arrived at a high-fidelity mockup phase of the application.

Upon launching the app for the first time, users would go through a single onboarding step of providing information on where they’re residing. This would help the application locate the users and their respective maintenance/management service.

The home screen - Reports - is divided into 2 main tabs: My Reports and Public Reports. The 2 distinct tabs are based on my observation that among the issues commonly reported by the participants in the user interviews, there are two major categories of issues: those pertaining to one’s personal interests, and those to the whole community’s.

While personal issues are only relevant to certain individuals, public issues affect the whole community and therefore deserves wider attention. For instance, if some gym equipments get broken, a lot of gym enthusiasts within a community might all want to know if they have been fixed. Thus, I decided to design an experience that allows common issues to be publicly displayed and followed by all individuals within a community, while personal issues are only communicated between the reporter and maintenance/management.

The My Reports tab show all the reports submitted by the user, both personal and public issues, since I intend for a user to be able to follow all of the issues he/she has reported. Meanwhile, Public Reports only shows the issues related to the whole community. On each tab, each report is displayed within a card that’s marked with tags indicating its progress, and whether it’s a personal or public issue, in case of the My Reports tab.

Upon clicking on each of the report, the card expands to a full screen display of the report’s details, which also features a timeline of updates on the issue. Here, I intend for a notification to be sent to a user whenever there’s a new update on his or her report, which he or she can choose to turn on or off in the settings. The notifications’ purpose are to enhance communication with residents about their reports, and keep them more on track with the progress of an issue’s resolution. A user also has the ability to comment on an open issue whenever there’s an update he or she would like to add.

After finding through user testing that the application was lacking an ability to quickly sort and filter through a list of report, I added these functions to the Reports tab.

The user can sort the reported public issues by date or by upvotes - also a suggestion discovered from usability testing. Sorting by upvotes let a resident quickly scan through issues based on relevance, potentially saving the problem of people creating duplicate reports of the same issue. Users can also filter public reports based on location or progress. Similarly, in My Reports, users can filter reports based on type of issue and progress.

The Create New Report view presents the user with a concise form to fill out details regarding the issue being reported. Here, I purposefully put a prompt for the type of issue at the top of the screen, to dictate which information would be displayed to the user.

I decided for the application to offer 3 main types of issues: personal, public, and urgent. The personal and public forms are for the discussed personal and public issues, respectively. These two forms are fairly similar, with form fields being straightforward and generously spaced out to cater for better legibility. In the public issue form, a user has the option to remain anonymous when submitting a report.

The urgent tab provides recommended actions rather than a form, since urgent matters require immediate attention. Knowing that emergencies could happen, I put in a notice prompting the user to call 911 for these matters. Meanwhile, there could be non-emergency issues that also require prompt assistance, such as a sudden power outage or suspicious activity. For those situations, I decided to put in options to contact maintenance workers or a residence hall’s front desk.

Upon submitting a report form, the application would present a confirmation screen. This is particularly important, since this screen reassures users that their reports have been received, and that help is on the way.

In addition, upon choosing a category of issue, if the issue is a common one and can potentially be fixed without the help from a professional, users would be prompted to find help from a self-help guide.

The Profile tab simply displays all of a user’s information. If users have not provided their personal contact details, they would be prompted to do so upon first opening this tab or upon editing their profile, with a notice that this provided information would save from re-entering their information for every new report created.

Prototype

Using the high-fidelity mockups, I put together a prototype to better demonstrate the interactions involved throughout the application's experience.

Stretch Goals

Due to time constraint and other limitations, I was not able to address several other intended elements of this experience. As discussed earlier in the case study, I designed this experience with the intention for it to be a cohesive system that could be utilized by residents, management, and maintenance workers alike. When all information is stored and communicated within one environment, it would be significantly easier for all of the mentioned parties to be notified of reports, take action, and track progress.

Another stretch goal for this experience is to expand it into a web application. A mobile app provides a quicker way for a college student to easily pull out his or her phone and put in a report. However, for other intended users of the system like those who work for a residence hall’s management, a web app would be more applicable. Also, under certain circumstances, a resident may need to input a lot of information, which may be more easily done on a computer as oppose to a phone.

SiriusXM Online Cancellation (Work in Progress)

The Problem

SiriusXM offers subscription-based radio services. Currently, the company is not letting customers cancel online. Subscribers have to cancel plans via phone calls.

In November 2018, the digital experience team got an assignment to create an online cancelation flow to potentially offer an alternative way for customers to cancel their subscriptions. This posed as a challenge, since this flow was completely new to the SiriusXM website at the time.

My Role

As an intern on the Digital Experience team, I assisted Senior UX designers throughout all steps of the design process. So far, we have got through user research, brainstorming, wireframing, and user testing. My responsibilities have been extensively focused on conducting competitive analyses and creating wireframes.

The Process

Research

To kickstart the project, we obtained data about SiriusXM listeners and their experience with our cancelation process from our analytic teams. Thanks to this data, we were able to learn about our users and their pain points during the cancelation process.

To get more insight into the online cancelation process, the team decided to start with a competitive analysis. I was tasked with comparing and contrasting the online cancelation flows of subscription-based services similar to that of SiriusXM. To do this, I explored the flows offered by services such as Netflix, Spotify, Hulu, Pandora, and Amazon Prime.

The competitive analysis shed light on a lot of notable aspects present within a seemingly simple flow. From my research, I was able to deduce a few conclusions about the common themes as well as differences present across the different flows. A lot of services try to divert customers’ attention away from the cancelation option, instead introducing alternative actions such as switching plans, temporarily putting the subscription on hold, or staying to benefit from a downgrade offer. Meanwhile, some flows are more lengthy and complicated than others. These details show that there’s a certain balance that needs to be achieved in this type of flow. From a corporate perspective, a service generally wants to retain its customers. However, from a design perspective, the process also should not be too painstaking or lengthy for users. This made me realize that our goal was to achieve a balance somewhere between these two extremes.

Brainstorming & Idea Development

Taking our learning from the research step, the team moved onto idea development, starting with brainstorming sessions. During these sessions, we incorporated data we already knew about our customers with examples we picked up from the researched cancel flows to devise our own cancelation process. The ideas got iterated a few times before two main concepts were chosen: a “plan switching” flow and a “reason picking” flow.

Wireframing

In the plan switching flow, the process starts with a “Switch your plan” option, which takes users to a page where the primary action is to switch to an alternative plan. This flow aims to discreetly divert the user’s attention from cancelation to a change of service.

In the reason picking flow, upon clicking on the option to cancel subscription, users are asked about their reasons to cancel, and presented with checkboxes laying out possible causes. Users have the option to pick one from the checkboxes, and subsequently presented with an alternative action or solution respective to the chosen reason.

During both flows, eligible customers would be shown a downgrade offer when they are a step away from confirming cancelation. After cancelation is completed, the accounting landing page would have a pushdown banner notifying customers with their canceled subscription, end date of benefits, and a reminder that they can reactivate their service at anytime.

Prototyping & Usability Testing

After discussions and iterations on the wireframes, the team decided to run a competitive usability test on the two cancellation flows to gain better insights into how potential users would react to them.

We recruited test participants and created test sessions using usertesting.com. We made sure the test participants closely aligned with the demographics of our listeners and were familiar with subscription-based services.

Prior to creating the test, the team tasked me with researching and synthesizing best practices for competitive usability testing with particular consideration to the two cancellation flows. After discussing the findings and more exploration, we decided to have the test participants go through both flows within one test session, following the same curated tasks while thinking outloud. The order of the flows are randomized throughout the sessions so as not to flaw the results with potential biases.

The recorded test sessions then got analyzed based on pre-determined comparable benchmarks of the two test flows. This way, common themes and touch points within both flows get compared objectively and efficiently.

Next Steps

Currently, we are in the process of analyzing the results from our usability testing sessions. Afterwards, we plan to move onto high-fidelity visual mockups/prototype and implementation.