Research as infrastructure, not a manual process.
We created a platform to create and distribute surveys across web and mobile products in an integrated way. I handled ideation, business rules, the development pipeline and handoff, and the product was built in about two months, using 100% of the Design System. It eliminated the recurring cost of external quantitative research platforms.

The problem
Running quantitative research in our products depended on external platforms, and their cost was high and recurring. Every team that wanted to hear from customers went into a queue, or a contract, before getting a single answer. Research was a manual, expensive process, when it should be a product capability.
What we built
A complete platform, back end and front end, to create and run surveys synchronized across web and app. A survey created once appears on both at the same time. It covers practically all quantitative research needs: NPS, CSAT, CES, SEQ, PMF, binary and ternary questions, short and long answers, chips, checkbox and radio button lists, plus redirect and message blocks.
- One survey
- App and web, at the same time
The decisions
- Questions as mini templates. Whoever creates a survey picks a block, for example a CES, and it comes with a ready-made title and instructions on how the customer should respond. Fewer writing mistakes, a standardized experience and nobody starts from zero.
- One survey, two platforms. Instead of maintaining one version for web and another for app, the survey is a single piece of content, delivered the same way.
- Care for the customer's screen. The survey overlays part of the screen, so the biggest risk is getting in the way of using the product. That's why we validate that data arrives correctly and nothing freezes the page before scaling.
Data quality
We don't yet segment the audience 100% inside the platform. Today we collect responses and segment by a few key questions. To be more certain the audience was the right one, we cross-check with a data lake that gathers customer information through a single user id.
An example: if I ask whether someone has debt and they say yes, but the lake says no, there's a divergence, and that divergence reduces the survey's credibility. By crossing both sources, we refine the audience. No sensitive data stays in the lake, because of LGPD.
- Key question
- Real data
- Confidence
How it was built
The team was complete, design and technology: me, as designer and product, three web devs and two app devs. I owned ideation, business rules, the development pipeline and handoff. From ideation to beta, it took about two months.
The whole project was built by our Design System team, using 100% of Pitaya. It was the most direct proof that Design System, product, technology and business can work together: the system created to give screens consistency became the foundation of an entire platform, which eliminated a cost that weighed on the business.
Where we are
- ~2 monthsfrom ideation to beta.
- 100%built with the Pitaya Design System.
- 2teams using it today, in testing and performance phase.
We haven't been able to measure the gains yet, because the study base is small. For qualitative research, we still rely on an external company that handles screening and recruiting interviewees, and we still use an external screen-metrics tool. For people answering, nothing changes: it's a question on screen. For people creating, it opens a sea of possibilities for innovation, improvement and understanding the customer.
Want to know more? If you're trying to bring order to something that needs to scale, let's talk.
Get in touch ↗ (opens in a new tab)Next case: AI that frees the team →