Greenworks Tools
Global leader in battery-powered outdoor power equipment, pioneering cordless technology to replace gas-powered tools.
For over 20 years, the brand has focused on
high-performance, sustainable solutions that deliver professional-grade power with lower maintenance, lower emissions, and smarter energy use.
1000+
Patents Published
500+
Product Catalogue
4
Business Verticals
The Team
Senior VP of Sales
IT E-Commerce Manager
Digital Marketing Coordinator
Tech Lead
Director of Category Management
Sr. Director of Digital Channels & E-Commerce
Senior Content Leader
Senior Lead UX Designer
Digital Marketing Manager
Goals
Conversion Rate
discovery,
purchase, and
post-purchase journeys
Retention &
Engagement
stronger account, ownership, and
lifecycle experiences
Platform velocity & scalability
shared systems, patterns, and reusable components
Friction points
across path
unifying flows and reducing cross-platform inconsistencies
Time to decision
faster discovery,
clearer decision-making, and streamlined actions
Support dependency
improving self-service flows and ownership tools
The Context
What I Walked Into
When I joined, UX was still taking shape across the organization. Teams were moving fast, priorities shifted often, and experience decisions were largely reactive.
There was no shared UX language, no predictable process, and no clear understanding of how design fit into business
decision-making.
Instead of a single “problem,”
I encountered ambient ambiguity.
What I Started Hearing
As I worked closely with different teams, similar frustrations surfaced—expressed differently,
but rooted in the same gaps.
We don’t know which designs are final vs exploratory
Do we even need
UX?
UX changes late and slows delivery.
We need to move faster, but consistency keeps breaking.
The only thing that matters is
Profits!
It’s hard to tie UX work to business impact.
We’re solving the same problems again and again.
There’s no shared standard or decision framework.
We know we need to work on UX, but where do we start???
We have huge inventory on the website?
How do we know what the user wants?
What I Realized
The challenge wasn’t resistance to UX.
It was the absence of structure.
UX needed to move from
helpful but optional to
predictable and trusted.
Teams wanted clarity:
When should
UX be involved?
What does “good UX” mean here?
How do we make decisions consistently?
How do we know we’re improving?
The Shift
Instead of asking,
“What should I design?”
I started asking,
“What system would make a better design inevitable?”
Building the Foundation
UX Culture & Education
Early on, I noticed that most UX friction wasn’t about disagreement—it was about misunderstanding.
-
Engineers weren’t sure why certain UX decisions mattered
-
Stakeholders interpreted UX feedback as subjective
-
Designers had to re-explain the rationale repeatedly
This told me the issue wasn’t skill—it was shared context.
I realized UX needed to function as a shared language, not a specialized function.
This emerged to:
-
Create common principles that teams could reference
-
Make design rationale explicit and reusable
-
Build trust by demystifying UX decisions
UX couldn’t scale without shared understanding.
Business Alignment
In a fast-moving environment, decisions were often made based on:
-
Past experience
-
Strong opinions
-
Time pressure
Even strong UX ideas stalled when they weren’t clearly tied to business outcomes.
I began reframing UX conversations away from features and toward: Goals, Trade-offs, Impact
Ensuring that:
-
UX decisions mapped to business priorities
-
Stakeholders saw design as a strategic lever
-
Success could be discussed in terms of leadership that cared about
UX needed to speak the language of the business to earn influence.
Research-Driven Decisions
I repeatedly heard variations of:
-
“How does this help the business?”
-
“Is this worth prioritizing right now?”
This created inconsistency and repeated debates.
Instead of positioning research as a “phase,”
I treated it as decision support.
This supports to:
-
Reduce opinion-led back-and-forth
-
Ground discussions in observable behavior
-
Create confidence when trade-offs were necessary
Research wasn’t about validation—it was about clarity.
Cross-Channel Ideation
I noticed teams were solving problems in isolation:
-
Web decisions didn’t consider app implications
-
Purchase experiences didn’t connect to ownership
-
Lifecycle touchpoints were treated as afterthoughts
This fragmented the user experience.
I began stepping back and asking:
-
“Where does this experience start?”
-
“Where does it actually end?”
This helped:
-
Break channel silos
-
Encourage end-to-end journey thinking
-
Ensure experiences felt cohesive, not stitched together
Users don’t experience products in channels — they experience journeys.
Roadmap & Scale
Even when alignment existed, I saw good ideas fail because:
-
Everything felt equally important
-
Teams lacked sequencing
-
UX work reacted to roadmaps instead of shaping them
I started focusing less on what we should design and more on when and why.
This helped to:
-
Size opportunities realistically
-
Balance quick wins with foundational work
-
Ensure UX decisions aged well as the platform grew
Good UX at scale is as much about timing as it is about quality.
Global leader in battery-powered outdoor power equipment, pioneering cordless technology to replace gas-powered tools.
For over 20 years, the brand has focused on
high-performance, sustainable solutions that deliver professional-grade power with lower maintenance, lower emissions, and smarter energy use.
1000+
Patents Published
500+
Product Catalogue
4
Business Verticals
Strategic Pillars
Business
Alignment
Goals → Experience strategy
Stakeholder vision
KPI focus
UX Culture & Education
Shared principles
Design rationale
Cross-functional trust
Research driven Decisions
Audits
Behavioral insights User feedback loops
Roadmap & Scale
Opportunity sizing Sequencing
Platform scalability
Cross-channel
Ideation
Web + App + Lifecycle
End-to-end journeys
So teams had a common language and reference point.
So design decisions were grounded in impact, not preference.
To reduce
assumption-led execution.
So collaboration felt stable instead of disruptive.
Making Structure Real
The UX Operating Rhythm
Weekly
SUNDAY
MONDAY
TUESDAY
WEDNESDAY
THURSDAY
FRIDAY
SATURDAY
Focused design reviews using shared criteria
Design Documentation for exploratory vs final
Daily Huddle with Developers
Monthly
SUNDAY
MONDAY
TUESDAY
WEDNESDAY
THURSDAY
FRIDAY
SATURDAY
Week1
Experience Quality Review
Reviewed shipped and
in-progress work to assess clarity, consistency, and adherence to shared UX principles.
Pattern & System Review
Identified repeated solutions and one-off implementations to inform design system updates and reduce future rework.
Cross-Functional Alignment Check-ins
Aligned Design, Product, and Engineering on priorities, trade-offs, and upcoming decisions.
Research & Insight Synthesis
Shared key behavioral insights, audit findings, and feedback to inform upcoming sprints and roadmap decisions.
Week2
Week3
Week4
Business Impact Review
Connected UX work to business goals, surfacing where experience decisions influenced conversion, retention, or efficiency.
Process & Collaboration Health
Evaluated how well UX was integrated into sprint workflows and identified improvements for the next cycle.
Where I Faced the Most Friction
Balancing short-term delivery pressure with long-term system thinking
Proving value before metrics were mature
Gaining alignment without formal authority
Introducing structure without slowing teams down
I addressed these by:
Anchoring conversations around outcomes, not artifacts
Embedding system work inside active projects
Prioritizing adoption over perfection
Instead of reviewing screens in isolation, I framed discussions around what problem we were solving and how success would be measured.
For example, PLP and PDP reviews focused on reducing decision friction and improving product clarity, rather than visual polish or layout preferences.
Rather than treating the design system as a parallel initiative, I built and validated components while working on high-impact flows like PLP, PDP,
and Account.
This allowed the system to evolve from real usage and ensured immediate adoption without slowing delivery.
I intentionally shipped a smaller, opinionated set of components that teams could trust and reuse, instead of waiting to build a “complete” system.
Feedback from designers and engineers guided incremental improvements, making the system feel practical rather than aspirational.
Measuring progress through behavioral signals, not vanity metrics
In the absence of mature UX metrics, I tracked indicators like reduced clarification cycles, increased component reuse, earlier UX involvement in planning, and fewer repeated debates—signals that UX was becoming more predictable and trusted.
Measuring Progress
Fewer repeated UX debates
“We’ve already aligned on this pattern — let’s use the system instead of reopening the discussion.”
Increased reuse of patterns and decisions
“We used the same component from PLP in Account — it worked without changes.”
Teams proactively asking how to apply UX
“Which UX principle should guide this decision?”
“Is there a recommended pattern we should start from?”
Faster design and engineering alignment
“This makes sense — we can build it as-is without needing another round of clarification.”
Clearer linkage between UX work and business priorities
“This makes sense — we can build it as-is without needing another round of clarification.”
The Team
Senior VP of Sales
IT E-Commerce Manager
Tech Lead
Digital Marketing Coordinator
Sr. Director of Digital Channels & E-Commerce
Director of Category Management
Senior Content Leader
Senior Lead UX Designer
That's me!
Digital Marketing Manager
Goals
Conversion
Rate
discovery
purchase
post-purchase journeys
Friction points
across path
unifying flows and reducing cross-platform inconsistencies
Retention &
Engagement
stronger account ownership
lifecycle experiences
Time to decision
faster discovery,
clearer decision-making, and streamlined actions
Platform velocity & scalability
shared systems patterns
reusable components
Support dependency
improving self-service flows and ownership tools
The Context
What I Walked Into
When I joined, UX was still taking shape across the organization. Teams were moving fast, priorities shifted often, and experience decisions were largely reactive.
There was no shared UX language, no predictable process, and no clear understanding of how design fit into business
decision-making.
Instead of a single “problem,”
I encountered ambient ambiguity.
What I Heard?
As I worked closely with different teams, similar frustrations surfaced—expressed differently,
but rooted in the same gaps.
🤔 How do we know what the user wants?
😩 We’re solving the same problems again and again.
😕 We don’t know which designs are
final vs exploratory.
😖 There’s no shared standard or decision
framework.
😤 We need to move faster, but consistency keeps breaking.
😵💫 We know we need to work on UX, but where do we start???
🤑 The only thing that matters is - Profits!
😐 Do we even need UX? It gives slow delivery.
😳 We have huge inventory on the website?
😓 It’s hard to tie UX work to business impact.
What I Realized
Teams wanted clarity:
The challenge wasn’t resistance to UX.
It was the absence of structure.
When should
UX be involved?
How do we make decisions consistently?
UX needed to move from
helpful but optional to
predictable and trusted.
What does “good UX” mean here?
How do we know we’re improving?
The Shift
Instead of asking,
“What should I design?”
I started asking,
“What system would make a better design inevitable?”
Building the Foundation
01 UX Culture & Education
Early on, I noticed that most UX friction wasn’t about disagreement—it was about misunderstanding.
-
Engineers weren’t sure why certain UX decisions mattered
-
Stakeholders interpreted UX feedback as subjective
-
Designers had to re-explain the rationale repeatedly
This told me the issue wasn’t skill—it was shared context.
I realized UX needed to function as a shared language, not a specialized function.
This emerged to:
-
Create common principles that teams could reference
-
Make design rationale explicit and reusable
-
Build trust by demystifying UX decisions
UX couldn’t scale without shared understanding.
02 Business Alignment
In a fast-moving environment, decisions were often made based on:
-
Past experience
-
Strong opinions
-
Time pressure
Even strong UX ideas stalled when they weren’t clearly tied to business outcomes.
I began reframing UX conversations away from features and toward: Goals, Trade-offs, Impact
Ensuring that:
-
UX decisions mapped to business priorities
-
Stakeholders saw design as a strategic lever
-
Success could be discussed in terms of leadership that cared about
UX needed to speak the language of the business to earn influence.
03 Research-Driven Decisions
I repeatedly heard variations of:
-
“How does this help the business?”
-
“Is this worth prioritizing right now?”
This created inconsistency and repeated debates.
Instead of positioning research as a “phase,”
I treated it as decision support.
This supports to:
-
Reduce opinion-led back-and-forth
-
Ground discussions in observable behavior
-
Create confidence when trade-offs were necessary
Research wasn’t about validation—it was about clarity.
04 Cross-Channel Ideation
I noticed teams were solving problems in isolation:
-
Web decisions didn’t consider app implications
-
Purchase experiences didn’t connect to ownership
-
Lifecycle touchpoints were treated as afterthoughts
This fragmented the user experience.
I began stepping back and asking:
-
“Where does this experience start?”
-
“Where does it actually end?”
This helped:
-
Break channel silos
-
Encourage end-to-end journey thinking
-
Ensure experiences felt cohesive, not stitched together
Users don’t experience products in channels — they experience journeys.
05 Roadmap & Scale
Even when alignment existed, I saw good ideas fail because:
-
Everything felt equally important
-
Teams lacked sequencing
-
UX work reacted to roadmaps instead of shaping them
I started focusing less on what we should design and more on when and why.
This helped to:
-
Size opportunities realistically
-
Balance quick wins with foundational work
-
Ensure UX decisions aged well as the platform grew
Good UX at scale is as much about timing as it is about quality.
Making Structure Real: The UX Operating Rhythm
Weekly
SUNDAY
MONDAY
TUESDAY
WEDNESDAY
THURSDAY
FRIDAY
SATURDAY
Focused design reviews using shared criteria
Design Documentation for exploratory vs final
Daily Huddle with Developers
Monthly
SUNDAY
MONDAY
TUESDAY
WEDNESDAY
THURSDAY
FRIDAY
SATURDAY
Week1
Experience Quality Review
Reviewed shipped and
in-progress work to assess clarity, consistency, and adherence to shared UX principles.
Pattern & System Review
Identified repeated solutions and one-off implementations to inform design system updates and reduce future rework.
Cross-Functional Alignment Check-ins
Aligned Design, Product, and Engineering on priorities, trade-offs, and upcoming decisions.
Research & Insight Synthesis
Shared key behavioral insights, audit findings, and feedback to inform upcoming sprints and roadmap decisions.
Week2
Week3
Business Impact Review
Connected UX work to business goals, surfacing where experience decisions influenced conversion, retention, or efficiency.
Process & Collaboration Health
Evaluated how well UX was integrated into sprint workflows and identified improvements for the next cycle.
Week4
Where I Faced the Most Friction
01
Balancing short-term delivery pressure with long-term system thinking
02
Gaining alignment without formal authority
03
Proving value before metrics were mature
04
Introducing structure without slowing teams down
I addressed these by:
Anchoring conversations around outcomes, not artifacts
Instead of reviewing screens in isolation, I framed discussions around what problem we were solving and how success would be measured.
For example, PLP and PDP reviews focused on reducing decision friction and improving product clarity, rather than visual polish or layout preferences.
Embedding system work inside active projects
Rather than treating the design system as a parallel initiative, I built and validated components while working on high-impact flows like PLP, PDP,
and Account.
This allowed the system to evolve from real usage and ensured immediate adoption without slowing delivery.
Prioritizing adoption over perfection
I intentionally shipped a smaller, opinionated set of components that teams could trust and reuse, instead of waiting to build a “complete” system.
Feedback from designers and engineers guided incremental improvements, making the system feel practical rather than aspirational.
Measuring progress through behavioral signals, not vanity metrics
In the absence of mature UX metrics, I tracked indicators like reduced clarification cycles, increased component reuse, earlier UX involvement in planning, and fewer repeated debates—signals that UX was becoming more predictable and trusted.
Measuring Progress
Fewer repeated UX debates
“We’ve already aligned on this pattern — let’s use the system instead of reopening the discussion.”
Increased reuse of patterns and decisions
“We used the same component from PLP in Account — it worked without changes.”
Teams proactively asking how to apply UX
“Which UX principle should guide this decision?”
“Is there a recommended pattern we should start from?”
Faster design and engineering alignment
“This makes sense — we can build it as-is without needing another round of clarification.”
Clearer linkage between UX work and business priorities
“This makes sense — we can build it as-is without needing another round of clarification.”
Explore More
What I Looked At First
Before proposing solutions, I stepped back and audited the experience across high-impact areas like PLP, PDP, Account, and App.
1
The same UI elements behaved differently across surfaces
2
Teams rebuilt similar components multiple times
3
Interaction states weren’t clearly defined
4
Simple changes required heavy design–engineering coordination
Greenworks Design System
Legacy Design System
(Project to Project)
UI Kits
These weren’t isolated UX issues—they were
symptoms of missing shared foundations.
The Atomic Approach
Designing the System
With strong foundations in place, the next challenge was creating a system that could scale without becoming rigid.
I used an atomic design mindset—not as a framework to follow blindly, but as a way to bring clarity and structure to increasing complexity.
The goal was simple: make the system easy to understand, easy to adopt, and easy to grow.
1
Architecture
I first defined how the system would scale across products and platforms, both web and app—so that components weren’t designed in isolation.
This ensured decisions at the smallest level supported consistency at the experience level.
Teams could design and build with confidence, knowing components would work across multiple contexts.
2
Atoms
I standardized the most fundamental elements—colors, typography, spacing, and interaction states—to remove ambiguity early.
These became the non-negotiables that anchored visual and behavioral consistency.
Small inconsistencies stopped compounding into larger experience issues.
3
Molecules
I combined atoms into common UI building blocks like inputs, buttons, and cards—patterns teams were repeatedly redesigning.
These molecules reflected real usage scenarios rather than abstract components.
Designers and developers stopped reinventing the same solutions, sprint after sprint.
.png)
4
Organisms
I then composed molecules into reusable sections used across PLP, PDP, and Account flows.
These organisms captured higher-level intent—how content, actions, and hierarchy worked together in real journeys.
Teams could move faster without sacrificing coherence across critical experiences.
5
File Distribution & Structure
Finally, I organized files and naming conventions so the system was easy to navigate and reuse.
Clear structure reduced friction in day-to-day work and made the system approachable for new team members.
Adoption increased when teams could quickly find and apply what they needed.
GW Design System(App)
Legacy Design System
Multiple UI Kits
Developer Notes
Greenworks Design System
How to Guides
Laying the Foundation
Before building components or defining a system, I deliberately slowed down to focus on the fundamentals. In an environment with growing complexity, jumping straight into solutions would have only scaled existing problems.
This phase was about building shared understanding before shared components.
Research & UX Audits
I conducted UX audits across high-impact surfaces to identify where patterns were breaking, which interactions were repeatedly redesigned, and where users faced unnecessary friction.
These findings helped separate one-off issues from systemic problems and informed what truly needed to be standardized.
What this solved: Reduced guesswork and ensured the system addressed real, recurring issues—not assumptions.
Accessibility-First Thinking
Instead of treating accessibility as a checklist or a later pass,
I embedded it into foundational decisions—color contrast, typography scales, focus states, and interaction feedback.
This ensured inclusivity was part of the system’s DNA, not something teams had to remember to add later.
What this solved: Prevented accessibility regressions and reduced rework caused by retrofitting fixes.
Material Design as a Baseline
I used Material Design principles as a reference point, not to copy them, but to ground the system in proven patterns around hierarchy, spacing, motion, and feedback.
This gave teams a familiar mental model while allowing flexibility for brand and product-specific needs.
What this solved: Improved predictability and reduced subjective debates around basic UI behavior.
Ongoing Communication with Developers
I worked closely with developers throughout this phase to understand existing architecture, constraints, and implementation patterns.
Regular conversations helped ensure the system aligned with how the product was actually built, not just how it was designed.
What this solved: Increased feasibility, reduced handoff friction, and built early trust in the system.
By grounding the design system in research, accessibility, proven principles, and developer realities, this phase created alignment before artifacts.
It ensured the system would be useful, adoptable, and scalable, rather than theoretically correct but practically ignored.
Hello there! I am
.png)
.jpg)
I bring clarity to complex problems and design with intent,
using strategy, research, and design thinking
to create lasting user and business value.
Key Collaborations
How I Approached It
I treated the design system as UX infrastructure,
not a visual cleanup.
Instead of starting with components, I focused on:
What decisions teams were repeatedly struggling with
Which patterns showed up across critical journeys
How to make UX easier to use, not harder to follow
Hello there! I am
I bring clarity to complex problems and design with intent,
using strategy, research, and design thinking
to create lasting user and business value.
Key Collaborations