Research and prototyping for an AI creative platform
In August 2025 a Bristol-based AI business asked me to research and design an internal creative tool.
To protect the client's interests, I've removed specific project details due to their sensitive nature.
Role
UX researcher and designer
Client
Confidential
Duration
6 days
Platform
Native web tool (React)
When
2025
Setting the scene
A Bristol-based AI company, specialising in tools for conversational gameplay and world-building, hired me to research their current tooling and suggest future upgrades.
The existing tool was functional but basic, with limitations that blocked new features. My task was split into two phases:
1. Short-term Goal (The Bridge Tool): Design a simple, new tool to bridge the gap between the old system and modern features. It needed to be feasible for development within a couple of months.
2. Long-term Goal (The '2026' Vision): Propose a more elaborate, expanded tool using an interface akin to visual scripting or node-based editors, planned for development in 2026.
The approach
Let's address the biggest factor in this project: the available time. The budget allowed only six days to understand the problem, conduct research, and provide a toolset prototype. Frankly, six days is a tight squeeze, but that constraint became a powerful motivator to ensure every hour was used effectively.
It's important to remember that six days isn't enough time to find the perfect solution, but it is enough time to find a validated solution.
In a quick turnaround project, the temptation is always to jump straight to design - skipping the 'boring' stuff for the exciting solutions. The reality, though, is that you still need to spend time researching and analysing. Without that information, you're just assuming. Assumption is the biggest risk to any design. I'll say it louder for those of you at the back...ASSUMPTION IS THE BIGGEST RISK TO DESIGN.
To mitigate that risk, I split the time: half on research and analysis, half on design and prototyping. This ensured the final deliverable was a solution validated by proper research.
The first step was clear: identify the most important project components. An effective outcome is paramount to the client, and the only way to ensure that was to talk to the people who would use the tool. That's where I started.
Stage 1
Research
This is where the groundwork of the project is laid. It's all about capturing as much data as you can, from which you can begin the analysis stage. I conducted user interviews and competitor research to build an understanding of the product from multple angles.
Stage 2
Analysis
Analysis of the research data allowed me to build a picture of the current issues and how they hold back existing tools. Thematic analysis and affinity mapping provided me with the direction from which to start thinking about solutions.
Stage 3
Design
This is where I started the ideation and sketching phase - taking the information gained through analysis and applying solutions in context with the user needs.
Stage 4
Prototype & Delivery
The final stage was to develop a prototype, presented to the client in a hands-on demo.
I also documented and handed over ideas and sketches of ideas for the '2026' tool.
Stage 1 : Research
The first stage is always research, but the challenge lies in identifying the most effective research methods for the specific project.
Given the restraints of the user base and the time budget, qualitative research was the clear priority.
My focus was threefold:
-
Tool understanding: gaining an understanding of the existing toolset and planned future features.
-
User insight: gathering direct opinions and needs from the users.
-
Market context: analysing how competitors had solved similar problems.
What the client had and what they needed
I started by using the existing toolset to identify strengths and weaknesses. Given the quick turnaround, I focused on evaluating if the tool could be improved simply by applying missing UX fundamentals.
I then interviewed the technical team to understand upcoming features and how the tool would need to support them. Using these insights, I sketched out the technical requirements of a core gameplay loop, which gave me a clear understanding of the back-end data structure that the front-end tool needed to manage.
User interviews
I interviewed both technical and creative users to understand the different ways they interacted with the existing tool and what outcomes were most important to them.
Competitor research
I conducted competitor research on similar tools. This allowed me to understand the different solution approaches: some companies relied on complex visual scripting tools, while others opted for simpler, more recognisable UI that traded flexibility for ease of use.
Researching - user interviews
I conducted user interviews over Zoom, speaking with four users in total: two from a technical background and two from a creative background.
My aim was to capture a diverse range of opinions since the goals of technical and creative users vary significantly. For example, some focused purely on narrative flow, while others spent their time analysing debug information.
After each session, I noted the main talking points and captured key quotes to help summarise their views.
Creative user
"95% of all of the work that was done...was in this conversations section"
Creative user
"A customer could never be let loose on this unless they already had, like, some engineering background or something. They would just cause utter chaos"
Technical user
"There's actually a really significant amount of complexity...which the tool, as it stands at the moment, doesn't really help you visualise."
Creative user
"it's a fairly tedious process of just playing the game through over and over and over again, testing it, looking at the state flags, and then tweaking what everything that happened up to that point of that state flag not being set, and why wasn't it set?"
Stage 2 : Analysis
With the research complete and data gathered, it was time to dive in.
While beginning this phase can feel daunting, the crucial first step is to identify the data type and the information you need to extract. This process dictates the type of analysis to perform.
Given the variety of research data collected for this project, I chose to use a combination of thematic analysis and affinity mapping.
Thematic Analysis
I performed thematic analysis on the user interviews. I gathered useful information and views, then codified the data to identify common themes. This allowed me to determine a clear order of priority based on the frequency of specific views.
Affinity Mapping
Affinity mapping was performed for the competitor research. I created a map that split competitor tools based on the focus placed on technical aspects versus creative aspects. This gave me a better understanding of the different approaches taken and the type of users each tool was likely aiming for.
Analysis images
Analysis outcomes
The analysis provided enough information to confidently identify the areas of development that would be most beneficial to both the user and the client.
These findings resulted in three key outcomes, which became the guiding principles for the design and sketching phase. Designing around these outcomes ensured we were on the correct path to building a tool that suited our users’ needs.
Better application of UX fundamentals
I quickly realised the existing tool suffered from fundamental usability flaws. To fix this, we rigorously applied core UX principles, prioritising Consistency and Standards and Error Prevention.
The existing inconsistent workflows caused cognitive overload and stifled creativity. It was therefore crucial to establish predictable standards and clearer feedback, transforming the confusing, technical system into an efficient, professional creative workspace. This decision ensured the tool became immediately usable for everyone, cutting down on the need for constant technical guidance.
Abstracting the technical aspects to focus on creativity
A key research outcome was the decision to entirely pivot the tool’s focus from a technical data editor to a dedicated creative application.
I found that the direct exposure of raw data, like state flags, was a major barrier for narrative designers, forcing them to think like engineers. Achieving abstraction became the critical mandate:
By masking technical complexity and framing the system in terms of narrative concepts - such as Knowledge, Objects, and Events - we empowered the team to concentrate purely on storytelling logic, solving their frustrating dependency on technical colleagues.
Feedback and visualisation
The final, and perhaps most significant, insight was the absolute necessity of providing immediate, contextual feedback and designing visual structures that clearly showed causality.
I determined this was vital because the existing "black box" system was crippling user confidence and making complex testing a nightmare.
By introducing appropriate visualisations - such as a Quest/Story timeline or a node-based view - we could finally "open the black box".
This gave the team instant, visual insight into how a change affected the story’s progression, dramatically boosting both iteration speed and accuracy.
Stage 3 : Design
This is where I began visualising solutions based on the key outcomes from the research and analysis phases. The task was now to investigate how to design effectively to solve the problems identified.
I also had a solid foundation for the direction of the designs, thanks to the competitor feedback. We used the collected data on how competitors approached similar solutions as a strong basis for the general direction of the new tool.
Data flows and hierarchy
Before jumping into digital designs, I start by sketching user journeys and data hierarchies. This helps align user interaction with how the information is stored and presented.
For this project, the user journey was based on how their actions affect back-end data manipulation, rather than a traditional app flow. This was crucial because I needed to fully understand the data structure before I could solve the complex visualisation problem.
Sketching
The next stage was sketching lo-fi wireframes to visualise how the tool would look and operate. The goal here is to quickly see and 'feel' the tool - and if it doesn't work, discard it quickly and start over.
Based on user research, I replicated a common workflow during these sketches to identify process improvements. I prefer working on paper because sketching multiple ideas and using a paper-based component library allows for lightning-fast iteration. (You can see an example of my paper-based component library in the section below.)
Medium fidelity designs
Once satisfied with the sketches, I moved on to creating medium fidelity designs in Figma.
This process begins to formalise the design and structures developed during the sketching phase. Transposing the concepts into digital designs helps us better understand how the tool feels on the device it would be used on.
Design progression
The design phase consisted of rough sketching, wireframing, paper prototypes, and digital designs. Each stage contributed to a deeper understanding of how to best support the user experience.
Design outcomes
Design isn't just about generating ideas; it's also about learning what to prioritise.
For this project, the main outcomes centered on managing data complexity and defining the scope of the two necessary tools: the short-term 'simpler' solution and the '2026' fully-featured version.
The most important takeaway was learning what to leave on the cutting room floor. We explored designs that fully abstracted the technical back-end for the user's benefit. However, due to the required overhead (a full translation layer), we had to place a limit on data abstraction. A feature that can't be supported, no matter how good on paper, leads to a poor experience.
Ultimately, the design phase gave me a clear understanding of how to separate the two tools, prioritise the most critical features for each, and create a smooth pathway for the future, more complex tool.
Identifying what was important for now, and what's important for the future
A key learning during this stage was the inherent complexity of the back-end data.
Because simplifying this complexity was a difficult challenge, I decided the solution required splitting the tool into two functions:
-
Function 1 (immediate): present the data in a clear, simple, and functional form, aligning with core UX fundamentals.
-
Function 2 (future): combine visualisation and content creation into one tool - the more advanced '2026' tool.
This clarified my focus for the immediate version: design an interface that effectively presents the data to the user while strictly adhering to core UX principles.
Identifying the functional layers
We returned to the core project criteria: delivering an achievable solution within a short timeframe. To meet this, the design phase focused on a modular system containing distinct 'layers' of functionality.
The tool is completely functional at the base layer, with each successive layer stacking to add UX improvements. This presentation helped the client easily prioritise the features and assess the development overhead.
The suggested layers are:
-
Base layer (raw data display): the foundational layer, focused on strong UX fundamentals for displaying large amounts of textual, raw data supplied to the back-end system.
-
CRUD & usability: adds full CRUD (create, read, update, delete) operations. This includes usability improvements like the ability to expand/hide large data sets for improved scannability.
-
Debug layer: allows users to modify and visualise data and the relationships between different data types, clarifying how content relates to other elements.
-
Data abstraction: creates a new interface that abstracts the raw data into a view directly illustrating the relationships between data types.
Stage 4: prototype & delivery
Once the designs were formalised, the next step was to develop prototypes for testing and client presentation.
It's important to note that this project was fundamentally a research and feasibility challenge. Ordinarily, this phase involves testing and iteration; however, our situation required creating a robust prototype, presenting it to justify the design decisions, and fully documenting it for the client's decision-making at a later date.
Prototype development
The first stage was prototype development, completed in Figma.
The goal was to create an interactive prototype of the tool's core features. This prototype would be presented to the client and serve as the reference point for their future decision-making.
Presentation
It's vital to communicate your work effectively, so the next stage was presenting the prototype and supporting documentation to the client.
This session allowed the client to fully understand the proposed solution's core features and ask key questions about the design and flow.
Annotations
Following the presentation and client feedback, annotations were added to the designs and prototype to capture notes on potential changes and additions.
This is an important step that would ordinarily lead to further iteration. However, given the project's time frame, continuous iteration was not necessary for this specific phase.
Delivery
The final stage was packaging up all the learnings, prototypes, analysis, and data and formally handing it over to the client.
Since a final decision was likely weeks, if not months away, the client required all information to be on hand for when they were ready to proceed.
Presenting prototypes
Presenting prototypes and ideas is a crucial part of the design process, as much of UX revolves around effective communication - whether that's sharing information with the user or providing validation to major stakeholders.
You must be able to present your ideas, as this is the only time you'll find out if they work (at least before they go live).
For this project, the presentation was conducted via Zoom with all major stakeholders. Everyone was given a link and able to share their direct experiences using the prototype during the meeting.
Learnings of the prototyping and delivery phase
The main learning from the presentation and client feedback was confirming that we delivered a solution, rather than the solution. We concluded the phase with new, specific questions, such as how features like 'state flags' should be implemented.
We also identified that this first version should serve as a baseline for the '2026' software. This '2026' version is less a separate tool and more an expanded feature set, focusing on enhanced visualisation that allows users to see their entire project in context with the content they are creating.
Project outcomes
These final takeaways are more personal than professional. I can't speak entirely for the client - but I believe this project was an excellent exercise in working with constraints but still maintaining a process that can lead to effective solutions.
I always like to try and think of a phrase or quote that can sum up a project - and I think for this one it's the phrase we've used a few times during this case study.
The quote that sums up this entire project is simple: Regardless of the constraints, the goal is always to deliver a solution, and never to burden yourself with the pressure of delivering the perfect solution. The truth is, it's never perfect. There's always someone that wants to do things differently, or suggest a change - for better or worse. The important thing is to try things out, validate your designs, and trust the process and your instinct.