For the purposes of this assignment, the application I'm imagining is a financial / accounting solution for startup and small business CFOs. The purpose of the application would be comparing a previously set budget (maybe at a management or board-level) with what is actually being spent day-to-day and cataloged based on account type, department, etc.
Given that accounts can be divided by department, members of each department are required to login and post their expenses on a bi-weekly or monthly basis, so that their budgets can be tracked appropriately. In order to do so, I'm assuming that data can be imported by:
- Quickbooks account
- Expensify (or something similar)
- Exported (CSV) credit card transactions.
- Manually-added expenses from personal cards, etc.
- Manually manipulating inputted data to reflect changes.
In addition, the CFO (maybe with other folks from finance) can import budgets and adjusted budgets as changes are made from management/board members.
Reaching out to customers with full transparency is going to be key. If there are multiple states of data in the system, they're already frustrated. Admitting that there is an issue and encouraging their participation in interviews means that you're looking to work with them to solve the problem.
- Subject: Got Data Problems?
- Body: We hear you- having multiple versions of your budget isn't going to get you far. As much as it would be nice to just "cook the books," well, that's...frowned upon. Join us in deciding the best possible ways to prevent this in the future and help us improve our product for you.
- Categorize customer and user segments by company size and role in the company.
- Create common use case patterns based on company and role.
- Document usage patterns based on analytics data that can be gathered before hand.
- "What brings you to the product? What is the biggest reason for accessing it?"
- "How often do you typically access the product?"
- "Where do you normally pull data from?"
- "How do you typically go about storing additional data?"
- "What is currently frustrating in how data is inputted / stored?"
- "Do you have a wish list for how we might better provide you with a storage mechanism?"
- "If you were provided a template for inputting data, would you find that helpful?"
- "Have you used other similar products in the past? If so, what did you find beneficial in their offering?"
- "Do you currently use version management systems? Would you prefer to have something like that for the states of your data, or would you prefer to overwrite the old data each time?"
Currently, users are being offered too many ways to input data into the system, manipulate it and save it. From there, tracking the state of the data becomes an insurmountable problem and the source of truth becomes lost.
Users have been categorized into the following segments:
- Large business CFO
- Small business CFO
- Executive-level management (business size was not relevant at this level)
Users from our initial feedback cohort have identified only 2 required use cases for inputting data (currently 5 separate use cases). By narrowing the number of supported use cases, the product can be streamlined such that fewer features are offered, but existing features can be expanded to ensure customer success. The use cases that will need to be supported are:
- Expanded Quickbooks integration that will allow for personal expenses to be included in expense accounts.
- Manually manipulating the data in the system to track changes.
By overriding a specific dataset (rather than creating a new one), users will be able to keep track of a single dataset, rather than various states of the same data.
Pros:
- Far easier to track a single version of individual datasets.
- Provides a clear indication of the current state of the data.
- Easy to implement.
Cons:
- Overwrites the existing data- destroying the previous history for this dataset.
- Requires more manual work offline to maintain the history of that dataset, rather than letting the system handle this.
- Prone to user error and angry users, if there is data loss.
Allow users to continuously upload new versions of a particular data set and go back through versions as necessary to track potential mistakes, or to see data trends at different points in time.
Pros:
- Provides lots of flexibility to users.
- Prevents data loss.
- Provides a safety net for users in case of error.
Cons:
- Relatively large product and engineering lift.
- Potential further user confusion, if not implemented properly.
The system might limit/consolidate use cases that are offered to users, in order to prevent lots of additional data entry.
Pros:
- Limits user error in data input.
- Simplifies the user experience a bit.
Cons:
- Doesn't fully solve the problem of data state for the remaining use cases that are offered.
- May limit required use cases for current or future customers as they expand their businesses.
In order to truly track an accurate data state, a version-management system will be required. This will allow users to override the existing data and have a single source of the data state, while also tracking previous inputs and not forever losing that version from history. The version management system will also allow users to manipulate the data within the system to track potential forecasts given specific scenarios (churn rates higher, sales lower than expected, etc) without necessarily saving this hypothetical state. While limiting the number of uses cases that are offered and expanding other integration points to support their needs would be helpful, it doesn't fully solve the problem and is probably more of a nice-to-have.
Required Features
- Timestamped versions for each dataset. This should also include the
author_idfor the person who made the update. - A selector for choosing the data state.
- Necessary: Allow user to download a CSV of that version.
- Shorter-term: Manipulate the dashboard charts and tables to show data from that version.
- Long-term: Allow the users to manipulate the data from this state of the data (think Git branch with changes)
Nice-to-haves
- Ability to restore the data to a particular historical state as "master".
- Allow users to manipulate data without saving it as hypothetical scenarios.
- Allow company admin (CFO) to revoke access from certain users from write access.
- Ability to purge one or many historical data versions.
- Ability to archive one or many historical data versions.
- Provide a version management UI that shows a full history of dataset versioning with details around authorship and a full change log.
Flow chart for review