Process3 min read

Not a PM, but I run the projects

"Project Manager" isn't in my title, but on a small agency team someone has to keep the design, the build and the client moving together. Here's what doing that has taught me.

My title says Web Designer and Front-End Developer. That's accurate. I design the interfaces and I build them. But on most of the client projects I work on, I also do something that isn't in the title: I run them.

On a small agency team, nobody's job is only to hold everything together. Someone still has to do it: understand what the client needs, walk the backend developer through the work, keep track of what's done and what's next, and make sure the thing actually launches. Because I sit between design and development, that person is usually me, and usually for about three projects at a time.

I didn't plan to become the one who coordinates everything. It happened gradually. These are the three habits that make it work.

1. Listen for what the client is trying to achieve

Clients rarely arrive knowing exactly what they need. They know what they want to happen. My job is to listen for that, and then design toward it, even when it means suggesting something they didn't ask for.

On a project for a marina operator, the goal behind the brief was simple: they wanted more berth bookings. So I added a berth map to the site, so visitors could see the berths at a glance. Then I built the content around it: how to contact the team directly, and which documents are needed to book a berth. By the time someone sends an inquiry, they already have what they need, and the conversation with the client's team goes faster.

The berth map wasn't in the original request. It came from understanding what the site was for.

2. Show the backend developer, don't just describe it

Every handoff starts with a call. I walk the backend developer through the Figma file, and by then I've usually already built the front-end prototype. They can see exactly how each part should behave instead of guessing from static screens.

A working prototype answers most questions before they're asked. It saves a lot of "what happens when you click this?" later in the build.

3. Break it into tasks and review each one

After the call, I turn the work into a task list in ClickUp. We build function by function. When one is done, I review it first, and then it goes to our manager for a final review before we move on.

Small, reviewed steps mean problems show up early, while they're still easy to fix, instead of all at once right before launch. It's also what makes running three projects in parallel manageable: at any moment I know exactly which function each project is on and who's reviewing it.

What I'd tell another designer in this position

If you're a designer who's slowly becoming the person who keeps projects moving, take it as a skill you're building, not extra work on top of your real job. Listen past the brief, show people what you mean instead of explaining it, and build in small steps that someone actually checks.

The title might not change. The work you can do will.