Process

I’ll ask you lots of questions to find out about your organisation and the project. If it seems we could be a good fit, we’ll have a short call to discuss things further.

Assuming that goes well, the first thing we’ll do is agree a small initial piece of work to kick things off.

In my experience, putting together a fixed brief at this stage commits us to a scope that we’ll probably want to change later. A small, flexible initial piece of work lets us experience working together without too much risk

Once we’ve sorted out the contract, initial deposit and start date, we’re ready to get going.

First up, we’ll schedule a standing weekly call for everyone involved in the project. This is a key part of the process that:

• maintains project momentum (critically important)

• gives you regular time to give in-person feedback and ask questions

• helps up develop a great working relationship

This meeting is as close to a non-negotiable as things get. Trust me, it’s a game-changer.

Next, we’ll start our initial mini project. This might involve discovery, collaborative moodboarding, wireframes, or something else entirely.

These early phases are often the most demanding from a feedback perspective, and it’s crucial to get your input at this stage. Noes are as useful as yeses, and you’ll really have to go out of your way to offend me with feedback (this isn’t a challenge).

I deliver most of my design work with a video walkthrough. This means the work, thinking and context can be shared asynchronously with the project team.

If everyone’s happy with the process and initial experience, we’ll continue working together.

Now we’re in the thick of it. I’ll be iterating and creating work at various levels of fidelity. We’ll push design boundaries to find where the line is help us work out where to settle.

I think and design in components and modules, rather than pages. This is how developers think, and the end result is a flexible system we can use to build your site.

I’m not dogmatic about designing mobile-first or desktop-first. For each component, I’ll consider what the most difficult viewport is likely to be, and work from there.

Because we’re not working to a fixed scope, we can easily adapt the project to suit new learnings or objectives. No awkward ‘out-of-scope’ conversations: we just decide if the new direction is worth the anticipated effort and change in priority.

I’ll still be seeking your feedback through this phase, but demands on your time will diminish as we become clearer on design direction.

I’ll also be checking in regularly with developers for input on implementation and accessibility details.

Once we’re confident on the design intent, I’ll start packaging up the components and styles, ready to pass on to developers.

I recommend starting this process as soon as possible. Doing this early is often more efficient than waiting until every single component is designed.

Once development starts, I’ll continue working on any outstanding components until we’ve tackled everything we need.

I’ll make myself available to developers for design QA and working through any additional design or implementation details.

Once the project is launched, we’ll assess your ongoing needs and how I can support you.

Where we anticipate a need for regular support, we might work out a monthly retainer. Otherwise, if you need small bits of advice/support over a longer period (e.g. a few hours over several months), a time bank may be more appropriate.

And that’s it! What now?

• If you have questions or would like to discuss a project, get in touch

• If you haven’t already, take a look through some of my work