Our team of two designers and fifteen developers was developing a customer relationship management (CRM) platform for investor relations (IR). Essentially, it should allow for investor relations officers to monitor all components of their IR program.
A CRM dedicated to investment management of publically traded companies isn’t something that really existed prior to the creation of Q4 Desktop. Most investor relations officers would use any other, nonspecific CRM like Salesforce for example. Selecting features that were directly related to stock trading would be key, as well as creating a design that was not visually overwhelming but still allowed for easy navigation. The main features of the product were to manage all your contacts, track targets via AI, develop a watchlist, get basic daily updates on your dashboard via AI, and most importantly to enable users to see how their company’s stock is performing relative to the market, industry, and their peers.
We took a very agile approach to our research and testing. We had a small group of potential users who were willing to give us their information to work with, and spend time speaking with our product managers via phone interviews to give feedback. UI wise, we found that users in the finance industry are used to seeing a lot of information at once. Cluttered tables and graphs are nothing new to them; they’re so familiar with it that they actually prefer having everything available at once. When it came to UX, they didn’t stray too much from the typical user, they wanted something that was easy and fast to get the information they needed and to move on with their day. Throughout the creation of Q4 Desktop we released the product in the usual agile fashion, and users would come back to us with feedback.
For all major sections of the application we created medium fidelity wireframes in UX Pin. We quickly found out that our stakeholders didn’t understand what they were looking at when they saw these wireframes, and from then on created high fidelity wireframes for all our features. The brand and skeleton of the product was created by my Creative Director, so those were parameters I had to work within when deciding how the product would work.
We didn’t feel the need to explore the information architecture separate from our wireframing process. The product is very flat in that sense; based on the skeleton, the user is always navigating from the main menu. There aren’t many layers that they have to travel through to take actions.
Creating complex data visualizations that offer information at a glance and are attractive proved a little difficult initially. We created four different types of data visualizations to start with so that we could reuse visualizations where needed and keep consistency throughout the product. I kept our pages not looking overly cluttered by creating very interactive charts, so that information could be added, removed, seen on hover, etc. And secondarily I also created a layout in which I could fit several elements; as long as they had clear hierarchy, it wouldn’t be terribly overwhelming. In our first pass of the product we added visualizations to our tables as well, like very small graphs or icons that would be easily identifiable for users.
The design system for Q4 Desktop wasn’t fleshed out when we began working on it, which led to some inconsistencies throughout the product. We had to take a look at all the features that currently existed and decide on a more defined system before we moved forward. One major example of this is ways that the user could filter in tables and in graphs; it was somewhat inconsistent and required the team to get together to make corrections.
Our users generally found the product easy to use, and enjoyed the visuals. They found it more attractive than other products they’re used to using so that gave them a bit of joy. However, expanding the product proved difficult since its design system wasn’t as scalable as I would have liked it to be. In some situations, I was very limited as to what I could do, I just had to fit things into existing elements and make it work. In other situations, there was no way to just add on top of the existing design, it required a huge change to the feature to make it work.
My second major learning from this product, is that when I came onto the project, accessibility was not a consideration at all. If we were to put this product through an accessibility check, I would assume only the typography would pass. I personally think this was a huge oversight for all of us, and something I would have changed in hindsight.