For Agencies

Our Work

Why Splice

For Business

Accessibility

Contact

Main Navigation


<p>There are two prevailing attitudes toward AI in creative circles: the apocalyptic and the dismissive. Somewhere between “it’s coming for your job” and “I don’t even want to talk about it” lies a middle ground where AI can genuinely assist agencies in working faster and smarter without compromising the creative process.</p>



<p>This isn’t about replacing designers. And no, it’s not about letting ChatGPT generate your next brand system. It’s about using AI as a tool to expedite the mundane tasks, reduce repetition, and clear the runway so your team can focus on the meaningful work.</p>



<p>Here’s what we’ve learned about where AI fits into the design-dev workflow and where it absolutely doesn’t.</p>



<h4 class="wp-block-heading">Where AI Doesn’t Belong (Yet)</h4>



<ul class="wp-block-list">
<li>Brand nuance: No AI tool understands your client’s brand voice, tone, or intent the way a strategist or designer does.</li>



<li>Design decisions: Tools like Midjourney and Adobe Firefly might spark ideas, but they don’t replace creative direction or art direction.</li>



<li>Creative intuition: AI isn’t going to invent a brilliant, unconventional concept that surprises and delights. That’s still your job. (And we like it that way.)</li>
</ul>



<h4 class="wp-block-heading">Where AI Can Actually Help</h4>



<ul class="wp-block-list">
<li>Wireframing and layout starters: While tools like WireGen previously offered AI-driven wireframing capabilities, they are no longer maintained or available in the Figma Community. For designers seeking to integrate AI into their workflow, consider exploring <a href="https://uizard.io/" target="_blank" rel="noreferrer noopener"><strong>Uizard</strong></a> for transforming text prompts into wireframes, <a href="https://www.figma.com/community/plugin/1151890004010191690/magician" target="_blank" rel="noreferrer noopener"><strong>Magician</strong></a> for enhancing design elements within Figma, and <a href="https://www.getstark.co/" target="_blank" rel="noreferrer noopener"><strong>Stark</strong></a> to ensure accessibility compliance. These tools are actively supported and can significantly streamline the design process.</li>



<li>Filling in real-ish content: Instead of lorem ipsum, use tools like <a href="http://claude.ai" target="_blank" rel="noreferrer noopener"><strong>Claude</strong></a> or <a href="https://chatgpt.com/" target="_blank" rel="noreferrer noopener"><strong>ChatGPT</strong></a> to create content that resembles the final product, helping both designers and clients visualize layout and flow.</li>



<li>Naming and variant generation: Naming layers, creating alternate headlines, writing microcopy, these are all great low-stakes areas for AI support.</li>



<li>Version clean-up: Developers on our team use Claude to help summarize and repackage complex technical explanations for clients. It saves time and keeps things human-readable.</li>
</ul>



<h4 class="wp-block-heading">How We Use It (and Why It Helps You)</h4>



<p>At Splice, we use Claude and other AI tools to handle repetitive or time-consuming tasks: cleaning up commit messages, writing rough page structure code, even auditing site content for accessibility flags. That saves our team hours we can reinvest into solving harder problems like complex integrations or custom feature builds.</p>



<p>It also lets us stay lean without burning out our people. Which means better pricing, more time for strategic thinking, and a development partner who can keep up without cutting corners.</p>



<h4 class="wp-block-heading">Take a Deep Breath</h4>



<p>AI isn’t magic. It’s not going to design your next award-winning website. But used thoughtfully, it can make the work smoother. Faster. Sometimes even better.</p>



<p>We’re not afraid of AI. We see it as a necessary evolution in how creative and technical teams work. The real opportunity lies in using these tools to elevate human performance, not replace it. Done right, AI can reduce burnout, free up mental space, and give people more time to do the meaningful, creative work that still needs a human touch.</p>



<p>And if that means your team has more space to focus on the creative, that’s a win for everyone.</p>



<p>Want help integrating AI tools into your workflow? Or just curious about what we’re using? <a href="/contact/"><strong>Get in touch</strong></a> — we&#8217;re happy to share what we&#8217;ve learned.</p>



<p></p>


post

Using AI in the Design Workflow


<h4 class="wp-block-heading">Why Your Design and Content Choices Need to Flex for Every Breakpoint</h4>



<p>We don’t need a separate mockup for every screen size. But we do need to talk about how your design (and especially your content) translates across them.</p>



<p>Modern frameworks have made responsive design second nature; we’ve got the media queries, flexible containers, and layout systems to make things technically work across screen sizes. But what often gets missed isn’t the layout. It’s the content itself.</p>



<p>That sweeping panoramic hero video that looks stunning on a 4K desktop screen? On a mobile phone held vertically, it’s either cropped to oblivion or hidden altogether. That elegant hover animation with layered parallax? It’s great… unless you’re using your thumbs. And the intricately styled mouse-based carousel? It falls flat when there&#8217;s no mouse in sight.</p>



<p>This isn’t a “designers should know better” kind of rant. It’s more of a heads-up from the dev and QA teams who are flagging these mismatches late in the game, after the client’s seen the full desktop experience and is now previewing mobile a few days before launch.</p>



<p>At that point, there’s a mad dash to recut images, hide features, or find alternate video clips that actually work on small screens. Everyone’s stress level spikes, timelines get tight, and we all wonder how we got here.</p>



<h4 class="wp-block-heading">Mobile-First Isn’t Dead—It’s Evolved</h4>



<p>We’re not here to wave the “mobile-first” flag just because it was trendy in 2016. But we do believe in thinking about mobile first-ish. Not because it’s a requirement, but because so much content consumption actually happens there. Designing for mobile forces prioritization. It clarifies what’s essential and what’s decorative.</p>



<p>It’s also a helpful lens for evaluating interaction. Are you designing for touch or mouse? Are you considering tap targets, scroll behavior, and what happens when there’s no hover state? Because your dev team is.</p>



<h4 class="wp-block-heading">Optimize the Content, Not Just the Layout</h4>



<p>We can scale things. But we can’t magically make content designed for a widescreen banner sing on a phone. That’s not a layout issue, it’s a creative one.</p>



<p>Designing with flexibility means:</p>



<ul class="wp-block-list">
<li>Choosing visuals that crop well or provide alternate aspect ratios</li>



<li>Knowing when a mobile-specific asset might be needed</li>



<li>Keeping interactions accessible and usable on touchscreens</li>



<li>Planning fallback behavior for fancy desktop features</li>



<li>Thinking through how a user will experience the content, not just how it will look</li>
</ul>



<p>It also means bringing your dev team in early. Not to nitpick, but to flag potential issues before you’re racing to fix them the night before launch.</p>



<h4 class="wp-block-heading">Let&#8217;s Make It Easier on Everyone</h4>



<p>This is the part where our PMs quietly weep with gratitude: when designers proactively ask, “Will this work on mobile?” or “Do we need a fallback for this on touch?”, it keeps timelines on track and launch days much calmer.</p>



<p>You don’t need to design for 18 breakpoints. But you do need to think about what happens between them.</p>



<p>If you’re not sure how something will scale, or if a feature’s going to break when it meets real content, we’re happy to talk it through early. The more we plan for flexibility, the better the end result (and the smoother the handoff).</p>


Laptop, Desktop, Tablet and Mobile devices

(Screen) Size Does Matter


<p><em><strong>A semi-useful rant for anyone who&#8217;s ever had to “just pencil in a number.”</strong></em></p>



<p>You know the email:</p>



<p class="has-text-align-left">“Hey! Quick favour&#8230; we’re pitching on a site build and need a dev estimate to include in the proposal. We don’t have wireframes or access to the client yet, but here’s the sitemap. Can you send us a number by end of day?”</p>



<p>It’s not malicious. It’s not even rare. Honestly, it’s just… Tuesday.</p>



<p>We know the situation well. You’re working off limited info, maybe the project is part of a competitive bid, maybe it’s a returning client, maybe it’s just the end of the quarter and you’ve got a <strong><em>this</em></strong> project-shaped hole in your forecast. We’re not judging. We’re here with you.</p>



<p>But here’s the thing: <strong><em>sitemaps are not scopes.</em></strong></p>



<p>They’re a starting point, sure. But estimating development based on a list of URLs is like pricing a house based on how many rooms it has, without knowing if one of them is an indoor pool and the other is a VR cave.</p>



<h4 class="wp-block-heading">We Can Work With Limited Info… To a Point</h4>



<ul class="wp-block-list">
<li>We’re always happy to give a ballpark if we know a few basic things:</li>



<li>What CMS are we building in? (WordPress? Sanity? Something custom?)</li>



<li>Is it multilingual? (Localized content = more dev complexity.)</li>



<li>How many post types are we working with? (Pages, case studies, blog, products, etc.)</li>



<li>Are there integrations? Anything weird? If you don’t know, ask if it “connects to anything.”
<ul class="wp-block-list">
<li><em>Also: We wrote a whole post on <a href="https://cm.splicedigital.com/agency-insights/how-we-estimate-the-weird-stuff/">how we estimate the weird stuff</a>.</em></li>
</ul>
</li>



<li>Are there GDPR or compliance needs? (Cookies, data handling, etc.)</li>



<li>Will the site include complex animations? (Parallax = time and budget.)</li>



<li>Design system: Custom or themed?</li>



<li>Are we building something bespoke from scratch or implementing a Figma-to-template build?</li>



<li>How many pages total?</li>



<li>Content entry—who’s doing it? Us? You? The client? (Please not the client.)</li>



<li>Are we migrating content from an old site? If yes, we need the URL. And maybe a drink.</li>



<li>How relevant is the current site’s structure? </li>



<li>Are they consolidating, expanding, or burning it down and starting fresh?</li>
</ul>



<p>Give us anything that helps us picture what’s actually being built, and we can give you a much smarter estimate or better yet, a range with a discovery phase baked in to validate the direction.</p>



<h4 class="wp-block-heading">Yes, Discovery. Again.</h4>



<p>I know, we sound like a broken record. But just like your design team wouldn’t dream of quoting a new branding package without understanding the client, we can’t scope accurately if the functionality is still a mystery.</p>



<p>If your client is asking for “a quick quote” before they’ve even shared the full brief, set the expectation that technical discovery is part of the process. It protects you. It protects us. And most importantly, it protects your budget when things start getting real.</p>



<h4 class="wp-block-heading">Help Us Help You (Even When You Have Nothing)</h4>



<p>We know sometimes you <em>just don’t have the answers yet</em>. The client’s being cagey. The pitch is due tomorrow. The strategy deck isn’t done. The content doesn’t exist. The Figma file is named something like &#8220;<em>homepage_final_v.8_draft</em>&#8220;. We’ve been there. We’re still there. And we still love you.<br><br>So, here’s the deal: if you’re flying blind, tell us. We can usually give you a <strong>range</strong>, not for the proposal, but for your own sanity. A rough “low if it&#8217;s basic, high if it&#8217;s bananas” estimate based on what little we do know. You can use that to pressure-test the budget internally before you go committing to anything.<br>But please, for the love of spreadsheets and sleep, <strong>don’t drop it into a fixed-bid proposal</strong> without at least a caveat. <br><br>Something like:<br><em>“Development estimate based on current assumptions. Subject to change pending technical discovery.”</em><br><br>Even better, bake in a line item for technical discovery and call it what it is: <em>essential due diligence</em>. Not fluff. Not padding. Just the part where we figure out what this thing actually is before promising to build it. And if that still feels like too much to ask? At least forward us the email chain where the client says, “It’s a simple site.” We’ll print it out and keep it in our <em>famous last words</em> file.<br><br>J.</p>



<p></p>


Scoped to Fail


<p>Navigation isn’t just a design choice. It’s infrastructure. And if it isn’t built on a strong foundation, you’ll feel it post-launch, when your client is poking around their shiny new site and suddenly realizing they can’t find half the content they asked for.</p>



<p>We’ve seen it enough times to know it’s worth talking about: navigation can’t just be designed in a vacuum, and it certainly can’t be scoped as an afterthought. It’s one of the most important (and most misunderstood) parts of a digital project, and it works best when designers and developers collaborate early, and when the client is willing to challenge their own assumptions.</p>



<h4 class="wp-block-heading">The Role of Information Architecture (IA)</h4>



<p>Before you even think about top nav, sticky headers, or mobile menus, you need to understand what the site is meant to do. That means:</p>



<ul class="wp-block-list">
<li>Defining core user flows</li>



<li>Auditing and organizing content</li>



<li>Understanding page depth and hierarchy</li>



<li>Identifying repeatable patterns (like FAQs, team bios, product listings)</li>
</ul>



<p>When the IA is strong, the navigation often falls naturally into place. When it’s weak, you end up band-aiding your way through the build and making compromises that frustrate users and limit growth.</p>



<p>We’ve built sites where a hamburger menu on desktop worked well because the content was minimal, the goals were clear, and the layout supported that decision. But we’ve also had to rebuild navigation structures post-launch when those same patterns didn’t support more complex content needs.</p>



<p>There’s no universal &#8220;wrong&#8221; design decision. It all comes down to context, and that starts with IA.</p>



<h4 class="wp-block-heading">Why Designers Can’t Go It Alone</h4>



<p>Designers bring incredible UX instincts to the table, and often have a strong grasp of user behavior and brand storytelling. But it’s easy to get caught up in inspiration sites and visual aesthetics, especially when clients are pushing for something they saw on Apple’s website.</p>



<p>The reality is, your client isn’t Apple. And their content probably doesn’t mirror the slick one-page scroll they sent you as a reference. Your job is to help them understand what works for their users, and that starts with realistic expectations about what kind of navigation structure will support their goals.</p>



<p>That doesn’t mean saying no to bold creative ideas. It just means testing those ideas against the content, goals, and constraints of the actual project. That’s where dev comes in.</p>



<h4 class="wp-block-heading">Why Dev Needs a Seat at the Table</h4>



<p>As developers, we’re often handed final designs with navigation baked in; menus, drop-downs, accordions, mobile states, all with the assumption that the IA is solid and the structure has been tested.</p>



<p>Sometimes that’s true. But more often than we’d like, once the build is complete and the client starts using the CMS, they realize it doesn’t work the way they thought it would. Or worse, they ask for changes that weren’t scoped, and now the nav needs to be re-architected.</p>



<p>We’re happy to build anything. But it’s always better (and more cost-effective) to pressure-test navigation early. We can:</p>



<ul class="wp-block-list">
<li>Spot scalability issues before they go live</li>



<li>Flag patterns that won’t translate well to mobile</li>



<li>Help map user journeys to real page structures</li>



<li>Offer solutions that balance creativity with functionality</li>
</ul>



<p>Bringing dev in early also helps avoid the dreaded post-launch nav rebuild, which eats up timelines, budgets, and good will.</p>



<h4 class="wp-block-heading">Why Navigation Is a Dev Problem Too</h4>



<p>We’ve seen it enough times to know it’s worth talking about: a site gets built exactly to spec, only for the client to realize post-launch that the navigation looked great but didn’t really work for their content.</p>



<p>It’s not about blame. It’s about how navigation often gets treated like a design flourish instead of what it really is, a functional system. Clients bring examples they love (and that do work—for those brands), but those same structures can fall apart under a different content model.</p>



<p>As a dev team, we can build anything. But redoing navigation after launch is expensive, time-consuming, and frustrating for everyone. The best outcomes happen when designers advocate early for nav systems that support real structure and goals, not just the client’s Pinterest board.</p>



<p>When we collaborate early, we can design and build navigation that’s scalable, accessible, intuitive and that holds up when the client&#8217;s team starts using it.</p>



<p>If you’re second-guessing a nav structure or trying to translate a wishlist into something functional, bring us in early. We’ll help pressure-test it before it becomes a problem.</p>


Why Navigation Is a Dev Problem Too


<h4 class="wp-block-heading">Why handing off a Figma file isn’t always enough—and what to consider instead</h4>



<p>We’ve seen both sides of the spectrum: the beautifully organized Figma file with well-documented components, and the “everything’s in here somewhere” version with inconsistent font weights, spacing, and zero annotations. One of those is much easier to work with, and one often leads to a lot of back-and-forth right before launch.</p>



<p>Let’s be clear: we love working with great designers. The ones who give us a style guide. The ones who tell us what every button looks like (default and hover). The ones who show us how link styles should appear (though we’ll always remind you: underline them for accessibility—<a href="https://cm.splicedigital.com/agency-insights/accessibility-the-overlooked-pillar-of-great-web-design">here’s why</a>). That level of clarity lets us build faster and more accurately, which is good for your timeline, your budget, and your sanity.</p>



<p>But more often than not, we get a Figma file and… not much else. No spacing rules, no consistent heading structure, and no clear guidance on what’s intentional and what isn’t. Sometimes things look inconsistent because they’re meant to be. Sometimes they’re just inconsistent.</p>



<p>Here’s the problem: if we build it exactly as it appears in the design file and something looks “off,” the instinct is to assume development made a mistake. But without a design system, we’re guessing—are those 56px and 72px top margins a creative choice, or just a copy-paste artifact?</p>



<p>This isn’t a blame game. This is a call for better tools, better process, and better collaboration.</p>



<h4 class="wp-block-heading">What’s the difference?</h4>



<p>A <strong>design file</strong> is a snapshot. It’s a set of screens with layouts and assets that represent how a product <em>should</em> look in certain states. But it often lacks the context that helps translate design into code.</p>



<p>A <strong>design system</strong>, on the other hand, is a source of truth. It includes the components, states, spacing, styles, and usage rules that inform how everything should behave across the product. It’s not about over-documenting—it’s about setting shared expectations.</p>



<p>Even a simple token sheet that includes:</p>



<ul class="wp-block-list">
<li>Heading hierarchy</li>



<li>Button styles (primary, secondary, disabled, hover, focus)</li>



<li>Link treatments</li>



<li>Field inputs and validation states</li>



<li>Spacing rules</li>



<li>Color palette and contrast ratios</li>
</ul>



<p>…can dramatically improve the handoff process and reduce development time.</p>



<h4 class="wp-block-heading">Does atomic design still apply?</h4>



<p>Atomic design principles (organisms, molecules, atoms) aren’t mandatory, but they’re helpful for framing how UI components relate to each other. If your design system is structured this way, it’s easier for developers to map out reusable components and build a scalable codebase. If not, that’s okay too—but consider organizing your components logically and consistently, so they’re not hidden in a “Misc” folder 18 artboards deep.</p>



<h4 class="wp-block-heading">What we <em>don’t</em> want</h4>



<ul class="wp-block-list">
<li>Font sizes that change by 1px with no pattern.</li>



<li>Random padding values across pages.</li>



<li>Six different call-to-action button styles on one site.</li>



<li>No guidance on what a hover or active state looks like.</li>



<li>An assumption that the dev team will “clean it up” in the build.</li>
</ul>



<p>That last one is important. If you don’t give us a consistent set of rules, we’ll make our best guess. But that guess might not align with your vision. And it definitely won’t be consistent with your next project.</p>



<h4 class="wp-block-heading">The ask</h4>



<p>We’re not expecting full-blown design systems for every site—especially for smaller projects. But even a lightweight guide that outlines key decisions helps us build exactly what you envisioned. Better yet, loop us in early and we’ll help flag anything that might need clarification before it becomes a QA issue.</p>



<p>This doesn’t just make life easier for devs. It improves design consistency, reduces bugs, shortens review cycles, and keeps clients happy.</p>



<p>We’ll always build what you give us. But if you want it to look <em>exactly</em> like what you designed, don’t just send us files—send us the system.</p>



<p></p>


Design Systems vs. Design Files


<p>Accessibility often shows up at the end of a project, right before launch, when it’s too late to really fix anything. But accessibility isn’t a checklist you cram in at the eleventh hour. It’s a collaborative effort between design and development that starts on day one. It’s the difference between creating a site that “looks nice” and one that works well for everyone.</p>



<p>And if you&#8217;re only thinking about accessibility from the design side or the dev side, you’re not getting the full picture.</p>



<h4 class="wp-block-heading">What Designers Can Control</h4>



<p>Designers play a major role in accessibility. Some of the most common (and fixable) violations start here:</p>



<ul class="wp-block-list">
<li>Color contrast: It needs to meet WCAG minimums; subtle greys on white aren’t cutting it.</li>



<li>Font size and hierarchy: Tiny text and non-standard heading orders trip up screen readers and strain users.</li>



<li>Motion and animation: Accessibility means considering users with vestibular disorders or cognitive differences. Auto-playing carousels or scroll-jacking effects? Not great.</li>



<li>Link states and button affordance: If your buttons only look clickable when hovered, you’re leaving out users who navigate by keyboard or touch only.</li>
</ul>



<p>Tools like Stark and built-in accessibility checkers in Figma can help flag these issues before they become code problems.</p>



<h4 class="wp-block-heading">What Developers Can Control</h4>



<p>Once a design hits development, a whole new set of accessibility opportunities and risks emerge:</p>



<ul class="wp-block-list">
<li>Proper semantic HTML: Using real heading tags, labels, and ARIA attributes isn’t optional.</li>



<li>Keyboard navigation: Ensuring all interactive elements can be accessed and used without a mouse.</li>



<li>Skip links and focus management: Essential for screen reader and keyboard users.</li>



<li>Alt text and dynamic content: Making sure all media and generated content has meaningful descriptions.</li>



<li>Even the most thoughtfully designed site can fall short without accessibility-minded development.</li>
</ul>



<h4 class="wp-block-heading">Where Things Break Down</h4>



<p>Accessibility isn’t the job of just one team. When it’s only the designer’s responsibility, or left entirely to devs to &#8220;code it in,&#8221; details fall through the cracks. And when it’s treated like a nice-to-have, users suffer.</p>



<ul class="wp-block-list">
<li>Making accessibility a shared priority means:</li>



<li>Reviewing accessibility implications during the wireframe and design stages</li>



<li>Building in accessibility as a default, not an add-on</li>



<li>Testing with screen readers, keyboard-only navigation, and contrast checkers</li>



<li>Prioritizing fixes when violations are found, not punting them to &#8220;Phase 2&#8221;</li>
</ul>



<p>It’s not harder; it just takes intention.</p>



<h4 class="wp-block-heading">A Word on Accessibility Widgets</h4>



<p>Accessibility overlays and widgets, those floating buttons that offer text resizing, contrast toggles, and other adjustments can seem like an easy fix. And to be fair, they’re better than nothing.</p>



<p>But here’s our POV: they’re not a substitute for doing the work.</p>



<p>Accessibility should be built into your design system and development practices. When you rely on a widget, you’re putting the burden on the user to make your site usable. Often, those overlays conflict with assistive technologies or override thoughtful UX decisions.</p>



<p>A truly accessible website doesn’t need a button that says &#8220;make this website accessible.&#8221; It just is.</p>



<h4 class="wp-block-heading">We Can Help</h4>



<p>If you&#8217;re not sure where your current site stands, we offer free preliminary accessibility reviews. We’ll take a look and let you know if a full audit makes sense and what steps you can take to improve.</p>



<p>We also offer full accessibility audits and remediation services, built to work collaboratively with both your design and development teams.</p>



<p>And while avoiding lawsuits shouldn’t be your only reason for making your site accessible, let’s be honest, it’s part of the conversation. Users trust us, designers and developers, to help them meet their legal and ethical obligations. Accessibility compliance isn’t optional, and it shouldn’t be framed as a choice.</p>



<p><a href="https://cm.splicedigital.com/accessibility/"><strong>Request a Free Accessibility Review</strong></a></p>



<p>Accessibility isn&#8217;t a trend. It&#8217;s not just about compliance, either.</p>



<p>It’s about respecting your users and making sure everyone has a great experience on your site, regardless of how they access it.</p>



<p>And when you make it a priority from the start, it’s not only easier, it’s just better work.</p>



<p>Want to talk accessibility? Need help fixing a site or planning your next project? <a href="https://cm.splicedigital.com/accessibility/"><strong>Let’s talk</strong></a>.</p>



<p></p>


Accessibility: A Pillar of Great Web Design


<p>It’s not the next big thing; it’s already here. But that doesn’t mean it’s the right fit for every project.</p>



<p>If you work with developers or follow tech blogs, chances are you’ve heard the term “headless CMS.” At this point, it’s not a trend, it’s a well-established architecture that’s been widely adopted across industries. We’ve been building headless sites for over four years. Tools like Sanity.io, headless WordPress, and others have become staples in modern dev workflows.</p>



<p>But here’s where it gets tricky: as headless becomes more common, the line between “new standard” and “just one of many options” gets blurrier. It’s easy to feel like you’re missing out by not using it or to assume that all modern websites should be built this way. In reality, it’s a powerful solution with real advantages, but only when paired with the right project and the right team.</p>



<h4 class="wp-block-heading">What Is Headless, Really?</h4>



<p>A headless CMS decouples your front end (what users see) from your back end (where content is created and managed). This separation gives development teams more flexibility, particularly when designing custom front-end experiences, building multi-channel content strategies, or integrating with modern frameworks and services.</p>



<p>Sounds great, right? It is! When used for the right reasons. But for teams used to traditional WordPress or plug-and-play systems, the jump to headless can introduce unexpected complexity.</p>



<h4 class="wp-block-heading">Why WordPress Still Dominates</h4>



<p>Despite the rise of headless, WordPress remains the most widely used CMS in the world. Its plugin ecosystem, editor familiarity, and large support community make it a practical, cost-effective choice for the vast majority of websites. Most agencies we work with default to WordPress unless a project has specific requirements that demand more flexibility or developer control.</p>



<p>That’s not a knock against headless. It’s a reminder that you should choose the tool that fits the project—not the other way around.</p>



<h4 class="wp-block-heading">So When Does Headless Make Sense?</h4>



<p>We’ve used headless WordPress and Sanity.io to power sites that needed:</p>



<ul class="wp-block-list">
<li>More advanced front-end frameworks for performance or animation</li>



<li>A custom authoring experience for non-technical content teams</li>



<li>Multi-platform content delivery (e.g., website + mobile app)</li>



<li>Lower long-term hosting and infrastructure costs (vs. platforms like AEM or Kentico)</li>



<li>Better scalability or long-term maintainability</li>
</ul>



<p>Headless is also a good fit when there’s a strong partnership with a development team that will stay involved post-launch. It’s not the best choice if the client needs something self-sufficient, with lots of plugin-ready functionality and minimal ongoing dev support.</p>



<h4 class="wp-block-heading">The CMS Isn’t Just for Users—It’s for Teams Too</h4>



<p>Agencies often spend a lot of time thinking about the site’s external audience. But it’s just as important to consider internal users: the marketing team, the content editor, the IT department.</p>



<p>When we’ve recommended Sanity.io, it’s often because the client’s team wasn’t familiar with CMSs and needed something clean, minimal, and intuitive. A few clearly labeled content types, drag-and-drop image fields, and some contextual help go a long way in creating confidence.</p>



<p>On the flip side, a powerful headless setup might frustrate users who expect a WordPress-style editing experience. That’s where communication is key, especially with IT teams, who may need to adjust firewalls, CDNs, or hosting environments to support the architecture. (We’ve run into this with Akamai and other enterprise tools; it’s fixable, but needs planning.)</p>



<h4 class="wp-block-heading">A Final Word on Fit</h4>



<p>If your dev team is suggesting headless—or if your agency is curious but unsure—it’s not about whether the technology is “better.” It’s about whether it’s better for this project, this client, and this team.</p>



<p>We’ll never recommend a tool just because it’s trending. But if your project could benefit from headless—if it needs advanced control, tight performance, or a long-term platform that avoids monthly enterprise fees—we’ll help you make the case. And if WordPress (or even something else) is the better fit, we’ll advocate for that too.</p>



<p>Just like in UX, the best solution is the one that meets the needs of the users—and in this case, that includes your developers, your clients, and your content editors.</p>


Composite tangled roads with lightbulb graphics on sky background

When To Consider a Headless CMS


<p><em>“Trying to manage a development budget is like trying to keep a cat in a bathtub: it&#8217;s messy, chaotic, and you’re probably going to get scratched.”<br>– Someone (probably)</em> </p>



<p>While this may not be an actual quote, I’m sure someone somewhere has come to that conclusion. I know I’m not the first person to struggle with this, and I definitely don’t have all the answers. But I’ve gathered some pro-tips from lessons I’ve learned the hard way so you, my agency friends, don’t have to.</p>



<p>Development projects, am I right? Who doesn’t love the mix of creativity, innovation… and financial anxiety? As a creative agency, the world of web development and tech jargon can feel like it’s waiting to throw you off your normally perfect game. But fear not. </p>



<p>Here are <strong>8 pro-tips</strong> (from experience) to help you tackle any project without blowing the budget. </p>



<h4 class="wp-block-heading">Pro-tip #1: Set Clear Goals and Prioritize<br>(a.k.a. Know What You Want Before You Ask for It) </h4>



<p>Before you even think about talking to a developer, figure out what you actually want. Are you trying to launch a sleek new site with modern tech, or just keep your current one from collapsing under the weight of your creative genius? These are two very different projects with two very different budgets. Clear goals are your North Star. Prioritize like it’s a dessert menu: go for the showstoppers first, and leave the “nice-to-haves” for later.</p>



<h4 class="wp-block-heading">Pro-tip #2: Do a Little Homework<br>(or How Not to Sound Like a Tech Dinosaur)</h4>



<p>Admit it, tech talk can feel like walking into a convention you weren’t invited to. As an aspiring nerd myself, I’ll tell you this: a little research goes a long way.</p>



<p><em>“Hey AI best friend, what CMS are the cool kids using these days?”</em></p>



<p>You don’t need to speak fluent developer, but you do need to understand enough to ask good questions. It&#8217;ll save you from nodding through a meeting like you&#8217;re watching a foreign film with no subtitles.</p>



<h4 class="wp-block-heading">Pro-tip #3: Embrace Flexibility<br>(Because Something Will Go Sideways)</h4>



<p>Murphy’s Law is alive and well in dev projects. Budget for it. Think of it like travel: hope for smooth sailing, but pack an extra pair of socks and prepare for delays. Contingencies are what save your sanity when the inevitable bugs, blockers, or “oh no, we forgot about X” moments crop up.</p>



<h4 class="wp-block-heading">Pro-tip #4: Adopt a Lean Approach<br>(Keep It Simple)</h4>



<p>Minimalism isn’t just for your living room. Strip your project down to the essentials, cut the fluff, and allocate budget to the parts that do the work. That brilliant 2 a.m. idea for animated logos? Only worth the splurge once the basics are in place. Cake first, then icing.</p>



<h4 class="wp-block-heading">Pro-tip #5: Invest in Talent<br>(a.k.a. Your Tech Sherpas)</h4>



<p>Hire people who know what they’re doing and can explain it in human speak. A solid dev partner is like a GPS for your project. They’ll help you navigate the twists and turns, flag pitfalls, and decode the jargon. You want someone who’s been down this road before and knows where the potholes are.</p>



<h4 class="wp-block-heading">Pro-tip #6: Use Technology Wisely<br>(or Don’t Fall for Every Shiny Thing)</h4>



<p>Tech is like fashion&#8230; trends come and go, but some tools are classics for a reason. Focus on tech that’s stable, scalable, and future-proof. Don’t let the latest hype drain your budget. Like a good pair of jeans, they may cost more upfront, but they actually fit and last longer.</p>



<h4 class="wp-block-heading">Pro-tip #7: Monitor and Adjust<br>(Because Budgets Drift)</h4>



<p>Budgeting isn’t a one-time task. It’s more like a Fitbit, track your activity and adjust when needed. Keep an eye on where the hours are going and check in regularly. A couple of extra sprints are fine. A few minor tweaks here and there? No problem. A runaway project? Not so much.</p>



<h4 class="wp-block-heading">Pro-tip #8: Communicate Like It’s a Group Project<br>(Because It Is)</h4>



<p>Scope change. The phrase that sends shivers down every agency’s spine.</p>



<p>Avoid drama by keeping communication open. Flag changes early, talk about how they affect time and budget, and document decisions. Transparency makes it easier to have honest conversations about trade-offs, and it builds trust with both clients and devs. Win-win.</p>



<h4 class="wp-block-heading">At the end of the day&#8230;</h4>



<p>Navigating dev projects as a creative agency doesn’t have to be a nightmare. With clear goals, a little prep, and the right partners, you can build amazing things and stay on budget. You don’t need to master GitHub or memorize the latest JavaScript framework, you just need to ask good questions and stay engaged.</p>



<p>And hey, if you ever need backup? You know where to find me. I’m the one with the “I survived a budget overrun and lived to tell the tale” t-shirt.<br><br> &#8211; J.</p>



<p></p>


A Survivor’s Guide to Dev Projects


<p>Or Why your dev partner needs Discovery too. </p>



<p>You know the brief—the client wants a site that “does this one thing” that no one’s really done before, or they want to integrate with a tool you’ve never heard of, or the functionality sounds cool but… how does it actually work?</p>



<p>At Splice, we’ve scoped hundreds of these “weird things.” And if there’s one constant, it’s this: you can’t estimate what you don’t understand. Discovery isn’t just for designers.</p>



<h4 class="wp-block-heading">What Counts as “Weird”?</h4>



<p>Not everything that’s custom is weird. But some requests throw up red flags right away:</p>



<ul class="wp-block-list">
<li>API Integrations (especially with industry-specific or proprietary tools)</li>



<li>User portals with layered permissions</li>



<li>Custom dashboards</li>



<li>Multi-step quote generators</li>



<li>Conditional form logic that updates live</li>



<li>Any sentence that starts with “It’s kind of like Airbnb, but for…”</li>
</ul>



<h4 class="wp-block-heading">Why Agencies Shouldn’t Quote These Blind</h4>



<p>You’d never quote a logo or brand identity without first learning about the client, their industry, and goals. Development is no different. Estimating these builds without discovery leads to:</p>



<ul class="wp-block-list">
<li>Blown budgets</li>



<li>Frustrated clients</li>



<li>Overworked devs</li>



<li>Last-minute fire drills</li>
</ul>



<p>Agencies who bring us in after the deal is signed are often the ones calling us at 10pm trying to figure out why something is suddenly impossible or double the price.</p>



<h4 class="wp-block-heading">What Discovery Looks Like for Dev Teams</h4>



<p>We’re not just dragging our feet. We need answers to estimate accurately:</p>



<ul class="wp-block-list">
<li>Does the platform have a public API? (And if so, is it documented?)</li>



<li>Are authentication methods standard (OAuth, API keys) or custom?</li>



<li>What’s the data structure? What comes in? What goes out?</li>



<li>What’s the expected user journey?</li>



<li>What happens if [insert complex edge case here]?</li>
</ul>



<p>We may ask the agency or client to reach out to their tech rep. We might need access to staging environments, sandbox credentials, or an actual human being from the client’s dev team. These are not optional, they’re essential for good scoping.</p>



<h4 class="wp-block-heading">What Happens If We Skip Discovery?</h4>



<p>Short version: someone eats the overage. And it’s usually us or you.</p>



<p>We’ve had projects where we were told, “It’s just a login,” and three weeks later we’re building a multi-factor SSO integration with a legacy ERP. There’s a reason we pause and ask the weird questions early.</p>



<h4 class="wp-block-heading">How Agencies Can Set the Stage</h4>



<p>Here’s how to prep your client (and protect yourself):</p>



<ul class="wp-block-list">
<li>Let them know that technical discovery is a normal part of development scoping.</li>



<li>Avoid pressuring your dev partner for an early number without clarity.</li>



<li>Be upfront about what’s unknown, unusual, or has bitten you before.</li>



<li>Budget time (and money) for discovery in your proposals.</li>
</ul>



<p>Your dev partner will love you. Your client will thank you. And your timeline will actually stand a chance.<br><br>If you’re staring down a project with moving parts, custom logic, or mystery integrations, <a href="https://cm.splicedigital.com/contact/">let’s talk</a> early. Our technical discovery process is collaborative, efficient, and designed to get everyone aligned before the heavy lifting starts.</p>



<p></p>


How We Estimate the Weird Stuff


<p>The idea of a &#8220;design handoff&#8221; has been around as long as designers and developers have worked together. But here’s the thing: it doesn’t really exist. Or at least, it shouldn’t.</p>



<p>Design and development aren’t separate steps in a linear process. They’re part of the same conversation. When you treat development like the final stage, something that happens after the design is done, you miss opportunities, introduce risks, and ultimately make the work harder for everyone involved.</p>



<h4 class="wp-block-heading">The Problem with the Handoff Mentality</h4>



<p>The traditional handoff model assumes that a designer creates a perfect blueprint, and the developer simply builds it. But in practice, things rarely go that smoothly.</p>



<ul class="wp-block-list">
<li>Designs are often approved before dev is looped in. This means developers are asked to build things that haven’t been scoped, vetted, or even sanity-checked for feasibility.</li>



<li>Accessibility gets missed. If accessibility isn’t built into the design from the start, it puts pressure on dev to make retroactive fixes and some design choices simply aren’t fixable.</li>



<li>Budget and timeline take a hit. When surprises emerge during build, you lose time either walking decisions back or building something that wasn’t scoped (and often wasn’t budgeted for).</li>



<li>The vision can fall apart. A designer might imagine an interaction one way, but if that wasn’t communicated, documented, or technically feasible, you end up with a watered-down version.</li>
</ul>



<p>In short, everyone loses.</p>



<h4 class="wp-block-heading">What Works Better: A Continuous Feedback Loop</h4>



<p>When dev is brought in early and often, projects run smoother. Here’s what that can look like:</p>



<ul class="wp-block-list">
<li>Involve development during discovery and wireframes. We can help identify technical challenges and opportunities before they’re locked into designs.</li>



<li>Collaborate on components. Want that cool hover state? Let’s talk about how it works across devices and what fallback states are needed.</li>



<li>Talk through animations, interactions, and edge cases. Developers can flag performance issues, accessibility concerns, or better ways to achieve the same effect.</li>



<li>Work in phases. Breaking projects into well-defined design/build cycles helps reduce scope creep and keeps budgets realistic.</li>
</ul>



<p>This doesn’t mean slowing down the creative process. It means enriching it with perspective and context.</p>



<h4 class="wp-block-heading">Especially When We’re Not In-House</h4>



<p>When we’re partnering with an agency, we don’t always get the benefit of hallway chats and Slack pings. So it’s even more important to loop us in before a design is finalized.</p>



<p>Designs that don’t account for scope or feasibility can create tough moments late in the game. Not because anyone did anything wrong, but because we weren’t in the room when decisions were made.</p>



<p>The earlier we can see the vision, the better we can help bring it to life.</p>



<h4 class="wp-block-heading">Final Thoughts</h4>



<p>Design and development are teammates, not relay runners. A project doesn’t get passed from one to the other. It gets built together. When we collaborate from the start, we spot problems earlier, build smarter, and deliver better results.</p>



<p>If you’re an agency or studio looking to bring a development partner into the fold early, we’d love to talk.</p>



<p><a href="https://cm.splicedigital.com/contact/"><strong>Contact Us</strong></a></p>



<p></p>


AGENCY INSIGHTS

From Brief to Build

Using AI in the Design Workflow

(Screen) Size Does Matter

Scoped to Fail

Why Navigation Is a Dev Problem Too