The Process
If you're considering working together, here's what the process typically looks like. Projects move through a few consistent phases, from early clarity through to launch, though not every engagement follows them in exactly the same way.
Discovery
I start by understanding the problem before defining a solution. That means looking at goals, constraints, existing systems, and the people who rely on them.
The aim is to surface patterns, risks, and assumptions early, so decisions are based on context rather than guesswork.
Depending on the project, conversations often touch on things like:
What exists today
Any current materials, systems, tools, or processes involved, whether that's a website, a document, a visual identity, or an internal workflow, even if it feels incomplete or outdated.
What's not working
Friction, limitations, recurring issues, or concerns that prompted the conversation in the first place.
Constraints and realities
Timing, budget ranges, internal capacity, approval processes, or external requirements that shape what's possible.
Structure
I turn what emerged during discovery into a clear plan. This defines scope, priorities, and direction so decisions stay aligned as the project moves forward.
The result is a shared understanding of what's being built, what's out of scope, and what "done" looks like.
At this stage, the focus is on clarity and alignment:
Scope and focus
What's included, what's not, and where effort should be concentrated to create the most value.
Organisation and hierarchy
How information, content, or components should be structured so they're clear, usable, and maintainable over time.
Decision framework
Agreed-upon principles for making choices as details evolve, reducing uncertainty later on.
Build
This is where ideas become tangible. Design and execution move forward together, with progress shared in working form rather than abstract concepts.
This phase is iterative, so adjustments are easy while there's still room to make them.
During this phase, collaboration typically includes:
Work-in-progress reviews
You see drafts, layouts, prototypes, or samples as they develop, rather than waiting for a final reveal.
Providing source material
Text, images, data, reference documents, or other inputs needed to work with real content instead of placeholders.
Ongoing alignment
Short check-ins to confirm direction and resolve questions before they compound.
Refine
With the structure in place, attention shifts to clarity, consistency, and quality. This is about the details that affect how everything reads, functions, and holds together.
This phase is about polish, not rethinking the foundation.
Refinement typically involves:
Focused feedback rounds
Reviewing specific aspects with clear criteria, rather than broad or open-ended revisions.
Consistency checks
Making sure tone, visual language, structure, and behaviour feel cohesive across the whole system or deliverable.
Edge-case review
Looking at less obvious scenarios to confirm everything holds up beyond the "happy path".
Launch
Launch is the transition from active production to real-world use. Final preparation ensures everything is ready to hand off clearly and confidently.
The goal is a clean, deliberate finish rather than a rushed endpoint.
Before launch, attention is usually on:
Final review and sign-off
Confirming everything meets the goals and expectations established at the start.
Ownership and access
Making sure files, systems, credentials, or documentation are in the right hands.
Next steps and support
Clarifying what happens after delivery, including maintenance, updates, or future phases if needed.
Starting Questions
What if I don't know exactly what I need yet?
That's completely normal. Most conversations start with a general concern, a rough idea, or a sense that something isn't working as well as it should. The early phases are designed to help clarify what matters most and what direction makes sense.
Do I need a detailed plan or brief before reaching out?
No. A brief can be helpful, but it's not required. Notes, examples, or questions are more than enough to get started. Structure and clarity come out of the process, not before it.
What if our current setup is messy or outdated?
That's often the case. Things don't need to be polished or well-documented to have a productive conversation. Understanding what's there, even if it's fragmented or fragile, is part of the work.
Is this only for brand new projects?
Not at all. Some engagements start from scratch, while others focus on improving, restructuring, or extending something that already exists. Both are valid starting points.
Who should be involved from your side?
Anyone who understands the goals, constraints, or day-to-day realities of the project. That might be a single decision-maker or a small group. The process adapts to what's practical for your organization.
What happens after the first conversation?
The initial discussion is about listening and understanding. From there, I'll propose next steps based on what surfaced, whether that's further exploration, outlining options, or deciding that something smaller or different is more appropriate.
Is there any pressure to commit right away?
No. Early conversations are about clarity, not obligation. You'll have time to consider whether the direction and approach feel right before moving forward.
Ready for the First Conversation?
You don't need a brief, a plan, or all the answers. The first step is simply talking through what's happening and what might make sense next.