Apr 2025 - Present
Customer Portal -
Leading the foundational rebuild of a B2B portal
Rebuilding the foundation — and leading design — on a B2B portal in transition.
Stepping into a UX Lead role on the project I'd led as sole designer, and rebuilding the foundations to carry it through the next phase.
Previously, in Part 1: As a sole junior designer, I led the foundational design of MyGarage — the first version of this portal — through scope cuts, infrastructure constraints, and a 12-customer pilot launch. Read Part 1 →
14
different logins
73
customer-facing apps
Abstracted for NDA reasons.
Role
UX Lead
Started as the sole designer on the project; currently leading design efforts in a team of 3 designers (1 senior, 1 junior, + me).
Partners closely with Product Manager, Product Owner, and Lead Architect on day-to-day decisions, and aligning a broad set of internal stakeholders on the longer-term direction.
Company
Daimler Truck North America
Timeline
Apr 2025 - Present
Status
Active.
MVP scoped for beta launch mid to late-2026. Not public facing at release, as of now.
What changed in April 2025
By April 2025, MyGarage had reached its MVP Pilot launch. The 12 beta customers were onboarded, and the project had proven its core premise: that surfacing previously-scattered fleet data, on its own, would meaningfully change how customers worked.
What the project needed next was structure. Carrying it from a pilot product to a scaled platform required more than design and engineering — it needed broader product-strategy ownership, dedicated leadership for dealer and customer communications across the company, and a design team that could match the increased scope of the work. One designer carrying the full weight of the product made sense in Phase 1; it wouldn't make sense in Phase 2.
The org restructured the project around those needs. The PM and I advocated for me to lead design going forward, given my history with the product. The project was also renamed: MyGarage became “Customer Portal”, signaling internally that this was the next phase of the work, not a continuation of the prototype.
Foundational Problems
MyGarage made it to pilot, but the design underneath had been built one piece at a time, not as a system.
That was the right thing in Phase 1. As the sole designer, working through scope changes, infrastructure constraints, and stakeholder alignment in parallel, I designed patterns as the product needed them — not as part of a system, but in response to whatever the next problem was. The pieces, individually, were sound.
But these pieces didn't add up to a foundation. There was no shared visual system, no scaled IA logic, and no consistent template for the dozens of screen types the product would need as it grew. Every new feature added in Phase 2 would either reinforce a foundation or expose its absence. With more designers joining, the absence would get worse fast — three people inventing patterns in parallel is how products end up incoherent.
The 12-customer pilot had validated what mattered — urgent, action-driving data, surfaced with enough clarity that customers could spot what needed their attention. Phase 2 needed to be built on something that could carry a much larger surface area than the pilot had ever tested. That meant rebuilding the foundation before adding to it — visual system, IA, page templates, and the process by which all three would scale.
The team had adopted MUI as the underlying component system — chosen for accessibility coverage, speed of iteration, and the realistic alternative being a custom system we didn't have the time or headcount to build. Our most experienced senior designer took the lead to maintain and control the MUI design system for Customer Portal.
Decision: Rebuilding the foundation
The decision that shaped Phase 2 wasn't a feature call. It was the decision to rebuild the foundation before adding anything new.
I led the redesign of MyGarage's foundational structure — the underlying visual system, the information architecture, and the set of templates the rest of the portal would be built on top of. The goal wasn't to make the existing portal look different. It was to make sure that everything we shipped from this point on could be designed, reviewed, and extended against a shared standard — so that consistency wasn't something we'd have to fight for on every feature, and quality wasn't something that depended on which designer happened to pick up the work.
This mattered more in Phase 2 than it had in Phase 1. With one designer, consistency lives in the designer's head. With three, it has to live in the artifacts. Templates, patterns, and a shared IA were how the team could move in parallel without the product fragmenting underneath us.
The redesign drew from two sources. The first was the pilot itself — what customers had told us mattered (urgent, action-driving data) and how they'd actually behave in the portal in practice. Patterns that had worked in pilot stayed. Patterns that had been invented under pressure and didn't carry well were the first things to go. The second source was outside reference: how mature B2B portals in adjacent industries handle scale, density, and information hierarchy. We weren't trying to match anyone — we were trying to surface standards we couldn't have arrived at on our own.
The IA was the first major piece. I built the initial sitemap around the fleet as the customer's mental model — not around internal product structure or data sources. Customers think in terms of their trucks, their organization, and the things they need to keep moving; the navigation had to reflect that. The PM and PO refined the structure from there, adding the detailed data each page would surface and mapping every page back to the team that owned its underlying data.
The rest of the foundation — page templates, sub-page patterns, the standards the team would design against going forward — followed from those decisions.
Dashboard Layout
Subpage (Details)
Table List
Table List (w/ KPIs)
Full-page Modal (Settings)
Full-page Modal w/ complex actions
Leading the team
Stepping into the UX Lead role meant changing how I worked, not just what I worked on.
In Phase 1, leading the project and designing the project were the same job.
In Phase 2, they had to become different jobs — because trying to design every screen as a team of three would either burn me out or undermine the people I was meant to be leading. I let go of wanting to lead every design effort and trusted the other designers with their expertise.
The team structure helped. The senior designer took on the Design System Lead role, which gave him clear authority over the patterns, components, and consistency of the system itself. My authority was over the project — its direction, its priorities, and the final design decisions across features. Those two responsibilities didn't overlap, which meant we could move in parallel without stepping on each other. It also meant I was leading the senior designer on project work while learning from him on systems work, which turned out to be the most useful kind of stretch — I was doing more leading and more learning at the same time.
Day to day, leading the team looked like two different jobs depending on who I was working with.
With the senior designer, the work was mostly coordination — checking in when he requested feedback (most often for consistency against the foundational structure or for a second read on a UX call), keeping him looped into the project context he had missed by joining mid-stream, and learning and following his judgment on the system work that he led. With the junior designer, the work was developmental: helping him think through how to approach a new feature, how to break a problem down, and how to design with rationale he could defend in review. Mentoring a junior designer is a different muscle than designing yourself — and being conscious of that helped me do both better.
The process I established gave the team a clear path through each feature. PM and PO would shape the PRD → requirements would be handed off to the UX team → the UX supervisor and the rest of the team would discuss the details and assign the feature to one of the designers, including myself → the designer would prototype → we'd review for consistency and final decisions → then we'd review with PM, PO, and devs before handoff. Naming the process made it teachable, which mattered as the team grew into it.
What I learned
The biggest thing I'm learning is when not to design.
Going from sole designer to UX Lead means most of the design happening on the project isn't mine anymore. The work has shifted to setting the standard, making the call when it matters, and trusting the designers I'm leading to handle the rest. Some of that came naturally; the rest is still a deliberate practice — especially the part about resisting the pull to do everything myself, which is the muscle I built over two years and the one I now have to retrain.
I'm also learning that being led by someone more experienced and leading them are two things that have to happen at the same time. The senior designer's depth on systems work is something I'm actively learning from, while the project work is something I'm leading him through. Holding both at once has been the most significant and impactful learning so far in my career.
What I want this role to teach me is how to be the kind of lead I would have wanted as a junior — clear on direction, generous with rationale, and trusting of the people I'm working with. I'm still figuring out what that looks like.
Apr 2025 - Present
Customer Portal -
Leading the foundational rebuild of a B2B portal
Rebuilding the foundation — and leading design — on a B2B portal in transition.
Stepping into a UX Lead role on the project I'd led as sole designer, and rebuilding the foundations to carry it through the next phase.
Previously, in Part 1: As a sole junior designer, I led the foundational design of MyGarage — the first version of this portal — through scope cuts, infrastructure constraints, and a 12-customer pilot launch. Read Part 1 →
14
different logins
73
customer-facing apps
Abstracted for NDA reasons.
Role
UX Lead
Started as the sole designer on the project; currently leading design efforts in a team of 3 designers (1 senior, 1 junior, + me).
Partners closely with Product Manager, Product Owner, and Lead Architect on day-to-day decisions, and aligning a broad set of internal stakeholders on the longer-term direction.
Company
Daimler Truck North America
Timeline
Apr 2025 - Present
Status
Active.
MVP scoped for beta launch mid to late-2026. Not public facing at release, as of now.
What changed in April 2025
By April 2025, MyGarage had reached its MVP Pilot launch. The 12 beta customers were onboarded, and the project had proven its core premise: that surfacing previously-scattered fleet data, on its own, would meaningfully change how customers worked.
What the project needed next was structure. Carrying it from a pilot product to a scaled platform required more than design and engineering — it needed broader product-strategy ownership, dedicated leadership for dealer and customer communications across the company, and a design team that could match the increased scope of the work. One designer carrying the full weight of the product made sense in Phase 1; it wouldn't make sense in Phase 2.
The org restructured the project around those needs. The PM and I advocated for me to lead design going forward, given my history with the product. The project was also renamed: MyGarage became “Customer Portal”, signaling internally that this was the next phase of the work, not a continuation of the prototype.
Foundational Problems
MyGarage made it to pilot, but the design underneath had been built one piece at a time, not as a system.
That was the right thing in Phase 1. As the sole designer, working through scope changes, infrastructure constraints, and stakeholder alignment in parallel, I designed patterns as the product needed them — not as part of a system, but in response to whatever the next problem was. The pieces, individually, were sound.
But these pieces didn't add up to a foundation. There was no shared visual system, no scaled IA logic, and no consistent template for the dozens of screen types the product would need as it grew. Every new feature added in Phase 2 would either reinforce a foundation or expose its absence. With more designers joining, the absence would get worse fast — three people inventing patterns in parallel is how products end up incoherent.
The 12-customer pilot had validated what mattered — urgent, action-driving data, surfaced with enough clarity that customers could spot what needed their attention. Phase 2 needed to be built on something that could carry a much larger surface area than the pilot had ever tested. That meant rebuilding the foundation before adding to it — visual system, IA, page templates, and the process by which all three would scale.
The team had adopted MUI as the underlying component system — chosen for accessibility coverage, speed of iteration, and the realistic alternative being a custom system we didn't have the time or headcount to build. Our most experienced senior designer took the lead to maintain and control the MUI design system for Customer Portal.
Decision: Rebuilding the foundation
The decision that shaped Phase 2 wasn't a feature call. It was the decision to rebuild the foundation before adding anything new.
I led the redesign of MyGarage's foundational structure — the underlying visual system, the information architecture, and the set of templates the rest of the portal would be built on top of. The goal wasn't to make the existing portal look different. It was to make sure that everything we shipped from this point on could be designed, reviewed, and extended against a shared standard — so that consistency wasn't something we'd have to fight for on every feature, and quality wasn't something that depended on which designer happened to pick up the work.
This mattered more in Phase 2 than it had in Phase 1. With one designer, consistency lives in the designer's head. With three, it has to live in the artifacts. Templates, patterns, and a shared IA were how the team could move in parallel without the product fragmenting underneath us.
The redesign drew from two sources. The first was the pilot itself — what customers had told us mattered (urgent, action-driving data) and how they'd actually behave in the portal in practice. Patterns that had worked in pilot stayed. Patterns that had been invented under pressure and didn't carry well were the first things to go. The second source was outside reference: how mature B2B portals in adjacent industries handle scale, density, and information hierarchy. We weren't trying to match anyone — we were trying to surface standards we couldn't have arrived at on our own.
The IA was the first major piece. I built the initial sitemap around the fleet as the customer's mental model — not around internal product structure or data sources. Customers think in terms of their trucks, their organization, and the things they need to keep moving; the navigation had to reflect that. The PM and PO refined the structure from there, adding the detailed data each page would surface and mapping every page back to the team that owned its underlying data.
The rest of the foundation — page templates, sub-page patterns, the standards the team would design against going forward — followed from those decisions.
Dashboard Layout
Subpage (Details)
Table List
Table List (w/ KPIs)
Full-page Modal (Settings)
Full-page Modal w/ complex actions
Leading the team
Stepping into the UX Lead role meant changing how I worked, not just what I worked on.
In Phase 1, leading the project and designing the project were the same job.
In Phase 2, they had to become different jobs — because trying to design every screen as a team of three would either burn me out or undermine the people I was meant to be leading. I let go of wanting to lead every design effort and trusted the other designers with their expertise.
The team structure helped. The senior designer took on the Design System Lead role, which gave him clear authority over the patterns, components, and consistency of the system itself. My authority was over the project — its direction, its priorities, and the final design decisions across features. Those two responsibilities didn't overlap, which meant we could move in parallel without stepping on each other. It also meant I was leading the senior designer on project work while learning from him on systems work, which turned out to be the most useful kind of stretch — I was doing more leading and more learning at the same time.
Day to day, leading the team looked like two different jobs depending on who I was working with.
With the senior designer, the work was mostly coordination — checking in when he requested feedback (most often for consistency against the foundational structure or for a second read on a UX call), keeping him looped into the project context he had missed by joining mid-stream, and learning and following his judgment on the system work that he led. With the junior designer, the work was developmental: helping him think through how to approach a new feature, how to break a problem down, and how to design with rationale he could defend in review. Mentoring a junior designer is a different muscle than designing yourself — and being conscious of that helped me do both better.
The process I established gave the team a clear path through each feature. PM and PO would shape the PRD → requirements would be handed off to the UX team → the UX supervisor and the rest of the team would discuss the details and assign the feature to one of the designers, including myself → the designer would prototype → we'd review for consistency and final decisions → then we'd review with PM, PO, and devs before handoff. Naming the process made it teachable, which mattered as the team grew into it.
What I learned
The biggest thing I'm learning is when not to design.
Going from sole designer to UX Lead means most of the design happening on the project isn't mine anymore. The work has shifted to setting the standard, making the call when it matters, and trusting the designers I'm leading to handle the rest. Some of that came naturally; the rest is still a deliberate practice — especially the part about resisting the pull to do everything myself, which is the muscle I built over two years and the one I now have to retrain.
I'm also learning that being led by someone more experienced and leading them are two things that have to happen at the same time. The senior designer's depth on systems work is something I'm actively learning from, while the project work is something I'm leading him through. Holding both at once has been the most significant and impactful learning so far in my career.
What I want this role to teach me is how to be the kind of lead I would have wanted as a junior — clear on direction, generous with rationale, and trusting of the people I'm working with. I'm still figuring out what that looks like.
Apr 2025 - Present
Customer Portal -
Leading the foundational rebuild of a B2B portal
Rebuilding the foundation — and leading design — on a B2B portal in transition.
Stepping into a UX Lead role on the project I'd led as sole designer, and rebuilding the foundations to carry it through the next phase.
Previously, in Part 1: As a sole junior designer, I led the foundational design of MyGarage — the first version of this portal — through scope cuts, infrastructure constraints, and a 12-customer pilot launch. Read Part 1 →
14
different logins
73
customer-facing apps
Abstracted for NDA reasons.
Role
UX Lead
Started as the sole designer on the project; currently leading design efforts in a team of 3 designers (1 senior, 1 junior, + me).
Partners closely with Product Manager, Product Owner, and Lead Architect on day-to-day decisions, and aligning a broad set of internal stakeholders on the longer-term direction.
Company
Daimler Truck North America
Timeline
Apr 2025 - Present
Status
Active.
MVP scoped for beta launch mid to late-2026. Not public facing at release, as of now.
What changed in April 2025
By April 2025, MyGarage had reached its MVP Pilot launch. The 12 beta customers were onboarded, and the project had proven its core premise: that surfacing previously-scattered fleet data, on its own, would meaningfully change how customers worked.
What the project needed next was structure. Carrying it from a pilot product to a scaled platform required more than design and engineering — it needed broader product-strategy ownership, dedicated leadership for dealer and customer communications across the company, and a design team that could match the increased scope of the work. One designer carrying the full weight of the product made sense in Phase 1; it wouldn't make sense in Phase 2.
The org restructured the project around those needs. The PM and I advocated for me to lead design going forward, given my history with the product. The project was also renamed: MyGarage became “Customer Portal”, signaling internally that this was the next phase of the work, not a continuation of the prototype.
Foundational Problems
MyGarage made it to pilot, but the design underneath had been built one piece at a time, not as a system.
That was the right thing in Phase 1. As the sole designer, working through scope changes, infrastructure constraints, and stakeholder alignment in parallel, I designed patterns as the product needed them — not as part of a system, but in response to whatever the next problem was. The pieces, individually, were sound.
But these pieces didn't add up to a foundation. There was no shared visual system, no scaled IA logic, and no consistent template for the dozens of screen types the product would need as it grew. Every new feature added in Phase 2 would either reinforce a foundation or expose its absence. With more designers joining, the absence would get worse fast — three people inventing patterns in parallel is how products end up incoherent.
The 12-customer pilot had validated what mattered — urgent, action-driving data, surfaced with enough clarity that customers could spot what needed their attention. Phase 2 needed to be built on something that could carry a much larger surface area than the pilot had ever tested. That meant rebuilding the foundation before adding to it — visual system, IA, page templates, and the process by which all three would scale.
The team had adopted MUI as the underlying component system — chosen for accessibility coverage, speed of iteration, and the realistic alternative being a custom system we didn't have the time or headcount to build. Our most experienced senior designer took the lead to maintain and control the MUI design system for Customer Portal.
Decision: Rebuilding the foundation
The decision that shaped Phase 2 wasn't a feature call. It was the decision to rebuild the foundation before adding anything new.
I led the redesign of MyGarage's foundational structure — the underlying visual system, the information architecture, and the set of templates the rest of the portal would be built on top of. The goal wasn't to make the existing portal look different. It was to make sure that everything we shipped from this point on could be designed, reviewed, and extended against a shared standard — so that consistency wasn't something we'd have to fight for on every feature, and quality wasn't something that depended on which designer happened to pick up the work.
This mattered more in Phase 2 than it had in Phase 1. With one designer, consistency lives in the designer's head. With three, it has to live in the artifacts. Templates, patterns, and a shared IA were how the team could move in parallel without the product fragmenting underneath us.
The redesign drew from two sources. The first was the pilot itself — what customers had told us mattered (urgent, action-driving data) and how they'd actually behave in the portal in practice. Patterns that had worked in pilot stayed. Patterns that had been invented under pressure and didn't carry well were the first things to go. The second source was outside reference: how mature B2B portals in adjacent industries handle scale, density, and information hierarchy. We weren't trying to match anyone — we were trying to surface standards we couldn't have arrived at on our own.
The IA was the first major piece. I built the initial sitemap around the fleet as the customer's mental model — not around internal product structure or data sources. Customers think in terms of their trucks, their organization, and the things they need to keep moving; the navigation had to reflect that. The PM and PO refined the structure from there, adding the detailed data each page would surface and mapping every page back to the team that owned its underlying data.
The rest of the foundation — page templates, sub-page patterns, the standards the team would design against going forward — followed from those decisions.
Dashboard Layout
Subpage (Details)
Table List
Table List (w/ KPIs)
Full-page Modal (Settings)
Full-page Modal w/ complex actions
Leading the team
Stepping into the UX Lead role meant changing how I worked, not just what I worked on.
In Phase 1, leading the project and designing the project were the same job.
In Phase 2, they had to become different jobs — because trying to design every screen as a team of three would either burn me out or undermine the people I was meant to be leading. I let go of wanting to lead every design effort and trusted the other designers with their expertise.
The team structure helped. The senior designer took on the Design System Lead role, which gave him clear authority over the patterns, components, and consistency of the system itself. My authority was over the project — its direction, its priorities, and the final design decisions across features. Those two responsibilities didn't overlap, which meant we could move in parallel without stepping on each other. It also meant I was leading the senior designer on project work while learning from him on systems work, which turned out to be the most useful kind of stretch — I was doing more leading and more learning at the same time.
Day to day, leading the team looked like two different jobs depending on who I was working with.
With the senior designer, the work was mostly coordination — checking in when he requested feedback (most often for consistency against the foundational structure or for a second read on a UX call), keeping him looped into the project context he had missed by joining mid-stream, and learning and following his judgment on the system work that he led. With the junior designer, the work was developmental: helping him think through how to approach a new feature, how to break a problem down, and how to design with rationale he could defend in review. Mentoring a junior designer is a different muscle than designing yourself — and being conscious of that helped me do both better.
The process I established gave the team a clear path through each feature. PM and PO would shape the PRD → requirements would be handed off to the UX team → the UX supervisor and the rest of the team would discuss the details and assign the feature to one of the designers, including myself → the designer would prototype → we'd review for consistency and final decisions → then we'd review with PM, PO, and devs before handoff. Naming the process made it teachable, which mattered as the team grew into it.
What I learned
The biggest thing I'm learning is when not to design.
Going from sole designer to UX Lead means most of the design happening on the project isn't mine anymore. The work has shifted to setting the standard, making the call when it matters, and trusting the designers I'm leading to handle the rest. Some of that came naturally; the rest is still a deliberate practice — especially the part about resisting the pull to do everything myself, which is the muscle I built over two years and the one I now have to retrain.
I'm also learning that being led by someone more experienced and leading them are two things that have to happen at the same time. The senior designer's depth on systems work is something I'm actively learning from, while the project work is something I'm leading him through. Holding both at once has been the most significant and impactful learning so far in my career.
What I want this role to teach me is how to be the kind of lead I would have wanted as a junior — clear on direction, generous with rationale, and trusting of the people I'm working with. I'm still figuring out what that looks like.