top of page
Help & Support Platform
I worked closely within a multidisciplinary team to design a new refreshed and re-engineered help and support application for financial advisors.
1 product designer
1 stakeholder
1 business analyst
2 developers
ux research, product design
background
all of the applications that advisors use daily at their financial firm include links to a 'help' platform that gives them access to FAQs, topics, guides, and tutorials. covering all aspects within their practice, this application was meant to empower advisors to find information and answers on their own rather than calling into tech-support agents, however, it was highly under-used.
the team worked together to create an agile project plan focusing on four main areas: understand, research, validate, and iterate.
the process
understand
the help and support tool was being under utilized, resulting in a steady rate of incoming calls to tech-support on information that was readily available within the tool. as a team, we needed to figure out why this application wasn't successful and improve our user's experience while using the tool and take some weight off of our support agents.
i took a deep dive into the help and support platform to start identifying issues that may have been visible clues as to why it was failing to engage users. i tasked my team members to do the same and urged them to only note obvious issues and be mindful to not make any assumptions. because of this, the initial areas of opportunities we highlighted were both broad and high level.
the tool is outdated
the tool doesn't match our design system
key navigational features, like search, are buried
observation & research
i looked at companies that had a robust amount of topics for users to comb through because i knew that our help and support tool covered a large range of advisory product areas. my goal was to identify how they were categorizing help topics and using search functionality within their support pages.
amazon
key highlights:
- recommended topics
- intuitive help categories
- prominent, easily identified search
key highlights:
- criteria for searching
- popular actions
- intuitive left hand navigation
- feedback component
key highlights:
- hierarchy of search
- bucketed key help areas
- clear delineated tabbed product areas
i scheduled interviews with 10 advisors that were in three different ranges of their careers: sales associate advisors, junior advisors, and senior advisors. my main goals for the user interviews were to understand what features of the application were successful, what features were failing, and what features users wanted that they didn't have.
my contextual inquiry efforts were focused on observing the users actually using the tool in their natural habitat in hopes to bring to light insights that the users may not even be aware of.
through my observatory research, i laid out what users said vs. what they actually did to reveal what they actually mean to identify areas to focus on.
"the tool doesn't look like the rest of the applications i use."
"i can't find what i'm looking for."
"i feel like i'm always calling in with the same questions."
"i want to provide feedback, but i forget what i want to comment on by the time i get to that section."
it may be hard for users to jump back and forth between applications that lack consistent components and patterns
users often open the tool from other applications and they land in it without context and without clear navigation
there is opportunity to show popular or suggestive search topics to allow users to get to answers quicker
a contextual feedback area may be more helpful to open when viewing content than having in a stand alone area
although support agents weren't going to be using this help and support tool, i still wanted to make sure they were represented in the design process. they were the ones that were answering incoming calls from advisors so i wanted to understand what the top issues were that they were receiving calls about and what their overall pain points were when dealing with these calls.
i spoke to a total of 5 agents and the main themes that were uncovered during these sessions were:
80% of incoming calls are
product/application specific
most questions agents help to answer can be found in the tool
there wasn't a standard process of documenting feedback
i brought my findings back to the team and together with the stakeholder, analysts, and developers we laid out key insights into an impact/effort matrix.
ideation
sketches
good old pencil and paper
wireframes
axure
with the outputs from research, i started to sketch out high level ideas to conceptualize the re-designed product. after getting my ideas out on paper and reviewing them with stakeholders, i moved on to putting them into wireframes.
wireframes
the home page would bring emphasis to the main 4 features of the tool:
search, help, support, and feedback.
popular topics across all applications would be featured on the front page.
categorized applications and product areas
navigating to any of the main three areas (help, support, feedback) would provide the user with related content.
left hand navigation would be use to switch between different topics within the main focus area.
the primary toolbar within the application would be contextual to emphasize area that the user is within.
when using the search, suggested searches will appear to help users further refine their search terms.
*suggestive searches [if feasible] would grow over time as the product became smarter through collection of user data.
test
good old pencil and paper
10
i set up usability tests with the initial 10 advisors i previously interviewed to validate the wires. my lose process with generating evaluative usability tests is as follows:
overall, the application yielded successful task rates and high satisfaction numbers. at the end of each test, i also gave the users the opportunity to think out loud about what they liked and disliked. the tool was most successful in exposing the search feature, which was a main feature the team wanted to improve. a feature that was not as well received was the feedback page. users didn't feel it needed that much emphasis since they didn't submit feedback often and still wanted it to be more contextual than having to navigate to a full page.
*although scenarios covering the feedback page tested well, this was a big miss on my end - i missed the mark on figuring out how feedback could be contextual which was a current user pain point.
since the feedback page in my wireframes didn't really address the user's pain points, i was inspired by their quick feedback to create a reusable feedback component. i was drawn to material design's 'fab' button because it could float above content in a way that wasn't distracting to users. if the use of a 'fab'-like feedback component tested successfully, it could be added to our internal design system, too.
feedback button presented as a fab
feedback as a cta removed from home
when open, the component would require 'type' to be filled out to help filter the comments by application/product area
95% of users successfully found and interacted with the feedback component.
deliver
since most of my designs included components that were already a part of our design system, i translated my wireframes to high fidelity and met with my team's developers to walk them through my designs. the feedback component, however, would be a newly created one so i wanted to see how feasible it was to include in our final product and also develop it as a reusable component.
working on the feedback component and defining it as part of our design system would require an extra sprint, but it was supported by our stakeholders and other teams would find it useful on their products.
once high fidelity comps were delivered to the development team and work kicked off, i reached back out to users who helped shape how the tool would be redesigned to give them a glimpse as to what they can expect in the future. a big win was showing them how the tool's look and feel matched other applications they use daily.
i also met with the support agents and walked them through the new information hierarchy of the tool and shared the feedback collection component.
although i didn't get to see the final tool through production, reconnecting with the users and support agents helped to further validate that we would be improving both of their experiences related to the tool.
final thoughts
there were so many pain points and concerns that our users and agents brought to light through initial interviews and usability testing so it was important for me to adapt quickly. for this project, i made sure to keep the communication between myself and users flowing and happening often so that i was able to iterate, 'test,' and deliver comps to the development team at a quicker rate. by moving quickly in my design process i also identified sooner rather than later that the feedback page i originally designed wouldn't meet the user's needs.
at the beginning of the project, i made sure to understand the full journey of users related to this tool. i looked beyond just the main users of the tool to determine if there were others that would benefit from this redesign. if i didn't pay attention to the whole experience, i would have missed the opportunity to connect with our support teams.
bottom of page