Designing criteria before designing solutions

Context

Cropwise Open Platform is Syngenta’s initiative to open its digital ecosystem to external partners through APIs, agronomic services, and data products.

I worked on the platform from day zero, in a context where the strategic decision to “open the platform” had already been made, but the boundaries, criteria, and real implications of that openness were still undefined. The initiative had high institutional visibility, multiple target audiences, and pressure to move fast before governance, scale, and value capture were fully clarified.

The real (unspoken) problem

How do you move fast without locking in the wrong decisions in a platform that needs to scale and remain viable for years?

Beyond exposing APIs, the challenge was to design a system that could learn, adapt, and grow without accumulating structural debt.

My way of working

I reduced ambiguity before designing solutions

THE HOW

Before any UI work, I focused on turning vague questions into explicit decisions, for example:

• “Who is the partner?” → defining which profiles would not be served initially (e.g. experimental startups vs enterprise partners with existing contracts)

• “Self-service” → identifying stages where full autonomy would break governance (e.g. direct access to sensitive APIs without legal or technical validation)

• “Open platform” → defining what could never be opened (e.g. core services tied to proprietary farmer data)

  
  This forced the team to confront real trade-offs early and avoided generic solutions.

I used the product itself as a governance mechanism

Instead of treating governance as an external process (legal reviews, contracts, manual exceptions), I:

• embedded rules directly into product flows (e.g. eligibility criteria before issuing API credentials)

• used UI to make constraints visible (e.g. explicit states such as available, restricted, under review)

• designed checkpoints where decisions had to be made before integrations could progress (e.g. mandatory approval before accessing advanced services)

  
  This reduced manual exceptions and prevented constant renegotiation with each new partner.

1

2

I modeled competing scenarios before committing to one

Rather than following a single roadmap, I worked with parallel scenarios, such as:

• full self-service vs assisted integrations (e.g. open sandbox vs guided onboarding for early partners)

• generic APIs vs specialized capabilities (e.g. broad endpoints vs use-case-specific services)

• fast scale vs progressive control (e.g. immediate openness vs layered access over time)

  
  Decisions were made by comparing reversibility cost, not just delivery speed.

3

I designed UI to expose trade-offs, not hide them

The interface was not designed to “feel simple” at all costs, but to:

• clearly show what is available now (e.g. public API catalog with status indicators)

• what requires additional validation (e.g. services accessible only after approval)

• what depends on negotiation (e.g. capabilities marked as custom or enterprise-only)

  
  This aligned partner expectations from the first interaction and reduced friction downstream.

4

System-level outcome

THE OUTCOME

Before any UI work, I focused on turning vague questions into explicit decisions, for example:

• “Who is the partner?” → defining which profiles would not be served initially (e.g. experimental startups vs enterprise partners with existing contracts)

• “Self-service” → identifying stages where full autonomy would break governance (e.g. direct access to sensitive APIs without legal or technical validation)

• “Open platform” → defining what could never be opened (e.g. core services tied to proprietary farmer data)

This forced the team to confront real trade-offs early and avoided generic solutions.

Why does this case matter?

This project is not about “launching a platform”, but about turning strategic ambiguity into explicit product criteria, using design as a tool for decision-making, governance, and long-term scalability.