Interning at Uzence Design Studio

Interning at Uzence Design Studio

A year inside a design studio being built from scratch
A year inside a design studio being built from scratch
Company/
Uzence Design Studio
Role/
UI-UX Design Intern
Duration/
June 2025 - Present

/context

I spent a year inside a design system being built from nothing. Auditing components, leading a team, fixing sprint blockers, writing code. Working at a startup teaches you how things actually get built — and I got to see all of it.

/the internship

I finished my Bachelor's in CS in May 2025. A month later, I joined Uzence Design Studio — a startup design agency based in Bengaluru, building a design system from scratch. Talented team, fully remote. Good place to start.

/Auditing Design System Components

The first thing I did at Uzence was auditing components the team was building.


25+ components — checking consistency, spacing, responsiveness, whether things matched industry standards. More than 50% had issues. I'd flag them in Figma or reach out directly, they'd fix it, I'd recheck.

Variants

Wrong states, missing sizes, mismatched styles across similar components

Responsiveness

Things that broke or looked off on smaller screens

Accessibility

Contrast, focus states, label clarity — checked against WCAG guidelines

Consistency

Did it feel like one system, or a bunch of components that just coexist
By the end I'd studied every component state, every edge case, every breakpoint. Auditing someone else's work forces you to understand it deeply. I studied each component — states, variants, edge cases, how it behaves across breakpoints. It gave me a strong foundation in component anatomy and design token application before I ever built anything myself.
By the end I'd studied every component state, every edge case, every breakpoint. Auditing someone else's work forces you to understand it deeply. I studied each component — states, variants, edge cases, how it behaves across breakpoints. It gave me a strong foundation in component anatomy and design token application before I ever built anything myself.

/Leading the Documentation

After auditing, I moved into documentation. 50+ components, 4 people, fully remote.


Before we started, I built a documentation template — structure, rules, what each section needed to cover. Shared it in a sync, kept updating it as we went. Every morning we'd check in — blockers, progress, anything needing dev input. I was the middle point. The goal was simple: four people writing docs that feel like one system.

Keeping that consistency across four people taught me that when you're coordinating people, clarity is the actual job. Vague direction creates rework. Building the template first forced me to think about information hierarchy and consistency at a system level — not just component by component.
Keeping that consistency across four people taught me that when you're coordinating people, clarity is the actual job. Vague direction creates rework. Building the template first forced me to think about information hierarchy and consistency at a system level — not just component by component.
Keeping that consistency across four people taught me that when you're coordinating people, clarity is the actual job. Vague direction creates rework. Building the template first forced me to think about information hierarchy and consistency at a system level — not just component by component.

/the Button Variant Problem

Button was the most complex component in the system — states, sizes, shapes, styles, appearances, all combinations. Another team was stuck on how to map it all out. They approached all the teams for a solution.


I took some time, thought it through, and proposed a matrix — mapping every appearance against every other variable to make sure no combination was missed. They used it. 1,000+ button states documented. Dev handoff went out 3 days later, unblocking the sprint.

That's when it clicked for me - a structured approach to complexity saves more time than any shortcut. The matrix wasn't a design decision — it was a systems thinking one. That distinction stuck with me.
That's when it clicked for me - a structured approach to complexity saves more time than any shortcut. The matrix wasn't a design decision — it was a systems thinking one. That distinction stuck with me.
That's when it clicked for me - a structured approach to complexity saves more time than any shortcut. The matrix wasn't a design decision — it was a systems thinking one. That distinction stuck with me.

/Designing the Website

The team needed a marketing website for the design system. I started with the IA — mapping out every section, what goes where, how it all connects. Then moved into visual direction. Dribbble research, gradient exploration, figuring out what the thing should feel like before touching Figma. From there, straight into building — Figma Make, Google Stitch, some vibe coding.

Working across IA, visual design, and code in the same project changes how you think. You stop designing in isolation. Every decision has a build consequence and that makes you more precise.
Working across IA, visual design, and code in the same project changes how you think. You stop designing in isolation. Every decision has a build consequence and that makes you more precise.
Working across IA, visual design, and code in the same project changes how you think. You stop designing in isolation. Every decision has a build consequence and that makes you more precise.

/What I Took Away

I came in thinking design was mostly Figma. It's not. There's an entire layer of decisions and communication that happens before and after the file — and you only see it when you're inside a real team building a real thing.


Leading the documentation team taught me that vague direction creates rework. Clear communication isn't a soft skill. It's a design deliverable.


The button matrix wasn't a design decision — it was a systems thinking one. That distinction changed how I approach complexity now.


And I don't open Figma without a plan anymore. Structure first. That's new. Design systems thinking became something I actually practiced every day.

Component Anatomy

Design Tokens

Accessibility (WCAG)

Responsive design

Component Documentation

Information Architecture

Developer Handoff

Vibe Coding

/What People said

She demonstrated strong design sensibility, attention to detail, and a solid understanding of user experience principles. Her ability to translate complex requirements into clean, intuitive interfaces greatly enhanced the quality and consistency of our design system.

- Adiba Taj, Director

She was a consistently motivating lead during our daily morning syncs and always made herself available to help whenever the team hit a roadblock. Her ability to resolve technical doubts and simplify complex tasks was a huge asset to our workflow.

- Mridhula Veera Raghavan, UI/UX designer

She consistently helped me improve my understanding of design systems, UX thinking, accessibility, component structure, and overall attention to detail while building interfaces.

- Naman Jain, Frontend Developer

In one standout instance, when our team hit a design roadblock, Updesh quickly proposed a creative solution that both I and our boss enthusiastically adopted.

- Beosha Balamurugan, UI/UX designer

I came in to design. I stayed to understand how things get built.

Create a free website with Framer, the website builder loved by startups, designers and agencies.