Episode #51: Building Better Product Design Feedback Loops with Nipurn Doshi

A product team does not need to wait for a polished design or a scheduled customer interview to start learning. In Episode #51, Nipurn Doshi, Lead Product Designer at Sigma Computing, shares a process that gathers evidence throughout design and development. His approach combines quick internal reactions, structured customer research, and product data, then asks designers to decide which feedback is useful.

What you'll learn

• How Nipurn moved from front-end engineering into user experience design

• How Sigma's designers work with product and engineering from the start

• How three feedback loops support faster design decisions

• Why task-blocking feedback matters more than a subjective preference

• How documenting rejected ideas can help future projects

Move from building interfaces to understanding problems

Nipurn studied computer science and spent three years as a front-end engineer. During that work, he felt something was missing: he was not receiving enough feedback or knowing whether he was building what customers wanted. That concern led him to study UX online and discover graduate programs in design. He later completed a master's in information science focused on human-computer interaction at Indiana University, contributed to an open-source Apache project, and interned in user experience research at NASA's Jet Propulsion Laboratory.

By the time of this conversation, Nipurn had spent five years at Sigma Computing. He describes Sigma as a cloud analytics platform that gives business users a familiar spreadsheet interface for exploring data in a cloud warehouse without code or specialized training. That context creates a demanding design problem. The product can introduce new approaches, but it must still feel usable to customers familiar with spreadsheets and established business intelligence tools.

Bring design into the project on day one

At Sigma, product designers own features from beginning to end. They work with product and engineering to scope requirements and define success metrics on the first day of a project. Depending on the problem, they also review past data, conduct user research, and study competing products before producing and iterating on prototypes.

The workflow is deliberately collaborative. Stakeholders can see Figma files early and add feedback without waiting for a formal demo. Engineers can begin building from what they see rather than waiting for a pixel-perfect handoff. Designers also work with design-system and visual designers to apply reusable patterns, helping users avoid learning a new interaction model for every feature. Once the team aligns, the work moves into a staging environment for more aggressive testing. Features typically reach a small set of beta customers before a broad release, creating another opportunity to correct the solution.

Use three feedback loops instead of one

Nipurn groups his feedback process into three buckets. The first is ad hoc feedback. He shares early solutions through Slack, quick Zoom calls, and clickable prototypes. The audience can include solution engineers, customer success, support, sales, finance, and other colleagues who either speak directly with customers or resemble the product's business users. This route gives the design more eyes before the next customer call.

The second bucket is structured research. Designers partner with engineers to turn prototypes into quick working versions, select customers from a research pool who match the relevant criteria, conduct interviews, and use the findings to improve the implementation.

The third bucket is product data. Sigma uses its own analytics capabilities to examine feature performance. With beta customers, the team combines qualitative and quantitative feedback. Depending on the feature, it may track CTA clicks, first-time discoverability, comprehension, errors, usage, or support calls. The team can then assess improvements against the metric chosen for that feature. The lesson is not to favor one kind of evidence. It is to connect fast reactions, deeper research, and observed behavior.

Iterate selectively and preserve the reasoning

Nipurn's first lesson is to iterate repeatedly rather than remaining in a design bubble until every pixel is final. That does not mean changing a design for the sake of activity. Showing users the current solution helps the team avoid building the wrong one, while internal customer-facing colleagues can provide useful input when customers are not immediately available.

Selection still matters. Nipurn distinguishes subjective feedback such as disliking a design from constructive feedback that identifies why someone cannot finish a task. Product teams cannot implement every request, so experience and judgment are needed to find the evidence that should change the work.

Frequent iteration also creates a documentation burden. Nipurn keeps older concepts in clearly labeled sections or pages within Figma and pins user feedback to them. A designer facing a similar problem can later see which option failed and why. The same record helps Nipurn return months later without losing the reasoning behind a decision. It takes time, but it turns discarded work into team knowledge.

Listen to Episode #51 for Nipurn's practical account of building feedback into each stage of product design, from the first prototype through beta measurement.