Background

This tool provides financial professionals and their office staff with the ability to submit and track money movement and position management requests for brokerage accounts held at one of two separate clearing firms.

My Responsibilities

• Requirements/business rule elicitation
• Process re-engineering
• Functional requirements
• Workflow and screen mapping
• Wireframes and high-fidelity mock-ups
• Taxonomy and interaction design
• Information architecture and navigation
• Data mapping to forms, data stores, and back-end workflow systems
• Testing and managing additional testers
• Communications and marketing materials
• Pilot team leader
• Product owner; Level II support

Team

• Subject Matter Experts: 10
• Developers: 5
• Testers: 8
• Pilot Offices: 12

Timeframe

• 2010 - 2012
• 1 year from project initiation to first pilot rollout
• 7 total pilot deployments
• 3 total enterprise deployments

Platforms

• Desktop
• Tablet

Problem Statements

The predecessor to this tool was a web-based copy of the back office workflow system - our new system needed to mitigate each of the following issues:

• The main menu was grouped by processing team rather than by user task.
• Data entry screens included home office terminology and concepts and required redundant entries which allowed for requests to be submitted with mismatched values.
• Online requests were limited to those that did not require a client-signed form.
• It was a common misconception that submissions would often get "lost"; follow-up required a search with limited available criteria, and results displayed only a small subset of request detail.

Generative Research

Identifying the right solution began with in-depth research of the problem space, current processes, and desired outcomes.

PRIMARY RESEARCH METHODS

• End User Interviews - Gaining an appreciation for the different ways requests are received by a financial professionals' office, the terminology used by the clients making the requests, and validating the specific deficits of the current process and system.

Moving Money Empathy Map

A close examination of the current process revealed a multi-channel experience with several less-than-optimal situations that routinely plagued financial professionals' offices and often required more than one phone call to resolve.

• Internal Interviews - Learning and documenting the underlying processes and business rules, and the nuances of each.

Example of Electronic Transfer Business Requirements and Decision Points

Electronically transferring cash between a brokerage account and bank account (EFT/ACH and Wire) encompassed 14 of the 46 unique workflows implemented within the new tool.

SECONDARY RESEARCH METHODS

• Reviewing call center logs and suggestion box submissions regarding these functions.
• Identifying consistencies and discrepancies across similar functions.
• Documenting existing system functionality.
• Understanding what preliminary information drives subsequent options.

Functional Design

A full understanding of data dependencies for each combination of request components was obtained, verified, and presented to the development teams  using a range of documentation methods to ensure the complexity was clearly communicated and understood for each unique scenario and decision point.

Example (redacted) flow chart of data elements and their relationships to one another

The connections between data elements ended up being entirely different than the resulting data entry workflows, but creating these visualizations first provided a solid outline of the business rules that helped to inform and validate the resulting interaction design.

Screen Flow and Navigation

All functions were compared and contrasted to identify their similarities and differences. To speed learnability and increase memorability, all screen flows followed the same logical model regardless of request type.

In addition, the navigation design included the following characteristics:

• Multiple ways to access the system
• Wizard-driven entry to support data dependencies
• Built-in branching/funneling based on previous selections
• Screen reuse for consistency
• A logical path back from any point

Consistent screen flow and navigation as applied to a specific high-level process (redacted)

Some workflows required a lot more data to be gathered than others. Consequently, the number of entry screens necessarily varied, but the screen flow and navigation remained consistent across every workflow.

Interaction Design

The primary business goal for this tool was to increase online submissions, which in turn would reduce data entry by the home office. Research with our user base informed me that, in order for this tool to be adopted as a normal part of a financial professionals' office workflow, it needed to be easier, faster, and less prone to error than filling out a paper form.

These functions of the system were defined, designed, and presented to the developers in the following manner:

• Standardized microinteractions were defined once and implemented across all workflows. This consistency would allow the user to become more comfortable with the system sooner, which would increase both data entry speed and accuracy.

Example UML Sequence Diagram - Account Number Entry and Search Microinteractions

UML sequence diagrams provided to the development team communicated each high level interaction between user and system.

• I designed each decision point in the workflow to build upon prior choices. Each option that did not apply to the current request based on one or more previously selected values were disabled rather than hidden. This behavior was selected not only because it would provide consistency, but it would also visually inform the user of all choices available for the associated account. If one of the disabled options was desired, the user would only have to modify a previous selection, maintaining the validity of the entire request.

Example Annotated High Fidelity Screen Mock-Ups (redacted)

Annotated mock-ups ended up to be the best best way to communicate on-screen control-related business rules to the development team. Overall business rules, such as which Account Types and Registrations could be associated with each workflow, were communicated through spreadsheets.

The onus for handling all of these complexities was put squarely on the system - programming a complex algorithm once, in order to simplify the process for the daily users of the utility, quickly became my mantra for this project. In order for this tool to be embraced as a worthwhile addition to the regular routine of a financial professionals' office, the system needed to do as much of the heavy lifting as it could.

Iterations

During development, situations were identified that could cause processing errors or delays. For one such instance, the development team posed the question, "Should we allow requests in XXX situation to be entered, or not?"

To answer this question, I designed and distributed a survey to advisory board members (an office-nominated, tenured group of office assistants), requesting a "pain" ranking (1 through 4, with 4 being highest) to be assigned to each item on a list of ramifications provided for two potential scenarios:

1. Allow request entry now, requiring acknowledgement of the issue; next steps to prevent processing delays would be provided.
2. Notify of issue and next steps, but prevent request entry until the situation had been rectified.

High fidelity screen concept mock-up - "Allow entry with notification" (#1) scenario

Survey results came back with the first option being expected to cause fewer pain points for the majority of respondents, which resulted in the design of a modal error message pop-up, reflecting expected functionality and message text.

Taxonomy

The title of this utility and the labels identifying each high-level function came directly from user experience research. The working title for this tool was "Account Maintenance", and was demonstrated to a 13-person focus group part way through development.

Several participants reflected on the name of this utility, and used a vehicle analogy to explain their collective mental models:

• "Maintenance" was viewed as fixing something that is broken, akin to replacing an alternator.
• "Servicing" was positively associated with more routine activities, much like an oil change or a gasoline fill-up.

 Based on this feedback, the official title of this utility was changed to "Account Servicing" prior to its first pilot release.

Similarly, the high-level functions were each labeled with verbs - "Move Money" and "Manage Positions" - to indicate the overall action that each category represented. The appropriate sub-options were categorized within each one.

The taxonomy of the new tool

The metaphor of "buckets" was used in presentations to executives, support staff and end users, and served to represent the high-level functions available within the new system.

Data Mapping

Mapping data to the back-end system, and to pdf forms to be printed for client signature, both presented challenges - similar scenarios required entirely different data mapping patterns. In order for each request to be processed properly the first time, it was critical that each unique mapping scenario was properly identified, documented, and coded.

The examples below reflect the level of documentation provided to the development team to properly map the data to the appropriate fields in the back end system. Data mapping for every unique entry screen was documented in this same manner.

Data Mapping example with minimum required data

Data Mapping example with maximum required data

Out of 12 unique recipient scenarios, four different mapping patterns emerged that had to be implemented accurately for the order to be fulfilled. These two examples cover the data mapping for eight scenarios - the top represents the entry screen, while the bottom (green background) represents the back office system.

New fields and functionality also had to be defined and added to the back office processing system to enable the display of all request detail back to the financial professionals' office, and to provide two-way text-based communication between the processor and the requester.

Key Outcomes and Highlights

• Consistent processes across all submission types (46 unique workflows)
• Reduced cognitive load - entry steps match user flow
• Error reduction - only valid options for selected account and request type combinations
• Built-in business rules and logic
• Just-in-time information display where and when needed (examples: available cash balance, current client age)
• Automatic form population for client signature based off of system entries
• Ability to attach required and optional documentation directly to the request
• Accurate back office workflow system population, including all attached forms
• Full search utility of all historical and current requests
• Processing transparency - Real-time queue of all currently-active requests, including full request detail, attached forms, and status history
• Two-way communication to address any issues or questions arising in-flight or after request completion
• Increased online adoption by 20% across all request types

Marketing One-Pager - Benefits and Features (redacted)

Being able to make requests online is seamless and quickest; less time spent on hold is always more productive."
Cindy H.
Office Assistant

...quick and easy compared to old methods."
Blaine M.
Office Assistant

Pilot Office Feedback

DROP ME A LINE

Like what you see? Let's get in touch!

Diana Criser, CUA, CXA
User Experience Practitioner
​Omaha, Nebraska

402.598.4969