.png)
Below is a screenshot with the major points that I wanted to change with the screen to update the design to align with moden application design trends. This was one of the largest impacts I had on the future of the project because it gave a strategic roadmap for the entire future of the platform that we were creating.
Below are some examples of one screen that implements the early notes on improving the layout of the platform for our brokers. The left panel shows some of the global functions for the platform such as search, settings, and the user profile. These functions are located here because they control the system itself and have no effect on the policy they are working on. Next, there is the page navigation where users can go to the different pages within the client's policy. Also, there is a modal where the user can get other information about the client's policy such as their insurance type (Home, Condo, Tenant, or Auto), the policy number, and the price that the user is paying. The main content area is scrollable which removes the need for repeated pages for one group of information and a three column layout was introduced to align the fields and field labels to make the page easier to scan and read. Finally, the right side of the screen has functions that apply to the policy, but may not need to be tied to the page the user is on. An example of these features is notes, which allows a user to enter some information that is not directly a question within the forum but may still need to be captured for regulatory reasons.
.jpg)
.jpg)
We found that in many instances, there were complex sets of information that needed to be captured but it was challenging to show that information in a concise and easily understandable way. Some examples of these situations would be claims, policy history, and coverages. While each of these data sets are very different in their individual requirements, they were similar in the sense that there could be a lot of information that could be grouped into instances. Using claims as an example; there are various different questions that may be required depending on the type of claim but a client may have multiple claims. This led me to decide that data tables would be an important component that needed careful thought on how to make a reusable but adaptable component that could be reused across the platform.
The read-only table was meant to be the easiest table for the users to interact with. These are tables that are automatically populated for the broker based on information that comes from an integration with another service. Since the brokers cannot change the information that comes back from the service, these tables are not interactable.
.png)
This table design was meant to be the most basic example of an interactable table. Using the heading of the table as the headings for the fields allows a cleaner design for each row as the user won't need to look at field labels repeatedly and allows the user to focus on entering the proper value into the field.
.png)
The design of these tables was particularly challenging, as each instance had to dynamically adapt to the section's requirements. We faced obstacles in both design and development, including displaying the tables effectively, managing errors, saving data, and handling various micro-interactions.
One of the challenges I tackled was designing the interaction for sales brokers when calling APIs to retrieve data on potential clients. Key APIs included AutoPlus and MVR for auto insurance and OPTA for home insurance quotes. The complexity arose from the platform's non-linear design, which allowed brokers flexibility in collecting information. This flexibility meant there was a high chance that there would be conflicts between the brokers' input and the data returned by these APIs, making it a particularly difficult task to address.
After consulting brokers about their process when creating a new quote, I added a License Number field to the new quote panel below the personal identifying information for their new clients, this is in line with their current process as these are all of the pieces of information that brokers collected when creating a new policy. This helps brokers collect it early which reduces conflicts with API data, and improves efficiency by providing key information upfront.
Another improvement that I introduced to show brokers information regarding the status of the reports was the column highlighted below. In this section, brokers could check on the status of a previous report that they have called, request a new report from either of the services they were using, and view the date of the last report they had received. All of these are vital pieces of information that will be required at different stages of the broker's client's policy lifecycle.
I introduced an override history panel to address conflicts between broker-entered data and API reports, which are the source of truth in Ontario. This feature highlights changes from the client’s initial declarations, helping brokers identify outdated records. If misalignments exist, brokers can discuss them with clients before updating government systems. The panel streamlines the process, ensuring brokers have clear visibility into overrides and can resolve discrepancies efficiently.
Working on this project at Questrade was a rewarding experience. While only a few highlights are shared here, these contributions significantly shaped the future of the staff-facing portal. I excelled in designing versatile components that addressed diverse use cases, empowering teams to adapt my designs confidently. By creating reusable building blocks, I streamlined workflows, enabling teams to work faster and build a cohesive system. This approach not only reduced workload but also enhanced user confidence by ensuring consistency and familiarity across the platform.
I'm happy to connect at any time through my email!
