PM Dashboard AND REACT FRONT END
How I Structured a Project Management Product to Scale Without Constant Redesigns
Problem area
Surfacing critical vehicle decisions for EV fleet dispatchers
Services provided
Product design, Design system, React + Tailwind live demo
Deliverbales
React Components, Dashboard UX, Design System
This was project management tool used by teams coordinating real work in real time.
The product had grown feature by feature, with each addition solving a local problem but increasing global complexity.
The challenge wasn’t lack of functionality, it was making the system understandable, extendable, and reliable as usage expanded.
Constraints & Non-Negotiables
This work was not a clean-slate redesign. The product was already in use, workflows couldn’t be disrupted, and the system needed to support future features without rewriting existing foundations. Any solution had to balance clarity with continuity and avoid introducing new design debt.
This work was not a clean-slate redesign. The product was already in use, workflows couldn’t be disrupted, and the system needed to support future features without rewriting existing foundations. Any solution had to balance clarity with continuity and avoid introducing new design debt.
Process
The process centered on identifying repeatable patterns across workflows and resolving inconsistencies at the system level. Rather than solving problems screen by screen, decisions were tested against how they would scale as the product evolved. This reduced one-off solutions and made future work easier to reason about.
The process centered on identifying repeatable patterns across workflows and resolving inconsistencies at the system level. Rather than solving problems screen by screen, decisions were tested against how they would scale as the product evolved. This reduced one-off solutions and made future work easier to reason about.
Design Tokens
Tokens were used to separate design decisions from implementation. Core values like spacing, color, and states were defined at the system level so the product could evolve without breaking consistency or creating design debt.
Tokens were used to separate design decisions from implementation. Core values like spacing, color, and states were defined at the system level so the product could evolve without breaking consistency or creating design debt.
Components
Components were built as stable, reusable building blocks with clear roles and limits. This reduced one-off layouts, improved learnability for users, and made it easier to extend the product as new workflows were added.
Components were built as stable, reusable building blocks with clear roles and limits. This reduced one-off layouts, improved learnability for users, and made it easier to extend the product as new workflows were added.
System Thinking Over Screens
The focus wasn’t individual screens, but a system teams could rely on as complexity increased. By defining structure and constraints early, the product can change without becoming harder to use or maintain.
The focus wasn’t individual screens, but a system teams could rely on as complexity increased. By defining structure and constraints early, the product can change without becoming harder to use or maintain.
What This Prevented
More than anything, this system helped prevent slow, compounding problems. Redesign churn was avoided, feature expansion didn’t require rethinking existing screens, and users didn’t need to relearn the product every quarter. These are quiet wins, but they’re the difference between a product that scales and one that stalls.
More than anything, this system helped prevent slow, compounding problems. Redesign churn was avoided, feature expansion didn’t require rethinking existing screens, and users didn’t need to relearn the product every quarter. These are quiet wins, but they’re the difference between a product that scales and one that stalls.
Closing Thought
As PM products grow, complexity is inevitable, redesign churn is not. This work shows how defining structure early can keep teams shipping without constant rework. If you’re building an ops-heavy product and feel complexity creeping in, this is the kind of work I help founders with.
As PM products grow, complexity is inevitable, redesign churn is not. This work shows how defining structure early can keep teams shipping without constant rework. If you’re building an ops-heavy product and feel complexity creeping in, this is the kind of work I help founders with.
Project Inquieries
Let's talk about your project
You will (re)launch with a brand that builds trust, a website that books clients, social media guidance and templates that look consistent, and authority assets that position you to lead.
Project Inquieries
Let's talk about your project
You will (re)launch with a brand that builds trust, a website that books clients, social media guidance and templates that look consistent, and authority assets that position you to lead.
Project Inquieries
Let's talk about your project
You will (re)launch with a brand that builds trust, a website that books clients, social media guidance and templates that look consistent, and authority assets that position you to lead.
$8.6M
Raised after dashboard redesign @ Earth Force
25M
Users scaled via product redesign Bandsintown
$3.1M
Funded following mobile app redesign. Ecobot
4.9
App store rating post-redesign @ Ecobot
uxisaac™
Designing for founders who are serious about growth.