Roleplay AI: Positioning, Architecture, Interaction
At an early stage startup, design leverage does not purely live in the interface. Most requests arrive without a clear shape, and the real work is figuring out where the problem actually lives before building anything.
As the founding designer, I worked on that problem at three levels:
- Positioning: running the validation behind the shift to sales coaching
- Architecture: designing the configuration model behind self-serve roleplay
- Interaction model: reframing the brief, from a role reversal to a new interaction model
Alongside them, I built the design function itself. More on that in the reflection.
Positioning
0→1: From Management Coaching to Sales Coaching
Problem
Roleplaying was a powerful learning mode attached to a low-urgency problem. Managers are time-poor, and practicing management skills with voice AI didn't beat typing into a generic LLM. Without a concrete stake, there was little reason to make practicing a habit, which made the product difficult to retain and sell.
Strategy
Over two months, I led the design and research side of rapid validation: conducting surveys and in-depth interviews, shaping fake-door and concept tests, and synthesizing the results into product directions. The PM owned commercial relationships; together, we killed weak bets and tested new ones to find where the market fit was.
Outcome
The direction I helped validate and translate into product repositioned roleplay from management coaching to sales coaching. We first validated it with a tech-sales enterprise, then entered BFSI, where high-volume, high-stakes sales gave practice clear ROI. Landed Prudential, followed by more enterprise clients across 7 APAC markets within six months of release.
0 → $2.5M ARR in two quarters.
Architecture
1→10: Building for Scale
Problem
The product was early, and the team was still learning the market, so no one had made a deliberate architecture decision yet. Every new client meant another manual build: I synthesized client materials, designed the scenario, handed off to engineering, tested and launched. Engineering didn't hold the full map of the product; design did.
Because I was also the one testing every build, I noticed the same issues kept repeating, down to small UI inconsistencies. That repetition was the signal: this wasn't a one-off bug, it was a structural gap.
Strategy
I surfaced the repeated build and QA issues as a structural problem, then partnered with engineering leadership on a platformized approach.
I decomposed the experience, mapped what was fixed versus variable across clients, and designed the configuration model and self-serve tool.
Outcome
- The configuration model I designed reduced routine roleplay setup from roughly six engineering hours to 30 minutes of self-serve configuration, removing engineering from the standard setup path.
- Built the foundation for scale as we raised our Series A, enabling self-serve onboarding for future enterprise clients and giving existing clients a path onto the new system.
Object
Scenario
Interaction model
Expanding Roleplay to Advisor Readiness Suite
Problem
Roleplay assumed reps already had something to say. Newer reps often didn't, making live scenarios more exposure than practice. A client asked to reverse the roles in our existing roleplay, where the AI performs and the rep observes. Product & Engineering initially just reversed the roles within the current interface.
But performing and observing are different interaction models.
Strategy
I challenged the assumption that a role reversal could reuse the existing experience. I separated the underlying objects that could transfer from the interaction, controls, and learning outputs that needed to be redesigned for observation.
We also wrapped it in a natural language interaction through a chat function, where they can riff with a tailored AI coach.
| Objects | Practice mode | Learn mode |
|---|---|---|
| Scenario | Sales scenario | Reused |
| Persona | Customer persona | Reused |
| Role | User = advisor, AI = client | User = client, AI = expert advisor |
| Objective | What the learner should accomplish | What the learner should observe |
| Output | Performance score + coaching | Takeaways + framework + reusable scripts |
This project is still fairly recent, so the designs are under NDA. Happy to walk through it in a conversation.
Outcome
The resulting experience turned an initial POC into a full-scale enterprise rollout.
It also set a precedent. Instead of reversing the roles for the least effort, we treated learning as its own interaction model. When the next roleplay-style request came in, the team stopped asking how to reuse the existing flow and started asking whether it was a different experience altogether.
Reflection
Beyond the Interface
When a product is still searching for PMF, the interface is only one part of a much larger system. If something isn't working, the problem might be the interaction, the product strategy, the onboarding, the GTM approach, or even the market itself.
Working closely with product and company leadership taught me to move between the different layers.
As Hupo grew, I also began to see how the org itself shaped the work. Processes, decision-making structures, and team culture influenced how people collaborated and what design could accomplish.
I became more intentional about shaping those conditions, not just designing within them. That meant establishing shared design foundations, building tools, and creating practices that helped design work across functions.
It also meant thinking about culture. In enterprise design, delight often takes a back seat to functionality and business needs. But I still wanted to make room for creativity in how we worked.
One example is this interactive onboarding experience I built for new designers. Rather than simply documenting our design practices in a Google Doc, I wanted to give them a feel for the kind of team they were joining.
Not every design decision needs to be visible in the product. Some of the most consequential ones shape the systems, relationships, and environments in which the product gets made.