The pieces worked. The whole was hard to understand.
Confluent helps companies move and process data in real time. Building on Kafka gives it enormous power, but using that power historically required a detailed understanding of connectors, topics, queries, and the relationships between them.
A business use case could mean configuring a source, transforming data, inspecting the result, and sending it somewhere else. Those steps were spread across disconnected surfaces. PMs and data scientists often needed engineers to assemble the complete workflow.
The move from an on-premises product to a cloud-first service made this more urgent. The interface had to support people who would not start in a command line while retaining the configuration depth that experienced users needed.
First, make configuration a reusable system
Connector setup exposed the problem at a smaller scale. Each connector had its own configuration screen, often a long form of technical fields. Authentication could require leaving Confluent, finding credentials, and returning without much guidance about what had gone wrong.
I replaced one-off flows with a shared configuration model. Common inputs and connector-specific requirements could use the same structure, rather than each new integration requiring an entirely bespoke experience.
The long form became a guided sequence. Required inputs, useful defaults, and validation supported the main path; advanced options preserved expert control without dominating every step. Instructions and deep links helped people complete external tasks such as authentication.
Design the foundation once, adapt it where it matters
The connector work also established foundational design-system patterns: form layouts, input components, validation, and page structure. Those patterns reduced the need to solve the same interaction problem for each connector.
Reuse did not mean treating cloud and on-premises workflows as identical. Managed setup and highly configurable infrastructure have different needs. The shared system provided consistency while leaving room for those differences.
Connector setup conversion increased from 43% to 65%. The reusable design also provided a foundation for a growth program spanning 100+ connectors.
Then, make the whole pipeline visible
Stream Designer extended the ambition beyond configuring one piece. It brought building, running, and troubleshooting a pipeline into one environment. This was related work that built on shared patterns, not simply a larger connector form.
As the sole product designer on the experience, I made the case for canvas, code, and hybrid ways of working. I used prototypes and customer research to validate an interaction model where visual configuration and SQL could round-trip rather than become separate versions of the truth.
The tradeoff was between approachable manipulation and technical precision. A canvas makes dependencies visible; code provides direct expression and control. The hybrid view let users move between them without losing the meaning of the pipeline.
A common language across product teams
Putting connectors, topics, and queries on one canvas surfaced terminology and mental-model collisions that separate product areas had been able to hide. Aligning the model was as important as drawing the graph.
I worked across teams on nested components, inspection, dependencies, and error handling, and extended related patterns into governance views. Building a pipeline and understanding where its data flowed needed to feel like parts of the same product.
The work also had to support different responsibilities: a PM framing the use case, a data scientist working on transformations, and an engineer reviewing configuration and code. A common view gave those conversations an explicit object to work around.
A shipped product and a reusable design foundation
Stream Designer launched after Confluent’s IPO, bringing the canvas-and-code interaction model into a shipped product.
The broader contribution was a shared product language across configuration, pipeline building, and governance. The design work connected improvements in individual workflows to patterns other teams could use.
Alignment is part of the design
A cross-product interaction model depends on more than reusable components. Teams need to agree on the objects, terms, and behaviors those components represent.
Cross-team alignment and knowledge transfer were material delivery constraints. Making the model concrete through prototypes and shared patterns was necessary to move the vision beyond one team’s roadmap.