UX CASE STUDY
Third Party Application Connector
CHARM
CASE STUDY HIGHLIGHTS
-
ORG & SECTOR: Fulton Bank, Consumer Banking
MY ROLE: UX Strategy, Research & Design; Brand Identity; Product Design.
TEAM: IT Project Manager, Tech Lead, App Dev, Business Analyst, Services Analyst & me
3PAC: Third Party Application Connector
-
Convincing IT PM that the proposed solution actually solves the problem.
Very first fully in-house built product.
Only having 1 developer fully resourced to working on this.
-
Zoomed back out to the bigger picture to focus on the right problem.
Led the small team through proper rediscovery.
Developed brand identity that also helped establish product credibility.
Thrilled the Business team with a sensible product that solved the issues.
Exposed issues that needed to be addressed outside the system, to which the Business was extremely grateful.
Taught the Business Analyst how to use Axure RP to add criteria directly to my prototypes, and make edits. HUGE WIN!
-
This stealthy project preceded Palmer Pricing, and gave the App Dev team the confidence needed to continue to build in-house.
This was a huge win to show Business that IT was a qualified partner, and that UX brings great value.
User confirmation interactions I’d proposed in my designs inspired the App Dev team to bring their A-game again.
Project Management Office began to see incredible value in what I brought to the table.
-
User testing
Realignment whiteboarding sessions
Feedback of feature flow options through prototypes before dev efforts
KEY TAKEAWAY
Empower every member of your team and watch them bloom.
Make sure you’re focused on the right problem.
When I was first called in to “help us save this” we were looking at a single incomprehensible screen. The conversation with the Tech Lead went something like this:
Amy: What are we trying to accomplish?
Mike: The user should know what to do by looking at this screen message.
Amy: What do we want them to do?
Mike: Look at the error code and from that determine that there was a mismatch between the two systems.
Amy: Are these folks back-end developers?
Mike: [chuckle] I was hoping you weren’t going to ask that.
As much as I wanted a super simple solution, and I hated being the bad guy in suggesting we go back to the drawing board, I knew the developers couldn’t go to the Business with this as the solution. The major rub? They’d already been working on the interchange between two main systems for the last 9 months, and only now had considered that many points of mismatch would require human intervention.
Better late than never, right?
TOP PICTURE: Whiteboard from a “Bigger Picture” view of everything going on that needed to be considered.
BOTTOM PICTURE: Translating the highlights of systems, flows between them, and the humans involved.
Create a consistent interface as the flow progresses.
Through a series of quick sketching sessions, we established the series of checks the Service Bus performed, that could be visualized appropriately in a step-by-step approach so it would make sense where the checks were happening in the event that human intervention would be needed at any point during the stepped checks. And, once we allowed ourselves the space found in the step-by-step approach, numerous use cases started to surface from the details the business analyst had captured.
It now made sense what we could expose on the front-end, where we could do that, and how a human could potentially interact with decision points. Patterns of interaction behaviors needed to be formed and translated to all involved in approving and building the solution.
“You rock our world!”
— Business Sponsor of 3PAC, after UX-led design proposal session
Be the best possible partner to your Business sponsors. No excuses.
Before we could build everything we’d planned and designed, we needed to share our proposal with our Business sponsors. To be as succinct as possible, it was a smashing success.
I shared a 54-page pdf compendium of many of the prototyped flow screens, diagrams, patterns, and handling of complex user scenarios you’ve seen visualized within this case study. They were most riveted by my system & user diagrams, specifically this one that shows captured issues contributing to a poor UX that would still remain despite our proposed solution.
It’s tough to say, “We can’t fix all of this with this project!” but it’s certainly easier to take when that’s shared upfront and with the right people.
Find a tool that a Business Analyst can also use. UX and BA can work so much better together!
Some of the most efficient workflows that I’ve experienced thus far have taken place in an environment where Business Analysts are able to take ownership of communicating business requirements in a more human-centric way — by connecting them directly to UX’s detailed prototypes. It requires a level of savvy and comfort in a mutual tool, but it is worth the time and investment in training BAs to work this way. This frees up UX from needing to constantly revise the prototype set every single time wording is changed. Working this way complements the strengths of both disciplines!
Use Human Scenarios as the bridge to better Service Design
I think of every scenario and touchpoint as a connection point that provides a goldmine of insights if we truly pay attention. Service Design is a holistic concept that represents the larger picture of human interconnection — the services an organization provides through its employees to its customers. To treat one as more or less important than the other would be a detriment to the entire delivery system, and the end result is always poor or subpar customer service. But, if we actively consider all parts of the larger service design picture, nobody is insignificant, no one is left performing heroics as expected behavior. Each employee better understands their value and is empowered to have a voice, use critical thinking, and contribute to productive solutions. In turn, customer experience improves as the result of empowered employees.
I’ve found that sharing these human scenarios in an easy-to-consume manner, such as my template structure below, helps the entire project team to focus on the human experience rather than system limitations. It may start out as a use case, but because we’re listening more closely and having empathy for the humans experiencing these things, we’re able to consider more natural ways to make improvements that have even further-reaching benefits than first considered.
At the time I was involved in this project, I’d recorded about 80% of the original use case below in a basic Word document and shared it with the Business Analyst to run with it. It was only recently when I revisited the document that I realized there were even further insights that were ready to be picked, that would make it come vividly alive, so I formed a template design that better organized the themes and will benefit future teamwork I undertake.