NDA-safe overview
Portal de Parcerias – structuring a partner experience for Cielo
A sanitized look at how I approached the UX of a partner portal for one of Brazil's largest payment companies — focusing on the problem framing, information architecture, and decision-making process.
- Role
- Product designer in a cross-functional squad
- Context
- Fintech · B2B partner portal
- Note on visuals
- UI details have been generalized to respect confidentiality; the process is real.
Problem & constraints
Cielo works with a wide range of partners who need to understand their performance, manage contracts, and access self-service support. The existing experience was fragmented across tools and touchpoints, which created friction and additional load on internal teams.
The challenge was to design a more coherent partner portal experience within constraints that included existing back-office systems, strict security and compliance requirements, and the need to align multiple internal stakeholders around a shared vision.
Understanding partners & internal teams
I started by mapping the different partner types and their needs, combining stakeholder interviews with a review of existing support tickets and onboarding materials. In parallel, I spoke with internal teams (sales, operations, support) to understand where they were spending the most time and where partners were getting stuck.
- Some partners were very self-sufficient, others relied heavily on account managers for simple tasks.
- Key information was often available, but scattered across PDFs, dashboards, and emails.
- Internal teams wanted more predictable requests, not more volume in already overloaded channels.
Journey map & opportunity areas
To align stakeholders, I created a high-level journey map showing how partners move from onboarding to day-to-day operations to renewal. For each phase, we mapped:
- What partners are trying to accomplish
- What touchpoints they use today
- Where they feel confident vs. confused
- Where internal teams experience friction
This artifact became a shared reference and helped us prioritize a first release around making core information easier to find and understand before adding more advanced features.
Information architecture & navigation
I proposed an information architecture that grouped tasks by partner mental models rather than internal system boundaries. For example, instead of surfacing separate sections for different back-office systems, we grouped content around questions partners actually ask:
- "How are my sales performing?"
- "What do I need to do next?"
- "Where can I update my information?"
I validated this structure with quick card-sorting style exercises with internal stakeholders and a small number of partners, iterating on labels and groupings until they felt intuitive.
Key UX decisions
One "home" for partners
I designed a clear portal homepage that surfaces the most important metrics, alerts, and actions in one place, so partners don't have to hunt across multiple sections to understand what matters today.
Progressive disclosure for complexity
Detailed financial or technical data is still available, but behind drill-downs and filters. The default views prioritize clarity and next steps, not exhaustiveness.
Clear separation of self-service vs. support
I worked with stakeholders to define which tasks should be fully self-service and which still required human support, and reflected that distinction in the flows and messaging.
Outcomes & reflection
While specific metrics and UI details are confidential, we tracked early signals such as reduced basic "where do I find…" questions from partners and more consistent use of the portal for routine tasks.
For me, this project was an exercise in balancing confidentiality with storytelling: showing how I work — how I frame problems, align stakeholders, and make tradeoffs — even when I can't show every screen.
If this kind of work is relevant to a role, I'm happy to talk through more detail live, within NDA boundaries.