Product & UX Designer

Uma Shankar

I find where work breaks down for people — then design, and build, the fix. Based in India.

scroll

About Me

I start with the problem, not the screen.

A background in computer science lets me take an idea from research to a working prototype, and keeps me grounded in what is actually buildable. Two years in, I am still figuring plenty out — I would rather test an assumption than defend it. What I have learned so far is that the useful work usually happens before the visual design does: understanding the problem properly, and being willing to throw the first idea away.

Download Resume

2+: Years Experience
5+: Projects Completed
100%: Client Satisfaction

Skills & Capabilities

Tools and methodologies I use to bring ideas to life.

Project & Process

Problem Formulation
Stakeholder Communication
Cross-functional Collaboration
Process Improvement
Incident Triage

Design & Research

User Research
Usability Testing
Information Architecture
User Flows
Wireframing
Prototyping
Visual Design

Technical

HTML
CSS
Python
Git

Tools

Figma
Framer
Protopie
Figma Weave
Wonder
Lovable
Notion

How I Think

My product-thinking framework for ambiguous problems.

Frame the problem

Who is affected, what's happening, why it matters — before jumping to solutions.

Find the signal

Combine usage data, interviews, and support issues. Evidence over assumptions.

Define the opportunity

Turn observations into a focused “How might we” statement, rooted in the actual cause.

Prioritize before building

Impact × value × confidence × effort. One meaningful problem beats several small ones.

Explore multiple solutions

Generate options before committing. Look for the simplest change that shifts the outcome.

Test the riskiest assumption

Find what could make the idea fail, and validate that first.

Measure the outcome

Success isn't shipping — it's the behavior or business result defined up front.

Be curious before being certain. Understand before solving. Prioritize before building. Validate before scaling. Measure outcomes, not output.

When the problem is especially ambiguous

What do we know? → What are we assuming? → What don't we know? → What is the cheapest way to learn it? That keeps me moving without pretending to have certainty I don't have.