An investment association must submit their investment deal records for analysis and sharing. For years, this process is bound to inefficient methods such as spreadsheet sharing and manual validation. Hockeystick means to change this by creating a tool for investors to automate their submission.
My role for this project is to create an end-to-end submission experience to replace the existing workflow.
Understanding the Problem
Right out of the gate, there were already questions and assumptions I've made based on my limited understanding of the existing workflow.
Questions & Assumptions
What is the current submission platform that the users are using?
Can it be assumed that all investors use document based models such as a spreadsheet or PDF to submit their financial data?
How often do investors submit their financial data?
Why do investors submit bi-yearly and yearly?
Are there any other stakeholders involved except for the investors themselves?
Investment groups are diverse and differs in size. Who are the actual users?
Who are the stakeholders?
I started by reaching out to existing account holders on our submission pipeline. From there, I identified the role and responsibilities of the submitter at those respective investment organizations (knowing the limited time they most likely have). This allowed me to map out several personas.
Private Investors (Angels)
High net worth individual, provides sole financial backing to companies. Manages primary portfolio directly. Involved in day-to-day investment recording and allocations.
- Efficient and organized due diligence
- Historical archives of submissions
Administrators (Hockeystick Data Team)
Role: Oversee customer issues, ensures smooth submission periods, and prepares ingestion through data cleansing, deduping, and loading
- Keeping track of customer status
- Resolving data issues during ingestion
- Communicating expectations to the customers (investors)
Data Analysts (VC firms, angel groups)
Role: Usually a junior role, reporting to managing partner or fund manager for tasks related to culling, stewarding, and maintaining organization financial data
- Performant and time saving interfaces
- Precision and error prevention measures
To delve deeper into defining the problem scope, I had to quantify and understand the entire submission process to begin with.
Exploring the workflow
With no additional help from the data team during this stage, I ran through a submission workflow myself solely based on the same information provided to our users.
The immediate impression is that the users performed both the input and submission process within the google sheet itself. During a submission period, a spreadsheet is provisioned to the user via email. The user would then "annotate" his/her completion by setting a dropdown value within the sheet. No further status is ever communicated to the user from that point on.
Upon performing the input step, the process immediately struck me as cumbersome and error prone. Sheets upon sheets were riddled with overridable complex formulas that tried to make the document dynamic. Validation were non-existent, and the horizontal format of the columns made it difficult to traverse through large quantities of data.
Looking underneath the hood
The lack of status update given to the user was puzzling to me. So I took a step back and looked the full extent of the submission workflow just to get a sense of its complexity. I ended up building a flow diagram to map out all the steps beyond the user's experience.
It was clear that the intricacies of our data management overshadowed the user's understanding of it, therefore the entire system was kept in the dark. Counter intuitively, the complexity of this problem stemmed from the yearly submission schedule, where hundreds of deals are processed all at once. This effectively concentrates a point of failure, as any of those record needs to be submitted, cleansed, deduplicated, or merged all within one submission session. This makes it incredibly difficult for errors to be resolved, as they are compounded by the number of records ingested.
One of many examples of an existing workflow. Understanding each of these (with technical details) showed me just how manual the workflow is.
After correlating the feedback provided by both the analysis and user feedback, The following pain points were identified and resulting goals are realized.
Changing the Experience
Challenging the Paradigm
I started by challenging the initial assumption that a bi-yearly submission cycle was the right approach. As seen in the exploration phase, a lot of the issues and errors were handled too late, thus they were not exposed to the user until intervention was needed. Furthermore, users were essentially duplicating their data onto our platform when they needed to submit, which introduces a slew of human errors along the way.
To address this, I conceptualized an ad hoc approach, which did not relegate the user to a bi-yearly routine, but rather to have the user define their own schedules. In essence, the idea is to motivate the user to keep track of their deals directly on our platform, allowing them to be recorded once and once only the moment they are signed.
- Errors stemming from duplication and relationship mapping can be handled immediately upon entry
- Simplifies the submission process by reducing the task from input to selection
- Allows the potential for auto submissions to be set up
- Still allow bi-yearly submissions to be performed, albeit at a much easier process
Designing the Experience
With the new direction, I created several pages with the goals and concept in mind.
A. Submission Dashboard
A dashboard page was considered to be the primary entry point for the user. The dashboard serves as a hub that makes it easy for users to start a new entry session.
- Event banner allows important submission periods to be shown to the user at first glance.
- Primary call-to-actions are prominently displayed at the top, giving users shortcuts to their immediate task
- Users are made aware of session's periodic autosave
- Helpers are explicitly shown, enabling any user to call for support without leaving the context of their workflow
B. Submission Form
The entry page is going to be the most frequently used page in the ad hoc experience. Therefore, it was imperative that the page had to prioritize quick input in order for it to be fully integrated into the user's daily pipeline.
- User's progression is always mapped and presented on every tab to bring context to the length of the submission process
- Animation and visual cues are added to direct the user's attention towards state changes (e.g. scroll to error, adding new transaction, saving loaders)
- Logical branches in the UI are implemented such that fields that are irrelevant to a particular section does not get shown
- Destructive actions are prepended with error dialogs to prevent accidental deletion
C. Submission Wizard
To address the user's lack of understanding of the submission process, it was necessary to walk the user through a wizard process where each page is dedicated to a singular task. At any point, the user is only focused on recognizing and understanding a singular objective, making it easy for them to make the right decision.
It is at this time that errors are prevented, which allowed the user to quickly scan for mistakes. had to show all the submission data in a reviewable form. A grid layout was chosen as the foundation of the page. Not only was it capable of displaying large quantities of data at the same time, it also allowed users to look for discrepancies across funding events. Furthermore, the set of fields are inherently the same across all records, making it a suitable candidate as vertical headers.
Outcomes & Learnings
Throughout the whole process, access to the end user was challenging. In circumstances like these, it was imperative to collect data from 2nd or 3rd party stakeholders. While my initial plans were to conduct user interviews with end users (investors), it was not always possible due to their busy schedules. However, realizing that our data team has ample of knowledge of user behaviour proved to be extremely resourceful in defining the problem space.
At the time of designing this feature, it was scheduled to be shipped after we finished our flagship product. I'm eager to see the increase in efficiency on a wide scale, and the potential to identify unique edge cases that we can incorporate into this ad hoc workflow.
Movie Purchasing Experience