This interview is with Ian Lawson, Founder | Website Planning, UX & Content Strategy Expert, Slickplan.
For readers meeting you for the first time, how do you describe your work as a Founder focused on website planning, UX, and content strategy?
My work as a founder is centered around one thing: bringing structure to a process that most teams experience as messy and fragmented.
I started out running a digital agency, and the biggest issue across projects wasn’t design or development. It was the lack of clarity before any of that started. Teams were juggling too many tools, making decisions too late, and trying to solve structural problems with visual design. That’s what led me to build Slickplan. It was a direct response to a problem I dealt with on real projects.
On the UX side, my focus has always been upstream. UX is not just interface design; it’s structure, flow, and how content is organized before anything gets designed. I’ve spent years refining that through both client work and building my own product, constantly iterating based on how real teams actually work.
Content strategy came from the same place. You can’t separate content from UX. The way content is structured is the experience. A lot of what I do now is about helping teams think through that earlier, so they avoid confusion and rework later.
At a high level, my work is about simplifying complexity: turning a scattered process into something clear, collaborative, and actually usable.
How did you carve your career path into website planning and site structure within the internet industry?
My path into website planning and structure wasn’t intentional. It came from seeing where projects were actually breaking.
I started in the early 2000s with a background in graphic design and business, right when web design still felt like the wild west. I worked my way through every layer of the process: design, development, content, project management, even teaching it at the college level. By the time I launched my agency in 2008, I had hands-on exposure to how websites were really built across different teams and industries.
What became clear very quickly was that most problems had nothing to do with design quality. They came from poor planning. Teams were jumping into visuals before the structure was defined, content wasn’t mapped out, and decisions were happening too late. That’s where I naturally shifted my focus—not because it was the most exciting part, but because it was the part causing the most damage.
Slickplan came directly out of that. We saw the same breakdowns in our own agency workflow, fixed them internally, and turned it into a product. What started as a tool to clean up our process ended up resonating with a much bigger audience.
The shift was simple. I stopped focusing on what looked good and started focusing on what actually made projects work. “Structure is what determines whether a website succeeds or struggles.”
Building on that, when you start a new engagement, what is the first structural decision you lock to prevent rework later?
The first structural decision I lock in is the sitemap — not just a list of pages, but a clear, agreed-upon hierarchy showing how everything fits together.
Most teams treat the sitemap as a formality. It’s not; it’s the foundation. If the structure isn’t locked early, everything that follows remains fluid. Design changes, content shifts, and scope creep occur because there’s nothing anchoring decisions.
I focus on getting alignment around page priority, grouping, and flow: how content is organized, what belongs where, and how users are expected to move through it. Once that’s clear, everything else becomes easier — user flows, content creation, and design all have direction.
In real projects, most rework comes from unclear structure, not bad design. “If the sitemap is still changing, the project isn’t actually started.”
To make that concrete, what is the minimal set of planning artifacts in your website planner before design or copy begins?
The minimal set is smaller than most teams expect, but it must be complete: a clear sitemap, a defined page-level content structure, and primary user flows.
The sitemap locks the hierarchy and scope. Without it, everything else is guesswork. From there, each key page needs a content outline — not full copy, but a structured breakdown of what needs to exist on that page and why. That gives both designers and writers direction instead of a blank canvas.
The third piece is the user flow: how people actually move through the site to complete key actions. This connects the structure to real behavior, which is where most planning falls apart if it’s skipped.
Most teams either overdo planning with too many artifacts or skip it entirely. The balance is simple: “You don’t need more documents. You need the right decisions made early.”
Moving from planning to collaboration, what’s your go-to agenda for a real-time workshop that turns a sitemap into a live workspace for design, content, and stakeholders?
My go-to workshop is built around turning the sitemap from a static diagram into a set of real decisions.
-
I start by walking the structure as a group — page by page, top to bottom. The goal is alignment: does this hierarchy make sense, are we missing anything, and are priorities clear? Most issues surface right here when people actually see the full picture.
-
From there, we shift into page-level thinking: we take key pages and define what needs to exist on them. Not design, just content structure — what sections are required, what the purpose of the page is, and what action it needs to drive. This is where design and content teams start to engage in a meaningful way.
-
The last piece is pressure-testing flows. We map how users move through the structure to complete key tasks. That’s where gaps show up: missing pages, unclear transitions, or unnecessary friction.
Tools help facilitate this, but the real value is in making decisions live with the right people in the room. “A sitemap only becomes useful when a team works through it together and commits to it.”
Translating structure into execution, how do you map that sitemap into content models and fields on CMS or e-commerce builds (e.g., WordPress, custom PHP/MySQL) so dev and content teams can move in parallel?
The key is mapping structure to fields early so content and development can move at the same time, rather than sequentially.
Most teams hit friction here because the sitemap and the CMS are treated as separate steps. Structure gets approved, then developers build models, then content tries to fit into those models later. That’s where things break. Fields don’t match real content, naming gets inconsistent, and teams start reworking each other’s progress.
The way to fix that is to define content at the page level as structured blocks, not loose documents. Each section on a page becomes a predictable set of fields: headline, body, media, metadata.
That’s exactly why I built Slickplan the way I did. The Content Planner sits directly on top of the sitemap, so once structure is defined, you can immediately start creating structured content that mirrors how it will exist in the CMS. From there, it can map cleanly into platforms like WordPress or custom builds through APIs.
The goal is simple. “Content and development should never wait on each other. The structure should make parallel work possible.”
Keeping users at the center, what’s your technique for turning keyword research into navigation labels and page hierarchy that match search intent?
The mistake most teams make is treating keyword research as an SEO task instead of a structural decision.
Keywords are just signals of intent. The real job is translating that intent into clear pages and navigation labels that make sense to users. I start by grouping keywords by what the user is actually trying to do, not just the terms themselves. That naturally shapes both the page hierarchy and how content is organized.
Personas play a role here too. If you understand who you’re building for and what they need, it becomes much easier to decide which terms belong in navigation and which belong deeper in the structure. Navigation should reflect how users think, not how teams talk internally.
In practice, this means choosing clarity over cleverness. If a navigation label matches search intent but confuses a user, it’s the wrong label.
Shifting into delivery, which practices or tools keep the build and release process visible and smooth once development starts?
The biggest thing is keeping the work visible across teams. Once development starts, projects get messy when structure, content, design, and development are all being tracked in different places with no shared view of progress.
For me, that starts with having the website plan connected to execution. We use Slickplan to keep the structure, content, and planning decisions clear, then pair that with a lightweight project system for delivery. Internally, that usually looks like a practical, stripped-down version of Agile: short cycles, clear owners, and fewer meetings than most teams think they need.
Outside of Slickplan, I use Notion a lot for operational visibility. It works well for tracking tasks, decisions, documentation, and release readiness without adding a lot of overhead. The tool matters less than the discipline behind it, though. Everyone needs to know what’s done, what’s blocked, and what changed.
The smoothest launches come from simple habits, not complicated systems. “If progress isn’t visible, delays aren’t discovered until they become launch problems.”
After launch, in the first 30 days, how do you use analytics and user behavior to validate that the site structure is working?
In the first 30 days, I’m not looking for every possible insight. I’m looking for proof that the structure is doing its job.
That usually starts with the basics: Are users reaching the right pages? Are they moving through the intended paths? Are there obvious drop-off points that suggest confusion or a mismatch in the hierarchy? We use analytics to spot those patterns, then pair that with behavior tools like Hotjar to see where people are engaging, hesitating, or missing key paths entirely.
I pay especially close attention to whether important pages are pulling their weight and whether users are interacting with the top of the page as we expected. If the structure is right, navigation feels natural and people move with less friction. If it’s wrong, you usually see it quickly in exits, weak pathing, or pages that should matter but clearly do not.
I’m not the person on my team living inside analytics dashboards all day, but I know what signals matter. “In the first 30 days, the goal is not optimization. It’s validation that the structure matches real user behavior.”
Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?
If there’s one thing I’d add, it’s this. Most website problems don’t start with design or development; they start much earlier.
Teams move fast, skip structure, and then spend the rest of the project fixing things that could have been avoided. Slowing down at the beginning actually makes everything faster.
Honestly, the process doesn’t have to be painful. With the right structure and a little alignment early on, building a website can feel a lot less like chaos and a lot more like a team actually working together.
Or put simply, “a little planning upfront saves a lot of headaches later.”