UX CASE STUDY
Loan Origination System
CHARM
CASE STUDY HIGHLIGHTS
-
ORG & SECTOR: Fulton Bank, Commercial Banking
MY ROLE: UX Strategy, Research & Design; Workshop Facilitation; UX Design; Agile Guidance
TEAM: Multiple departments involved — approx. 80 individuals involved at any given time. Of that, I was the sole UX person, prior to Slalom agency joining project team.
CLOS: Commercial Loan Origination System, referred to here as Navigator
-
Being the first UX Designer in an extremely traditional organization.
Overcoming Business’ impatience and underlying resistance in revisiting discovery sessions. “We’ve done this before.”
Successfully juggling workshop facilitation, capturing & sharing session insights, and setting continual aspirational goals for an incredibly large team — all on my own.
Maintaining my optimism and ability to positively impact the outcome despite extreme office politics.
Having a voice once an entire external agency was introduced into the project team.
-
As soon as possible, I established rapid rapport with key leads, IT colleagues, and departmental influencers.
I held role-based framing and persona workshops that engaged all participants.
Refined workshops’ rough personas into finalized personas blessed for team use.
I held story-mapping workshops to bring to light obstacles & details.
Dug deep for stronger empathy for the customer experience — highlighting process areas to be addressed beyond the scoped software.
Collaboratively handed-off user research work to Slalom agency, showing leads how to tie insights into agile workload.
I gathered all insights & next steps into a reusable reference utilized for this and other large projects.
I joined forces with Change Management to share insights on user transition & change.
Joined forces and became a voice for the Quality Assurance team.
Created an optimized project management site for team to find right thing at right time.
-
UX got on the map as an essential leader, influencer and contributor to a project effort’s success.
Business’ trust in IT’s ability to listen to them as subject matter experts grew.
Personas played a starring role in establishing Change Management’s “Super Users,” effecting how development work was planned, iteratively approached, and tested.
-
User testing
Contextual interviews
Design Thinking exercises
Personas and role comparison matrices
Prototyping
Agile workflow research & visualization
Retrospectives & Lessons learned
KEY TAKEAWAY
Start with the biggest story around reaching a goal and then dig deeper.
Establish rapid rapport with key leads, colleagues, and influencers
When I first started, I immediately launched into a listening tour to introduce myself at the same time as getting to know many of the key leads of the Navigator project I was about to jump right into, as well as my IT colleagues and influencers in various departments.
I made a list of everyone I needed to talk to by printing out the org chart and circling the names of people I should get to know. One whole week into the new position at Fulton, I was asked to give a presentation to the entire project team — to introduce UX (brand new to the org) as well as a preview of design thinking exercises we’d do together that would be different from what they’d experienced before.
In an opening ice-breaker exercise, I asked each participant to share with me their thoughts — on their colored index card — as prompted by my questions.
Engage others by drawing out existing knowledge from the head.
To start uncovering as much as possible — main goals, current process, frustrations and pain points, tools used, time factors, ways they’re currently successful, internal networks, and unexpected insights — I carefully planned workshop groups of around 5 active participants per group where I framed the session objectives, the rules of our design thinking space, and the exercises we’d do together.
Since this project involved a full new project “reboot,” those in attendance to these workshops included hired project management contractors who had little understanding (yet!) of the humans who were going to be heavily impacted by whatever the team built.
To align everyone in gaining a more objective understanding of each human role involved in the project, I formed available participants into small groups, gave them each a role to play, and then asked them to interview the individual who lives that key position every day. During the “interview” each person played their assigned role, following the rules for that role, listed on their colored game cards I prepared.
While the interviewing continued, I visited each group to observe levels of engagement, notes that were being kept, and the insights that were being garnered.
Build lightweight personas together to build shared understanding.
With each workshop I ran, I improved timing around exercises, I became more adept at handling challenges and items that threatened to throw us off track, and I spent more preparation time prior to each workshop — preparing template boards with color-coded areas to match the “gamecards.”
I also started giving better guidelines for the lightweight personas that each group created together. This resulted in more concrete insights and less digging after the persona workshops concluded.
Set the stage for story-mapping to agile planning.
Prior to the story-mapping workshops, I spent substantial time preparing an easy-to-understand example to showcase what we’d do together, how we could then break it out further, and then continue all the way through to agile planning.
I used these collective references to show the project team, the workshop participants, and the hired agency, Slalom, who came in after all workshops were completed, how to easily break out what can otherwise become overly cumbersome from design exercises that are very natural to all of us — telling our stories and anchoring them with action steps taken.
With the entire organization very familiar and very comfortable with years-long requirements gathering done behind closed doors, these human-centric exercises were vastly different from anything they’d experienced before.
I took great care to set the proper framework prior to beginning our story-mapping sessions. Then, when the working team from Slalom was later introduced into the project, it became very clear that they, too, didn’t have much experience in building toward iterative and agile ways of working. We discussed these examples, along with everything that had come out of the workshops, at great length, until they saw the pattern I’d helped to extract.
Organizationally, there were many learning opportunities that sprung from these concepts. And this wouldn’t be the last time I’d demonstrate how this could work.
How do these folks reach their goals today? Mapping our stories establishes the plot and then we dig deeper.
TOP PICTURE shows the first and the largest overall story of the process and ultimate goal, complete with the trigger, steps along the way, obstacles, and the ultimate “hoped-for ending” of a satisfied customer. Ever present in every workshop was “The Bucket” that would hold items that were great in themselves, but were ultimately off-track (and could potentially derail). A big red marker dot was our visual indicator that there’s more to the story that should be considered and further explored.
MIDDLE PICTURE and BOTTOM PICTURE show stepping to the next level of understanding by further exploring the smaller stories within the largest overall story. The story-telling format is similar, just with a more zoomed-in approach featuring smaller goals that must be achieved. The trigger of each smaller story is often some type of notification and/or hand-off from the previous story, and concludes in some kind of hand-off to the next story.
BOTTOM PICTURE also shows some of the early framing ice-breaker exercises I run to get people in the mood to engage (rather than sit back to be entertained or talked at).
Overall, this captured what was happening in reality — all to understand what needed to be potentially considered in the ideal system solution of choice — or what needed to be handled in some way outside of the system.
“This felt like therapy! Wow! This was so helpful!”
— Eric R., newer Commercial Relationship Manager, shared after the story-mapping session
Utilize the power of personas for shared empathy of our users.
With the rough personas in hand, as well as direct access to individuals in those roles, I refined each into a finalized and more robust persona board. The individuals in the roles gave the personas their final blessing, and I shared them with the team.
I also found benefit in putting related roles side-by-side in comparison matrices, so the audience could see shared similarities as well as key differentiators.
Crucial CX insight was gained.
As a result of mapping the entire story as it was realistically being lived in its current process, we came up with a clear “cliffhanger” that would continue to derail the goal of a happy customer. Although the employee experience could be substantially improved in a proposed software solution — in what most of the team was constantly considering — the customer experience would continue to suffer if there wasn’t proper closure.
Timeline of my discovery work with the team…
In the roadmap below, notice the 28 interviews conducted as part of my “Listening Tour.” Workshops were held in November into the beginning of December, with me completing all finalized personas, role matrices, all highlights and insights from the story-mapping sessions, and developing a much-needed vendor software UX evaluation guide, within the few weeks that followed the intensive workshop schedule.
“What you aim at determines what you see.”
— JORDAN B. PETERSON, PSYCHOLOGY PROFESSOR
Scoring Vendor Software on UX/UI Best Practices & Standards
Begun out of a direct request for help in evaluating software that vendors would try to sell to the organization, I converted my original bulleted list (thumbnail above within my roadmap timeline) into a more usable scoring form. This was modeled after Nielsen’s Usability Heuristics, intensive research around form standards, and my personal experience of complex input-heavy, form-centric systems. The level covered in this evaluation is what can typically be observed during vendor demo sessions. This scoring model was built to empower the internal team to make smarter and more consistent decisions against common measures.
Be open to allies from unexpected places.
After my involvement with helping the team through discovery, and a full agency team had taken over the agile workload, I joined forces with the Transition Team, made up of Change Management and Learning & Training disciplines. This enabled me to get closer to the group of early adopters and persona testers that they called “Super Users,” and to share insights on user transitions and change they’d experience.
One of the immediate needs I’d identified was the poor user experience of the current project website, where all project team members were directed to find project documentation, risks, timelines, and deliverables. Being situated within IT gave me an edge to working with the right folks in SharePoint support to get proposed changes implemented.
Make sure the team can actually find what they need.
Teams are only as good as their collective knowledge and the tools they can use. If they can’t find the right thing at the right time they aren’t able to take the right action when it’s needed. And those are the folks that are familiar with the project! What about new people that join the project team?
One of the biggest misconceptions I had to shake loose was that a project site is mainly for the project manager. That is a huge fallacy.
A project site is for the entire project team, including those that are supporting the project team — even those who have yet to join the project. And, even when the project is completed — the project site should be a well organized artifact of everything that went into it.
So, I researched where we needed improvements, I prototyped and tested my proposed designs, and then worked directly with the SharePoint developer to make it come to life.