LEARNWISE.AI ∙ 2025
A modular workflow builder for AI assistants
Web app
SaaS
Learnwise.ai are an edtech platform that enables school administrators to configure and deploy AI assistants to their students.
I collaborated directly with their founding team to design their admin tooling and AI assistant interface that scaled to from 1 to 2M users and 40 to 150+ institutions within my first year.
For this project, I collaborated with the CEO, product owner, and two engineers to design what would allow non-technical school administrators to customise their AI assistant’s behavior based on user intent and context.
Problem space
School administrators could reliably trigger escalation flows as the existing help desk system could reliably detect user intent and guide them to human assistance.
However, this help desk feature was too rigid.
Custom AI behavior required engineering involvement
Administrators wanted more control over their AI assistant's behavior, but even simple customization outside escalations required engineering support. The result was an un-scalable workaround where any revisions required going through the process all over again.
Challenges
What made this project particularly challenging was how undefined the problem space was.
During the kick-off conversation, the team brought up how their help desk feature was performing well in terms of being able to reliably identify when to trigger based on the admin-defined conditions.
Beyond that, there was no clear product direction, only a belief that the this could potentially support a broader set of AI-driven workflows.
With this, the closest we got to a PRD was, verbatim: “We need something that recognizes intent and then does something after.”
Ensuring the system was approachable
A major consideration for school administrators, who were domain experts in education, but not necessarily technical users.
I prioritized the capabilities needed to validate the first concept:
The platform needed to start simple enough to be learnable, but flexible enough to support complex behaviours over time. With a major consideration being that the system stayed approachable to school administrators of varying technical expertise.
Initial concept
My approach was to first reduce the problem into modular building blocks for mapping conditional logic and automations.
I first mapped the workflow system into two steps:
- Triggers — set of conditions that initiate the flow
- Actions — what the assistant should do if the conditions are met
From there, I worked closely with the product team to define which capabilities were essential for the first release versus what could be deferred.
Prioritizing foundational interactions
Rather than trying to define every possible AI workflow upfront, I prioritized the foundational interaction patterns that would allow the system to scale over time.
This way, we could start building without all the possible actions defined.
This enabled us to launch with a flexible foundation while continuously expanding available actions based on customer needs and emerging use cases.
Grounding LLM behavior
Another important design decision was made after learning from one of the ML engineers how examples help ground AI behavior.
To make intent detection more predictable, I introduced positive and negative examples into the user message trigger.
Outcome & retrospective
Six months after launch, we were averaging 8 flows per institution with a maximum of 38 flows.
The most common use cases were custom messaging, contextual CTAs, and helpdesk routing, enabling assistants to respond differently based on a student's intent or situation.
More importantly, Flows established a scalable foundation for future AI interaction patterns.
01/ USER REQUESTS
Shortly after launch, customers were already asking for more advanced features like proactive notifications, url-specific workflows, role based conditions, event-based conditions things the existing model could not support.
02/ ITERATING BASED ON USER FEEDBACK
Restructured to support proactive, targeted workflows
I restructured the interaction model by separating flow initiation from decision logic:
- Triggers — when a flow should start, and
- Conditions — whether it should continue
This way admins could have more control over the who, when, and where workflows would activate.
03/ RETROSPECTIVE
This project was ultimately an exercise in designing through ambiguity and providing a designs the team could build upon despite incomplete requirements.
I was need to create enough structure to be useful today, while leaving space for the platform to evolve over time.
What started as relatively simple IF/THEN logic evolved as admins needed workflows that could reach the right user, in the right context, at the right moment.
💌OPEN MAILBOX
ALEXINE MARTINA ©
Made for alexinemartina.com by Alex
