We’re jumping into @Kike_pena’s article today, The AI concept that changed our company’s way of working. His core argument is that design influence has shifted from execution to enablement. Instead of designers building every interface and prototype, teams created a safe system that lets others explore ideas with AI, guided by clear design and product rules.
Kike advocates for something called a product playground.
This is a local environment that simulates products at a fundamental level using structure, layout, and basic content. Think gray boxes and text. It gives teams a place to quickly play with ideas and functionality, and creates faster conversations between designers, product teams, and users.
When designers define the rules, constraints, and quality bar, AI and teams can explore ideas faster without losing coherence. Design influence stays strong (the idea is that the chaos stays contained), and designers stop becoming the bottleneck.
Let’s jump into the discussion:
He reframes AI as a way to scale thinking… not just output. His designers spend less time making screens and more time defining the constraints, patterns, and principles that shape good decisions.
This structure is what allows speed without sacrificing quality.
So here’s the real question I want to explore:
How does this work for teams that are not yet fluent with these tools?
And how well does a product playground actually hold up in practice?
First off, always enjoy our conversations Kike, you’re infectiously optimistic. It’s great to chat with you today! I encourage others to ask questions as you have some great things to share to help teams be more effective.
First big question, is how do you get a team onboard with a major shift like this outside the design group?
The promise of a tool that lets people build products faster than ever is attractive enough to get C-level executives and other company teammates interested in participating in this idea. One big paradigm we got rid of was like “digital products are only built by tech people,” with the product playground, everyone can create in their own environment, product ideas that eventually can be real.
Beyond this impact, the numbers change dramatically in the product-building dynamic; we moved from a 3-month creation span to even weeks.
I think we all agreed that, at some point, the product creation was slow and sometimes bureaucratic. Product playground democratizes product development within defined design standards. Non-designers have now what you mention: productively putting ideas and not waiting for a sprint for designers to materialize it, and also having a co-creation voice WITH THE DESIGNERS towards a solution. I have to say something: with the Playground, the designers are always protagonists in the product creation
This is great. It’s something I’ve pushed my designers to do for decades. You have to represent the ideas and fight for quality, even when the work isn’t “yours.” This is how design leadership is developed.
Synthesis and judgment are required to elevate these conversations. Maybe even more so when creation is shared across a group.
We decided to wrap up all these conversations into a production stage we called “acceleration,” where all profiles converge to build ideas together. In this stage, it is now normal to show multidisciplinary ideas to a big audience; the outcome of this stage is part of a new dynamic mindset we created from the UX team
So with AI outputs, the quality bar can vary widely, especially when prompting goes sideways. There’s a lot of back-and-forth to work through that can be frustrating.
Is this space more conceptual, or a place to move things into production?
So far, the product playground is intended for fast exploration with UI components, so a high-definition prototype isn’t mandatory, and prompts don’t have to be perfect. After these iterations, designers can refine the design in Figma and hand it off to devs. Some designers tho have decided to build directly in the Playground, leaving Figma behind. I think this is all part of the learning process of adopting this tool.
Part of the plans we have for the product playground in the medium term is to connect with the actual component production library, so at that stage, everyone can build things directly to production.
Thanks for adding more color @Kike_pena! We’ll keep this open for more questions, as it’s so important for product and design teams driving AI initiatives. Thank you for sharing your ideas and inspiring leaders to take action. This is wonderful.
As a developer, this is probably my favorite use case.
As a designer, are there any thoughts around building on a systematic level that, instead of producing large components, that you start with building blocks and work your way upwards (sorta like atomic design)?
I’m definitely curious/excited to see where the experimentation is going to take you!
@Kike_Pena this has my operational brain TURRRRNNNNING! Biggest thing I’m going to call out here, is this feels like you spend less time coordinating work and more time learning what actually works and in my spot, this is literal gold.
Has this actually changed decisions, or mostly speed? Good one here
We were always into Cursor as a vibe coding tool after reviewing some of the most popular, such as lovable, framer, builder, perplexity, etc.
The main challenge for us as designers was learning in our own terms; nobody was willing to teach us how to use the tool, so we decided to “play” with the tool; at the beginning, with a lot of fear, but now, some of my teammates find it more effective than Figma…
For version one (just playing around), we created a UI design system from Figma to the Playground directly, but it is local so far. We are trying to connect it (for version 2) with an official production components repo through a custom-made MCP
To answer the question posed by the title of this post, it sounds like designers set the bar, but how do they know if new ideas dropped into the playground meet that criteria? Seems like if AI can facilitate the creation of these new ideas, it can also help assess these ideas based on the parameters that the teams set. This would give you a structured way to have AI both create new ideas, and then evaluate those ideas based on a stack of metrics defined by the designers.
Actually, part of the mindset changes we face when learning from this new dynamic is understanding a new design vision we call “infrastructure design,” which is precisely what you mention: thinking in terms of building blocks to allow others to use the system. With the Playgrund, we need to think of the systems rather than just isolated parts.
With the Playground in the acceleration stage, we see time differently, and dynamics within the group has changed big time. Part of having a “look-alike production” environment is that we start from the solution towards users and build from there (saving almost 70% of the time spent creating something), unlike months ago. So, the mindset is new, decisions and momentum feel different.
Yes, there were other challenges from a design mindset; considering “leaving behind” somehow the pixel language to start talking front-end. This barrier was difficult to remove during the initial stages of the Playground.
Yes, I had detractors, especially in the engineer’s high-level management position, where they thought a designer was not capable of creating something directly in code. I think most of the friction came from a professional perspective, where people start thinking AI will replace them and are unwilling to learn a new language.
PMs and people from different areas were fascinated to see that now they were builders too and had moved away from those old thoughts like “to deliver something, a designer has to design it and then an engineer has to build it.”
