Nelson Sharma
Design Manager — UX systems, DesignOps, and design engineering
I lead multidisciplinary design teams and build the systems that help good work ship: clear ownership, strong standards, and enough hands-on frontend work to keep decisions real.
Leading a 10-person design team on a product used by 3.2M+ people.
Remote
-
7.3yrs
In
Design -
2.6yrs
In
Leadership -
10
People on
the team -
5
Design
Domains
From designer to managing designers.
I started by learning how to make good work. Then I learned how to create the conditions for other people to make it.
-
01
Graphic designer
I learned to make.
- Brand
- Campaigns
- Visual communication
- Visual craft
- Composition
- Typography
- Image
-
02
UI designer
I learned to design for screens.
- Websites
- Interfaces
- Interaction
- Design systems
- Interface
- System
- Interaction
-
03
Design manager
I learned to make space.
- People
- Ownership
- Systems
- Operations
- Team
- Environment
- Operating model
-
Today
- 10 designers
- 5 crafts
- 2.6 years leading
I didn’t leave the craft when I took the title.
I have 7.3 years in design and 2.6 years in leadership, currently leading a 10-person multidisciplinary team across product, social, web, presentation, and illustration. My job is to create the conditions for good work: clear ownership, useful systems, practical operations, and enough proximity to the frontend to keep decisions honest.
-
Five crafts, one bar
Product, social, web, presentation, illustration. All under one umbrella, held to one written standard, so “good” doesn’t depend on who happened to review it.
-
Into the frontend
Design systems, HTML and SCSS, shipped into the product. It keeps me honest about what I design.
-
Agents take the tedious half
First drafts and scaffolding go to the machines. Judgement stays with people.
Tools I use
Fluent across the workbench.
I move between product thinking, visual craft, prototyping, presentation, and implementation without handing the work off at the seams.
- FigmaFluent
- SketchFluent
- Claude CodeFluent
- CodexFluent
- FramerFluent
- Adobe PhotoshopFluent
- Adobe IllustratorFluent
- Adobe InDesignFluent
- KeynoteFluent
- PowerPointFluent
Most design problems aren’t design problems.
Good design work breaks down when ownership is unclear, priorities shift, and every decision needs approval. These six pieces show how I fix the conditions around the work.
-
I turned a Git repo into a team OS.
Work, OKRs, availability, AI skills, assets and team history, all version-controlled in one shared workspace.
Shared context without depending on individuals
-
Everyone has a backup. Nobody staffs the third layer.
Assigning designers to domains is what every team does. Staffing the layer under the backup is not.
Resilient coverage without manager dependency
-
Intake, and the polite art of moving a date.
If everything is urgent, nothing is planned. Six fields and published turnaround times, so an estimate is agreed once rather than renegotiated every time.
Predictable workload, no deadline crunch
-
Velocity and peer review, running continuously.
Two angles: what shipped, and how it was to work with. Taste stays out of it, and the team sets the weights rather than me.
Stronger judgement without manager bottlenecks
-
The annual review as reconciliation.
A year of data we both already have, so the fourth quarter counts for exactly as much as the first.
Designers growing into greater ownership
-
I went first, and got audited hardest.
Engineering and I wrote the rules before designers got access. The point was not making everyone use AI; it was knowing when to stop.
Agents in the codebase without designers carrying the risk
Hands-on
Still building.
Recent work across systems, accessibility and responsive product experiences, shaped with the same hands-on curiosity that got me into design.
-
Design system
One design system for a 13-year-old product.
A design system shouldn’t require tribal knowledge. 8,375 hardcoded values, including 23 different off-whites, consolidated into 243 tokens that designers and engineers both build from, and that outlive the people who wrote them.
Read the case study -
Accessibility & usability
Making an enterprise product usable, not just consistent.
Accessibility isn’t a checklist at the end; it is a signal the system isn’t doing enough thinking for the people using it. Audited the four highest-traffic areas, shipped the fixes, then fed each one back into the system that kept producing them.
Read the case study -
Mobile & tablet
Bringing a desktop-era platform to phones and tablets.
“Responsive” didn’t mean the product made sense on a phone. Wrote the mobile layer it never had — 89 commits across 647 files in about seven weeks — starting with the fact that the TypeScript and the CSS disagreed about what mobile meant.
Read the case study -
Product concept & build
Turning catalogue onboarding into a self-serve product.
A client-facing catalogue that replaces static PDFs and email rounds with branded previews, clear choices, and a build-ready brief for production.
Read the case study