Evo

Evo began as a strategic ambition, not a neatly bounded product.

The vision was expansive: a future-facing geoscience platform spanning desktop and cloud applications, APIs, shared services, and new micro-capabilities such as notifications and web visualisation. It was intended to serve not only geoscientists and engineers, but also developers, data scientists, IT stakeholders, partners, and decision-makers working across mining and civil environments.

That level of ambition is exciting. It is also dangerous.

Because without clearer audience definition, stronger market framing, and a more grounded understanding of what people were actually trying to do, a platform vision of this scale can quickly become too broad to guide product decisions well.

My role in this programme was to help turn that ambition into something more concrete. I contributed to the formation of the business model and product strategy, defined target audiences, shaped the initial UX and research plan, synthesised analysis, and developed early prototypes to support testing and production planning. The work spanned a multidisciplinary team across Christchurch, Auckland, Vancouver, and Toronto and required challenging foundational assumptions about what Evo should be, who it should serve, and how its value should be expressed.

Role User Experience Lead

Capability Product strategy, Service design, Information architecture

System Data platform, Enterprise SaaS

Evo was Seequent’s strategic initiative to define a cloud-based platform for the future of geoscience software. The intention was not just to launch another application, but to create a broader ecosystem that could connect tools, data, people, and workflows across the life of a project.

That meant the design problem was upstream of interface design.

Before anyone could confidently decide what the product should look like, the team needed stronger answers to more fundamental questions:

• who are the real audiences?
• what jobs are they trying to get done?
• where does a platform create value beyond point solutions?
• what would make customers, partners, and executives believe in the opportunity?
• how should Evo differentiate itself in a world of desktop tools, fragmented data, and emerging cloud ecosystems?

1. Discovery & Strategic Framing

The first challenge with Evo was that its vision was bigger than its definition.

There was already energy around the idea of a cloud platform. There were opportunities around APIs, interoperability, collaboration, and new digital services. There was also a real strategic need: the future of geoscience software was not going to be solved by desktop tools alone.

But a broad platform narrative is not yet a product strategy.

The work needed stronger framing.

Starting with desirability, not just feasibility

One of the most important moves in the programme was approaching Evo from the desirability lens first. That is not always how platform work begins. In many organisations, platform thinking starts with architecture, internal capability, or technical possibility.

Here, we pushed for a more grounded question:

That reframed the discovery work. Instead of beginning from internal assumptions about what a platform should include, we focused on the needs, behaviours, and aspirations of the people Evo was meant to serve. This brought more objectivity to the business design process and helped the team move from broad hypotheses to more evidence-based thinking.

Replacing assumptions with facts

The programme was deliberately structured to challenge internal certainty.

We set out to identify the major assumptions sitting underneath the Evo vision and replace them with evidence from interviews, research, synthesis, and feedback. That mattered because platform strategies can become dangerously abstract if they are not regularly pulled back toward what users and partners are actually experiencing.

This made the work less about defending a pre-written vision and more about discovering where the real opportunity sat.

Thinking in ecosystems, not just products

Another key framing shift was that Evo was not simply an application opportunity. It was an ecosystem opportunity.

The potential value was not only in offering new cloud features, but in connecting tools, partners, customers, and workflows in a way that could deliver disproportionate value across geology and engineering contexts. That required looking beyond traditional product boundaries and asking how data, integrations, collaborators, and complementary capabilities might work together in a more connected environment.

That ecosystem perspective shaped much of the later segmentation and strategy work.

2. Research, Segmentation & Product Definition

The research phase was where Evo started becoming more legible.

We engaged a diverse range of customers and partners across industries, functions, and levels of expertise. These were not lightweight feedback sessions. They were open-ended conversations designed to draw out stories, frustrations, ambitions, and patterns that would not surface through more rigid interview formats.

The point was not to collect opinions about an imagined platform. It was to understand what people were already trying to accomplish, where their current workflows were breaking down, and what would make a new platform proposition credible to them.

Audience definition became a strategic tool

As the interviews and synthesis progressed, it became clear that the existing ways of segmenting the market were too blunt. Industry verticals alone were not enough. Nor were simplistic assumptions about “users” and “partners.”

A more behaviour-driven view was needed.

That led to a stronger segmentation framework that looked at customers and partners through the lens of:

• what jobs they were trying to get done
• what commercial or strategic relationship they might have with Evo
• what pains, gains, and barriers shaped their behaviour
• how their motivations differed even when they operated in adjacent sectors

This was an important shift because it gave the product strategy more usable structure. It helped define not just who Evo might serve, but why those groups would care.

Customer value propositions

The customer segmentation work moved away from simple industry grouping and toward behavioural categories based on role type and the jobs people were trying to get done.

This was a much stronger lens for product design. It highlighted the fact that different audiences might work in different sectors but still share similar operational goals, frustrations, or value expectations. By mapping jobs, pains, gains, and product fit more explicitly, the team could see where Evo’s proposition was strongest and where the platform would need to do more to become compelling.

Partner value propositions

The partner work was equally important and arguably even more strategic.

Rather than viewing partners only through old categories such as alliance, reseller, or integration type, the framework shifted toward understanding them based on their reciprocal commercial relationship with Evo. That transformed the conversation. It made the team think more clearly about partner incentives, the shape of mutual value, and where ecosystem participation would create real leverage rather than superficial network breadth.

That was particularly useful for a platform proposition, where partner logic often matters as much as end-user logic.

Personas as strategic artefacts, not just UX outputs

Once the audiences were better understood, we derived personas from the interview material and segmented research. These were not decorative deliverables. They were used to make the audience model more concrete and help the team reason about behaviour, aspiration, decision criteria, and context in a more applied way.

The personas helped bring more shape to the strategy by clarifying:

• how different audiences defined value
• what decisions they were trying to make
• what barriers they faced in adopting new tooling or ecosystems
• where Evo needed to support not just functionality, but confidence and credibility

Service and workflow mapping

The broader service blueprint and task mapping work helped the team see Evo as a connected experience rather than a bundle of capabilities. It clarified the higher-level flow of how the product might be built, accessed, used, extended, and supported across an ecosystem.

This was useful because it gave design and development teams a shared way to view the moving parts of the platform at a systems level. It also created a structure that could support simultaneous exploration of individual components without losing sight of the end-to-end flow.

3. Prototyping The Platform Direction

With the strategic groundwork in place, the next step was to make the platform direction more tangible.

At this stage, the objective was not to lock the product down visually. It was to test whether the strategy could be expressed in a usable direction. Lo-fi wireframes and prototype flows helped translate the more abstract platform thinking into something that could be reviewed, discussed, and tested.

That mattered because platform strategy can remain too conceptual for too long. Prototyping forced clearer decisions about structure, navigation, integration logic, content grouping, and where the product needed to feel coherent rather than simply ambitious.

Lo-fi wireframes as a strategy test

The early wireframes were valuable because they exposed where the strategic story held together and where it was still too vague. They helped the team ask:

• does this audience model translate into a usable product structure?
• can the ecosystem logic be made understandable?
• where do workflows need to be simplified or staged differently?
• what needs to be present in a beta to meaningfully test the direction?

Those questions made the strategy stronger.

Enabling beta thinking

The prototype work also helped bridge discovery and production planning. Instead of leaving the programme at the level of research outputs and strategic themes, it moved the work toward something concrete enough to support a beta direction.

That was important because the business did not only need insight. It needed momentum. The early design work helped carry the strategy forward into something the organisation could test, refine, and build from.

4. Outcomes & Reflection

The Evo programme resulted in a much stronger foundation for product and business direction.

By the end of the work, the team had:

• a clearer audience model
• more grounded customer and partner segmentation
• stronger value proposition thinking
• a defined UX and research roadmap
• early product structure and wireframes
• a more credible basis for beta planning and production rollout

What this enabled

• stronger market framing for Evo as a platform, not just a cloud feature set
• greater executive and stakeholder alignment around where the opportunity sat
• a research-backed product strategy grounded in real audience needs
• clearer prioritisation for beta exploration
• a better bridge between ecosystem ambition and product reality

Why this work mattered

What makes this project important is that it sits at the part of product design that often gets underrepresented in portfolios.

This was not a polished UI redesign. It was the work of helping define what the product should be, why it should exist, and how to make a strategic platform idea more concrete, credible, and testable. It required research, synthesis, systems thinking, business framing, and enough design fluency to turn those insights into something product teams could actually build from.

Reflection

Evo reinforced something I care deeply about: when the ambition is large, clarity becomes more important, not less.

A vision as broad as “the future of geoscience software” can easily collapse under its own abstraction. The value of this programme was in pulling that vision closer to the ground — into audiences, jobs to be done, partner logic, workflows, evidence, and prototype form.

That is what made the work meaningful.

Not just that Evo was a compelling idea, but that the team left with a stronger basis for deciding what kind of platform it needed to become.