This project requires a heightened level of sensitivity as its contents have not been publicly disclosed yet.
Migrating products from a legacy system to the new strategic platform
An experience audit followed by a redesign
Jan 2022 - May 2023
Responsibilities: Desktop research, Feature audit, Concept maps, Site map, Task flows, Content and Usability audits, User interviews, Wireframing, Visual/ UI Design and User Testing.
Context
Industry
Banking sector, Treasury. Located in South Africa.
Users
Property Practitioners, Attorneys, Executors and Insolvency practitioners
Team
A squad of 10-15 (business, design & dev), but worked mostly with design lead or independently.
Product
Third party fund management: Property management, Liquidations, Deceased estates & Conveyancing
Project timeline
Below is a high-level project timeline showcasing the completion dates for core tasks, which were often in progress at the same time.
-
Jan - Feb '22
Joined team
Set up project framework and templates
-
March '22
Client informational interview (Property Management)
-
April '22
Client informational interviews (Conveyancing, Liquidator)
-
May '22
Client informational interview (Deceased estates)
Concept maps (all)
Task flow (Open a body corporate account)
-
Aug '22
Site map (all channels)
Feature audit (all channels)
-
Oct '22
Client informational interview (Property Management)
Task simplification
-
Nov '22
Client informational interviews (Property Management & Conveyancing)
-
Dec '22
Client informational interviews (Liquidations)
Task comparison
-
March '23
Client informational interview (Property Management)
Card sorting exercise
Wireframing (Open a body corporate account)
-
May '23
Detailed design/UI (Open a body corporate account)
I went on Maternity leave in May and when I returned the project was placed on hold
The brief
About Treasury
Treasury Services manages CIB’s liquidity/ cash flow which is generated primarily through interest earned on cheque accounts, deposits and other product & service offerings.
The project
The goal was to migrate select Treasury products from the legacy system and rebuild on the new strategic platform where clients will be able to access all their banking products and services.
In order to migrate those products over to the new platform, we conducted an experience audit* followed by a redesign.
* The experience audit consisted of desktop research, concept maps, site map, feature audit, task flows, user interviews, personas and a card sorting exercise.
Important terminology
New platform:
The new strategic platform that we are migrating to.Legacy system:
The legacy system where our current products are situated.Attorney Management System (AMS):
The channel our Conveyancers and Attorneys use to manage funds on behalf of their clients.Third Party Fund Management (TPFM):
The channel our Executors, Insolvency Practitioners and Property Practitioners use to manage funds on behalf of their clients.
Our products
Treasury has an entire portfolio of products and services. The select products that were part of the migration strategy were the ones that enable our clients to manage the funds on behalf of their clients - thus third party fund management solutions.
A key function in enabling our clients to manage funds on behalf of their client is the ability to open, manage and close third party fund accounts on our system.
On average, 69,7% of our clients open and / or close accounts on a monthly basis.
Migration strategy
All 4 of the products were set to be migrated over to the new system, but our focus was to migrate Property Management first. For majority of the design discovery phase we focussed on all products. Nearing the stage of visual design we only focussed on Property Management.
Why did we not design all products in parallel?
It will allow us to analyse one task / product and if we optimise it we can easily apply those optimisations or changes to the other tasks, flows and products with confidence that we are not breaking anything.
It will help us gauge the amount of work required to migrate to the new platform. For example, if 75% of our flows are the same as the first channel, it might decrease the amount of time and effort spent in designing for the new platform for all the rest of the channels as we could simply use the first channel as a template.
Who are our users?
Colleagues (staff)
Client relationship managers (CRM)
Client services centre representatives (CSC)
Investment risk advisors (IRA)
Clients
Attorneys, who:
Specialise in Conveyancing
Manage third party funds (via Conveyancing) on behalf of their clients
Executors of an estate (which could be an Attorney, Absa Trust or a Relationship Banker)
Insolvency practitioners, who specialise in Liquidations / Sequestrations (who might also be Attorneys)
Property Practitioners (also referred to as Property Managers)
Corporate clients outside of TPFM but who use the legacy system to do their banking
Design discovery
The following sections will unpack some of the work completed for the experience audit which includes desktop research, concept maps, site map, feature audit, task flows, user interviews, personas and a card sorting exercise.
Objective 1: Understand who our clients are and what they do
Purpose
Before we can understand what we are building, we must first understand who we are doing it for. The goal is to understand:
What a Property Manager, Conveyancer, Liquidator, Executor & corporate client is
What do they do?
What is their business offering?
Who are their clients?
What value / services do they provide for their clients?
How our system helps them / why do they need it?
Artefacts
Desktop research
Concept maps
Desktop research
Desktop research was conducted for Property Managers, Attorneys (traditional as well as Conveyancers), Executors and Liquidators to understand:
What their role is
What they do (Duties, responsibilities, tasks etc)
What their business offering is
Who their clients are
What value / services they provide for their clients
How our system helps them / why do they need it
Concept maps
Concept Maps were created for all primary client types (Property Managers, Conveyancing / Legal Practitioners, Executors and Liquidators) across our 4 products.
The concept maps are informed by the desktop research as well as interviews with staff members.
Creating the concept maps allowed us to understand and visualise the relationship between our clients (Property Managers), their clients (Landlords etc) and our system.
Preview:
Templates:
We also created templates for the desktop research and Concept maps which allowed us to streamline our work and easily adapt across other products.
Overview of the products and users
Conveyancing
Background:
Roughly 90% of Attorneys who use AMS are Conveyancers. They're responsible for transferring ownership (and other rights) of a property from one person (the seller) to another (the buyer).
The remainder of Attorneys (roughly 10%) use AMS to manage third party funds on behalf of their clients. For example: Trust funds, road accident funds, selling of businesses, etc
* A Conveyancer or Attorney might also use Deceased Estates and / or Liquidations.
Why are accounts opened?
Accounts are opened so that funds can be transferred between the seller & the buyer of that property/company.
A Conveyancer will open an account for each new property/company transfer (this could be either a new client or an existing client with a new sale). There is thus an account for each property sale.
Account name:
Section 86(4) account
Why are accounts closed?
Once the sale is complete and the property is transferred, then the account is closed.
Deceased estates
Background:
An Executor is appointed to wind up the Estate of someone who has passed away. They are nominated in the Will but appointed by the Master of the Court.
Executors who use our system are:
Attorneys
The Deceased's Financial broker
Absa Trust
* If the Executor is an Attorney, they might also use Conveyancing and / or Liquidations.
Why are accounts opened?
Accounts are opened to receive funds from the deceased's personal bank accounts, assets that were sold or payouts from their policies, pension, shares, investments etc. Once funds are received they can then pay the deceased's creditors and distribute the remaining money and assets to their beneficiaries.
The Executor will open a new account every time there’s a new estate / person who has passed away & they're appointed to handle the case. There is thus an account for each deceased person's estate.
Account name:
Deceased Estate account (Also called an "Estate late account")
Why are accounts closed?
Once the estate is consolidated and all fees are paid to the beneficiaries then the account is closed.
Liquidations
Background:
A Liquidator/Sequestrator is appointed to liquidate a company that has gone bankrupt (they are appointed by the Master of the Court).
Liquidators who use our system are licensed Insolvency Practitioners (who may or may not be an Attorney).
* If the Liquidator is an Attorney they might also use Conveyancing and / or Deceased Estates.
Why are accounts opened?
Accounts are opened to receive funds from the sale of assets / debt collection of the bankrupt company. Once funds are received they can then pay the company’s creditors, and even salaries or water and lights etc.
The Liquidator will open a new account for each new liquidation case / client - every time a company goes bankrupt and they're appointed to handle the case. There is thus an account for each bankrupt/liquidated company.
Account name:
Insolvent account
Why are accounts closed?
Once all fees are paid and the matter resolved then this account is closed.
Property Management
Background:
A property manager is an individual or company that is hired to oversee the day-to-day operations of a unit of real estate. The property manager acts on behalf of the owner to preserve the value of the property while generating income.
* Property Managers don't use any of the other products (Conveyancing, Deceased Estates, Liquidations)
Why are accounts opened?
Accounts are opened to receive funds from tenants of the building (rent). Once funds are received they can then pay for items like repairs, maintenance, salaries etc.
The Property Manager will open an account for each client/property they manage. They might have a client who owns 5 properties managed by 5 different Body Corporates in which case they will open 5 Body Corporate accounts; one for each property.
Account names (there are 2 accounts):
Body Corporate account & Rental Deposits account
Why are accounts closed?
The account will only be closed if they no longer manage this client / if the client no longer manages that property.
Thus, this scenario is slightly different to the others as there is no “closing event”, meaning there is no company that has been liquidated or a property that has been sold or beneficiaries that have been paid. With Property Management the tenants of the building pay rent every month and there are daily/monthly/ad hoc costs to maintain the building etc - so there’s continuous movement of funds in the account. So for as long as the Property Manager manages this particular client/property, they’ll use the account.
Objective 2: Understand how our legacy system currently works
Purpose
In order to migrate our offering to another platform, we must first understand what it is that we offer currently. The goal is to:
Understand our offering and how it works
Identify common functionality across the product offerings
Identify opportunities to improve the experience of our offering when migrating to the new system
Artefacts
Site map of the legacy system
Feature audit
Task flows
Feature comparison between the legacy system and new platform
Content audit
Heuristic assessment / usability audit
Objective 3: Understand the new strategic platform
Purpose
In order to migrate our offering, we must understand the system that we are moving to. The goal is to:
Have an understanding of what the platform is and how it works
Identify similar user / task flows, so that we may repurpose what exists for our offering - potential quick wins.
Artefacts
Task flows
Feature/task comparison between the legacy system and new platform
Site map
We created a Site Map of the legacy system which shows the hierarchy and organization of the navigation and pages pertaining to the features used by our clients.
It was extensive and included a mapping for all pages across the system pertaining to our 4 products in all instances, such as features:
belonging only to our products (such as “Open a body corporate account”), or
owned by other teams/products that our clients make use of (such as “Pay a beneficiary”)
Creating the site map assisted us in completing the feature list (discussed further down). It also helped us understand our products and features better. A few example of these insights are discussed below.
Document preview:
Site map findings
During the process of creating the Site Map of the legacy system, we also documented our learnings. These have been categorised comparatively according to the following:
Similarities
Duplications
Discrepancies / differences
Observations
We also tagged the findings as follow:
Nav: Navigation, menus, breadcrumbs (Where can users find things)
Feature*: A product capability/functionality that delivers value to a client/customer (What can users do)
Task*: Actions performed by a client/customer (How do users do it)
* Some findings could be tagged as both a feature or a task (e.g. Statement download). It will be tagged a feature if changes affect the product offering and a task if changes affect the way users complete it.
In addition to documenting the finding, we also noted down questions, observations and provided recommendations; which we could later us when redesigning the screens.
For example:
Feature audit
Following the work from the Site Map, we conducted a feature audit which provides a detailed breakdown of all the features and tasks on the legacy system - pertaining to the AMS and TPFM products as well as some features used by the general corporate client.
For example when navigating to "Enquires > Statement Enquiry" you can perform the following tasks:
View bank statement details (on screen)
Print bank stamped statement (in PDF format)
Download bank statement
The non-bank stamped statement is available in CSV and Fixed-length Txt format
The bank stamped statement is available in PDF format
Document structure:
The features are documented using the structure of the current navigation. In addition, client usage is also indicated:
Document preview:
Task simplification & comparison
The feature audit allowed us to document all the tasks within each of our products and features. The next step was to simplify these tasks, so that we may utilise that in the comparison to the new platform.
What is task simplification?
Task simplification is the most basic form of a task. For example:
"Download an iT3B tax certificate for a Property Management account" simplified is "Download a document"
The above example for “Download a document” is the simplified version of the task as it’s not specifically unpacking the type of document being downloaded, the format, method, or even which feature it belongs to.
This simplification was important so that we can identify common tasks and patterns across all our current products, as well as those on the new platform. Once we highlight that this task exists in the new strategic platform, it will then allow us to understand and use their existing pattern for downloading a document which we can then retrofit to our specific use cases which will be to download a tax certificate, statement or account confirmation letter.
The following categories have been used:
Account functions (such a view account balance or open an account)
Document functions (such as upload or email a document)
Generic functions (such as delete, copy or edit something)
Unique people* functions (such as view people details)
Unique payment functions (such as make or cancel payment)
* People refers to Users, Beneficiaries, Conveyancers, Executors, Trustees or Liquidators.
Document structure
Document preview
Task flows
Now that we had a full view of all the product features and tasks that would be migrated, we had to identify* which flow / task we were building first. We identified our first flow as “Open a body corporate account” for Property Management, and started working on the task flow, which is shown below.
Task details:
Task: Open an account
User: Property Manager / system manager with access rights
Scenario: User opens up a Body corporate account for their client
Information depicted on flow:
Straight-through flow
Alternative flows
Detailed additional information (per page)
* Task identification
Some considerations we used for identifying which flows / tasks to build first:
What has been developed and usability tested on the new platform
Frequency of use
Sequence of use
Effort to build (cross functional team)
Number of clients using feature/task
Revenue generation for the bank
Objective 4: Understand our client needs and pain points
Purpose
To ensure that we are building the right solution for our clients, we will conduct interviews with clients (and colleagues) to get an understanding of:
Their frustrations with our product offering that we should improve on
Whether our offering is meeting their needs
What we are doing well (and should consider while migrating)
Artefacts
Interview scripts
Meeting notes and recording of interviews
Insights map
User Journey map
Personas
Objective 5: Understand how clients are using the system
Purpose
To ensure that we are building the right solution for our clients, we will observe how they use our system currently, which will allow us to understand:
Which features they use most and how often
Importance of certain features and functionality to their business process
Whether there are ways in which they use the system different to how it was intended
Artefacts
Interview scripts
Meeting notes and recording of interviews
Insights map
Card sorting exercise
Task flow diagrams
Feature grid
Client interviews
Our goal was to conduct 2 types of interviews:
Selecting participants
Unlike the usability interviews, which would require designs and prototypes, the informational interview was something we could start right away.
In consultation with other members of our team, who often engaged with our clients from a sales perspective, we identified:
the number of clients we would need to interview for each product and
the clients/companies we’d like to interview
Some considerations to selecting participants was client availability, size of their business, which products they used, how often they used the system and their willingness to engage with us previously.
Interview script
We created an interview script template which was adapted slightly for each product and their unique nuances.
It was also evolving during the interview process, as we would enhance it based on learnings from the last interview, and then use for the following interviews.
Conducting the interview
Method: All interviews were done remotely via Microsoft Teams
Attendees: 2 designers were present in addition to the client;
1 interviewer (myself)
1 notetaker (my design lead)
Using cameras:
Both our cameras were on for the introduction
I kept mine on for the duration of the interview
Most clients had their cameras on as well
During the interview, notes were captured on an excel template (so it contained all their answers in rough format)
After the interview we scheduled a debrief to unpack some of their feedback and document our learnings
Client availability
We aimed to interview 2 clients per product and 4 for Conveyancing (2 Conveyancers and 2 general Attorneys), thus a total of 10 participants.
We were able to interview 3 clients for Property Management, 2 for Conveyancing and 1 for Liquidations, so a total of 6 clients. The one interview was in a workshop format so had multiple clients, while the other 5 interviews were standard 1 on 1 interviews.
The interviews took place over the span of a few months.
Response rates were low and client availability was limited. Throughout the duration of this interview process (and even future engagements), we often struggled getting hold of clients. Some contributing factors were time of month / year (busy season) and the demanding nature of their role.
Inviting participants
The design team did not at this stage have a direct relationship with the clients we’d be interviewing, so we first asked the sales team to introduce us prior to sending the interview invitation (shown below).
The email invitation was created in collaboration with our UX writer.
Personas
We started putting together personas for Property Management using the data from the desktop research as well as insight from the client interviews.
In addition to creating a standard user persona, we also created a company profile.
Both templates are shown below.
Company profile
This is the template for the company / business, for example a Property Management company.
The tags in the header should inform you of the following:
Is this a company or individual persona
Is this a complex or simple persona
Has it been validated by research
The “key personas” are important people at the company that we create personas for.
Template vs populated
The personas were initially created for our Treasury project, however the goal was to use the template / framework within the larger design team at CIB as well.
After completing the skeleton for both persona templates, we started piloting it within the rest of the design team so that we could test it against real-world data and adapting it where need be.
We had managed to populate most of our Treasury templates using data from the desktop research and colleague interviews, but would still require further interviews with the client - especially for the company profile.
Individual persona
This is the template for individuals who work at the company, for example the Property Practitioner or Receptionist.
An overview of this individual should be depicted on the company persona under “Key personas”.
Card sorting exercise
Objective
We conducted a card sorting exercise to help guide us in defining the information architecture for building our Attorney Management & Third Party Fund Management products on the new platform. In the first iteration of the card sort, we allowed participants to create their own categories - thus an open card sort.
What is a card sorting exercise?
Card sorting will help you understand your users' expectations and understanding of your topics. In a card sorting session, participants organise topics into categories that make sense to them and they may also help you label these groups. For example:
Tasks (i.e Cards)
We asked our clients to sort 20 tasks (i.e the Maze cards) into categories. These 20 cards ranged from a variety of tasks across the AMS and TPFM platforms.
Collaborators
We've collaborated with numerous colleagues during the process of setting up and conducting the open card sort. Below is a list of these colleagues and the purpose of the collaboration:
Client relationship team
Investment risk advisors & Sales team members: Our liaisons for getting client information such as their contact details or understanding their availability. They've also guided us on identifying clients for engagements.
Pilot group
Analyst, Sales, Investment risk advisor, Product manager, Portfolio manager: We conducted a pilot exercise to understand the effectiveness of both the email and card sort on Maze.
Inviting clients to participate
An email was sent to all the clients we asked to participate in a card sorting exercise.
Keeping in mind that we already interviewed these clients, so it was not necessary to introduce ourselves, but rather position the exercise and value it would bring, especially since they were not familiar with card sorting.
A unique was sent to all participants as follow:
https://mazelink.co?name=S
Assumptions
The information architecture and navigation of the legacy system is very different from what we can see of the new platform.
We would like to understand how our clients view and structure the information, and more specifically which tasks will be grouped together. We also want to see what the categories can be labelled - hence starting with an open card sort which will allow participants to think freely and unstructured.
Below are some possible outcomes we expected:
Expected outcome 1
Primarily seeing "Accounts", "Payments" and "Document" type categories form.
Do clients view it based on task? For example "Download account confirmation letter" under a Document section.
For example:
Expected outcome 3
Is it a combination of 1 & 2 (entry points from multiple categories)?
For example "Download account confirmation letter" sitting in both the Account and Document categories?
For example:
Go live
The email was sent to each participant (a total of 9 clients) with the intention for them to complete it unassisted and reach out to us should they have questions or require assistance.
It was intended to be unmoderated but due to poor response rate we set up calls with a few participants.
See Learning section below for more details on the poor response rate
Learnings
From the Pilot card sort:
Participants were not familiar with card sorting exercises, thus:
There was some confusion on the creation of own categories. We amended the content on the Welcome and Instruction pages to make this more clear
We added some visuals to the instructions to assist in comprehending the task better
Some participants completed the card sort accidentally and weren’t able to go back to complete it. We updated the completion restrictions so that all cards needed to be sorted before continuing.
Some participants were unable to sort all the cards into categories as they were not familiar with the tasks within their specified role. Similar to our system users who don’t all perform the same tasks. We wanted to lift the completion restriction but were unable due to the feedback in point 2 above.
Platform
We used Maze to conduct our card sorting exercise.
Maze is a digital platform that allows product teams to remotely engage with testers (our clients) through prototypes, card sorting exercises, surveys and other tools to gather their feedback.
Here's a preview for building an open card sort:
Clients (i.e Testers)
To ensure the highest chance of participation, we selected all the clients that we've managed to have interviews with thus far, which was 9.
Product design team
Design director: Guiding us on the usage of Maze as a viable platform for the product design team
Copywriter: Assisted us with the content for the email
Expected outcome 2
Seeing "Accounts" and "Payments" categories form.
Do clients view it based on relation? For example "Download account confirmation letter" in the Account section because the letter belongs to a specific account?
For example:
Expected outcome 4
Is it something else entirely?
This is something we are keeping an eye on during the user interviews and card sorting exercises.
From the client card sort:
We’ve struggled with client availability throughout the entire project, but this particular activity was sent out during financial year end and month end - so it was poorly timed on our part and led to low response rates.
It was intended to be unmoderated and ended up being moderated because of poor response rate. We ended up scheduling 15min meetings directly with clients to assist them with the card sort. Which worked in our favour as it:
Provided clients with an opportunity to ask questions (they were not familiar with card sorting)
Ensured completion since it’s time scheduled in their diary
Observations about the platform:
We were able to create unique links for each participant which assisted us in reading the metrics better and enquire further with participants if needed.
You cannot move backwards in a Maze, which we wanted to utilise in the event where participants accidentally completed the Maze - which occurred in both the pilot and client card sorts. We ended up with a completion restriction for all cards to be sorted before continuing. This was not our intended goal to force participants to sort all 20 cards.
The built-in instructions page is limited in terms of adding content and images. We ended up creating a new instructions page in addition to the default one with enhanced wording and visual instructions.
Some participants were unsure how to create new categories. The platform simply creates new categories when you hover a new card on the page, but this is not clear.
Wireframes & UI
Objective 6: Build and test new solutions
Purpose
To take all our learnings and findings from the design discovery phase and explore different ways we could solve the problem. The goal is to design and prototype new screens that we can test with users.
Artefacts
Wireframes
Client feedback
Detailed design / UI
Wireframing
We decided to focus on Property Management during the wireframing and UI phase, and identified* “Open a body corporate account” as our first flow to wireframe, as per the task prioritisation when building task flows.
Whilst working on the wireframes, specifically when designing for document upload, it became evident that we needed to get feedback from our clients to understand how they upload and store documents, as it would affect the designs. We thus had 2 variations of our flow.
Wireframe versions:
V1 Contextual:
Document upload is placed within context of the Account details and Trustees pages (this is also where it is placed in the legacy flow)
V2 Dedicated:
Document upload is a dedicated step within the flow where all required documents would be uploaded
Preview
Here’s an example of the wireframes for the Account details & Trustees landing pages
Version 1: Contextual document upload
Preview
Here’s an example of the wireframes for the Account details & Trustees landing pages
Version 2: Document upload is a dedicated step
Next steps
Below is an overview of the client feedback process to better understand their document upload and storage preferences.
Throughout the process of designing the wireframes, we showcased it to core members of our team to gather their feedback or get answers to questions. Many updates were made during this collaboration process and once finalised it was time to move to higher fidelity design in Figma. This is shown further down.
Software
The software we used for Wireframing is Miro:
Client feedback on document upload and storage
What is the objective
Understand how clients store client documents on their computer, and their experience uploading documents on our system.
The insights we receive from clients will:
Help us determine where documents should be uploaded in our "open account" flows. For example via a dedicated document upload step or contextual document upload on different pages
Whether clients are uploading single, bulk or consolidated documents, based on how and where they store the files on their computer
Definitions:
Method for getting feedback
Based on the experience during the card sorting exercise, we felt it best to offer clients multiple methods to interact with us, so that they can choose the most suitable one, which hopefully guarantees a higher rate of response. The methods we used:
Send an email where they can reply to the email with their answers, or
Ask for us to set up a 15min call where they can verbalise their answers
Getting client feedback
Below is a summary of the questions asked in the email.
Questions:
Current document upload experience
Please complete these two sentences:a. When uploading documents, it frustrates me that ...
b. It would be a lot easier to upload documents if ...
When uploading documents, would you prefer to (see image below):
a. Upload the required documents whilst capturing related information
b. Upload all required documents at the same time
c. I don’t mind / either way is fine
d. Other (please elaborate)
Findings
Response outcome
2 out of 5 participants responded
Responses per question
Question 1
When uploading documents, it frustrates me that the system doesn’t allow us to upload documents over 2MB in size
It would be a lot easier to upload documents if we could:
Upload documents over 2MB in size
Use special characters like "@" in the name
The client feedback was not conclusive of a certain approach, so we'll need to reply on best practice and user testing later on.
There would be a benefit in allowing participants to upload multiple documents at the same time (bulk upload - either via drag and drop or by selecting multiple docs when uploading)
Document size limitations to be improved
File naming (does not allow special characters, even though we rename and classify these documents on our system)
Clients (i.e participants)
We've selected clients based on the following criteria:
Clients that we've managed to have interviews with thus far so that we can ensure:
A higher chance of participation
Get insights from all products that will dictate the pattern creation for document upload for all flows.
Clients that use verticals where Account opening flows require document upload (which is all except Conveyancing)
Clients that Open accounts as part of their role
We have thus excluded:
Deceased Estates clients, as we have yet to interview anyone thus far (we have no contact or relationship yet)
Conveyancing clients, who don't upload documents when opening accounts
A few Property Management clients who do not perform the task of opening accounts.
3. Typically, how do you store client documents on your computer? (see image below)
a. Option A
b. Option B
c. Option C
d. I/we use a different structure (please elaborate)
Methods of response:
1 via email, 1 via MS Teams call
Question 2
2 votes - I don’t mind / either way is fine
1 vote - Upload all required documents at the same time
Question 3
1 vote - I/we have a folder per client with subfolders for each document category
1 vote - I/we have a folder per client and all the documents are in a single folder
What does the data tell us
Reasons for lack of direction:
We did not have a large enough pool
Participants are from the same company (lack of diversity)
There is conflicting information
How might we:
Allow all file sizes to be uploaded Could we compress them in our system
Allow files with special characters in their title to be uploaded Could we rename and classify them on our side - which we already do.
Allow for bulk and consolidated upload and then select document type
Detailed design / UI
After concluding the wireframing for the “Open a body corporate account” flow, and we started working on higher fidelity designs in Figma, using our design system.
We also expanded from only designing the primary flow for a new user (i.e the wireframes), to include all user types and flows, thus:
Flows:
Primary flow (straight-through)
Alternatie flows
Negative flows
Here’s a breakdown of all the flows for “Open a body corporate account” that we designed for:
Steps in the application
Because we did not get definitive results from our clients on document upload and storage during the wireframing stage, we decided to do the UI with both variations still in place, which we would test again later on. The steps of the flow are thus as follow:
Preview
A view of the account details screen showing the difference between:
Contextual document upload (Version 1)
Document upload is a dedicated step (Version 2)
Side note:
We were still defining the information architecture and our placement within the new system, so items like the navigation and banners were still placeholders during this design phase.
Preview
A view of document screen if it were a dedicated step in the application.
Guidelines & columns
Part of designing this first flow was establishing our guidelines and use of columns.
Our standard approach is to use 2-3 columns (depending on the content and sections of the form itself)
In the instance of the review & success page, we utilise the 4 column approach.
Users:
First time user
Return user
Other variants (such as Foreign passport holders)
Software
The software we used for UI design is Figma:
Before & after
A side-by-side look into some of the legacy screens versus the proposed new screens - which was still to be user tested.
Account details:
Review:
Next steps
This flow was signed off with business and in the process of being reviewed by our UX writer. Our next step was to start working on the wireframes and UI for the second flow for the Property Management product.
