The real work happens in the configurations
Datamorf's configuration panels were where users actually configured everything: integrations, triggers, transformations, destinations. They were also where most of them gave up. I redesigned the full panel system from the ground up, building a scalable design language that made complex configuration feel manageable.
Context
Datamorf Configuration Panels
What's Datamorf?
Datamorf's workflow builder gives users a visual overview of their automation pipeline. But the real work happens inside the configuration panels where users set up each element: integrations, triggers, transformations, and destinations. These modals carried a significant amount of technical complexity, with dense settings, multiple input types, and conditional logic that varied depending on the element being configured.
For non-technical users, opening a modal often meant facing a wall of options with no clear hierarchy, no consistent structure, and no sense of where to start. Many didn't get past it.
Team
I worked directly with the founder and the engineering team, from research and system definition through to final handoff, building the configuration panel system as a standalone design workstream running in parallel with the workflow builder redesign.
My Role
Product Designer, I was responsible for auditing the existing configuration panel landscape, defining a scalable design system, and designing the full high-fidelity flows for every modal type, including all states, edge cases, and conditional logic.
Challenge
Redesign a fragmented, overwhelming set of configuration panels into a consistent, scannable, and scalable system, one that non-technical users could navigate confidently, and that engineers and future designers could extend without starting from scratch every time.
Research
Datamorf Configuration Panels
The panel problems weren't isolated, they were symptoms of a deeper structural issue. I approached the research in parallel with the workflow builder work, using the same user sessions to surface modal-specific insights.
Competitive Audit
I studied how competitors handled element configuration in workflow and automation tools. One pattern emerged clearly: even products with highly visual, plug-and-play builders lost users at the configuration layer. When the settings panel was overwhelming, users quit, regardless of how intuitive the builder itself was. The modal experience was as critical as the visual builder, and most tools were underinvesting in it.
Modal inventory
Before any redesign work could start, I needed to understand the full scope of what existed. I audited every modal in the product (integration creation and edit, triggers, transformations, destinations) and catalogued all input types: text, numbers, dates, options, dropdowns, descriptions, filters, and conditional logic (if/or). This inventory made the fragmentation immediately visible: similar inputs looked different across modals, similar actions lived in different places, and there were no shared structural rules.
User Interviews
During the same interview sessions conducted for the workflow builder redesign, I included tasks that required users to configure individual elements. I observed where they slowed down, where they got stuck, and what they said when they couldn't find something. The configuration layer consistently produced the highest frustration, not because the settings were wrong, but because users couldn't scan them quickly enough to know where to start.
Screen Recording Analysis
Using Posthog, I reviewed session recordings from a broader set of users to identify where frustration was building and where people were abandoning the flow. One pattern emerged clearly: When a trigger connection failed, the interface showed nothing, no error explanation, no suggested fix, no path forward. Users would attempt the same action repeatedly, unable to understand what had gone wrong. The information needed to resolve integration errors simply wasn't there.
Synthesis
Three consistent problems shaped everything that followed:
Missing structure and hierarchy: modals presented all information at the same visual weight, with no clear indication of what mattered most
Missing consistency: each modal behaved differently, so users couldn't build a mental model that transferred from one to the next
No scalable system: every new modal was built from scratch, making the fragmentation worse over time and slowing engineering down
Hypothesis:
If we introduce a consistent modal structure with clear hierarchy, progressive disclosure for complex settings, and a shared component system underlying every modal type, users will be able to configure elements confidently, and the team will be able to build new modals without reintroducing inconsistency.
Design Decisions & Testing
Datamorf Configuration Panels
Structure first
Before designing any specific modal, I defined the rules that would apply across all of them, consistent top and bottom bars, a clear content hierarchy, section separators, and spacing rules. Early testing confirmed the structure worked. But for the most complex modals, a clean layout alone wasn't enough.
Progressive disclosure
Non-essential settings were collapsed by default. Users could scan required fields first, complete the core configuration, and expand advanced options only when needed. A/B testing confirmed this was the turning point, users reported feeling the modal was manageable before filling in a single field.
States and feedback
A user cannot save until all required fields are complete, which meant every input and every action needed a defined state: empty, in progress, complete, and error.
Final Design
Datamorf Configuration Panels
The Modal System
The final delivery was a comprehensive configuration panel design system in Figma: a full component library covering every input type with all states and variants, structural rules for every modal type, and an annotated rules sheet built for engineers and future designers. Every component was built with variables to handle the full range of configuration panels without creating new components from scratch.
The system covered four modal families, integration, trigger, transformation, and destination, each with full high-fidelity flows including happy paths, edge cases, empty states, error states, and conditional logic branches.
Flow Extraction settings panel
Flow Transformation settings panel
Flow Destination settings panel
Destination settings panel in-app
Impact
No quantitative analytics were available, but usability testing and demo feedback showed consistent improvement. Users reported feeling less overwhelmed when opening panels, and were able to locate settings, even those hidden in collapsed sections, without confusion. The consistency between panels types meant that completing one configuration made the next one faster. Internally, the design system gave the engineering team a clear, scalable reference for building new configuration panels without reintroducing fragmentation, one of the most practical deliverables of the entire Datamorf engagement.
Reflection
The configuration panel system was in many ways the less visible half of the workflow builder redesign, but arguably the more complex one. The builder is what users see. The panels are where they actually work. Getting that layer right required thinking less about individual screens and more about rules: what stays consistent, what adapts, and how to communicate that logic clearly enough that it holds up without a designer in the room.
If I were to continue developing this system, I would focus on two things: implementing proper analytics to track drop-off within individual modals. The system is scalable. The next step is making it measurable.