The Problem To Be Solved

Reducing Risk, Without Tech Debt. 😬

The Real Estate Ops team had to manually input every incoming transaction and outgoing disbursement on a per order basis. Much of this information was already captured in the platform. The input of the transactions was repetitive and left a lot of room for manual error. After an extensive interview with the Ops team, funders both in NY and in TX, this was identified as the most urgent, important feature add to streamline workflows.

Refactored UI Design Needed

Other UX/UI related problems included displaying irrelevant information, repetitive data entry, and not being standard in comparison to what a standard ledger/financial statement should look like. Experienced funders also mention the platform looking nothing compared to what they have used in their careers (+20 years).

Project Type

Desktop WebApp (Internal Facing)

My Role

Lead Product Designer

Team Structure

Product Manager, Director of Design, FE + BE Engineers

Duration

4 Months

KPI

Task Completion Rate

Phase 1 – Exploration

Service Blueprinting

After the project started, I decided to hold a service blueprint workshop so that I might better comprehend how everything worked from end-to-end from the finance team’s viewpoint. I began to form a few hypotheses and used them as guidance to determine what were the next steps. I needed to understand:

  • “What happens when a new order is opened?”
  • “What occurs at the end?”
  • “What happens when something goes wrong, should anything go wrong?”
  • “If something goes wrong, what are the steps for reconciliation?”
  • “What does a successful fully funded order look like?”
  • “Are there any other software(s)/App(s) being used outside of the platform?”

This exercise served as a check on our knowledge of the business. We were able to iterate our understanding of the business process. We started to uncover current inefficiencies by asking questions so that we can trace back an issue if one occurred.

(Fig. 1 — Collaborative Service Blueprint Exercise)

(Fig. 2 — Flowchart)

The workshop was an essential piece that helped me to continue exploring ways to close gaps in my understanding. It was clear that the current flow and UI were performing suboptimal and weren’t up to standards with the industry. With a birds-eye view, it became easier to generate and test ideas to determine which of the changes had a positive impact on users without risk to the business.

I saw the need to create the ability to visualize multiple processes and their sequences of the proposed solution into a single document. Ultimately, it enabled us to have better conversations, efficiency increase, and proper documentation.

Phase 2 – Interpretation

Interpreting The Findings

New Contraints & Priorities

After the workshop, there were new considerations that arose that I had to be mindful of. After talking with engineers the biggest concern that came up was the architecture of the platform, micro-services. One downfall of micro-services is that the entire system is more complex, and it becomes harder to track down issues without additional tooling, whereas the monolith applications were self-contained, and were typically not as hard to debug. 
So with the new learnings from talking with users in mind, and aligning with engineering, we (product + design) prioritized work accordingly. 

A Second Look

Conducting a UX audit allowed us to understand flows and pain points, which we’re confident would help inform future decisions.

The Real Estate Ops team had to manually input every incoming transaction and outgoing disbursement on a per order basis. Much of this information was already captured in the platform. The input of the transactions was repetitive and left a lot of room for manual error. After an extensive interview with the Ops team, funders both in NY and in TX, this was identified as the most urgent, important feature add to streamline workflows.

(Fig. 3 — Design Review, “Escrow Matching” Concepts)

Phase 3 – Experimentation

Iterate, Iterate, Iterate

After the workshop, there were new considerations that arose that I had to be mindful of. After talking with engineers the biggest concern that came up was the architecture of the platform, micro-services. One downfall of micro-services is that the entire system is more complex, and it becomes harder to track down issues without additional tooling, whereas the monolith applications were self-contained, and were typically not as hard to debug. 
So with the new learnings from talking with users in mind, and aligning with engineering, we (product + design) prioritized work accordingly. 

(Fig. 4 — UX Audits & Iterations)

Solution 1 – New Feature

Escrow Matching

The matching process begins with the import of transactions, followed by the execution of the auto-match process, confirmation of suggested matches, and creation of manual matches.
This tool can match large numbers of transactions quickly and identify unmatched transactions, allowing accounting staff to focus on matching the most complex transactions and performing analysis. After Matching is complete, the platform stores confirmed matches and provide suggested matches as well as any unmatched transactions for review by the Finance team for account reconciliation. 
Equipped with this information, the Finance team is able to focus time and effort on investigating only the most challenging exceptions.

(Fig. 5, 6 — Escrow Transactions)

Solution 2 – New Feature

Split Transactions

The Split transaction feature allows you to divide up a transaction into multiple categories. This allows users to split most posted transactions (including negative ones) by a dollar amount, or percentage. The primary reason for splitting a transaction is to allocate portions (splits) of the transaction to different accounts. 

(Fig. 7 — Split Transactions)

Next Steps

Conclusion

New timelines, resourcing issues, and reprioritization meant the scope of the project was constantly changing. I had to adapt to those changes and still deliver the best design in time with tight deadlines. 
I had to work under very strict technical constraints, but still fight for what I believe is essential to having a good user experience. I learned how to define a true MVP vs. something that is simply not usable and therefore not shippable.
There were many great use cases we could tackle with a rich feature set. However, every single one was costly or unrealistic. I had to determine where the real value was for Box so we did not spread ourselves too thin.