Episode #52: Resolving Product Ambiguity Through User Research with Sandesh Shinde

Sandesh Shinde learned an enduring design lesson in his family kitchen. He helped an interior designer prepare a remodeling concept, but his mother rejected it because it did not fit the way she stored utensils and other items. The primary user had been left out. In Episode #52, that story becomes a practical guide to resolving ambiguity through research, observation, and testing.

What you'll learn

• How a rejected kitchen design shifted Sandesh toward user-centered work

• Why client goals and end-user goals must both shape a product

• How discovery and definition help teams clarify uncertain requirements

• How to choose a testing method based on objectives and resources

• Why observed behavior can matter more than a user's stated preference

Start with the primary user's real context

Sandesh began as a visual designer in an advertising agency, working across corporate branding, advertising, websites, and television commercials. Within the first years of his career, he began to recognize that design thinking needed to account for users. The kitchen project made that gap personal and specific. A concept could look considered yet still fail if it ignored how the person doing the work organized the space.

He responded by exploring user experience, connecting with industry experts, attending workshops and webinars, and earning usability analyst certification from Human Factors International with support from his manager. He describes empathy for users as a driving force in his transition. By the time of the interview, he had 15 years in the design industry and was a Design Lead at SAP.

His role involved building and customizing enterprise resource planning products around customer requirements, including customer-facing, data insight, and machine learning projects. The work began with understanding a client's vision, goals, objectives, and desired features. It also required a separate question: what do the people using the resulting product need to accomplish? User interviews, prototypes, and user testing helped him identify tasks, pain points, and challenges. The aim was to help both the client and the end user reach their goals as simply and effectively as possible.

Use discovery to turn ambiguity into alignment

One of Sandesh's recurring product design challenges is unclear stakeholder input. Goals, objectives, or business requirements may not be fully defined, creating uncertainty for the team. He treats the discover and define phases as essential because they help participants refine the objective and get onto the same page before committing to a solution.

His toolkit includes UX research, workshops, brainstorming, user journey maps, empathy maps, critical paths, and visual stories. These activities are not valuable because they produce artifacts. Their value is in making the user's perspective and the overall product vision visible enough for people to discuss. A journey can expose where a workflow breaks. A critical path can focus attention on the tasks a person must complete. A workshop can surface differences in what stakeholders believe the product is meant to do.

This approach gives teams a concrete way to reduce ambiguity. Instead of filling missing requirements with design assumptions, they can use discovery to identify what remains unknown, define the intended outcome, and align around evidence from users.

Match the test to the question and watch behavior

Sandesh does not present experimentation as one fixed procedure. Across the product development lifecycle, he uses different methods to understand mental models, evaluate flows, and test prototypes. He mentions A/B testing, surveys, moderated and unmoderated user testing, contextual inquiry, and card sorting. The right choice depends on the objective and the resources available.

That qualification matters. A team should first decide what it needs to learn, then choose the lightest suitable method. Sandesh does not prescribe one method or a fixed sequence for every project. He says the testing objective and available resources should determine which method the team chooses.

Sandesh also warns about the gap between what users say and what they do. During testing or in a real environment, someone may call an interaction incorrect and still follow it. Designers therefore need to listen closely without treating every statement as a complete account of behavior. Observation, prototype testing, and validation of research assumptions provide a fuller picture.

His naturally quiet style supports this work. Rather than treating limited talkativeness only as a weakness, he uses it to listen carefully and let users tell their stories. Speaking less can create room to understand their problems, needs, and objectives more deeply.

Listen to Episode #52

Episode #52 connects a memorable early mistake to a disciplined design practice. Listen to hear Sandesh explain how he balances client and user goals, brings uncertain stakeholders toward alignment, selects research methods, and learns from the difference between stated preferences and observed actions.