Software is seemingly more powerful than pen and paper - as long as it is designed with speed and usability in mind.
Portfolio Analysis is FactSet's sophisticated analytics platform that has been serving the financial community since early 2000. It was built with a C++ code base that has come to serve 12,000 unique users on average monthly. On a whole, Portfolio Analysis has kept pace with the growing complexity of the financial market since its' inception but speed and usability of the application has taken a significant hit as a result. In 2012, it was decided that the future of Portfolio Analysis was on the web so product development and engineering were tasked with the redesign of the application that would take it there.
Empower Users to Discover
After 12 years of continuous development, Portfolio Analysis 2.0 reached a level of complexity that was hindered by it's design. The application scaled to support multiple asset classes, each with their own intricacies, but unfortunately the interface didn't scale well along with it. In 2012 we were faced with taking a hard look at the application and mapping out existing functionality, only to build it all out again in a more efficient manner. The hope was with a more organized approach to all Portfolio Analysis has to offer, improved usability would be the result.
Portfolio Analysis 2.0 has a deceivingly simple interface where 95% of the settings that you can apply to your report are contained within a single 'Options' button that is front and center in the application. Under the hood however, this single 'Options' button in fact holds roughly 550 options that can be set for a particular document. And to further confuse the end user, some options impact the single report you are viewing while other options impact all reports that are contained within the document.
We began by mapping out all 550 options and denoting whether those options were 'local' to the report or 'global' to the document. At the end of this exercise we realized 70% of the options were 'global' options and these options are also very particular to the portfolio that is being analyzed.
We determined that if a user can tie these settings to portfolios as account attributes and opt into using the default settings, then we could greatly reduce the complexity of our options dialog and promote consistency across documents for our end users. Local report options could live inside each tile where it is clear that the options set will impact that single tile. Global options would be retrieved via the application toolbar where it's more visually obvious that options set there would impact the entire document.
Utilizing account settings to set these 'global' options would also reduce the number of documents a user may have to build as they can cycle accounts through the same set of reports and the account settings would update automatically as long as they are opting in to use the default account settings.
Historically, the majority of Portfolio Analysis' user base have been performance analysts that have the patience and time to learn the advanced application that is necessary for their day-to-day workflow. We spent the next few months interviewing performance analysts & portfolio managers in order to better understand the needs of all user types we would like to support. In addition, 75 internal specialists on the Portfolio Analysis product participated in focus groups led by product development.
Flowcharts for numerous workflows were mapped out prior to development in order to help communicate the overall goal of a feature with stakeholders that were not as familiar with the product as the developers were. The flowchart below is an overview of the audit feature in Portfolio Analysis.
Sketching User Flows
Workflows were sketched extensively on paper and whiteboards during brainstorming sessions. Mockingbird software was used to provide clean and consistent sketches that helped facilitate further discussions with product development and engineering. Feedback collected was then incorporated and vetted further until there was sign-off from stakeholders.
The research piece of this project took roughly a year to complete. Ample time was dedicated to research given the complexity of the project and the determination that the correct product was being built. There was a short overlap between research and development so that wireframing could begin as soon as possible. Below are wireframes depicting how a user would add a tile to their multi-tiled report to build a dashboard that was a highly requested feature.
High Fidelity Mockups
Once wireframes were vetted for consistency and accuracy with their interactions, the finer details were focused on in the visual designs. Below are the final visuals for the wireframes that were shown above. Usability tests exposed that the location of the 'Done' and 'Cancel' button was not ideal in the wireframes so these buttons were shifted to the top right as users scan from top to bottom.
The Final Product
Portfolio Analysis 3.0
After 2 years of R&D and development work, we released a beta version of Portfolio Analysis 3.0 on August 28, 2014. The speed and usability improvements have been well received and the adoption period is a result of document conversion and training that must be complete prior to turning off Portfolio Analysis 2.0. We are continuing to refine and develop Portfolio Analysis 3.0 but are overall pleased with the result.