Kiln
Wealth management · Workflow Automation Platform · PRODUCT DESIGN
Kiln
Designing a workflow-building platform that lets operations teams create compliant processes without starting a new engineering project each time.
Weeks → 1–2 days
to launch a process
20+
workflows shipped
~20+
dev weeks reclaimed (estimate)
5–10
ops staff building
Manual and spreadsheet processes retired; the broader initiative was funded on this case. Dev-weeks is a stated estimate.
Role
Product Designer
Company
Wealth management firm
Timeline
Feb 2025 → Apr 2025
An effort to accelerate delivery became an operational capability
At a global wealth management firm, I worked as a Product Designer on Kiln, an internal platform for building and managing operational workflows. Much of my work focused on simplifying the processes that clients and internal teams depend on to get work done.
The brief was to reduce the time required to introduce new workflows. Previously, operations teams depended on product and engineering to translate process requirements into software. Building a new workflow could take weeks, even when much of its structure resembled something the business had already implemented. The challenge wasn’t simply to design a faster workflow editor. We needed to make it possible for people without development experience to build processes while preserving the controls those processes required.
What began as an effort to accelerate workflow delivery became a platform that gives operations teams the tools to build and manage workflows themselves.
The builder: a visual canvas, reusable building blocks and stage configuration in one place.
Every new workflow needed engineering
Operational workflows determine how work moves between people, which information is collected, which documents are required and what happens at each stage. Across a regulated financial-services business, these processes must remain consistent, traceable and aligned with business requirements. When every new workflow depends on engineering, introducing a process or changing an existing one competes with other development priorities.
Before Kiln, creating a new process could take weeks. Operations teams understood the business requirements but relied on product and engineering to turn them into a working application. Similar stages, statuses, fields and document requirements were implemented repeatedly, even when they already existed elsewhere. Manual and spreadsheet-based processes also remained in use while teams waited for dedicated development capacity.
The underlying problem wasn’t that individual workflows took too long to design. It was that the business needed engineering to build each new workflow, rather than having a reusable way to create them.
Before: every workflow change went through product, engineering and QA. After: operations configure, validate and publish in 1–2 days.
Key limitations included:
Non-technical builders
Operations specialists understood business processes but needed an interface that did not require programming or knowledge of workflow-engine internals.
Compliance and governance
The platform had to support controlled transitions, appropriate access and consistent workflow configuration.
Different workflow requirements
Each process could need different fields, documents, stages, statuses and responsibilities without requiring a separate application.
Reusable building blocks
Existing data and document structures needed to be available across workflows without being repeatedly recreated.
Two connected user journeys
The building experience had to work for operations teams, while the resulting workflows had to remain usable for the people completing them.
A configurable platform, not a faster editor
I helped design Kiln as a configurable workflow-building platform. Operations teams can assemble a process using reusable data sets, document sets, stages and statuses, then manage the workflow through a visual canvas.
The platform separates the structure of a workflow from the engineering work previously needed to create each one. Instead of requesting a bespoke implementation, an authorised operations user can configure the process using the available building blocks and rules.
What shaped the platform?
Change who can build, not just how quickly developers build
The initial problem appeared to be development speed. A faster engineering process could have reduced delivery time, but operations would still depend on a separate team whenever they needed a new workflow. That led to a different product question: what would operations need to create a process themselves? The answer wasn’t unrestricted access to the underlying workflow configuration — it was a guided environment that translated familiar process concepts into reusable building blocks.
Trade-off
This changed the platform’s purpose — accepted because Kiln wasn’t designed merely to help developers configure processes faster, it was designed to make workflow creation an operational capability, with engineering maintaining the platform rather than implementing every individual process.
Make constraints part of the building experience
Giving users a blank canvas and a collection of unrestricted actions would make workflow creation flexible, but would also make invalid configurations easier to create. The guiding principle became: the best error is the one that can’t be made. The canvas needed to account for the state of the workflow being built, so available actions reflect what can validly happen next instead of allowing structural errors to surface only at the end.
Trade-off
Less unrestricted freedom on the canvas — accepted because builders could work within a more predictable structure, reducing the need to understand or manually check every underlying rule.
Reuse one configuration model across workflows
Many operational processes require similar information structures even when their overall journeys differ. Rebuilding fields, document requirements and status definitions for each workflow would reproduce the duplication Kiln was intended to remove. The platform therefore provides reusable configuration objects, including data sets, document sets and stage/status structures.
Trade-off
A more sustainable foundation, not a faster one — accepted because an improvement to a shared building block can support future workflows rather than being confined to one bespoke implementation.
What can Kiln do?
Five connected capabilities help operations teams assemble and manage workflows without requiring a bespoke engineering build for every process.
Build on a visual canvas
Operations users can arrange stages and define how a workflow progresses through a visual building environment. The canvas makes the process structure visible, helping builders understand how work moves from one stage to another.
State-aware controls guide the available configuration actions, reducing the need to work directly with the underlying technical implementation.
Only valid places light up as a step is added, and checks run before publishing.
Configure reusable information
Builders can use available data and document sets to specify the information a workflow needs. This provides a consistent structure for frequently used fields and document requirements while allowing different processes to use the appropriate combinations.
The library approach reduces repeated configuration and makes established business information easier to reuse.
The library: data and document sets are defined once, edited in one place and reused across workflows.
Define stages and statuses
Stages and statuses give a workflow its progression and communicate where a run currently sits. Builders can configure these structures to reflect the operational process rather than relying on engineers to encode each journey separately.
Clear stage and status definitions also support the people completing the workflow, who need to understand progress and what happens next.
One choice, three views: the builder’s stage configuration, the running workflow, and the status the end user sees.
Reuse existing workflows
The platform supports duplicating a workflow as a starting point for a related process. Operations teams can build on an established structure rather than configuring every stage and requirement from scratch.
This makes workflow creation faster while allowing differences to be introduced where the new process genuinely requires them.
One choice, three views: the builder’s stage configuration, the running workflow, and the status the end user sees.
Manage workflow activity
Kiln extends beyond the building canvas. Its dashboard, inbox and run-management views help authorised users find active processes and understand operational activity.
Measures such as runs started, completion rate and SLA violations provide visibility into how configured workflows perform after they begin running.
Overview, workflow list and library: what authorised users see once workflows are running.
What changed
Kiln changed the time and resources required to introduce operational workflows. Processes that previously took weeks to build could be launched in approximately 1–2 days, with operations teams creating workflows directly through the platform.
1–2 days
to launch a process, down from weeks
20+
workflows shipped
~20+
dev weeks reclaimed (estimate)
5–10
ops staff building
Manual and spreadsheet processes retired; the broader initiative was funded on this case. Dev-weeks is a stated estimate.
The impact extends beyond making one process faster to deliver. By making workflow creation reusable and accessible to operations, the platform reduces the need for a new engineering effort each time the business introduces a similar process.
How I worked
With
Operations, product and engineering
I worked closely with operations specialists to understand how workflows were defined and where the existing delivery process depended on engineering. I collaborated with product and engineering to translate those operational needs into a platform model that could support reusable workflow creation without exposing unnecessary technical complexity to non-technical users.
ARTEFACTS
Process maps, workflow models and prototypes
My work included current-state process maps, workflow grammar, state models, early canvas explorations, reusable-library concepts and high-fidelity prototypes. These artefacts helped us move from individual workflow requirements toward a shared platform structure and made complex workflow logic easier to discuss with both operations and engineering.
GOVERNANCE
Permissions, publishing and controlled configuration
Because Kiln gave operations teams more control, governance had to be part of the product rather than an afterthought. I considered how permissions, valid transitions, publishing rules and reusable libraries could prevent invalid configurations and unnecessary duplication while still giving teams enough flexibility to build the workflows they needed.
What I learned
Design for the person building the experience
Kiln required me to consider two connected journeys: the operations specialist assembling the workflow and the people who later complete it. Making the builder flexible is not enough if the resulting process becomes difficult to understand or use.
Constraints can improve usability
I learned to think of restrictions as part of the product’s guidance rather than obstacles to flexibility. When the interface makes valid next actions clear, users need less knowledge of the underlying system to build a reliable process.
Reuse changes the value of a design decision
A design improvement to one workflow benefits that process. An improvement to a reusable platform building block can benefit many existing or future workflows. That changes how decisions about structure, consistency and maintenance should be evaluated.
Governance belongs in the experience
A workflow builder needs more than a convenient canvas. Configuration rules, access and controlled changes must be understandable within the experience, because the processes people create will be used to carry out real operational work.
What’s next
The next opportunity is to make it easier for operations teams to discover and reuse existing workflow configurations before creating new ones.
Workflow templates, improved version management and clearer visibility into configuration changes could reduce repeated setup and support ongoing governance. Analytics could also help teams identify where workflows regularly stall or require similar changes, providing evidence for improvements to the shared platform.
The longer-term goal is to make each new workflow easier to create and maintain because the platform continues to learn from the processes already built with it.
More case studies