Designing a Workflow That Helps Loan Officers Better Support Borrowers
February 2025 - September 2025
FLEX (Farm Loan Employee eXperience) is an internal case management application I helped design for USDA loan officers. Its purpose is to guide loan officers through the end-to-end process of reviewing and deciding on farm loan applications. The product had two goals: make the loan review process more efficient for loan officers, and make it more equitable for applicants by creating a consistent, well-documented experience at every step. The origin of this government contract and creation of this product is based on external research completed by GSA. While the scope of this specific contract did not allow for us to conduct research ourselves, we leveraged these insights as much as possible to inform our designs.
what i did
My role on this project was UX & UI design. I worked within an existing design system and collaborated closely with product owners who were themselves USDA loan officers and subject matter experts.
Why it mattered
Research into service center workflows revealed that loan staff often tracked application progress manually using paper files, spreadsheets, and disconnected systems. This made it difficult to maintain visibility into where an application was in the process and to keep track of important documentation, such as submission dates, acknowledgments, and applicant responses.
Providing a single, streamlined place for loan officers to manage this information helps standardize how applications are processed. By centralizing documentation and key milestones within the system, the process becomes more transparent, efficient, and consistent, regardless of who is reviewing the loan.
My roles
UX & UI Designer
tools
Figma
What I Made
Wireframes and mockups for the appeals process screens.
The Problem
Decision Phase and possible appeals
This case study focuses on one of the most complex screens in the application: the Decision step. In this stage, a loan officer records the final disposition of a loan: approved, denied, or withdrawn.
To better understand what I would be designing, I first mapped out the different paths associated with each possible decision. This included identifying the steps triggered by each outcome, the information that needed to be documented, and potential edge cases that could arise.
One of the main challenges in designing this screen was determining how to organize the large number of fields required for each decision while still following the established design patterns used throughout the rest of the application, which I had inherited.
I also considered how the interface would behave if an applicant moved through multiple outcomes over time. While uncommon, an applicant could theoretically be denied, pursue multiple appeals, later receive an approval, and ultimately withdraw their application. Thinking through scenarios like this helped ensure the design would remain scalable and flexible enough to handle complex loan journeys.
Before beginning any interface design, I mapped out my understanding of the requirements and the workflow they implied for loan officers. I also visualized the type and volume of data that would need to be captured at each stage of the process, which helped inform how the interface should ultimately be structured.
dealing with Piecemeal Requirements
Another challenge in designing this experience was that requirements were often delivered piecemeal. When the Decision screen was originally designed months earlier, the team was told there were only three possible outcomes: approved, denied, or withdrawn. At that stage, there was no mention of an appeals process that applicants might pursue after a denial.
Because the team was not permitted to conduct direct research with USDA loan officers, we didn’t have the opportunity to uncover this part of the workflow earlier through user interviews or observation.
Below is what the base version of what the Decision screen looked like. A common design pattern used throughout the FLEX application was that entering data in one card would trigger the next card with the corresponding next steps to appear to the right. This pattern worked well for simpler, more linear workflows where the next step was predictable.
However, the appeals process introduced a level of variability and branching that the original pattern wasn’t designed to accommodate. Unlike other parts of the application, the workflow here could evolve over time depending on how an applicant responded to previous decisions. The potential areas where appeals-related fields could be added while following the existing design pattern are highlighted in yellow. However, I quickly realized that either option introduced drawbacks and would contribute to a crowded and potentially confusing layout.
What I learned
Receiving requirements late or in incomplete pieces was a recurring challenge on this project. Because of constraints outside the design team’s control, we were not able to go back and redesign the Decision screen to better account for the full appeals workflow. Instead, I had to adapt the solution within the structure that had already been built.
Experiences like this also pushed me to become more proactive when reviewing requirements. I began asking more detailed questions earlier in the process to ensure we had a clearer understanding of the full workflow and edge cases before starting the design.
The complexity of the appeals process ultimately became a useful example that the team could point to when advocating for better visibility into upcoming requirements. Along with the rest of the design team, I used this scenario to help product owners understand why having a more complete picture of the workflow upfront was important, especially since we were not permitted to conduct formal research with USDA loan officers.
Over time, this helped shift how our team communicated with stakeholders and encouraged earlier conversations about longer-term requirements. While we couldn’t change the constraints around user research, it helped ensure that designers had better context for the systems we were being asked to build.
What I decided to do
As mentioned above, the first decision I had to make was where the appeals workflow should live within the interface.
I considered two options:
Keep everything on the same page
Place the appeals content below the main decision workflow, requiring the user to scroll.Move appeals to its own conditional tab
The tab would only appear if the loan officer entered “Reconsideration” in the applicant response field.
My main concern with both approaches was discoverability. If the workflow appeared below the primary decision interface, there was a risk that users might miss it entirely since it would sit below where most of the work was happening. We also weren’t certain that automatically scrolling users to the section could be reliably implemented.
Ultimately, I chose the conditional tab approach. The appeals process was a potentially long, data-heavy workflow, and it deserved its own dedicated space. Placing it below the fold on an already dense screen would have made it easier to overlook and more difficult to navigate.
The conditional tab also communicated to the user that a new phase of the process had begun. To ensure the tab didn’t appear without context, I paired it with an inline banner notification and a red dot indicator on the tab itself. This helped signal immediately that additional action was required and reduced the risk that the loan officer would overlook the appeals workflow.
Designing the Appeals flow
Helping Loan Officers Better Support Borrowers
Once I had established a dedicated tab for appeals, the next challenge was determining how to structure the four sequential escalation steps. Each step required its own fields, meeting notes, and document attachments, and the interface needed to support loan officers as they progressed through the process.
My first instinct was to stack the steps vertically and reveal them progressively by only displaying the next step once the previous one was completed. While this approach kept the interface visually clean, it introduced a potential issue. Loan officers would have little visibility into what lay ahead in the process.
For experienced loan officers, this may not have posed a major issue as they were already familiar with the escalation flow and could anticipate the upcoming steps. However, less experienced loan officers might not fully understand the scope of the appeals process, making it harder for them to clearly guide borrowers through what to expect.
This concern became more significant when I revisited insights from the external research mentioned earlier. Borrowers consistently said they wanted to understand the full loan process upfront rather than discovering steps one at a time. Their satisfaction with the experience was strongly influenced by how clearly their loan officer explained the journey ahead.
This insight shifted how I framed the design problem and allowed me to more clearly see the link between employee and customer experiences. If borrowers wanted greater transparency, loan officers needed tools that enabled them to provide it. Beyond training alone, the interface itself could reinforce this transparency by making the full process visible.
My goal now was to improve the employee experience so that loan officers could more confidently support their customers. By surfacing the entire escalation process within the tool, loan officers regardless of experience level could easily see the potential road ahead and communicate it to their borrowers.
For these reasons, I chose to display all four escalation steps at once. Making the full process visible helped equip loan officers with the context they needed to guide borrowers through the appeals journey, creating a more consistent and transparent experience for everyone involved.
Making use of the empty space
Once I decided to display all four steps at once, two issues became more clear. First, the layout looked visually unbalanced, leaving a large amount of unused space on the right side of the screen. Second, seeing all four cards and their associated fields at the same time created a crowded interface that could quickly become overwhelming.
I had to find a way to communicate the full process upfront so loan officers could understand and explain the entire appeals journey to their borrowers, but do so in a way that kept the interface simple and making better use of the available space.
Initially, I avoided widening the cards to fill the empty space because of the meeting notes section within each step. Loan officers would be typing notes during borrower meetings, and I wanted the text field to remain at a comfortable width for both typing and reading. Expanding the cards to the full width of the screen would have made the note fields excessively wide, which can negatively impact readability.
At that point, I realized that the content within the cards didn’t need to be strictly stacked vertically. By restructuring the layout and moving the meeting notes and document attachment sections to the side, I was able to widen the overall card while keeping the notes field at a comfortable width. This allowed the interface to make better use of the available space.
visualizing the path of Escalation
Once I found a better way to make use of the available space,I still needed a way to communicate the full appeals process without displaying every field from every step at once and overwhelming loan officers.
I decided to place each step inside an accordion, which allows loan officers to expand and collapse cards as needed. This kept the full process visible while limiting the amount of information displayed at any given time.
In order to better visualize the path of escalation, each step only becomes expandable once the user reached that stage of the appeals process. The progression is triggered by the “Applicant Response” field in the previous step. This field documents whether the applicant has chosen to escalate the decision and pursue another appeal after the initial meeting. When an applicant decides to move forward, the next step becomes available.
I also considered how the steps themselves should be ordered. Initially, I assumed the most recent or active step should appear at the top. However, after reflecting on the mental model of the process, I explored whether reversing that order might better communicate the structure of the appeals journey.
Since the process is sequential and escalatory, I decided to place the first step, “Reconsideration”, at the bottom of the accordions. As appeals progress, each subsequent step becomes available above it, hopefully reinforcing the idea that the applicant is moving upward through the escalation process.
To make this progression clear, steps that are not available yet remain visible but locked. The lock icon signals that additional escalation levels exist, but they cannot be accessed until the applicant chooses to proceed.
Longer term
What I would Explore with testing
This design was built without the ability to conduct formal user research. Our users were USDA employees and access to them was restricted to conversations filtered through our product owners. This was a significant limitation and one I pushed back on throughout the project. However if I had the opportunity to test this design, here's what I'd want to learn:
Does the bottom-to-top accordion order match the loan officer's mental model, or does it feel counterintuitive?
Do users want only one accordion open at a time, or is there value in being able to compare two steps side by side?
How much do meeting notes vary in length and type across different loan officers? This would inform whether the fixed-height text area with internal scrolling is sufficient or needs to be more flexible. This would also help me evaluate the width of the meeting notes section I went with.
Is the lock icon alone enough to communicate that a step is unavailable, or does it need a tooltip explaining what action unlocks it?
How do loan officers feel about the conditional tab? Does the red dot and banner give them enough context, or does the sudden appearance of a new tab feel disorienting?
Ideally, these questions would have been validated before finalizing the design. Because access to users and stakeholders was limited, I relied on established design guidelines whenever possible to make sure what I made was aligned with proven interaction patterns.