Designing Agentic Product workflows that users trust.
We’ve maybe reached peak ‘can I stuff AI into this product’ relevancy panic, although it’s hard to predict given the long-tail investment. As the use cases are being more objectively monitored and the hard reality of token costs are being reckoned with, there remains an unresolved undercurrent of ‘is this what people want’.
My background is not purely Product and Software design. My foundations in Design started in Brand, Publishing and Broadcast which are more qualitative than quantitatively driven. What this has given me is more of an empathetic perspective and ‘feel’ in terms of how things are ‘Loved’. In Brand - and Media generally - to be Loved is the high water mark of retention. It’s intimately associated with fandom, but it’s not as quantifiable or extreme. It’s instead a sense of legitimacy amongst the noise and change, and it was primarily used by ‘Loved Brand’ teams as the justification to experiment and push. With Love comes forgiveness, and as a ‘Loved Brand’ you had a mercurial sense of what was safe and what was push-possible.
From this perspective, what software got wrong was - they were super useful and super-ingrained - but not loved. And so with AI-stuffing what happened was not forgiveness, but distrust. Apple is a ‘Loved Brand’. Apple is not AI-stuffing.
This is not an AI-doomer position. I have been actively designing AI into products and brands since 2015 when it was more accurately referred to as ML. 2015 was a long time ago and attitudes have changed massively since. But the approach at that time was very much about introducing change and functions in a way that enabled the user, and often quietly. Enhancing known wants and needs with more seamless and effortless processes. Rounding off the corners and increasing comfort. Your feed gave you the content you were looking for - it wasn’t an ‘AI feed’. The workflow you built identified it was built incorrectly and a modal suggested the correct routing change - not a AI workflow builder with a personality with long-form semantic behaviours.
AI-stuffing is about slamming a big, obvious LLM-forward AI feature into an existing optimal environment and forcing an adoption. This in turn undermines the precarious social contract. It also looks increasingly desperate. Especially when a lot of AI-stuffed features fail to consider the complexity of human interactions and the general push back it inevitably causes.
From a brand point of view, AI is also not cool. And this might seem like a half-baked hot take, but AI as a concept, is socially rudderless. It is just ‘AI’. It’s not the hidden undercurrent of a well loved feature. It’s ‘AI’, positioned, branded and stuffed in a way which makes it feel like the unloved, politically and socially troubled brand ‘AI’ has collaborated with your product and for some reason has you over a UX barrel.
Start with a system.
Mapping the IA is the traditional starting point with complex systems, but with Formsflow the primary issue was that the IA was a variable. Depending on the instance, the IA could be drastically different - in terms of feature parity, look and feel, expected outcome and flow.
One big issue was the lack of consistent UI. Interactions, frameworks, actions were all a variable and broke the perceived IA in the various instances. Those instances were often on-prem or on private cloud, making QA additionally difficult. When your product is being utilized by the BC Government and the RCMP, getting access to what they physically can see on their screen, or how their data actively flows with the product becomes very very difficult, if not impossible.
The general UX (and to some extent the IA) was informed by a variety of different Bootstrap versions with developer-led workarounds. Icon sets were ad-hoc and developer determined. So I made the initial suggestion that we align the various product instances in a unified UI. This, typically, is a bad decision - enforcing feel before flow - but Formsflow needed, in this scenario, a baseline. A baseline that could be taken offline and discussed, improved and provide a single point of truth. A baseline that could run independent of the variant components and instances. A baseline that could build a user testing environment around it, validate it, and ultimately determine what the Public Cloud SaaS could be. Without consistency, there was no validation, no progression, no vision and ultimately no stakeholder/investor unity.
This felt like an inexperienced decision - to, in some way, put form before function. But without it, we couldn’t get the alignment - there wasn’t the sales confidence, there wasn’t the marketing touchpoints, there wasn’t a vision to get behind and actually say “this is what Formsflow actually is and does”.
And so we started with a modular design approach, which could provide the quantified foundation for a scaleable system. This was a decision full of risk and had large technical and design debt cost. But we also couldn’t just ‘start-over’ with active on-prem customers - to do so would have forked the product so massively that we’d be forced to support an endlessly variable codebase.
Given the design debt, I chose to unify the various Bootstrap versions into Material. This alone took significant validation and QA. Where Material won though was through it’s tabular libraries, something which the Bootstrap variants struggled in terms of legibility and it’s ability to handle mass-data in responsive environments. It won through also on its extensive developer documentation. It was not a light decision - the technical debt had to be costed and it was significant. But it became the first trust-leap with the stakeholders that provided some early velocity. Velocity was, in my mind, more important. We needed to move, or appear to move quickly, and to prove to the stakeholders and the product itself that we could decide change, execute change, and the world wouldn't end.
Sometimes simply moving from a place of paralysis, even if the decision is risky, is better than staying still.
Define Accessible.
Formsflow was not accessible. Given the client-type, this was an important refactor. Additionally from type to colour to responsive behaviour, the product displayed inconsistency to the point of illegibility. With Material as the foundation and buy-in I moved quickly to deploy a token system that could over-ride existing style sheets to quickly deploy change.
This is basic stuff - 12px <p> moves to 16px <p>. But it makes sense also to alter the future component grid. If the token changes you are making cannot adhere to something concrete, you’re adding more variables into the mix. I implemented a responsive grid based on the quant we had, added mobile specific structures, and moved everything to an 8px grid structure with a 4px divisible.
This broke a lot of things. But what it broke provided clear prioritization. If the accessibility baselines broke surfaces or bounding, then this was the hot-fix priority. To allow this to happen we moved the product to a Staging > QA > Production environment, where previously Staging was missing. This added more process and cost, but it reduced risk.
The tokens considered scale, they considered consistency and they considered future expansion. The debt cost as calculated was tempered by the consideration that this is a ‘one big push’ - pushing the tokens and grids immediately allowed for less QA specific spend on component deployment going forward. Product could with some confidence expect the behaviour and edge case knock-on effects from a component or change deployed on each breakpoint, on a 8px grid with the tokened surface luminance.
Colour in particular was very considered. Formsflow had a long history of custom UI per-client install, often at the cost of accessibility. So tokens had to consider not only the correct surface contrasts, primaries and system needs, but it also had to consider how those various stops could translate into a client documentation environment when the client has a specific design system they wanted to apply to, override or compliment our own.
This forced a lot of research and trade-offs, but it also forced the colour theory into a more mathematical environment. By taking known design system luminance of the client base, I was able to calculate with Claude Code the best stop progressions that could match to hundreds of possible outcomes, and provide a solid progression framework that kept the accessibility guidelines in check - both on our own systems and with incoming custom systems.
The same was true of iconography. The longer I’ve been leading in design, the more I’ve found custom iconography to be a fools errand. They have their place in brand systems, and that intercept, but at scale, especially with the Enterprise scale of Formsflow, we needed to adapt an existing icon system into our own. I identified Lucide as having the lowest debt, aligned it to our grid, scale and future-proofing, and placed the token system into the development hand-off as a technical-heavy Figma Dev export. This ultimately made the handover minimal, but it expedited the buy-in from a dev team that was burdened by UX refactoring work (which was at this point universally hated by everyone).
Rebuild.
Given that the development team was starting to face mass-refactor, I started to move at this point towards components. Again, this doesn’t really make much sense. Typically from the IA you would move to flows, and from flows you would move to components. The danger I was facing here was being caught in a ‘re-skin’ scenario where the UX and IA gaps were being papered over. But to maintain momentum and gain developer buy-in we need to start building. Without development feeling like they were actively in a state of contribution, but rather ‘being told what to change’, I risked unmooring the developer appetite. This is change management 101, but this is also about managing expectation at the same time. I also needed to not only re-skill the development aspect into a new definition of what good looks like, but also begin the path of up-skilling the existing design staff in what the expectation is, and what levers they can pull. If the development team was unmotivated, the design staff become quickly handcuffed to micro-improvements.
We began by identifying which heavy-use UI elements failed accessibility and token changes. A simple first task was calendars. Calendars are a solved problem, but only if they are consistently handled. Material gave us a low-stake approach out of the door, but Formsflow has some legacy feature needs that required customization. We tackled this, followed by dropdown behaviours, before moving to navigational tabs.
What this approach did was to begin instigating the IA shift in reverse. I do not recommend anyone does this ever. But the combined mass-change effect of tokens and systems, apathy and need for higher momentum politically made this the best path to take. What the outcome was here was an IA that changed per push, and blend of build and refactor, and a slow incremental QA that did not tax resources or worry the enterprise base.
Over the following 6 months we deployed nearly an entire incremental component system, which dovetailed with the grid, token and custom guardrails in hand.
This is not sexy work. It’s very slow, incremental and pseudo-political progression. But in my experience, it’s how in some environments things get done. You have to adapt to the needs of the customer, the org, the resources.
Reconnect.
With the system near-fully deployed, I returned to both Marketing and higher-level Product strategy. We needed funnels, we needed billing, we needed support. We also needed multi-turn AI form building and AI form submission features.
For Marketing, given the funnels were broad, there was a strong need for mass-landing page generation based on use case or search criteria. I started a sub-derivative of the Product Design System, presenting a reduced token and colour set, expanded the font abilities and redrew the primary logos and touchpoints to align. From there I anchored this sub-set in Figma and deployed MCP to allow Marketing a free approach to modular builds within structured brand guidelines, which I extended into hosted brand pages that could be accessed also by MCP.
This provided mass-consistency across the product touchpoints, while keeping complexity low. A Marketeer could spin up a landing page using a product of their choosing, or external web resource, and deploy via MCP into the active build. Likewise a customer could build a form via MCP (for example Claude) and access UI tokens from their instance. This kept design requests low and provided filter-down from the product strategy. If a component updated, and required a token change (or more commonly a icon addition), this could be commanded from the main Design System down to the Marketing sub-system down to the MCP and directly on the landing pages or agentic interface.
Agentic future proofing.
There is a sense that AI should be leveraged on the product surface as much as possible, even if it’s not directly solving a user problem. At worst this generates apathy and clutter.
In the case of Formsflow, the need was there. A user could semantically build a form instead of using a dated drag and drop interface, and there was a real gain in allowing that same semantic process to bypass the mass-complexity of BPMN workflow coding. Given that in a large organization the use case of the form designer was so vast, it made absolute sense to apply semantic processes where possible.
The big issue with semantic additions is cost. I first began working with semantic LLM products back in 2015, which was pre-cloud LLM. This was very costly from a hosting point of view - a basic semantic engine could leverage multi-EC cores and skyrocket your server cost depending on the mass data being parsed. With cloud LLM, the cost implication is moved to token renting.
When designing semantic / agentic flows, beyond the use case, I focus primarily on token burn. The industry is in flux, and the business models around the tokens are often unknown at scale. This means I tend to design cynically for token use, and presume that the preferred flow or system I want to impose is likely aligned to an increase in token burn. So this means that it largely makes sense to develop a design strategy which is angled towards low token usage, comprehensive prompt creation (ideally user generated) and the ability for human-in-the-loop QA (ideally user generated) that does not try to rely on unlimited multi-turn revisions. It makes little sense to implement a strategy that potentially maximizes token burn for a better outcome, if that better outcome undermines the products ability to function (or indeed the business to function).
While typical agentic users are used to token limiting in Claude, especially those used to free-tier casual use, it is implied in the subscription SaaS environment - and very much in the high cost enterprise environment - that token limiting is punitive, or seen as a cost-save measure. Effectively your tiered SaaS or costed Enterprise tier model in Agentic futures is stuck with a cost variable in a core feature which, if high-value, not only creates your retention, but also generates your highest capital expense.
So with this in mind I tried to approach the AI implementation in a way whereby usage metering was not a primary lever. It was also key to build feedback loops into the agentic offering early in the iteration so there could be human-in-the-loop validation at the metric side, but also trust markers on the user side.
The approach I took was building a Design System that contained Agentic components that could be used anywhere in the product where AI would be featured, while keeping those components separate from the usage metering. Usage metering would be its own component set and applied logic. In this way the Agentic components moved freely from business model constraint, removing 3rd party variables. In turn the business model could be iterated in the less-user facing usage metering logic.
Outcomes.
This is not a beautiful portfolio piece, nor is it particularly than dynamic to talk about, but Formsflow was one of the more challenging and comprehensive products I’ve worked on, simply because of it’s footprint and complexity. In many ways Formsflow is the sort of project that can be solved with experience - the solutions are often simple, often procedural, often deft and nuanced and involve deep thought. But these are the projects that typically become the most interesting to be involved in and the most rewarding to find solutions for.
Formsflow has now deployed to public cloud, private cloud, open source, on-prem and MCP environments with a unified language. Formsflow public cloud has since started taking on paying customers, and the public cloud has generated a much needed market signal that has unlocked additional enterprise revenue.
