Let’s talk about the work you’ve done
What did you work on in the last two years?
A lot. At last count 20+ projects for 2019 alone.
Can you be more specific?
Not really, work is under NDA but let me talk about some projects.
Project: Servicing Apps (Project Sun)
Participants: 2 UX Designers (Me & an Intern), 6 Agile Cells / Dev Teams, 10 Product Owners plus everyone above them.
Timeframe: About a year
Requirements: We need a product to condense all of our existing applications (currently 20+) into one application. This is a long term project.
I’ve found that enterprise environments tend to develop apps in a one-off manner without discussion or plan for the future. A need verbalized is enough to warrant funding of projects. This project was a plan to deal with that and consolidate what was a large playing field of poor experiences, difficulty training, and updates to aging software.
This endeavor began with one mini-app or module and blossomed from there. The goal was always to build a product to hold everything but what that meant wasn’t really understood. As I worked through the very first module it became clear the opportunity we had before us.
Imagine starting something from scratch, truly brand new software that is not updating legacy bad habits or just building onto something that should have been decommissioned a decade previously but something new.
A Modern design framework, a clean style, a well thought out visual and informational architecture and cohesiveness built into every page, every app in the system. Getting there though took a lot of work, a lot of selling the vision to a lot of executives, a lot of presentations about the possibilities are before us.
Perhaps I could have just said it would save us money and that would be enough but I wanted everyone to embrace the possibilities that were possible. If everyone owns something, everyone cares for its success.
My biggest successes for Project Sun were the establishment of the product owner council and the bi-weekly developers awareness meetings.
Project: The Aide
Participants: 1 UX Designer, 1 Agile Cell / Dev Team, 3 Product Owners
Requirements: An easier way to transfer data between customer and bank
Time Frame: 7 Months
Hit your feet running as they say. When I started at Chase, I had not even finished my new employee training (to be fair, it’s like 20 hours and full of esoteric knowledge) when I was assigned to my first project.
The Aide was new functionality for customers to import very specific information into our system. The existing process (which we weren’t replacing) required extensive modification of customer’s data and/or systems to interface with ours. While doable, it was a significant commitment. Not to mention requiring people with very particular skills and a customer might not have that at their disposal.
This process should be easy enough for non-technical employees to complete.
Main goals: No training required. (As a side note, 2/3rds of the way through this project I tried to complete the Original Method. I was unsuccessful.)
Match customer data to bank data.
Accommodate variable data types and formats (ex. Date Formats).
Allow the creation of templates so that settings/progress can be reused.
Allow the customer to choose between pre-populated data, enter custom data, or use local file information for 30+ fields.
Process: No matter the project or timeframe, I try and get in as much research as I can. I talked with the Subject Matter Experts on a near daily basis for the first couple weeks I worked on this and this was before official sprinting had begun. This project exposed the core concepts/items/data points that surround our business: how are Merchant Category Codes used, what exactly does cycle mean in this context, or this value doesn’t seem important and we should drop it.
Design, Set, Go. I sketched and sketched, I worked through user flows, and I designed interactions. I worked with senior leadership to get buy in on a new design pattern for this. I presented to the Product Owners and Developers, and incorporated that all into a solution. This was months of work, tweaking flows and adjusting for ever so changing requirements.
As it goes, we had to scale back the design near the end which meant adjusting the interactions to accommodate lost of functionality.
This project lasted about 5 months (with an additional 2+ months for a phase 2) and is currently in pilot.
Project: Boarding / Number
Participants: 1 UX Designer, 2 Agile Cells / Dev Teams, 3 Product Owners
Time Frame: 18 Months, Ongoing.
Requirements: There was a need for an automated process to help with client management on the back-end side of the business. It had previously been done with excel spreadsheets, emails, and errors.
Additional Info: I joined this project after it had been in development about a year.
I have worked with this team for the majority of my time at Chase and am proud of the relationship we have built.
This project is a nexus of many other systems and processes, requires extensive knowledge of extremely technical terms and flows, and has more failure scenarios than you could shake a tree at.
A recent request saw us adding functionality that connected to outside systems and the user would need the output of this process as part of their work. As this is an existing app that has been in use for quite a while, its system architecture / design system is established (rigid and difficult to change). This is an added constraint when trying to insert functionality / interactions which are brand new to the app.
What was the number? The number related to a physical aspect of the Plastic Credit Card. The secondary number was related to the management of the first number.
The architecture didn’t allow us to freely edit content on the page both from an UX perspective and from a development perspective. As this information was extremely self contained and the page already had a lot of information on it. It made sense to move the bulk of the interaction into a modal but the team was still left with the user needing to modify the output and we couldn’t put this on the page.
When the application first launched, we received feedback that we had not designed some of the data fields to support the user’s unique work. Where we had thought the field would be the same for every project, it turned out the field might have multiple values and we had not accounted for this. At the time I was given leave to come up with solutions but all of my suggestions were outside budget / time constraints. So this problem went unfixed until a time when we could be address it. One positive to the issue is that there was a work-around that was more annoying that difficult. I still argued often that we should fix it.
This Number functionality represented an opportunity to build a foundation to support our eventual fixing of data field issue above. I took one of my solutions for the data field and adjusted it to work with the Number but still later allow the data fields to be incorporated here. In a rare occurrence, Development loved this suggestion and Product saw the benefits that this solution would bring to future functionality.
Feedback I have received from the users have been positive: talking about ease of use and intuitiveness. Feedback from the Dev Team refers to this as a badge of honor, that we did so well with this.
Finally, I wrote about a recent release on this project: Here. (In a humorous fashion)
Future Reflections: This foundational work has seen increased use with new functionality that has been added. I find it funny in a way, how excited the team is to use it when we get the opportunity. But I am also proud of how well it solves our current work issues.