I own product problems from definition to design system — and bring a founder's commercial judgement and a teacher's clarity to them.
- Based inChandigarh, India
- DisciplineProduct design
- StudioNoFault Design
Gursimar Singh · Chandigarh, India
I'm a product designer. My work starts with an unclear problem and ends with a system a team can build from.
In practice that means framing the problem before proposing an interface, structuring the information architecture so the product can grow without being reorganised, and treating interaction, content and visual design as one set of decisions. The case studies here are written around those decisions, not around the screens.
I design in systems — tokens, components and patterns — because a product is used far more often than it is presented, and consistency is what makes it feel trustworthy from one session to the next.
I also build what I design. Working as a vibe coder, I take a design from Figma to a working front end with AI coding tools, which means ideas get tested as real products — and that I understand what engineering will need from a design before handoff.
Founding and leading NoFault Design put me on the commercial side of design: scoping honestly, weighing trade-offs with clients, and owning delivery from first conversation to launch. It is why I can argue for a design decision in business terms, not only aesthetic ones.
Teaching UI/UX at Chandigarh University sharpens the part of the job that is communication — explaining why a decision is right to people who do not share my context. It is also the fastest way I know to find the gaps in my own reasoning.
What I bring to a product team, in the order it usually matters. The software comes last — it is listed separately, with my experience.
Product Design
Deciding what a product should be before deciding how it should look — scope, priorities, trade-offs, and the flows that follow from them.
UX Strategy
Connecting user needs to business intent, and choosing where design effort will actually change an outcome.
Interaction Design
States, feedback and transitions designed as part of the product's behaviour — what happens after the tap matters as much as the button.
Information Architecture
Structuring content and navigation around how people look for things, so a product can grow without being reorganised every release.
Design Systems
Tokens, components and patterns that keep a product consistent as it scales, and let a team move faster instead of redrawing the same decisions.
Design Research
Personas, needs and competitive teardowns used to frame the problem — research that changes a decision, not research that decorates a deck.
Prototyping & Vibe Coding
Designs in Figma, then built into working, deployable front ends with AI coding tools — so an idea is tested as a real product rather than a clickable mockup.
Usability & Accessibility
Readable type, clear language, adequate targets and states that never rely on colour alone — built in from the first frame.
Visual Design
Typography, hierarchy and craft in service of comprehension, so the interface reads well before it looks good.
Design Leadership
Setting direction, running critique, managing clients and owning delivery — from founding a studio and teaching design at university.
Build systems, not isolated screens
A screen solves today. A system keeps solving after you have left the project.
Make complexity feel simple
Simplicity is not the removal of capability. It is the careful ordering of it.
Understand before designing
The problem is rarely the one stated first. Time spent on the question is never lost.
Design for humans, not screens
Context, attention and doubt matter more than the device the interface lands on.
Make every interaction intentional
If an element cannot explain why it exists, the interface is better without it.
Keep learning
Tools change quickly, judgement compounds slowly. Invest in the slower one.
I founded NoFault Design and lead it — which makes me accountable for the whole arc of the work, not just the screens.
That means setting design direction, scoping honestly with clients, deciding what a budget should be spent on, and carrying projects from first brief to launch. It is where design decisions meet commercial ones, and where I learned to argue for the first in terms of the second.
Teaching design means more than explaining tools.
It means helping people understand why something works, how users think, how systems behave, and how design decisions influence real-world outcomes.
Have an idea worth exploring? I'd like to hear about it.