Ideation with vibe coding

Validate concepts early to lock in budgets and build a vision.

CHALLENGE

Choose wisely which projects to invest in.

Speed

Build a working prototype to quickly validate ideas.

Test

Test with stakeholders, users and the technical team to validate feasibility and find the sweet spot between design, technology and business.

Make them talk

Connect teams and build a shared vision and roadmap.

Choose wisely which projects to invest in.

Speed

Build a working prototype to quickly validate ideas.

Test

Test with stakeholders, users and the technical team to validate feasibility and find the sweet spot between design, technology and business.

Make them talk

Connect teams and build a shared vision and roadmap.

BACKGROUND

The Standard Ideation Phase

Like many organizations, our company was in a period of significant cost-saving. This meant that any new project idea couldn't just get a green light. It had to be thoroughly evaluated before opening a substantial investment of time, money, and resources.

As the UX team, we responded by crafting a rigorous process we called "The Ideation Process". It was designed to assess the viability of every idea. It started with a brief, followed by in-depth user research to truly understand the problem.

We'd then validate or invalidate that initial brief.

From there, usually we'd move into brainstorming, building low-fidelity wireframes to test direction, and collaborating with our tech team on feasibility, also cost estimates. We even created a high-fidelity prototype to present to users and stakeholders, tying it back to a clear budget and timeline/roadmap for the full project.

This process was methodical and comprehensive, but it had a major flaw: the ideation phase was slow.

A simple project could take two weeks, but in reality, it often stretched on for one to two months, followed by stakeholders slow decision making and the wait time for getting the budgets approved and the green light.

The briefs were often unclear or incomplete. Even worse, the entire process sometimes ground to a halt at the brief stage when we discovered that stakeholders weren't actually trying to solve a user problem. They were simply trying to implement a mandate, like "we need to use AI," without a clear purpose behind the technology.

The Standard Ideation Phase

Like many organizations, our company was in a period of significant cost-saving. This meant that any new project idea couldn't just get a green light. It had to be thoroughly evaluated before opening a substantial investment of time, money, and resources.

As the UX team, we responded by crafting a rigorous process we called "The Ideation Process". It was designed to assess the viability of every idea. It started with a brief, followed by in-depth user research to truly understand the problem.

We'd then validate or invalidate that initial brief.

From there, usually we'd move into brainstorming, building low-fidelity wireframes to test direction, and collaborating with our tech team on feasibility, also cost estimates. We even created a high-fidelity prototype to present to users and stakeholders, tying it back to a clear budget and timeline/roadmap for the full project.

This process was methodical and comprehensive, but it had a major flaw: the ideation phase was slow.

A simple project could take two weeks, but in reality, it often stretched on for one to two months, followed by stakeholders slow decision making and the wait time for getting the budgets approved and the green light.

The briefs were often unclear or incomplete. Even worse, the entire process sometimes ground to a halt at the brief stage when we discovered that stakeholders weren't actually trying to solve a user problem. They were simply trying to implement a mandate, like "we need to use AI," without a clear purpose behind the technology.

Vibe Coding: Why Not?

My goal was to speed up our ideation delivery without sacrificing the core validation steps.

I introduced vibe coding, a new approach that streamlined our process. By using a quick, low-level prototyping method, we could bypass the long, drawn-out phases and get straight to assessing the project's direction and technical feasibility. This allowed us to quickly answer the most important questions: Are we solving a real problem? And is this something we can actually build?

We could also open the vibe coding doors to non designer profiles: this change has been transformative. We've been able to significantly cut down our ideation time and work hand in hand with our stakeholders.

Vibe Coding: Why Not?

My goal was to speed up our ideation delivery without sacrificing the core validation steps.

I introduced vibe coding, a new approach that streamlined our process. By using a quick, low-level prototyping method, we could bypass the long, drawn-out phases and get straight to assessing the project's direction and technical feasibility. This allowed us to quickly answer the most important questions: Are we solving a real problem? And is this something we can actually build?

We could also open the vibe coding doors to non designer profiles: this change has been transformative. We've been able to significantly cut down our ideation time and work hand in hand with our stakeholders.

Choosing the Right Tool

My team was spending weeks, even months, stuck in ideation, with projects often going nowhere. I realized we needed a faster way to validate concepts.

This led me to explore different "vibe coding" tools—solutions that could quickly bridge the gap between design and development.

I will describe some of the main tools I tried: I started the journey began with Replit, an online IDE that promised to transform ideas into live, interactive prototypes.

  • Pros: It was great for quickly getting a full-stack application up and running. I loved the collaborative nature, where I could invite a developer friend to pair-program with me in real-time. The AI assistant was also a powerful ally, helping me generate boilerplate code and troubleshoot issues on the fly.

  • Cons: Replit was a coding tool first and a design tool second. I often felt like I was spending more time debugging syntax errors than I was on the user experience. Also, my company wasn't willing to make a contract with them…

Next, I moved on to v0 by Vercel, an AI-powered tool that generates React and Tailwind components from a simple text prompt.

  • Pros: The speed was incredible. I could describe a component—a pricing table, a hero section with a call to action—and a few seconds later, I had a beautifully designed, responsive component. The output was clean, modern, and ready to be dropped into a project.

  • Cons: The tool was a bit of a black box. The UI it generated was fantastic, but I didn't have the granular control I needed. Trying to match it perfectly to our company's design system was a challenge, as I couldn't simply drag and drop our existing components. Also, my company didn't manage to find a contractual agreement with them (big organizations say: "either my way or no way")

This brought me to a realization: the perfect tool wasn't a separate one at all. It was the one I was already living in every day: Figma. And when I discovered Figma Make, I knew I had found my answer.

Figma Make was different. It wasn't about generating a new component in a vacuum, but about working with the components, libraries, and design patterns that already existed in our system. I could take an existing design, describe the interaction I wanted to create, and Figma would generate the code for a fully working prototype.

Choosing the Right Tool

My team was spending weeks, even months, stuck in ideation, with projects often going nowhere. I realized we needed a faster way to validate concepts.

This led me to explore different "vibe coding" tools—solutions that could quickly bridge the gap between design and development.

I will describe some of the main tools I tried: I started the journey began with Replit, an online IDE that promised to transform ideas into live, interactive prototypes.

  • Pros: It was great for quickly getting a full-stack application up and running. I loved the collaborative nature, where I could invite a developer friend to pair-program with me in real-time. The AI assistant was also a powerful ally, helping me generate boilerplate code and troubleshoot issues on the fly.

  • Cons: Replit was a coding tool first and a design tool second. I often felt like I was spending more time debugging syntax errors than I was on the user experience. Also, my company wasn't willing to make a contract with them…

Next, I moved on to v0 by Vercel, an AI-powered tool that generates React and Tailwind components from a simple text prompt.

  • Pros: The speed was incredible. I could describe a component—a pricing table, a hero section with a call to action—and a few seconds later, I had a beautifully designed, responsive component. The output was clean, modern, and ready to be dropped into a project.

  • Cons: The tool was a bit of a black box. The UI it generated was fantastic, but I didn't have the granular control I needed. Trying to match it perfectly to our company's design system was a challenge, as I couldn't simply drag and drop our existing components. Also, my company didn't manage to find a contractual agreement with them (big organizations say: "either my way or no way")

This brought me to a realization: the perfect tool wasn't a separate one at all. It was the one I was already living in every day: Figma. And when I discovered Figma Make, I knew I had found my answer.

Figma Make was different. It wasn't about generating a new component in a vacuum, but about working with the components, libraries, and design patterns that already existed in our system. I could take an existing design, describe the interaction I wanted to create, and Figma would generate the code for a fully working prototype.

Vib Coding with Figma Make

There were three key reasons why I chose Figma Make for my vibe coding process:

  1. Seamless Integration with Our Designs: This was the biggest win. I could use all of the design system components, typography, and styles we've meticulously built over the years. Figma Make understood our existing work, so I could build a high-fidelity prototype that was a true reflection of our product, not a generic, off-brand version.

  2. A Single Source of Truth: We had already made the strategic decision to build our design system's documentation in Figma Sites, replacing a separate tool. This meant that our design guidelines, component libraries, and now our vibe coding prototypes could all live in the same place. It created a single source of truth for our entire product team, from design to development.

  3. Future-Proofing Our Workflow: While the initial focus was on the front-end, I also wanted to explore how these prototypes could eventually connect to our back-end services. Figma Make has the potential to export clean, production-ready code, but we still need some tech support to bridge that final gap. Our next step is to collaborate with engineering to make that a reality, further solidifying the connection between design and development.

My journey to find the right vibe coding tool led me right back home. By choosing Figma Make, I'm not just picking a tool—I'm building a more efficient, integrated, and collaborative workflow that empowers my entire team.

Figma Make it's only a beta app, and I choose to invest in something I believe will have great potential in the coming years.

Vib Coding with Figma Make

There were three key reasons why I chose Figma Make for my vibe coding process:

  1. Seamless Integration with Our Designs: This was the biggest win. I could use all of the design system components, typography, and styles we've meticulously built over the years. Figma Make understood our existing work, so I could build a high-fidelity prototype that was a true reflection of our product, not a generic, off-brand version.

  2. A Single Source of Truth: We had already made the strategic decision to build our design system's documentation in Figma Sites, replacing a separate tool. This meant that our design guidelines, component libraries, and now our vibe coding prototypes could all live in the same place. It created a single source of truth for our entire product team, from design to development.

  3. Future-Proofing Our Workflow: While the initial focus was on the front-end, I also wanted to explore how these prototypes could eventually connect to our back-end services. Figma Make has the potential to export clean, production-ready code, but we still need some tech support to bridge that final gap. Our next step is to collaborate with engineering to make that a reality, further solidifying the connection between design and development.

My journey to find the right vibe coding tool led me right back home. By choosing Figma Make, I'm not just picking a tool—I'm building a more efficient, integrated, and collaborative workflow that empowers my entire team.

Figma Make it's only a beta app, and I choose to invest in something I believe will have great potential in the coming years.

"Although, it felt like watching a junior designer"

Case Study: Strategic Bidding Platform (Ideation Phase)

Context

In volatile agricultural markets, merchants and originators need to set bids that balance competitiveness with profitability. Existing approaches relied on static reports and manual analysis, which lacked real-time visibility and flexibility.

Our team was tasked not with building a solution yet, but with exploring what an internal bidding platform could look like. The goal was to ideate collaboratively, evaluate alternatives, and propose a roadmap that would convince stakeholders to invest in development.

The Design Challenge
  • Problem: Bidding processes were fragmented, opaque, and reactive. Merchants lacked real-time tools to understand competitive dynamics or share consistent insights with originators.

  • Opportunity: Build a scalable, in-house platform that could:

    • Visualize competitor landscapes dynamically.

    • Optimize bids using live market conditions and producer geography.

    • Enable role-based collaboration between merchants, originators, and admins.

  • Decision Point: Should we invest ~$500k in building our own platform — or buy an external one like GeoGrain or Contango?

Process
1. Collaborative Exploration with Vibe Coding
We used a vibe coding tool for rapid prototyping and ideation with real users:
  • Merchants: Tested how map vs grid interfaces supported daily decision-making.

  • Originators: Gave feedback on whether shared snapshots would be clear and trustworthy.

  • Data Scientists: Validated feasibility of dynamic recalculations and market influence algorithms.

  • Stakeholders: Observed sessions and saw tangible concepts early, which increased their confidence in the project’s potential.

This approach allowed us to prototype, test, and iterate in the same room, shortening feedback loops and ensuring alignment across disciplines.

2. Benchmarking External Solutions

We conducted a competitive analysis of GeoGrain and Contango:

  • Strengths of external tools: Established credibility, robust data sets, proven adoption in the market.

  • Weaknesses of external tools: High licensing costs (~$500k annually), limited customization, and features not tailored to Cargill workflows.

  • Internal alternative benefits:

    • Greater control over data quality and integration.

    • Ability to design around actual user roles (Merchants, Originators, Admins).

    • Potential to add differentiating features such as version history, collaboration flows, and more granular producer-level insights.

This analysis framed the value of an internal build, both financially and strategically.

3. Designing the Core Concepts

Through workshops and iterative prototyping, we outlined the building blocks of an internal platform:

  • Dual Workflows:

    • Map Mode: For quick, geospatial scanning of competitive threats and opportunities.

    • Grid Mode: For deep analysis, bulk editing, and structured comparisons.

  • Dynamic Landscapes: Real-time recalculation of market influence zones as bids are adjusted.

  • Role-Based Permissions: Clear separation between merchants (editors), originators (read-only validators), and admins (system managers).

  • Collaboration Features: Snapshots, version history, and sharing functions to prevent confusion from multiple working files.

  • Visual Clarity: Intuitive red–amber–green color coding and persistent filters to handle large datasets (5,000+ records).

These were not final “product requirements,” but concepts to spark discussion and illustrate potential impact.

4. Roadmap Proposal

Once the ideation phase concluded, I created a roadmap proposal — not as a delivery plan, but as a structured vision of how the project could unfold if approved:

  1. Foundations – Define entitlements, roles, and a shared glossary to ensure system-wide clarity.

  2. Core Workflows – Develop Map and Grid modes as complementary entry points.

  3. Decision-Making Enhancements – Add landscape calculations, bid editing, and real-time recalculation.

  4. Collaboration Features – Introduce snapshots, sharing, and version history to align users.

  5. Optimization & Best Practices – Refine with filters, persistence, and user guidance for efficiency at scale.

This roadmap served two purposes:

  • For stakeholders: A realistic view of timelines and costs (~$500k benchmark, aligned with external solutions).

  • For the team: A logical design flow that sequenced features by dependency and impact.

Outcome of the Ideation Phase
  • Validated Need: Direct user input confirmed that merchants and originators would gain significant value from an internal platform.

  • Stronger Case for Internal Build: Benchmarking showed we could deliver more control and functionality for the same cost as external tools.

  • Stakeholder Alignment: The roadmap proposal allowed leadership to discuss budgets, timelines, and commitment with a clear picture of what “success” could look like.

Case Study: Strategic Bidding Platform (Ideation Phase)

Context

In volatile agricultural markets, merchants and originators need to set bids that balance competitiveness with profitability. Existing approaches relied on static reports and manual analysis, which lacked real-time visibility and flexibility.

Our team was tasked not with building a solution yet, but with exploring what an internal bidding platform could look like. The goal was to ideate collaboratively, evaluate alternatives, and propose a roadmap that would convince stakeholders to invest in development.

The Design Challenge
  • Problem: Bidding processes were fragmented, opaque, and reactive. Merchants lacked real-time tools to understand competitive dynamics or share consistent insights with originators.

  • Opportunity: Build a scalable, in-house platform that could:

    • Visualize competitor landscapes dynamically.

    • Optimize bids using live market conditions and producer geography.

    • Enable role-based collaboration between merchants, originators, and admins.

  • Decision Point: Should we invest ~$500k in building our own platform — or buy an external one like GeoGrain or Contango?

Process
1. Collaborative Exploration with Vibe Coding
We used a vibe coding tool for rapid prototyping and ideation with real users:
  • Merchants: Tested how map vs grid interfaces supported daily decision-making.

  • Originators: Gave feedback on whether shared snapshots would be clear and trustworthy.

  • Data Scientists: Validated feasibility of dynamic recalculations and market influence algorithms.

  • Stakeholders: Observed sessions and saw tangible concepts early, which increased their confidence in the project’s potential.

This approach allowed us to prototype, test, and iterate in the same room, shortening feedback loops and ensuring alignment across disciplines.

2. Benchmarking External Solutions

We conducted a competitive analysis of GeoGrain and Contango:

  • Strengths of external tools: Established credibility, robust data sets, proven adoption in the market.

  • Weaknesses of external tools: High licensing costs (~$500k annually), limited customization, and features not tailored to Cargill workflows.

  • Internal alternative benefits:

    • Greater control over data quality and integration.

    • Ability to design around actual user roles (Merchants, Originators, Admins).

    • Potential to add differentiating features such as version history, collaboration flows, and more granular producer-level insights.

This analysis framed the value of an internal build, both financially and strategically.

3. Designing the Core Concepts

Through workshops and iterative prototyping, we outlined the building blocks of an internal platform:

  • Dual Workflows:

    • Map Mode: For quick, geospatial scanning of competitive threats and opportunities.

    • Grid Mode: For deep analysis, bulk editing, and structured comparisons.

  • Dynamic Landscapes: Real-time recalculation of market influence zones as bids are adjusted.

  • Role-Based Permissions: Clear separation between merchants (editors), originators (read-only validators), and admins (system managers).

  • Collaboration Features: Snapshots, version history, and sharing functions to prevent confusion from multiple working files.

  • Visual Clarity: Intuitive red–amber–green color coding and persistent filters to handle large datasets (5,000+ records).

These were not final “product requirements,” but concepts to spark discussion and illustrate potential impact.

4. Roadmap Proposal

Once the ideation phase concluded, I created a roadmap proposal — not as a delivery plan, but as a structured vision of how the project could unfold if approved:

  1. Foundations – Define entitlements, roles, and a shared glossary to ensure system-wide clarity.

  2. Core Workflows – Develop Map and Grid modes as complementary entry points.

  3. Decision-Making Enhancements – Add landscape calculations, bid editing, and real-time recalculation.

  4. Collaboration Features – Introduce snapshots, sharing, and version history to align users.

  5. Optimization & Best Practices – Refine with filters, persistence, and user guidance for efficiency at scale.

This roadmap served two purposes:

  • For stakeholders: A realistic view of timelines and costs (~$500k benchmark, aligned with external solutions).

  • For the team: A logical design flow that sequenced features by dependency and impact.

Outcome of the Ideation Phase
  • Validated Need: Direct user input confirmed that merchants and originators would gain significant value from an internal platform.

  • Stronger Case for Internal Build: Benchmarking showed we could deliver more control and functionality for the same cost as external tools.

  • Stakeholder Alignment: The roadmap proposal allowed leadership to discuss budgets, timelines, and commitment with a clear picture of what “success” could look like.

Saving 2M+ thanks to internal tools


Benchmarking External Solutions

We conducted a competitive analysis of GeoGrain and Contango:

  • Strengths of external tools: Established credibility, robust data sets, proven adoption in the market.

  • Weaknesses of external tools: High licensing costs (~$500k annually), limited customization, and features not tailored to Cargill workflows.

  • Internal alternative benefits:

    • Greater control over data quality and integration.

    • Ability to design around actual user roles (Merchants, Originators, Admins).

    • Potential to add differentiating features such as version history, collaboration flows, and more granular producer-level insights.

This analysis framed the value of an internal build, both financially and strategically.

Designing the Core Concepts

Through workshops and iterative prototyping, we outlined the building blocks of an internal platform:

  • Dual Workflows:

    • Map Mode: For quick, geospatial scanning of competitive threats and opportunities.

    • Grid Mode: For deep analysis, bulk editing, and structured comparisons.

  • Dynamic Landscapes: Real-time recalculation of market influence zones as bids are adjusted.

  • Role-Based Permissions: Clear separation between merchants (editors), originators (read-only validators), and admins (system managers).

  • Collaboration Features: Snapshots, version history, and sharing functions to prevent confusion from multiple working files.

  • Visual Clarity: Intuitive red–amber–green color coding and persistent filters to handle large datasets (5,000+ records).

These were not final “product requirements,” but concepts to spark discussion and illustrate potential impact.

Saving 2M+ thanks to internal tools


Benchmarking External Solutions

We conducted a competitive analysis of GeoGrain and Contango:

  • Strengths of external tools: Established credibility, robust data sets, proven adoption in the market.

  • Weaknesses of external tools: High licensing costs (~$500k annually), limited customization, and features not tailored to Cargill workflows.

  • Internal alternative benefits:

    • Greater control over data quality and integration.

    • Ability to design around actual user roles (Merchants, Originators, Admins).

    • Potential to add differentiating features such as version history, collaboration flows, and more granular producer-level insights.

This analysis framed the value of an internal build, both financially and strategically.

Designing the Core Concepts

Through workshops and iterative prototyping, we outlined the building blocks of an internal platform:

  • Dual Workflows:

    • Map Mode: For quick, geospatial scanning of competitive threats and opportunities.

    • Grid Mode: For deep analysis, bulk editing, and structured comparisons.

  • Dynamic Landscapes: Real-time recalculation of market influence zones as bids are adjusted.

  • Role-Based Permissions: Clear separation between merchants (editors), originators (read-only validators), and admins (system managers).

  • Collaboration Features: Snapshots, version history, and sharing functions to prevent confusion from multiple working files.

  • Visual Clarity: Intuitive red–amber–green color coding and persistent filters to handle large datasets (5,000+ records).

These were not final “product requirements,” but concepts to spark discussion and illustrate potential impact.

Roadmap Proposal

Once the ideation phase concluded, I created a roadmap proposal — not as a delivery plan, but as a structured vision of how the project could unfold if approved:

  1. Foundations – Define entitlements, roles, and a shared glossary to ensure system-wide clarity.

  2. Core Workflows – Develop Map and Grid modes as complementary entry points.

  3. Decision-Making Enhancements – Add landscape calculations, bid editing, and real-time recalculation.

  4. Collaboration Features – Introduce snapshots, sharing, and version history to align users.

  5. Optimization & Best Practices – Refine with filters, persistence, and user guidance for efficiency at scale.

This roadmap served two purposes:

  • For stakeholders: A realistic view of timelines and costs (~$500k benchmark, aligned with external solutions).

  • For the team: A logical design flow that sequenced features by dependency and impact.

Outcome of the Ideation Phase
  • Validated Need: Direct user input confirmed that merchants and originators would gain significant value from an internal platform.

  • Stronger Case for Internal Build: Benchmarking showed we could deliver more control and functionality for the same cost as external tools.

  • Stakeholder Alignment: The roadmap proposal allowed leadership to discuss budgets, timelines, and commitment with a clear picture of what “success” could look like.

Roadmap Proposal

Once the ideation phase concluded, I created a roadmap proposal — not as a delivery plan, but as a structured vision of how the project could unfold if approved:

  1. Foundations – Define entitlements, roles, and a shared glossary to ensure system-wide clarity.

  2. Core Workflows – Develop Map and Grid modes as complementary entry points.

  3. Decision-Making Enhancements – Add landscape calculations, bid editing, and real-time recalculation.

  4. Collaboration Features – Introduce snapshots, sharing, and version history to align users.

  5. Optimization & Best Practices – Refine with filters, persistence, and user guidance for efficiency at scale.

This roadmap served two purposes:

  • For stakeholders: A realistic view of timelines and costs (~$500k benchmark, aligned with external solutions).

  • For the team: A logical design flow that sequenced features by dependency and impact.

Outcome of the Ideation Phase
  • Validated Need: Direct user input confirmed that merchants and originators would gain significant value from an internal platform.

  • Stronger Case for Internal Build: Benchmarking showed we could deliver more control and functionality for the same cost as external tools.

  • Stakeholder Alignment: The roadmap proposal allowed leadership to discuss budgets, timelines, and commitment with a clear picture of what “success” could look like.

Reflection

This wasn’t about delivering a finished product, it was about shaping the process.

What I learned and demonstrated:

  • Facilitation: Running cross-functional workshops with users, data scientists, and stakeholders.

  • Strategic Design: Evaluating external vs internal solutions and framing the financial + usability tradeoffs.

  • Vision Building: Turning early exploration into a structured roadmap that made investment decisions easier.

  • Precise estimation for the stakeholders: let's be honest, stakeholders want precise numbers and dates in order to give a green light for the project.

  • We saved 50K only by implementing a quicker ideation process, on top of 2M+ on external tool vs developing internal tool.

For my portfolio, this case study highlights my ability to bridge design, business, and data science during the ideation phase — a skill set that’s often overlooked but crucial for setting projects up for success.

Reflection

This wasn’t about delivering a finished product, it was about shaping the process.

What I learned and demonstrated:

  • Facilitation: Running cross-functional workshops with users, data scientists, and stakeholders.

  • Strategic Design: Evaluating external vs internal solutions and framing the financial + usability tradeoffs.

  • Vision Building: Turning early exploration into a structured roadmap that made investment decisions easier.

  • Precise estimation for the stakeholders: let's be honest, stakeholders want precise numbers and dates in order to give a green light for the project.

  • We saved 50K only by implementing a quicker ideation process, on top of 2M+ on external tool vs developing internal tool.

For my portfolio, this case study highlights my ability to bridge design, business, and data science during the ideation phase — a skill set that’s often overlooked but crucial for setting projects up for success.

Got an idea? Let's talk.

Have a new idea worth exploring? Let's collaborate and create something amazing together.

Got an idea? Let's talk.

Have a new idea worth exploring? Let's collaborate and create something amazing together.