The project itself :
Project Overview
Coherence is a complex platform and toolkit for building multiplayer games and connected experiences.
I was a founding senior designer who led the end-to-end product design and research for the software.
Problem:
“I can’t find what I need when using coherence. When I encounter errors, I don't know how to fix them.”
- User interview.
“We need something that is faster to demo.”
- Stakeholder.
Goal:
Make Coherence onboarding and navigation more clear and efficient.
My role:
Principal Product Designer specialising in the Software component of the Product.
Responsibilities:
Leading research.
Leading the product design.
Product strategy.
Getting started:
Understanding the Product & Aligning Stakeholders
At the start of the project, I built a strong understanding of the product by working closely with the Head of Product and the CTO . This also included collaborating with marketing and sales to understand how the product is positioned and sold, and with developers to identify technical constraints and system limitations.
As we weren’t starting from scratch, it was important to understand the product’s history. What had been built, what worked, and where challenges existed. I also reviewed existing research and data to build on prior insights rather than duplicate effort.
This gave a clear view of the product’s current state and scope.
Problems we know so far…
Setup:
Setup was spread across multiple screens and workflows.
Understanding:
Users lacked a clear mental model of how the system worked.
Recovery:
When something went wrong, users couldn’t easily recover.
What we had to work with
Analysing data and research, I started to map out the product by going through it end-to-end.
Implementing Continuous Research
Building on the mapped journeys, I conducted research to validate assumptions and gain deeper insight into real user behaviour.
I had a lot of avenues to conduct research, which were:
Speaking with companies already using Coherence.
Game Jam Events ran by Coherence.
Quantitive research, such as analytics. Seeing drop off points, etc.
Given the evolving nature of the product, I established a continuous research approach rather than relying on fixed research cycles. Instead of conducting a few rounds of research followed by static iterations, I embedded ongoing feedback loops.
This approach allowed us to continuously adapt the product in real time. As the platform was still early-stage, with fewer technical constraints and more flexibility to iterate, I was able to act quickly on insights and refine the experience as I learned.
Pro tip: UX Insights and Game Jams - I go into this more on this blog post here.
The above showed what analytics surfaced. The main drop off points were during Onboarding.
Designing a cohesive product:
Iterative Design
With a foundation of existing and ongoing research, I approached this with an iterative design approach. Designing alongside research, learning, failing fast. Worked closely with developers to prioritise builds, allowing space to explore and resolve more complex challenges.
System Thinking & iterate, iterate, iterate
Rather than addressing isolated issues, the goal was to rethink the experience at a system level.
Testing and research showed me that:
Navigation is fragmented: users were forced to move across multiple screens to complete simple tasks which contributed to a drop off of over 50%.
Lack of system understanding: users couldn’t troubleshoot or recover from errors due to limited visibility and explanation meant support tickets were difficult to keep up with on our end.
Inefficient onboarding: setup took too long, particularly impacting demos and time-sensitive events like game jams. Onboarding could take anything from 20 minutes to an hour.
These core challenges shaped the design direction, focusing on simplifying navigation, improving system clarity, and reducing time to get started.
Above is a flow I created showing the product from end-to-end and showing how most of the users I researched were actually using it. Not how Coherence preferred they used it, but how they were actually using it.
For instance, they didn't:
Refer to the documentation.
They skipped parts of onboarding and went rogue at times.
The other screenshots was some quick, lowfi concepts to share with the team. Followed a crazy 8's style, where I worked with a few engineers and designers to come up with some quick concepts, not really focussing on quality, but quantity just to help cover all basis.
Stakeholders were shocked to see how users were actually going through the SDK parts. Which helped translate the problem to them. The above concepts helped visualise how we could fix it.
How to create an MVP in a fast moving environment
Visualising direction to get buy in for MVP.
To support flexibility, I intentionally kept design work a few weeks behind development. This created space to respond to Stakeholder feedback and ongoing research, enabling us to pivot when needed without slowing progress.
Using insights from research, I translated key pain points into early prototypes to explore potential solutions. These prototypes focused:
Simplifying navigation.
Improving system understanding.
Having onboarding in one screen rather than fragmented and all over the place.
Visualising the product became very important to get Stakeholder buy in before we progressed. Meetings could go in circles because we were focussed on what to build with very little alignment. In a way, prototypes became more about creating a vision where we could bring everyone together (Stakeholders, Developers etc) and get alignment on difficult and complex problems.
Screens show clearer guidance when navigating → Onboarding in one area that is clear and concise.
Failing fast
Fail fast at Design stage. Prevent failures at Build and Release stages,
The problem: While consolidating setup into a single space improved structure, testing revealed that the experience had become too linear. Some users preferred to explore independently and didn’t want to follow a guided tutorial. They already had enough understanding to get started, using documentation only when needed. For these users, a forced tutorial introduced friction which slowed them down. This also increased onboarding time, not decreased it.
Also, for current users, it was jarring to see so many changes at once.
Where I made improvements with errors and improved understanding of the product, it failed in efficiency and engagement.
This highlighted an important insight: while upfront guidance can support learning, making it the only onboarding path can be restrictive. The challenge became balancing structured guidance with the flexibility to explore. Ensuring users could engage with the product in a way that suited their experience level. Avoiding the 'one size fits all' approach.
The above direction enabled us to:
Onboarding was part of set-up. This allowed users to feel like they were interacting and doing things whilst learning what is they're doing with concise sentences and links to documentation to increase knowledge of the product.
This allowed users to explore and decreased timing on Demos. If you knew what you were doing, you could fly through this with ease.
Everything was within a central Hub section. No longer fragmented, but something that could be scaled and easier on the brain to configure and understand.
Metrics showed we were headed in the right direction
Analytics showed over the months that sign ups, installation and onboarding was on a steady increase showing that the changes were working.
In one month, we got over 1k sign ups completed. As Marketing used an improved demo and onboarding was more efficient, more users were engaged.
I also helped:
Reduce onboarding time from 20+ minutes to 5 minutes.
Reduction in error handling tickets. Less time spent helping users.
Contributed to Coherence’s growth post-$8M Series A, helping scale the product and improve the user experience.
The clear version:
Refinement & Phased Delivery
Following validation, I refined the design and prioritised what could be delivered immediately versus what would form part of a longer-term vision. Larger or more complex ideas were scoped for future iterations, ensuring we focused on impactful improvements that could be shipped quickly and benefited users whilst the iron was hot.
What was delivered
The Hub transformed a previously constrained concept into a scalable, flexible solution.
This approach allowed us to build a solution that could scale and evolve over time, while continuing to iterate directly in the live product. A key consideration was balancing meaningful change with stability and avoiding disruptive updates for existing users while still improving the experience for new ones.
By focusing on incremental, well-considered changes, we were able to introduce a more intuitive and flexible experience without compromising the workflows that current users relied on.
You can watch that end-to-end journey here:
Final thoughts:
Outcome
With an increase in sign ups, installation and completed onboarding, Coherence is headed in the right direction with the room to scale and improve.
Takeaways
I came away with more lessons on how to handle Stakeholders and the wider business than I did anything new with Design itself.
Learning one:
Don't think of design as siloed screen. Think of it as designing an entire system from end-to-end. Understand the product. Don't just listen to users, but listen to CTO's, Business and Developers.
Learning two:
By combining continuous research with iterative design and live testing, I was able to make informed decisions quickly and adapt the experience as I learned. This is a key strength for Start-Ups and Scale-Ups.
Next Steps
Coherence is on the right path to iterate and improve. As Coherence grows, change will stabilise, making early scalable foundations essential.
Scale and iterate, but make sure it's informed and not blind-siding current users.
Continue to grow foundational aspects, such as the design system, principles, rules etc.