How do you take a $15 billion dollar mutual fund with an underachieving web presence, and give them the depth and richness of design and functionality that better represents who they are to their customers and peers within the financial services industry?
I had managed the migration of IVA Funds previous site from a proprietary PHP-based CMS to Drupal for Strategic Domain. During that process, we created their entire back end functionality, which included a range of user- and role-based navigation and functionality. They were happy enough with the way the site worked, but felt that the front end should be more up to the standard set by other top financial sites.
Aspirations
The process began, as it does with most clients, with a focus on “aspirational sites,” other funds and banks already doing (at least in part) what they wanted to achieve. Because of the nature of IVA’s business, we would have to strenuously avoid the traditional commercial banking look. They needed something that was clean, dignified, and respectable, with the requisite gravitas. Interestingly, there were few sites that were truly well designed in the space, so we would have to draw equally from good design principles.
At the same time, we broke down all of the existing site content, and rearranged sections based on new internal naming and organization.
UX Wireframing
We began an fairly long process of wireframing, applying the content to skeleton-like blueprints of every page on the site. This allowed the client to visualize the flow of information, and test for problems with navigation and content accessibility.
We did many, many iterations of the wireframes. Some iterations involved a simple change to navigation, while others required entire sections to be renamed, moved, and new content to be added.
Over time, we ended up with a pretty good vision of what the site was supposed to look like.
More importantly, thanks to the power and flexibility of Axure, we were able to program interactions such as lightboxes, error checking for incorrect usernames or passwords on login, and even sophisticated date picker functionality.
Finally, with all changes made, and mistakes corrected in the wireframes, we received approval, and were able to turn our attention to the design process. We had to give them an entirely new look, while cleaving closely to an established palette. Fortunately, the design process would have clear content and page hierarchy blueprint to work from with the wireframes.
UI Designing the Funds
Fortunately, our designer for this key project was one of my collaborators from my days at Fry, Noel Suthers. Noel and I had done work together for a number of different clients, including Godiva, Coach, Wedgewood, and many more.
We took Noel through some of the client’s aspirational sites, and discussed what we wanted to achieve with the design. He quickly came back with a number of very interesting and diverse concepts, each with its own unique value. After a bit more reshaping, we were able to begin taking the client through the designs, and getting their feedback.
The next major hurdle would be converting existing users to new navigation architecture, and new roles on the revised site.
Role Reversals
The roles established in the previous Drupal migration were going to be tested with the site-wide renaming and reorganization.
Of course, to the user, this would all have to be perfectly seamless. They would have to log in from one day to the next, and still have complete access to all of their financial information, albeit in an enhanced and restructured format.
Mapping Permissions and Exceptions
Once I received requirements from management, it was time to map the existing roles, to the new site’s set of roles. It was only after lengthy discussion and trial and error that I was able to come up with the approved mapping. The only thing left to do would to accommodate the exceptions. Of course, there are always exceptions. In this case, a handful of users needed some special complex combination of roles and permissions. Thanks to the way the dev team renamed the legacy roles, and set up the new ones, it became a simple matter to attribute the proper permissions.
Developmental Progress
This development was a bit unique in that I had two teams in place – an Indian team coding basic site structure and migrating content, and a U.S. team focused on granular functionality, permissions, and special client requests. Which overall, wasn’t a bad way to break it down, but the Indian team started at 11pm and worked until 9:30am (New York/East Coast time), and my U.S. team was here with me beginning at 9:30am, and going until anywhere from 6 to 8pm in the evening.
So my schedule became late night communication with India to set targets and milestones for the days work, and then early morning discussions to track progress and set targets against the next set of functionality goals. This would then give me the next set of tasks to turn over to the U.S. team for the day. Both teams were great about executing on their targets, but it always came down to me to identify, prioritize, and track progress against each line item, until we could move on to the next. About six weeks of that definitely began to wear me down, so I was glad to make fairly quick progress until we were finally ready for beta release, and QA.
Testing, Testing
I designed a number of test scenarios to put the new site through its paces – everything from logging in as every possible conceivable role attribution and combination, to logging in as individual users with access to specific data. Again, I’d have to go back to the thoroughness of effort put into the user interfaces, wireframing, and role mapping, but there were thankfully few bugs, and those that came up were fairly easy to fix. We did find that Drupal had occasional issues with files uploaded by the admin (“user 0”) were not accessible to other users. Usually, however, the fix was as simple as deleting & re-uploading the file.
Learning to Fly
The old agency model involved tying clients to expensive, complicated, and proprietary systems that required long and expensive systems integration and management contracts. With the amazing Open Source tools now available, together with a more positive and proactive agency-client relationship, the name of the game is empowerment – giving clients the tools to handle most of what they might need to do on their own site. The agency would only need to get involved if there was some major site functionality or design change that would have to get done.
While the back end of the site did not change dramatically, and most of the updates could already be handled seamlessly by the same staff, we did spend a very constructive 4-5 hours at the client’s office, taking them through the paces of typical updates. We also provided them with a fairly exhaustive and updated documentation site.
Well Documented
In the past, we had given clients a single-page printed sheet, but it became apparent to me that there was simply too many things to remember, that changed too frequently. So I quickly coded up a documentation site, with searchable, regularly-updated articles on how to manage, maintain, and update every aspect of the site. Of course, the documentation site would have to be password-protected, but the transition to making it a living, breathing online document, as opposed to a static sheet made a huge difference for the client in their ability to continue taking ownership of their site.
Ready for Liftoff
Finally, with the last few client updates, and the last few fixes in place, we launched the revised site. On a somewhat bittersweet note, IVA Funds closed their funds to new investors, as their company philosophy required them to stay smaller and more nimble in order to better respond to market forces. And now, they have a web presence that better represents their image and place in the financial world.
You must log in to post a comment.