The Challenge
Having a CMS that caters to the banking industry had proven to be successful for Kasasa, however their technology stack was starting to show its age. The Adobe Flash™ based admin tool highlights the tech debt accrued over the years. Getting off Flash meant understanding the nuances of the various dependencies in the old system. While the company had tried an off-the-shelf solution to replace it, its complexity proved to be too daunting for the average user, leading to numerous frustrations including additional training, maintenance, and support.
“Using the CMS has been a bear. It’s not user friendly or intuitive and even with some tutorials and walkthroughs, it misses the mark.” — Client Bank
The Not-So-Ideal Solution
As you can see from the video (sped up 8X), the replacement CMS the company tried was overwhelming, offering up way too many choices for something as simple as updating an image on the main page.
We realized that the only way we were to get this right was to migrate off this system to a newer, home-grown system that was showing good results since its hackathon debut.
Hackathon to Production
Listening, Reflecting, & Identifying
Users seemed to respond well to the simple UI of the new offering, but it was still lacking in features and extensibility with other systems.
We had to understand the entire process from design hand-off to development through delivery and follow-up. This is where we engaged internal and external teams to uncover additional frustrations and inefficiencies. I addressed hierarchy, information architecture, and project priorities through collaborative workshops. I also employed various strategies to collect and analyze the data I had at my disposal.
Information Architecture
Mapping the experience highlighted the issues uncovered through qualitative data gathering and gave the team perspective on the disconnect between the users’ experience and how the system was built. The most obvious was that users must contend with up to three different applications for site management. This was confusing, frustrating, and required too much context switching.
The new, streamlined approach I offered up had potential but ran into tech debt challenges. The cost of changing to the “happy path” for users would have to come incrementally.
Getting the system out of Flash became an internal priority. Since the front end was already built on a popular HTML/CSS framework, we only had to worry about the legacy dependencies as we moved forward with our suggested improvements.
Prototyping
Building, Testing, & Learning
The original concept for the new CMS was developed during a hackathon. While it was an improvement over the old CMS, there were still outstanding issues that needed to be addressed including better editing capabilities and asset management.
After collecting and processing user feedback, I spun up an Axure prototype the team used to show a possible future state for where the CMS could go. Features included inline editing of text customizations, a context-aware slide-in panel for editing, and interactive affordances that allowed users to hover over an element within the CMS to identify if it was editable. These were regarded as table stakes based on a competitive analysis I led and conducted.
Further Client Feedback
Feedback was distilled into “Positives,” “Negatives,” and “Recommendations” based on what we heard. This was crucial in providing the necessary understanding around dev, business, and UX requirements.
We whiteboarded our findings for all to see and conducted show-and-tell sessions which afforded us speed and accessibility with key stakeholders as they could just walk up and comment easily.
Key Takeaways:
- Clients had different priorities than the business. For example, Blog support (a business feature slated for an upcoming release) was nowhere near the top of their list so far as importance.
- Scheduling content was a major pain point for all participants.
- Live view, the area in which clients saw their changes immediately publish (and a perceived benefit) made clients anxious because they couldn’t preview their work before it went live.
Developer Environment
I didn’t want to neglect our secondary stakeholders — our developers and support staff. We needed to understand their day-to-day as well, therefore I conducted some job shadowing and found out that
many of our developers have multiple windows with each app opened in a separate tab. They’re able to jump from the browser, to the code editor, to Photoshop easily. This is atypical for FIs who are often editing on an older desktop.
Functional Build
We worked through some of the main features including image banners, scheduling, and others that were slated for release. We coordinated with the development teams to ensure things were accurate to the design spec.
Because we were able to get with clients early and often to test our hypotheses, by the time the features made it to the app they were well vetted and met clients’ expectations.
Iterating Further
While migrating from old technology was nice, we weren’t finished yet.
The problem with dev goals is that they often don’t matter to users. We kept asking questions to refine the application even further. My team helped plan and orchestrate workshops to not just validate thinking, but uncover areas of improvement.
One such area was scheduling content. We worked through various prototypes, continually tweaking and learning based on what users were telling us. We identified the need for both automated setting up and pulling down content, but the desire to keep content in an archive was new. Seasonal events, promotions, and a paper trail for compliance were all reasons cited.
Kasasa CMS Editing Environment
Results
Better experiences begin with users at the center. Introducing a regular cadence with clients allowed us to improve the software through direct evidence.
By providing UX a seat at the table, we were able to turn a process that had been more Dev and PM focused into one that brought insight and clarity around what users really want and need. We adjusted our roadmap when it was determined that our users didn’t care as much about certain features and prioritized things that mattered to them. And while this is an ongoing process, we’ve established a foundation for further growth by ensuring the triad of Dev, PM, and UX were working in concert.
Ultimately, we were able to:
- Better differentiate ourselves in the market by providing industry specific solutions
- Uncover new business opportunities by capturing additional client needs through testing
- Engage clients early and often, making them feel more connected and invested
- Bolster our consultation arm by understanding their workflow and streamlining processes
- Scale our platform across financial institutions by addressing the big challenges first
- Modernize our offering to reflect user expectations
54
%
Fewer support tickets
4.8
Client satisfaction score (out of 5)