As our UX team of five designers and five front-end developers grew to support more feature teams, it became unclear who was working on what. Design requests were either skipped and brought up last minute or came with vague questions like, "What's your bandwidth?" To address this, I created a sprint-based assignment spreadsheet to clarify workloads and facilitate planning.

I asked Product Management to share desired work and high-level ideas before each sprint, enabling the director of front-end development and me to assign story point estimates. By summing story points and assessing capacity (accounting for PTO or other factors), we determined what fit above the "waterline" and allowed PMs to adjust priorities as needed. The spreadsheet streamlined resource allocation, balancing story points across team members and integrating design and front-end work. This process is documented in the following spreadsheet from 2022.

At Inxeption, our company held a multi-day summit to define our product’s focus. Coming out of the summit, we had the first two tabs of the spreadsheet below, but there was no concrete plan. When I hadn’t received updated goals, I took the initiative to compile a unified list of priorities and coordinate with a senior business leader to ensure alignment. Within two months, our design team had completed most initiatives, largely due to this clear, actionable prioritization (shown in the last two tabs).

In the fall of 2023, I became the sole platform designer left to support 16 developers, four product managers, and six QA testers while our second designer was on maternity leave. Because I like to be involved in my features, I was struggling to keep track of milestones:

• Whether developers were starting to code only based on Chief Architect engineering requirements, without a design handover

• Whether they had completed code without reviewing the UI with me

• Whether I or a PM had even seen it on QA before it went live

• Whether the feature had been demoed to the Product group so we all could keep up with platform changes

• Whether there were unresolved issues

The Product Management organization was stretched thin, juggling competing priorities, and some team members were relatively early in their careers. Recognizing an opportunity to bring order to the design pipeline, I created a comprehensive spreadsheet to track every feature I was aware of over a five-month period. Regularly reviewing the sheet with PMs not only kept me informed about up to 20 features at a time but also encouraged them to adopt and update the tracker themselves. This proactive solution highlights my ability to address pain points effectively and lead by example through detailed, consistent tracking.

One of the main projects in 2023 encountered numerous challenges due to loose requirements, lack of prioritization, and frequent turnover of product managers. The epics that captured this project work reflected that turbulent environment. After release, there were many interrelated bugs and stories logged in different projects and epics.

Because I was the only Product team member (of all the designers, product managers, engineers, or testers) consistently participating throughout the project and aware of the full vision, I was driven to help clean up the backlog and provide clear definition for future releases. I found all the tickets through four different queries and unified them into one list shown here, which helped the product manager at the time to define subsequent releases.

I created this calculator to determine whether a freight shipment with certain characteristics should be considered a less-than-truckload (LTL) shipment or a full truckload (FTL) shipment at checkout, which affects cost. The decision is based on the shipment's linear footage, which refers to how much of the length of a truck is taken up by a shipment. That calculation depends on the size of a single pallet of the product, how high pallets can be stacked, and whether they can be turned 90º to save space. Engineering and QA could plug in these parameters and verify whether LTL or FTL quotes were correctly returned by the code.

This calculator became a much-used resource for engineering and QA when implementing net and monthly payment terms, which could be applied independently for different products in the same quote (called "offers" here), with modifiers such as bulk discounts, offer-level discounts, shipping fee, and storage fee.

Retrospectives are an Agile ceremony that we used semi-regularly at Inxeption. I proposed the format that we used for several years, which is described in the first yellow sticky note below. Project Managment was the main owner of this ceremony. Design does not typically run this ceremony, but because I was senior and trusted enough to run processes for the entire Product org, I stepped in as needed. I ran this particular retro session, which entailed summarizing the release accomplishments (in yellow) to jog everyone's memory, reading every card to ensure clarity, keeping time, and leading the discussion on the top-voted cards to produce goals for future releases (in blue). This sample demonstrates my commitment to iterative improvement and ability to communicate with the entire Product org.