At the beginning of the first contract, each of us was given an approximately 50% completed flow that we needed to get to a pixel-perfect, development ready status. However, we quickly realized that each of these flows, and many others across the online banking update, had originally been designed in a vacuum. For example: other designers didn’t know the basic product requirements for the online help center we were designing, so they were creating issues in how they suggested users contact the bank. There wasn’t a design community or the mindset to ask the people who would know; they simply designed alone and with blinders on and then had to scramble to make fixes as designs went up the approval ladder.

Our team leads encouraged us to do the opposite. By whatever means (email, Teams message, word-of-mouth, etc.) find out who had historical knowledge of your experiences and the flows to which is needed to be connected. Some examples of this silo breakdown from my workload include:

• Getting to know the designer with all the knowledge of “disputing a transaction” as I worked on the parallel experience for “stopping a payment” and eventually getting her pulled into our design pod for daily stand-ups and peer feedback reviews

• Cold messaging peers until I found the previous design partner of the old designer, who had the right historic knowledge to help me prove that what a product team perceived as a concrete requirement was an outdated tech limitation

• Scheduling time for team feedback and inviting other designers (Full time employees, outside of our contract) to participate 

• Being an active participant in UX Gatherings and other design practice sessions when the client did decide to foster the community (even if that meant some weeks our team was the only group talking)

Thus, by showing up with a collaborative mindset in our own little pod, we made a few friends and made the work environment less isolating. Those that aren’t the closest friends at least now know that we’re not going to drop the topic until high standards are met in our work ;)

In adopting design work mid-design, I unexpectedly became the most knowledgeable person on each flow. Our client culture involved a constantly-shifting team roll call and not a lot of accountability for POs in tracking their own requirements and decisions. Our team quickly learned that with people moving around so often and less-than-ideal documentation, past designers made assumptions about past design decisions. This was how our current flows got handed down again and again in such poor shape–it was like a game of file telephone.

Thus, we asked questions, ask clarifying questions, and asked (you guessed it) even more questions. We politely made noise and stirred pots until we got the info we needed to proceed. With time, each of us would get to a SME knowledge level where we counted on our own files having the most up tot date details, comments, and tech limits annotated for our team. Personally, I also made sure to track updates and callouts in Jira issues and comments, too. 

Now when I get teams messages about product team members wanting to know who made what decisions, I can very politely and efficiently rely and share a Jira issue link. In serendipitous sitcom fashion, this sometimes lets my repeat offenders discover that they painted themselves into a corner without me having to point fingers or pull screenshot receipts of messages and emails. 

At the beginning of our contract, we were working in Sketch and using InVision to store and hand off prototypes. Coming into files with fresh eyes allowed me see lots of little things that past designers had overlooked. So, almost daily, I would reach out to the team members on the design system and ask questions. 

“What’s going on with this divider line?”

“Why is this red a different hex code that the standards document?”

“Are there any rules for an 8-column table when it goes to mobile responsive sizes?”

It wasn’t just me, but our whole design contract team, that was starting to ask questions. So a new feedback cycle was put in place. We consulted on fixing broken components, how we were using the component library, and growing the Design System documentation. Catching nuanced details became a calling card for our crew. Before submitting file for approvals, our whole team would swarm and make sure components, fonts, and colors were accurate to the standards. The design system management team said that our files were the most approval-ready they had ever seen in the design practice!

At the end of 2024, InVision shut down. This necessitated the switch from Sketch to Figma for our designing.

I personally documented and preserved 75+ Sketch files and InVision Freehands related to the 5 flows (in 2 different epics) for which I was now lead designer. 

When that was done, I helped teammates do the same.

And we waited for the storm to hit. We consulted on how to best recreate a robust design library in a whole new program with a whole new logic. We stress tested Figma assets from the design library rebuild on our main machines when our consulting machine access wasn’t yet granted. We prepared for the mountain of a task ahead of us: when InVision went dark and we finally had legal and security access to Figma to rebuild files.

And then it happened. While we could pull in Sketch artboards to Figma directly, nothing would be connected to the design library. Nothing would be responsive. Nothing would have variables and colors and fonts stylings. So we rebuilt files with side-by-side reference. Did I mention that the rebuild design asset library had a different naming convention and architecture, too? 10 robust Figma file rebuilds later and I now consider myself a pro.

When I was done with my rebuilds, I helped teammates do the same. 

Now, it’s known that I have a knack as an efficient and speedy rebuilder. I’ve been called in to help two other flow designers meet their deadlines (I knew nothing about their flows before the rebuild assist) and have taken over as lead designer for a parallel flow on a completely different product (the mobile app!). 

It’s plain and simple: I didn’t ever not meet a deadline on this project. I never had to work over 40 hours a week and I only had 1 deadline that was a bit of a buzzer-beater (the product team brought a requirement change to me 4 hours before the approval pitch meeting). This was not the client culture. Full time employees with less workload were continually not making deadlines all around me.

I am not a procrastinator. I am a good judge of how much time and effort a design task will take me; I know my own working style very well. Up against a time crunch or deadline, I always reach out to seniors and managers, looking to brainstorm ways to be efficient within the boundaries we all have set.

If you need this done by X date, I need the time to do it. If that means I need to be heads down for a week with no other distractions, let’s communicate this priority to other teams and put some things on the back burner. Communication and knowing myself allows for healthy boundaries, less stress, and happy clients when the deliverable is done. I’ve even coached FTEs in the practice on this mindset when I’m called in to work with them to help them meet a deadline.

I sat in on sprint meetings as the experiences I designed were being build. I stress-tested the same builds on the QA server once the code was pushed. I logged 300+ bugs across 5+ flows, retesting each as fixes were pushed. I failed probably 75% of those fixes and found other other bugs to log. There’s no other way to put it: it was a lot of tedious work. There were a LOT of bugs. 

In crafting an MVP, any designer worth their salt will inevitably say to themselves “if we could have X feature here, this product would be awesome!” Thus, the ideal future state starts to form in their mind.

I kept documentation on features that were cut from MVP designs and “nice to have” elements of each flow. We brought topics to the research team at the bank, got survey data, asked care center employees questions, and sat and thought extensively about user journeys from task to task and flow to flow. I’ve synthesize research, wireframed iterations, and pitched ideas to experience design managers. I’ve gotten buy in for amazing improvements to future state. Mid-fidelity designs are ready for wider feedback as soon and the product teams are ready to circle back around post MVP. 

See, there is a little bit of a flaw in being too organized and capable… I was so effective and wonderful at managing and building the flow for the responsive website and then consulting on the design of the parallel experience for the mobile app that at one point someone said “Well, why don’t we just make Amelie the lead designer for the mobile app flow, too?”

So, I learned a new design library with a VERY different spacing and spec logic. And I took the expanded workload in stride. All in all, that means I worked across 3 products, 4 epics, and balanced 6+ flow logics at any given time over the course of 3 years with this banking client.