User Research Methods — How Palash Sarkar Understands Users Before Designing

Palash Sarkar has seen well-designed interfaces fail simply because they were built for an assumed user rather than a real one. User research is the corrective — and it doesn't have to mean months of formal studies to be genuinely useful.

Interviews Over Surveys When Possible

Surveys are efficient for quantity but shallow on the "why" behind an answer. When timeline and access allow, Palash Sarkar prioritizes short user interviews — five or six focused conversations often surface more actionable insight than a hundred survey responses, because follow-up questions reveal reasoning a multiple-choice answer never could.

Competitive Audits as Structured Research, Not Copying

Studying competitor products isn't about imitation — it's about understanding what conventions users already expect, and where competitors are genuinely failing their own users. On an enterprise project like CustOS.ai, competitive audits revealed which patterns were confusing across the entire category, not just one product, informing decisions that improved on the whole space rather than one competitor.

Testing Assumptions Early, Cheaply

Rather than waiting for a finished prototype to validate assumptions, Palash Sarkar tests core assumptions early with low-cost methods — quick clickable wireframes shown to a handful of target users, even informal conversations. Catching a wrong assumption before visual design begins costs almost nothing; catching it after launch costs a rebuild.

Key Takeaways

User research doesn't require a dedicated research team or months of runway to be worthwhile — even lightweight interviews and early assumption testing meaningfully reduce the risk of designing for an imagined user instead of a real one. Palash Sarkar treats some form of research as non-negotiable on every project, scaled to what the timeline allows.