Alex Simpson joined an insurtech startup where Figma was burning hours and stalling decisions. Here's how switching to Moqups changed not just the design process, but how the whole business thinks together.
Honestly, Moqups is my default app. It's always open to the point that I don't even think about it – I just use it.
Meet Curium
Curium is an insurtech scale-up with two core products, a full GRC system (governance, risk, and compliance) and a claims management system. Based in Australia, the company is expanding to New Zealand and currently eyeing the UK as their next market. Curium’s customers come from all segments of the insurance industry: brokers, underwriters, insurers, suppliers, and pension funds.
Meet Alex, the Product Manager
Alex Simpson joined Curium with over twenty years of experience as a Product Manager. Hired by the company’s founders as their first employee, Alex sees his role as twofold. First “to make sure our product has the right market fit, and that it does what our customers need it to do.” But also to act as “translator” between departments within Curium’s fast-growing team – ensuring that requirements and specifications get communicated quickly and accurately.
The Challenge for Curium
“What distinguishes Curium from our competitors,” Alex explains, “is that we have deep industry knowledge baked into our product and process. We’re able to help users adopt best practices, build a compliance culture, and translate that into claims as well.” And Curium can do that quickly, often reducing an expected six-month implementation to only a couple of weeks.
But to provide that kind of service – and to move seamlessly between international markets with different compliance rules – Alex’s team needs to build a bulletproof framework into which Curium can pour its expert content. And that means finding the right visual communication tool so conversations happen at the right time and no detail gets lost.
The Problem with Figma
We were having discussions around high-fidelity design, but the thinking hadn't happened yet about the complexity of the actual feature we were building.
Before adopting Moqups, Curium tried Figma. But it just wasn’t right for their team, or for their needs. “We weren’t all experienced Figma users, so it was very complicated and cumbersome.” More critically, Figma’s focus on aesthetics was actually derailing the process.
“We had endless conversations about where we should put a button, or what color it should be," Alex recalls. "The focus was very heavily on design and colors. But the important thinking about the functionality – how things should actually work – was getting lost in the noise."
The team needed something more than a design tool: an app that any member of the team could use, and one that allowed for thoughtful explorations of a feature’s purpose. Enter Moqups.
The Solution
The breaking point came when Alex was trying to explain a key edge case to a developer. It wasn't overly complicated, but they'd already spent five hours in Figma just trying to get it to look right. "This is ridiculous," he thought. "I can't show what I want to communicate because I can't draw it quickly enough." Alex had used Moqups before, so that's what he turned to.
I said, let's just open Moqups. Within a couple of minutes, I'd mocked it up, and the developer got the idea. And I was like – well, let's just complete it here and send it off. We can have this developed by tomorrow.
From that point on, Figma was sidelined for product work. "Why are we wasting hours messing around in Figma," Alex asked the team, "when that's not what we need?"
The Moqups Advantage
Alex's approach with Moqups is deliberate: keep everything as simple as possible. He prefers grayscale boxes and shapes, and nothing that invites a conversation about color or shadows.
"My goal was to stop all of these premature design conversations," Alex explains, "and to start having a back-and-forth about what a feature actually needs to do, rather than just how it looks and feels."
With Moqups, we ideate in meetings and literally just drag and drop boxes onto the screen to collaborate, asking "What if we did this?" or "What if we did that?" We allow discussions about purpose and functionality to open up – without people focusing on the wrong things.
Once there's consensus about a new feature, Alex will map out the full user flow, adding the screens and requirements for each step. That way, when the developer opens the file, they can immediately see the entire journey – the flow, the UI, and the documentation together, in a single view. No switching between apps, and no missing context.
An App for the Whole Team
The product team initially adopted Moqups for their wireframing and prototyping but, one by one, other teams also found reasons to use the app. The development team now uses Moqups to comment on requirements. The Head of Operations uses it to build board-pack materials. Sales uses it for presentations and diagrams. Implementation teams produce client-facing assets in Moqups. And sometimes, when a new feature is pending, marketing will grab the wireframes, add color, and have promotional material ready to go.
Alex says the key to this widespread adoption is Moqups' accessibility and ease of use: "When people join my team who have never used it before, it's literally a non-issue. I just say, "Here's your account" – and then they don't need any help onboarding. They just start doing stuff. That's it."
Everything from org charts to grant and award submissions to investment applications has been built in Moqups. As a result, the whole company's visual knowledge lives in one place, and that has helped break down bottlenecks and departmental silos. As Alex says, "All our people can access Moqups to do whatever they need."
Moqups for Complex Projects
Curium's claims-lodgement module presented a particularly demanding test case for Moqups. Insurance claim forms are dynamic – answer one question a certain way and you see a follow-up; answer it differently and you get a different path. These trees branch and branch again. A relatively simple form can produce a flow of 600 to 800 steps. Complex forms can produce thousands!
We use Moqups to communicate those flows to our clients: "Okay. Are we right? Is this good?" And then only once all the stakeholders have signed off in Moqups do we go on to create the actual forms.
For Alex's team, Moqups isn't just an internal tool – it has become part of how Curium works with its customers directly. The visual flow sits between both sides as a shared reference point: something to read, question, and agree on before anything is committed to code. The clarity of this sign-off process removes the ambiguity that normally causes implementation projects to drag. This sort of collaboration is only made possible by the fact that clients can use Moqups as easily as the Curium team.
Show, Don't Tell
There's a story Alex tells that gets right to the heart of Moqups. Working on some financial screens, he needed to show a developer how two fields in a form should interact – each one calculating from the other. Words weren't getting it across, so he mocked up the interaction instead. "Like this, see?"
Sometimes, words aren't enough. It's quicker to just show it.
It sounds simple. But that capacity to make thinking visible – and fast enough to be acted on – is what runs through every Curium use case that Alex describes. It's also, perhaps, why the idea of switching tools has never occurred to him. "It doesn't even enter my head," he says. "I don't even think about looking for another tool. Moqups is just a part of my day."
