I worked in the Fidelity Investments User Experience Design (UXD) group from July 2015 - March 2017. Seeing a large, mature design group in action taught me about process and procedure. I was a design lead for seven projects spanning three scrum teams. For each project, I worked with business partners and developers to scope the requirements and goals, draft a wireframe, conduct usability testing, and provide visual design specs that work with Fidelity's web components.
My process for each project began with digging into the need for each project. My group within UXD focused on modernizing the customer experience and reducing the volume of calls coming into our customer support centers, so the "why" was usually connected to that. With an understanding of both the business and the customer needs, my next step was to create early-stage wireframes to confirm with business partners that I was on track to solve business and customer problems. These early designs didn't show "how" we would solve the problem, only confirm that we were solving the right problem.
To learn which specific design is the most usable, I created many designs, showed them to other designers to see which were the best, and tested those for usability. Projects required as few as one round of usability testing or as many as five rounds to find the best design solution. My favorite way to conduct usability testing was "guerilla testing" where I took a prototype to Fidelity's cafe during lunch and would ask people walking by to spend a few minutes completing a handful of tasks on my prototype. I liked conducting usability testing myself because I could see exactly when people became confused and learn exactly what they expected to happen. I often came up with the next version of the design as I sat there and talked to participants. Finally, I would create visual design specs (defining specific, pixel-by-pixel dimensions) for the best design. Finally, creative quality assurance made sure that the working code matched the designs.
Below are some of the interesting points or lessons learned from my projects.
Margin and Options Accounts View Page
I conducted five rounds of "guerrilla usability testing" to find the best design for the margin and options accounts view page. This was a difficult page to design because the margin eligibility rules are complicated (only one account per ownership type can have margin), and a traditional presentation of accounts would confuse users who did not understand the rules. Across all five rounds of testing I asked users to complete simple tasks like "Can you tell me which accounts have margin enabled?" and "How would you get margin on this account?"
The earliest designs tried to show the margin rules in the user interface with forcing functions like dropdowns and radio buttons. This made sense to a room of designers, but participants in usability tests found it confusing. Next I tried a design similar to the other view pages my team members were building, but these overly simple pages combined too much information. The final design created more columns and used longer calls to action than other "standard" designs being created in my group, but made the information users needed explicitly clear and easy to understand. When I asked users questions like "Can you tell me which accounts have margin enabled" and "How would you get margin on this account," participants found the tasks so easy that they wondered if it was a trick question -- a great change from the earliest designs when users couldn't complete the tasks! To deviate from the standard I had to prove that the standard design was less usable than a new design. One non-standard design was the call to action on accounts ineligible for margin. Rather than labeling the link "disabled" or "ineligible" and explaining why somewhere else on the page (which discourages interaction), I labeled the action as "How to enable margin on this account," which brings up a layover that explains the margin rules and how they affect this account.
I also had the opportunity to show my development team in Bangalore, India how I conduct usability testing so they could learn the value of UX. I showed my team my current prototype and asked them how they thought people would interact with it. We then brought in engineers from other teams and had them complete a few tasks. They got to see that we all predicted people would interact with it one way, but users interacted in other ways and questioned things we thought were simple. This helped them see that UX design is an iterative process, and sometimes we have to throw out the current design and find a better one.
Change of Address
The change of address should have been pretty straightforward, except that at Fidelity each account can have a separate address and people can have seasonal addresses. I created multiple versions trying to show accounts with addresses other than the main address. Usability testing between the top choices showed no real difference in performance or preference, so we made the decision about which decision to implement largely based on which best kept in line with the Fidelity visual design standards.
The second image here shows the Axure menu on the left. To coordinate with product management, development, content strategy, and other stakeholders, I created a "UI single source of truth" that was always the most current place to find any version of the page, including different user types, scenarios, visual design specs, and paths to this page. I gave my team one link to the shared drive at the beginning of the project and continually added and updated to the content at that link, but the link never changed. This "UI single source of truth" worked so well that I've used it in every large project since.
Granting another person inquiry access on your account is a simple transaction -- as long as the other person is a Fidelity customer. Even though the old page told people that they could only grant inquiry access to existing Fidelity customers, people ignored this message and entered the SSN of non-Fidelity customers, resulting in errors and frustration. We attempted to prevent these frustrating user errors with a forcing function -- the only action a person can take on the page is to answer whether or not their intended recipient is a Fidelity customer. Answering "no" reveals a message that reminds them of the rule and provides a link to help their intended recipient sign up for a Fidelity account. Answering "yes" reveals the form at the heart of the transaction.
Search and Topic Hubs
We had a hypothesis that the most frequent search requests merited hand-curated "search topic hubs" that present the most likely destinations in an easy-to-scan format. I created several possible versions and a usability researcher conducted in-depth interviews to find which one performed the best. The researcher looked for task success, time on task, and asked about preference. We found that the design that looked just like Google's search topic hubs performed the best and was the preferred design.
Designs in Pre-Production
If you are actively interested in interviewing me, I can provide you a password to a protected page with designs that are not yet live on Fidelity.com. These designs include:
- Options Application
- Virtual Assistant Transaction Testing
- 404 Page