Challenge
Challenge
Challenge
Is the current account categorisation experience sufficient for users to accurately categorise their financial statements?
Solution
Solution
Solution
Apply design thinking to explore the problem space, generate potential solutions, and rapidly test them with users and subject matter experts.
Scope
Scope
Scope
Conduct interviews with external and internal stakeholders, user testing, competitor analysis, workshops, sketching and mid to high fidelity designs ready for handoff.
Context
Context
Codat allows users to manually categorise their financial statements pulled through the accounting API. Accurately categorising these accounts allows users to produce both traditional and industry specific metrics. Clients extract these metrics and create a credit model by applying weightings and thresholds for decisioning. This process allows clients to make faster lending decisions on small businesses.
Codat automatically applies suggest categorisation to a clients account. Creating a front end that will encourage an increase in the number of highly accurate accounts that are confirmed by clients will aid Codat’s data science team in building a more accurate enhanced categorisation model. The resulting impact should be that Codat’s overall suggestion rate and accuracy rate increases following the release.
The first focus is on increasing the accuracy of categories which are confirmed by providing the user with enough information to identify the correct category. Then the focus will be on increasing the number of accounts which are categorised by making it more efficient for clients to categorise highly accurate accounts in bulk.
Codat allows users to manually categorise their financial statements pulled through the accounting API. Accurately categorising these accounts allows users to produce both traditional and industry specific metrics. Clients extract these metrics and create a credit model by applying weightings and thresholds for decisioning. This process allows clients to make faster lending decisions on small businesses.
Codat automatically applies suggest categorisation to a clients account. Creating a front end that will encourage an increase in the number of highly accurate accounts that are confirmed by clients will aid Codat’s data science team in building a more accurate enhanced categorisation model. The resulting impact should be that Codat’s overall suggestion rate and accuracy rate increases following the release.
The first focus is on increasing the accuracy of categories which are confirmed by providing the user with enough information to identify the correct category. Then the focus will be on increasing the number of accounts which are categorised by making it more efficient for clients to categorise highly accurate accounts in bulk.
Problem
Problem
Codat’s models are not advanced enough to accurately categorise all account automatically, resulting in clients having to manually review accounts. The current categorisation UI provides very limited information and functionality which results in clients not having enough information to categorise correctly resulting in accounts being incorrectly categorised. Impact of this:
• The financial statements produced are not accurate
• The financial statements produced are not accurate
• Codat’s enhanced financials models and other dependent models are being trained on poor data.
• During manual reviews, clients cannot quickly and efficiently get through all accounts for a business which means using this feature increases the time it takes to underwrite.
Codat’s models are not advanced enough to accurately categorise all account automatically, resulting in clients having to manually review accounts. The current categorisation UI provides very limited information and functionality which results in clients not having enough information to categorise correctly resulting in accounts being incorrectly categorised. Impact of this:
• The financial statements produced are not accurate
• The financial statements produced are not accurate
• Codat’s enhanced financials models and other dependent models are being trained on poor data.
• During manual reviews, clients cannot quickly and efficiently get through all accounts for a business which means using this feature increases the time it takes to underwrite.
Objectives
Objectives
After receiving feedback from clients that the current account categorisation user interface did not meet their needs, I needed to redesign the experience to benefit our clients while also helping to train Codat's enhanced categorisation model.
After receiving feedback from clients that the current account categorisation user interface did not meet their needs, I needed to redesign the experience to benefit our clients while also helping to train Codat's enhanced categorisation model.
Process
Process
I knew that changes needed to be made to the core account categorization product, but I did not yet know what information or functionality would help our clients quickly, efficiently, and accurately categorize accounts. A small team consisting of a product manager, business analyst, and myself was formed to explore the problem space.
To support our proposal to redesign the experience, we started a discovery process to explore the purpose of the account categorisation experience, its perception and usage internally and externally.
I knew that changes needed to be made to the core account categorization product, but I did not yet know what information or functionality would help our clients quickly, efficiently, and accurately categorize accounts. A small team consisting of a product manager, business analyst, and myself was formed to explore the problem space.
To support our proposal to redesign the experience, we started a discovery process to explore the purpose of the account categorisation experience, its perception and usage internally and externally.
Discovery
Discovery
To understand how the current account categorization experience was working and performing for our users' needs, I conducted a series of stakeholder interviews (internal perception) and client interviews (external perception). I also reviewed competitor analysis that had been previously completed by my product manager.
To understand how the current account categorization experience was working and performing for our users' needs, I conducted a series of stakeholder interviews (internal perception) and client interviews (external perception). I also reviewed competitor analysis that had been previously completed by my product manager.
Stakeholder interviews
Stakeholder interviews
I identified 11 key stakeholders across the business, from the product, solutions, development, and insights teams. They were sent a survey to gauge the internal perception of the product. I followed up with short interviews to allow stakeholders to elaborate on key points and increase understanding.
I identified 11 key stakeholders across the business, from the product, solutions, development, and insights teams. They were sent a survey to gauge the internal perception of the product. I followed up with short interviews to allow stakeholders to elaborate on key points and increase understanding.
Key findings
Key findings
• The current account categorisation UI is too static and does not allow users to categorise as accurately as required.
• Account categorisation sits within a product called Assess. In order to categorise accounts users must leave the Assess experience and categorise their accounts in the Accounting API settings pages.
• The current experience does not tell users which accounts and required to be categorised as for some instances full account categorisation is not required.
• The current account categorisation UI is too static and does not allow users to categorise as accurately as required.
• Account categorisation sits within a product called Assess. In order to categorise accounts users must leave the Assess experience and categorise their accounts in the Accounting API settings pages.
• The current experience does not tell users which accounts and required to be categorised as for some instances full account categorisation is not required.
Client interviews
Client interviews
I organised interviews with two of our clients (Ampla & Wayflyer) and was able to conduct 8 individual interviews with them. I wanted to understand how they currently bulk-categorise accounts, how efficient they are during the categorisation process, what information they are missing, and whether they know which accounts need to be categorised in order to view metrics.
I organised interviews with two of our clients (Ampla & Wayflyer) and was able to conduct 8 individual interviews with them. I wanted to understand how they currently bulk-categorise accounts, how efficient they are during the categorisation process, what information they are missing, and whether they know which accounts need to be categorised in order to view metrics.
Key findings
Key findings
• No way to see which accounts are required to be categorised.
• Better backend logic and UI to display accounts that Codat deems ‘categorised’.
• Users have to manually assign categories to each account, there is no way to bulk categorise accounts.
• Clearer category groupings, by their type (income, expense, asset etc)
• No way to see which accounts are required to be categorised.
• Better backend logic and UI to display accounts that Codat deems ‘categorised’.
• Users have to manually assign categories to each account, there is no way to bulk categorise accounts.
• Clearer category groupings, by their type (income, expense, asset etc)
Discovery findings
Discovery findings
Based on the completed discovery so far, it was clear that there were some quick wins and key features that could be implemented. These features would include highlighting which accounts need to be categorized, allowing users to confirm accounts that have been partially categorized by Codat, allowing users to change the 'Type' categorization level, and adding more information to help users understand each account better.
However, the more pressing concern was that users needed to be able to categorise large numbers of accounts as quickly as possible, which the current user interface did not support.
Based on the completed discovery so far, it was clear that there were some quick wins and key features that could be implemented. These features would include highlighting which accounts need to be categorized, allowing users to confirm accounts that have been partially categorized by Codat, allowing users to change the 'Type' categorization level, and adding more information to help users understand each account better.
However, the more pressing concern was that users needed to be able to categorise large numbers of accounts as quickly as possible, which the current user interface did not support.
Ideation
Ideation
Based on the completed discovery so far, it was clear that there were some quick wins and key features that could be implemented. These features would include highlighting which accounts need to be categorized, allowing users to confirm accounts that have been partially categorized by Codat, allowing users to change the 'Type' categorization level, and adding more information to help users understand each account better.
However, the more pressing concern was that users needed to be able to categorise large numbers of accounts as quickly as possible, which the current user interface did not support.
Based on the completed discovery so far, it was clear that there were some quick wins and key features that could be implemented. These features would include highlighting which accounts need to be categorized, allowing users to confirm accounts that have been partially categorized by Codat, allowing users to change the 'Type' categorization level, and adding more information to help users understand each account better.
However, the more pressing concern was that users needed to be able to categorise large numbers of accounts as quickly as possible, which the current user interface did not support.
Stakeholder workshop
Stakeholder workshop
The stakeholder workshop included members of my team as well as the wider product, solutions, and insight teams.
The outcomes, as expected, were more product-specific and looked forward at the bigger picture of what account categorisation could be, with suggestions to:
• Overhaul the UI, which was clear from the beginning
• Embed account categorisation within the Assess product (which it interacts with). For new users account categorisation is hidden and hard to find
• Allow for a deeper level of categorisation to help train the enhanced categorisation models
• Fast and more efficient categorisation of multiple accounts at once
The stakeholder workshop included members of my team as well as the wider product, solutions, and insight teams.
The outcomes, as expected, were more product-specific and looked forward at the bigger picture of what account categorisation could be, with suggestions to:
• Overhaul the UI, which was clear from the beginning
• Embed account categorisation within the Assess product (which it interacts with). For new users account categorisation is hidden and hard to find
• Allow for a deeper level of categorisation to help train the enhanced categorisation models
• Fast and more efficient categorisation of multiple accounts at once
Client workshop
Client workshop
The client workshops included subject matter experts such as underwriters and data scientists from the Ampla and Wayflyer teams.
The outcomes were more specific to their needs. They wanted to see:
• Confidence metrics for the accounts pre-categorised by Codat
• Account descriptions to give more context about each account
• A way to approve Codat’s categorisation if it was correct
• Different sections within the UI to show accounts that had been categorised and ones that still needed to be categorised
• View each accounts categorisation path
Workshop outcomes
Workshop outcomes
After the workshops, I took the core themes and created a fishbone diagram to help present the issues I had uncovered and the causes of those issues.
After the workshops, I took the core themes and created a fishbone diagram to help present the issues I had uncovered and the causes of those issues.
I took the ideas and notes generated in the workshop along with the fishbone diagram to the development team and used a priority vs feasibility matrix to understand what would be easy and difficult to implement.
I took the ideas and notes generated in the workshop along with the fishbone diagram to the development team and used a priority vs feasibility matrix to understand what would be easy and difficult to implement.
We prioritised the core features that we would base the account categorisation MVP on. We specified each of these features along with release 2 features that would not be focused on for the MVP.
We prioritised the core features that we would base the account categorisation MVP on. We specified each of these features along with release 2 features that would not be focused on for the MVP.
Release 1 (MVP)
Release 1 (MVP)
1. A user can view suggest categories and recategorise any account.
- Users can view a list of accounts which are present with a non-zero balance in the syncedfinancial statements(basically filter out non-used)
- Accounts are grouped by top level and ordered by:
- Income
- Expense
- Asset
- Liability
- Equity
- Users can view the following account details:
- Account name
- Suggested category
- Users can select one or many accounts to recategorise
- Users can incrementally save categories
- Users can recategorise selected accounts to any category within the same level 1 if available i.e.doesn’t allow Assets
2. A user can view the confidence rating on a suggestion.
- This is visible to users when reviewing categories
3. A user can view the materiality of the account (balance)
- Users can view the latest months closing balance +the % of that asset group absolute total. If negative, then show it as a % of the absolute total
- Accounts list is ordered by the highest value account to lowest in each group
4. A user can view the description of each account
- Users can view the account description if available
5. A user can view the original source category
- FullyQualifiedCategory
6. A user can confirm accounts
- Users can see confirmed accounts separate from accounts still requiring confirmation
- Users can recategorise from this tab
7. Recategorisation success/ error
- On recategorisation, it should be obvious to the user if there categorisation was successful or errored
1. A user can view suggest categories and recategorise any account.
- Users can view a list of accounts which are present with a non-zero balance in the syncedfinancial statements(basically filter out non-used)
- Accounts are grouped by top level and ordered by:
- Income
- Expense
- Asset
- Liability
- Equity
- Users can view the following account details:
- Account name
- Suggested category
- Users can select one or many accounts to recategorise
- Users can incrementally save categories
- Users can recategorise selected accounts to any category within the same level 1 if available i.e.doesn’t allow Assets
2. A user can view the confidence rating on a suggestion.
- This is visible to users when reviewing categories
3. A user can view the materiality of the account (balance)
- Users can view the latest months closing balance +the % of that asset group absolute total. If negative, then show it as a % of the absolute total
- Accounts list is ordered by the highest value account to lowest in each group
4. A user can view the description of each account
- Users can view the account description if available
5. A user can view the original source category
- FullyQualifiedCategory
6. A user can confirm accounts
- Users can see confirmed accounts separate from accounts still requiring confirmation
- Users can recategorise from this tab
7. Recategorisation success/ error
- On recategorisation, it should be obvious to the user if there categorisation was successful or errored
Release 2
Release 2
1. Users should be able search through the transaction list using search term to filter for relevant accounts only.
- Filter on account name, description and fullyQualifiedName
2. Users can bulk select accounts to be categorised to the same category / for approval.
- Users should be able to bulk select all accounts in the group
- If a filter is applied, it should obey that filter
3. Users can see how many accounts are still required to be reviewed so they can prioritise their efforts.
4. Users should be able to reorder the table headers to see the most relevant accounts.
- Users should be able to reorder based on any of the account information headings
5. Users can filter based on most recent accounts to see relevant accounts only.
- Users can view the last created date and the last active date in the table
- Users can filter by last active
1. Users should be able search through the transaction list using search term to filter for relevant accounts only.
- Filter on account name, description and fullyQualifiedName
2. Users can bulk select accounts to be categorised to the same category / for approval.
- Users should be able to bulk select all accounts in the group
- If a filter is applied, it should obey that filter
3. Users can see how many accounts are still required to be reviewed so they can prioritise their efforts.
4. Users should be able to reorder the table headers to see the most relevant accounts.
- Users should be able to reorder based on any of the account information headings
5. Users can filter based on most recent accounts to see relevant accounts only.
- Users can view the last created date and the last active date in the table
- Users can filter by last active
Sketching
Sketching
Once the key features had been defined, I began sketching out some paper prototypes. I went to my product manager to validate these. Once we were happy with the basic structure, I started creating some mid-fidelity designs that I would use for testing. The main priority was to remove the modal and surface the account categorisation UI on its own embedded page within the Assess product. The restrictive nature of the modal was the root cause of the usability problem.
Once the key features had been defined, I began sketching out some paper prototypes. I went to my product manager to validate these. Once we were happy with the basic structure, I started creating some mid-fidelity designs that I would use for testing. The main priority was to remove the modal and surface the account categorisation UI on its own embedded page within the Assess product. The restrictive nature of the modal was the root cause of the usability problem.
Testing
Testing
Since we had a reasonable timeline, I decided to test with mid-fidelity prototypes, which would allow the tests to feel closer to the finished UI and allow me to test end-to-end flows, which would be difficult and limited with a paper or sketched prototype. It would also make it easy for me to quickly make changes based on feedback.
Since we had a reasonable timeline, I decided to test with mid-fidelity prototypes, which would allow the tests to feel closer to the finished UI and allow me to test end-to-end flows, which would be difficult and limited with a paper or sketched prototype. It would also make it easy for me to quickly make changes based on feedback.
Testing schedule
Testing schedule
I was able to test with 8 users, 5 internal and 3 external. The sessions were a combination of user interviews and semi-guided exploration of the prototypes I created for the 7 key features mentioned above.
User interviews: This was another opportunity to confirm our initial findings and understand how internal and external users use account categorisation, and whether our proposed features would be beneficial to them.
Prototypes: Before the sessions, I mocked up some prototypes in Figma and displayed them one at a time to participants as I asked questions and talked about their perception of the screens.
I was able to test with 8 users, 5 internal and 3 external. The sessions were a combination of user interviews and semi-guided exploration of the prototypes I created for the 7 key features mentioned above.
User interviews: This was another opportunity to confirm our initial findings and understand how internal and external users use account categorisation, and whether our proposed features would be beneficial to them.
Prototypes: Before the sessions, I mocked up some prototypes in Figma and displayed them one at a time to participants as I asked questions and talked about their perception of the screens.
Findings
Findings
The testing sessions were very successful in validating our ideas and the key features we wanted to implement in the new account categorisation UI.
A user can view suggest categories and recategorise any account, A user can view the original source category: This feature was received very well, as users were excited to be able to see categories suggested by Codat, as it would save them a lot of time if they were happy with the categorisation provided.
A user can view the confidence rating on a suggestion: Viewing a confidence level was seen as a big positive, as it would let users know which accounts required immediate action. They were also happy that Codat could surface how confident we were about our initial categorisation. However, users did mention that some additional UI styling would make the confidence level clearer and more prominent.
A user can view the materiality of the account (balance), A user can view the description of each account: Our clients, in particular, were very excited about this feature, as it would provide them with more information about the account. Clients mentioned that they would also want to see the percentage of the account balance along with the numerical amount.
A user can confirm accounts - Participants thought this feature would save them a lot of time, as they did not necessarily have to recategorize every account if they were happy with Codat's categorization. However, users did mention that they would also want to be able to bulk-confirm accounts and receive feedback from the UI that the account had been successfully confirmed without it just disappearing into the confirmed tab.
Users were very pleased that the original modal which housed the experience was gone, they were also pleased that the page was embedded within Assess as opposed to the Accounting API settings as this would make it much more accessible for new users.
The new proposed multi-select component was also received well, although users wanted to be able to categorise further than the current three levels available.
The testing sessions were very successful in validating our ideas and the key features we wanted to implement in the new account categorisation UI.
A user can view suggest categories and recategorise any account, A user can view the original source category: This feature was received very well, as users were excited to be able to see categories suggested by Codat, as it would save them a lot of time if they were happy with the categorisation provided.
A user can view the confidence rating on a suggestion: Viewing a confidence level was seen as a big positive, as it would let users know which accounts required immediate action. They were also happy that Codat could surface how confident we were about our initial categorisation. However, users did mention that some additional UI styling would make the confidence level clearer and more prominent.
A user can view the materiality of the account (balance), A user can view the description of each account: Our clients, in particular, were very excited about this feature, as it would provide them with more information about the account. Clients mentioned that they would also want to see the percentage of the account balance along with the numerical amount.
A user can confirm accounts - Participants thought this feature would save them a lot of time, as they did not necessarily have to recategorize every account if they were happy with Codat's categorization. However, users did mention that they would also want to be able to bulk-confirm accounts and receive feedback from the UI that the account had been successfully confirmed without it just disappearing into the confirmed tab.
Users were very pleased that the original modal which housed the experience was gone, they were also pleased that the page was embedded within Assess as opposed to the Accounting API settings as this would make it much more accessible for new users.
The new proposed multi-select component was also received well, although users wanted to be able to categorise further than the current three levels available.
High-fidelity designs
High-fidelity designs
After the success of the initial mid-fidelity designs and testing, I was confident to move into the high-fidelity designs. I wanted to design the full experience, incorporating release 1 (MVP) and release 2 features. These would then be broken down and handed off to the engineers. Throughout the design process, I had incrementally completed technical validation, but at this point, it was vital to technically validate the designs with the whole engineering team.
After the success of the initial mid-fidelity designs and testing, I was confident to move into the high-fidelity designs. I wanted to design the full experience, incorporating release 1 (MVP) and release 2 features. These would then be broken down and handed off to the engineers. Throughout the design process, I had incrementally completed technical validation, but at this point, it was vital to technically validate the designs with the whole engineering team.
Testing
Testing
After making changes and incorporating feedback from the mid-fidelity prototype testing, I wanted to conduct a further round of testing with the high-fidelity designs, focusing on the usability and interactions of the product, as opposed to the feature requirements. I wanted to ensure the experience was exactly what the stakeholders and clients expected and needed before handing off the designs to the engineers.
After making changes and incorporating feedback from the mid-fidelity prototype testing, I wanted to conduct a further round of testing with the high-fidelity designs, focusing on the usability and interactions of the product, as opposed to the feature requirements. I wanted to ensure the experience was exactly what the stakeholders and clients expected and needed before handing off the designs to the engineers.
Testing schedule
Testing schedule
I was able to test with 10 users, 6 internal and 4 external, with a focus on external testers for this round. The sessions were a combination of user interviews and semi-guided exploration of the high-fidelity prototypes. The prototypes incorporated release 1 and release 2 features.
User interviews: This was an opportunity to confirm the updates we had made and ensure the information was displayed in the correct format and as the users expected.
Prototypes: Using the high-fidelity designs, I mocked up some interactive prototypes that focused on the flow and interactions within the experience.
I was able to test with 10 users, 6 internal and 4 external, with a focus on external testers for this round. The sessions were a combination of user interviews and semi-guided exploration of the high-fidelity prototypes. The prototypes incorporated release 1 and release 2 features.
User interviews: This was an opportunity to confirm the updates we had made and ensure the information was displayed in the correct format and as the users expected.
Prototypes: Using the high-fidelity designs, I mocked up some interactive prototypes that focused on the flow and interactions within the experience.
Findings
Findings
Findings
Similarly to the previous round of testing, this testing was very successful. All of the updates were received well, and users were able to move through the prototype with no issues.
Internal and external feedback was overall very positive. Key tasks and heat maps to show user journey success are shown below.
Similarly to the previous round of testing, this testing was very successful. All of the updates were received well, and users were able to move through the prototype with no issues.
Internal and external feedback was overall very positive. Key tasks and heat maps to show user journey success are shown below.
Navigate to account categorisation from the companies page
Navigate to account categorisation from the companies page
Navigate to account categorisation from the companies page
All users found the ‘Categorize accounts’ button and completed the task successfully.
Misclick rate - 0%
Average task duration - 2.4s
Average task duration - 2.4s
All users found the ‘Categorize accounts’ button and completed the task successfully.
Misclick rate - 0%
Average task duration - 2.4s
Average task duration - 2.4s
Search for and select all ‘operating’ accounts
Search for and select all ‘operating’ accounts
Search for and select all ‘operating’ accounts
All users were able to find the search box and successfully search for 'Operating' accounts, and select all once the search had completed.
Misclick rate - 22%
Average task duration - 5.7s
Average task duration - 5.7s
All users were able to find the search box and successfully search for 'Operating' accounts, and select all once the search had completed.
Misclick rate - 22%
Average task duration - 5.7s
Average task duration - 5.7s
Select all the asset accounts and recategorise them.
Users were asked to categorise the accounts to - Asset > Non-current assets > Land and buildings
Select all the asset accounts and recategorise them.
Users were asked to categorise the accounts to - Asset > Non-current assets > Land and buildings
Select all the asset accounts and recategorise them.
Users were asked to categorise the accounts to - Asset > Non-current assets > Land and buildings
All users found it easy to select and categorise all of the Asset accounts.
Misclick rate - 36%
Average task duration - 8.9s
Average task duration - 8.9s
This was a significant improvement over the previous user interface. A test conducted by my product manager concluded that for someone who knew exactly what the accounts were, it would take 15-20 seconds to categorize an account. In this test, users were able to categorise 50 accounts in under 10 seconds, as opposed to what would have taken a user previously 12.5 minutes to complete the same task.
All users found it easy to select and categorise all of the Asset accounts.
Misclick rate - 36%
Average task duration - 8.9s
Average task duration - 8.9s
This was a significant improvement over the previous user interface. A test conducted by my product manager concluded that for someone who knew exactly what the accounts were, it would take 15-20 seconds to categorize an account. In this test, users were able to categorise 50 accounts in under 10 seconds, as opposed to what would have taken a user previously 12.5 minutes to complete the same task.
Sort the accounts by their confidence level
Sort the accounts by their confidence level
Sort the accounts by their confidence level
This was a simple test, but it was important to ensure sorting within the headers was intuitive. All users were able to sort the accounts by their confidence level.
Misclick rate - 0%
Average task duration - 2s
Average task duration - 2s
This was a simple test, but it was important to ensure sorting within the headers was intuitive. All users were able to sort the accounts by their confidence level.
Misclick rate - 0%
Average task duration - 2s
Average task duration - 2s
I was very please with the results from the test. It was clear that the product was extremely usable and the functionality was as expected. Some of the tasks had a higher misclick rate than I would have liked, although after reviewing the heat maps the misclicks may have been unintentional as they were all very close to the desired location.
In the last section of the test I asked users ‘Is there anything else you would like to have seen included in the UI’. I received comments around adding further filters, created date and last active date.
I was very please with the results from the test. It was clear that the product was extremely usable and the functionality was as expected. Some of the tasks had a higher misclick rate than I would have liked, although after reviewing the heat maps the misclicks may have been unintentional as they were all very close to the desired location.
In the last section of the test I asked users ‘Is there anything else you would like to have seen included in the UI’. I received comments around adding further filters, created date and last active date.
Final designs
Final designs
Final designs
Improve discoverability of account categorisation
Improve discoverability of account categorisation
Improve discoverability of account categorisation
One of the key issues with the current account categorization experience was that the user needed to navigate through five different pages before they could categorize their accounts.
Embedding account categorisation within Assess solved this issue, but I wanted to go a step further. Adding a 'Categorize accounts' button within the companies header allowed for maximum discoverability, as users would be able to see this as soon as they selected the company they wanted to make a decision on.
The button styling would also change depending on whether urgent action was needed to be taken.
One of the key issues with the current account categorization experience was that the user needed to navigate through five different pages before they could categorize their accounts.
Embedding account categorisation within Assess solved this issue, but I wanted to go a step further. Adding a 'Categorize accounts' button within the companies header allowed for maximum discoverability, as users would be able to see this as soon as they selected the company they wanted to make a decision on.
The button styling would also change depending on whether urgent action was needed to be taken.
Accounts to review
Accounts to review
Accounts to review
Within the 'Accounts to review' tab, users are able to view all accounts that have been partially categorised by Codat, grouped by their top-level category (Income, Expense, etc.). Users can also see an 'Unknown' section, which groups the most ambiguous accounts that Codat was unable to categorise. These accounts require immediate attention.
Within each account, the user can see clear information to provide a better understanding of the account, along with a confidence score provided by Codat.
Users are able to select one or multiple accounts to recategorise or approve their current categorisation. These actions can be taken across the groupings.
Filters and search are available to help users see only the accounts that are most important to them.
Additional filters, created on date, and last active date have been added based on user testing feedback.
Previously, buttons at the end of each row were used to select the account the user wanted to categorise. However, I updated this to use checkboxes, as this is a much more common design pattern.
Within the 'Accounts to review' tab, users are able to view all accounts that have been partially categorised by Codat, grouped by their top-level category (Income, Expense, etc.). Users can also see an 'Unknown' section, which groups the most ambiguous accounts that Codat was unable to categorise. These accounts require immediate attention.
Within each account, the user can see clear information to provide a better understanding of the account, along with a confidence score provided by Codat.
Users are able to select one or multiple accounts to recategorise or approve their current categorisation. These actions can be taken across the groupings.
Filters and search are available to help users see only the accounts that are most important to them.
Additional filters, created on date, and last active date have been added based on user testing feedback.
Previously, buttons at the end of each row were used to select the account the user wanted to categorise. However, I updated this to use checkboxes, as this is a much more common design pattern.
Confirmed accounts
Confirmed accounts
Confirmed accounts
In the ‘Confirmed accounts’ tab users can see all accounts that have previously been confirmed, this allows for clear differentiation between what actions/ work the user needs to take.
Confirmed accounts can be recategorised if needed.
In the ‘Confirmed accounts’ tab users can see all accounts that have previously been confirmed, this allows for clear differentiation between what actions/ work the user needs to take.
Confirmed accounts can be recategorised if needed.
Multi-select component
Multi-select component
Multi-select component
The multi-select component is integral to the experience. It appears once an account is selected at 2.5rem above the bottom of the user's screen.
The component is contextual depending on its use case. For example, on the 'Accounts to review' tab, users are able to approve and recategorise accounts. On the 'Confirmed accounts' tab, users are only able to recategorize accounts if needed.
Since the multi-select component is so essential to the account categorisation experience, it was important to have clear and concise documentation and to build it as a reusable component. A component this powerful could be used across Codat's products for multiple different use cases.
The multi-select component is integral to the experience. It appears once an account is selected at 2.5rem above the bottom of the user's screen.
The component is contextual depending on its use case. For example, on the 'Accounts to review' tab, users are able to approve and recategorise accounts. On the 'Confirmed accounts' tab, users are only able to recategorize accounts if needed.
Since the multi-select component is so essential to the account categorisation experience, it was important to have clear and concise documentation and to build it as a reusable component. A component this powerful could be used across Codat's products for multiple different use cases.
Engineering handoff
Engineering handoff
After making the necessary updates, I was ready to annotate the designs and prepare them for handoff to the engineers. Given the complexity of the product, it was essential to provide thorough annotations and specifications to ensure a successful implementation.
After making the necessary updates, I was ready to annotate the designs and prepare them for handoff to the engineers. Given the complexity of the product, it was essential to provide thorough annotations and specifications to ensure a successful implementation.
