Scott Pollard — Designer / Developer

Category: Thoughts

  • It’s More About How I Think Than What I Do

    It’s More About How I Think Than What I Do

    Occasionally, when I tell someone what I do for a living, I’ll hear something along the lines of, “I couldn’t do your job. I’m no good at art.”

    I’ve always found that an interesting response.

    I understand where it comes from. Design is often associated with being able to draw, having an eye for colour or making things look attractive. And while those skills certainly have their place, they’re only a small part of what I do.

    For me, the interesting part has always been the thinking behind it.

    Understanding a problem, questioning assumptions, making connections and finding a way to communicate something. Sometimes that involves drawing, sometimes writing code, and occasionally it involves doing neither.

    I think we have a tendency to confuse creativity with artistic ability. We decide quite early in life whether we’re creative or not, often based on whether we were any good at drawing at school.

    But some of the most creative people I’ve encountered wouldn’t describe themselves as artistic at all. They’re engineers, developers, problem-solvers or people who simply have an unusual way of looking at things.

    After more than two decades working across design, development and technology, I’ve come to realise that what connects everything I do isn’t necessarily a particular skill.

    It’s how I think.

    What working in agencies taught me

    I spent a significant part of my career working in agency environments, where you’re often moving between different clients, industries and problems.

    One day you might be working on a website, the next a branding project or something completely unfamiliar. You learn to adapt quickly, understand different audiences and find solutions within the constraints of a brief, budget or deadline.

    That variety can be a brilliant education.

    You encounter different ways of working, different expectations and plenty of situations where you have to figure things out as you go along.

    But one of the biggest lessons I took from agency life was that the brief isn’t always the problem.

    A client might ask for a new website because their existing one isn’t generating enquiries. But is the design really the issue? Could it be the messaging, the product, the audience or something happening elsewhere in the business?

    It’s tempting to jump straight into producing what has been requested, particularly when deadlines are involved.

    I’ve learnt that spending a little more time understanding the problem can save an enormous amount of time solving the wrong one.

    Lesson 1: Don’t confuse the brief with the problem.

    Before starting anything, try asking what has prompted the request. What isn’t working? What would a successful outcome actually look like?

    Sometimes the most useful contribution you can make is questioning whether the proposed solution is needed at all.

    Moving in-house changed my perspective

    Moving from agency work into an in-house role introduced a different way of thinking.

    In an agency, projects often have a relatively defined beginning and end. You research, design, develop, deliver and eventually move on to something else.

    Working in-house gives you the opportunity to see what happens afterwards.

    You live with the decisions you’ve made. You see how people use what you’ve built, how it performs, what needs improving and which ideas perhaps weren’t quite as clever as they initially seemed.

    You also gain a much deeper understanding of the business itself.

    Rather than approaching each project as a relatively isolated piece of work, you begin to see how everything connects. Design, development, marketing, customer experience, technical infrastructure and business objectives all influence one another.

    A website problem might actually be a messaging problem. A marketing problem might be related to the product itself. And a technical improvement might have a much greater impact than an entirely new design.

    It’s encouraged me to think less about individual deliverables and more about the wider system.

    Lesson 2: Think beyond the thing you’re making.

    Consider what happens after launch. Who will maintain it? How will you know whether it’s working? What other parts of the business might it affect?

    A successful project isn’t necessarily one that looks impressive on the day it’s delivered. It’s one that continues to be useful long afterwards.

    Learning to question the obvious

    One thing I’ve become increasingly interested in is how easily we fall into familiar ways of solving problems.

    Design and development are full of established principles, best practices and conventions. Many exist for very good reasons, and ignoring them simply to be different rarely helps anyone.

    But I do wonder whether we sometimes become too comfortable repeating what we’ve learnt.

    We use familiar layouts, follow similar processes and look towards competitors for inspiration. Before long, everyone starts producing variations of the same thing.

    It’s particularly noticeable in digital marketing, where the tools and measurements available to us can encourage everyone towards similar solutions.

    If everyone is looking at the same data, following the same advice and optimising towards the same objectives, where does differentiation come from?

    I’ve found that some of the most useful questions are also the simplest.

    Why are we doing this? What are we assuming? What happens if we approach it differently?

    Lesson 3: Learn the rules, but don’t stop questioning them.

    Established approaches are useful starting points, not necessarily the final answer.

    It’s worth occasionally stepping away from the obvious solution and considering what you might be missing.

    Understanding behaviour is as important as understanding technology

    Later in my career, while studying UX and UI, I became increasingly interested in human behaviour.

    I’d always been curious about why people make certain decisions, but studying user experience gave me another way of thinking about it.

    We can create technically excellent websites, carefully considered interfaces and beautifully designed experiences, but none of that guarantees people will behave as we expect.

    People don’t always make logical decisions. They rely on habits, assumptions, previous experiences and countless other influences that aren’t immediately obvious.

    And sometimes the way people actually use something is very different from the way we imagined they would.

    This has encouraged me to become more interested in behavioural science and the psychology behind decision-making.

    Not because I think every problem needs a psychological explanation, but because understanding people adds another dimension to creative problem-solving.

    It’s also made me more cautious about accepting familiar UX principles without considering the context in which they’re being applied.

    Lesson 4: Don’t design for the person you assume exists.

    Try to understand the people you’re designing for, the circumstances in which they’re making decisions and what might be influencing their behaviour.

    Data can tell you what’s happening, but it doesn’t always explain why.

    And sometimes a conversation with a real person reveals something that hours of analysing dashboards never would.

    The value of knowing a little about a lot

    I’ve never found it particularly easy to fit what I do into a single job title.

    Over the years I’ve worked across graphic design, branding, development, UX, SEO, marketing and various other disciplines.

    I’ve sometimes wondered whether that lack of specialisation was a disadvantage.

    There are certainly situations where deep expertise in one particular area is essential, and I’ve worked with specialists whose knowledge goes far beyond my own.

    But I’ve also come to appreciate the value of understanding how different disciplines connect.

    Knowing how something is developed can influence how you design it. Understanding marketing can change how you approach user experience. Knowledge of hosting infrastructure can reveal why a website isn’t performing as expected.

    These connections become particularly useful in an in-house environment, where decisions rarely exist in isolation.

    Lesson 5: Develop depth, but stay curious about what’s happening around it.

    You don’t need to become an expert in everything.

    Understanding enough about neighbouring disciplines to ask informed questions, recognise opportunities and communicate with specialists can be incredibly valuable.

    Sometimes your contribution isn’t having all the answers. It’s recognising that the answer might exist somewhere outside your own area of expertise.

    Why I still make things for no particular reason

    Outside work, I spend a lot of time experimenting with things that have no obvious commercial purpose.

    Drawing, photography, generative art, coding little experiments, building models and making physical objects.

    Some projects work, others don’t. Occasionally I lose interest halfway through and move on to something completely different.

    For a long time, I probably considered these activities separate from my professional life.

    But I’m beginning to think they’re more connected than I realised.

    When you’re making something without a client brief, deadline or measurable objective, you have the freedom to experiment.

    You can follow an idea simply because it interests you. You can make mistakes, explore unexpected results and change direction without having to justify every decision.

    That freedom is increasingly valuable when so much of our professional work is measured against performance indicators and business objectives.

    And it’s surprising how often something learnt through a seemingly unrelated hobby becomes useful elsewhere.

    Lesson 6: Make room for curiosity without expecting a return.

    Not every creative activity needs to become a side hustle, portfolio piece or professional development exercise.

    Sometimes making something simply because you want to is reason enough.

    The value might not be immediately obvious, and that’s perfectly fine.

    Learning when not to create something

    Perhaps one of the more surprising lessons from working across different disciplines is that creativity doesn’t always involve making something new.

    Sometimes the best solution is to simplify what’s already there.

    In development, that might mean removing unnecessary complexity rather than introducing another framework. In design, it could mean reducing the number of choices rather than adding more features.

    In marketing, it might mean communicating an existing benefit more clearly rather than launching another campaign.

    There’s a tendency in creative industries to associate progress with producing something tangible. A new design, a new feature, a new strategy.

    But knowing when not to create something requires judgement too.

    Working in-house has reinforced this for me. When you’re responsible for maintaining and improving something over several years, you become much more aware of the long-term consequences of decisions.

    Lesson 7: Don’t mistake more work for better work.

    Before creating something new, consider whether improving, simplifying or even removing something might achieve a better result.

    The most creative solution isn’t necessarily the most complicated or visually impressive one.

    Sometimes it’s the one nobody notices because everything simply works.

    It’s how you approach the problem

    I still enjoy the practical side of what I do. Designing, writing code, experimenting with new technologies and seeing an idea become something real.

    But as my career has developed, I’ve become increasingly interested in the thinking that happens before any of those things.

    The questions we ask, the assumptions we challenge and the connections we make between different experiences.

    Agency life taught me to adapt, work across different problems and think quickly.

    Moving in-house has taught me to think more deeply about the consequences of decisions, the relationships between different parts of a business and the value of improving something over time.

    My interests outside work have reinforced the importance of curiosity, experimentation and occasionally doing things without knowing where they’ll lead.

    And studying human behaviour has reminded me that even the most logical solution needs to make sense to the people experiencing it.

    I’m still learning, and I expect my interests and the tools I use will continue to change.

    But perhaps that’s why I’ve become less concerned with finding the perfect job title or defining myself through a particular set of skills.

    The tools are important, and experience matters. But neither tells the whole story.

    So when someone tells me they couldn’t do my job because they’re no good at art, I think about all the creativity that exists beyond drawing or design.

    The person who finds a simpler way of doing something. The colleague who asks the question nobody else has considered. The engineer who sees a solution where everyone else sees a problem.

    They’re all thinking creatively, even if they’d never describe themselves that way.

    And perhaps that’s the biggest thing I’ve learnt over the years.

    Creativity isn’t simply about what you can make. It’s about what you can see, question and imagine differently.

  • Not Working, Networking

    Not Working, Networking

    I spent Sunday afternoon doing a bit of networking. Not the sort involving name badges, awkward introductions and people trying to sell you something, but the much nicer sort involving coffee, conversation and meeting people you wouldn’t normally cross paths with.

    A friend of ours set up a social group called Preston Coffee & Chat back in March, with the idea of bringing people together, making new friends and encouraging a little more face-to-face conversation.

    We went along to Chew’s Yard in Preston to help promote the group, handing out flyers and chatting to people over the course of four hours.

    It was a lovely way to spend a Sunday afternoon.

    Conversations that go somewhere

    One of the things I enjoyed most was the variety of people we met. Different ages, different backgrounds and plenty of interesting conversations.

    A particular highlight was chatting with a student about their end-of-year branding project. We ended up discussing their ideas, looking at the direction of the work and exploring a few ways they could develop it further.

    Having spent over 20 years working across design, development and marketing, it’s always enjoyable to revisit the creative process through someone else’s eyes.

    I think there’s something quite rewarding about sharing experience without it being part of a formal working environment. Sometimes a fresh perspective or a few questions are enough to help someone see their own work differently.

    And it works both ways. Talking to people who are still studying and experimenting is a useful reminder that creativity doesn’t have to follow the same processes we’ve become accustomed to over the years.

    Getting away from the usual circles

    Working in digital means I spend a considerable amount of time looking at screens, solving problems and communicating with people online.

    It’s easy to forget how valuable an afternoon of completely unstructured conversation can be.

    There was no agenda, no presentation and certainly no expectation that anything productive needed to come out of it. Yet I came away having met some interesting people, shared a little knowledge and learnt a few things myself.

    I suppose that’s networking in its simplest form. Not collecting contacts or looking for opportunities, but just being curious about people and what they do.

    More of this, please

    I think what our friend has started with Preston Coffee & Chat is a genuinely worthwhile thing. Creating opportunities for people to meet, particularly when so much of our lives happens online, feels increasingly important.

    It was good to play a small part in helping promote it, and even better to see how a simple conversation can turn into something interesting.

    Four hours well spent, and a nice reminder that you don’t always have to be working to put your experience to good use.

  • Never Taken a Shortcut Before?!

    Never Taken a Shortcut Before?!

    There’s a strange thing that happens when something works in marketing: everyone starts doing it.

    Someone finds a particular style of advert that performs well and before long, everyone’s adverts look like it. A website converts well, so its layout gets copied. A certain type of LinkedIn post gets attention, so suddenly everyone is writing in the same style, using the same hooks, the same carousels and the same calls to action.

    It makes sense. If something has already been shown to work, following it feels like the sensible option. It’s also a shortcut, and shortcuts become considerably less useful when everyone takes the same one.

    The safest option might be the riskiest

    There’s a lot of comfort in doing what everyone else is doing. You can point at competitors and say, “They’re doing it.” You can find case studies showing that a particular technique works, find a template, follow the instructions and measure the results.

    Nobody is going to question why your SaaS website has a massive headline, a gradient background and three cards underneath it. That’s just what SaaS websites look like. Nobody questions why the advert looks like every other advert in the category.

    But marketing has a slightly awkward problem: one of its jobs is to make you noticeable.

    If the route you choose is the same route everyone else has chosen, you might have reduced the risk of doing something wrong while simultaneously reducing your chances of being remembered.

    There’s safety in familiarity, but there’s also a danger of becoming invisible.

    Best practice has a shelf life

    I don’t think there’s anything wrong with best practice. There are good reasons why certain patterns become common, and we know quite a lot about usability, accessibility, conversion and how people interact with websites. Throwing all of that away for the sake of being different would be equally daft.

    But there’s a difference between understanding why something works and simply copying the output.

    If ten competitors have independently arrived at roughly the same website, the eleventh company doesn’t necessarily gain an advantage by building another version of it. Sometimes the interesting question isn’t, “What are our competitors doing that works?” It’s, “What are they all doing that gives us an opportunity to do something different?”

    That applies to more than websites. Look at advertising within almost any industry and you’ll quickly spot the patterns. Similar language, similar photography, similar offers and similar claims. Sometimes you could swap the logos around and barely notice.

    Following the established route might make producing the next campaign easier, but being easier to produce doesn’t necessarily make something more effective.

    Efficiency creates sameness

    Technology is making this even more interesting. We now have tools that can produce competent marketing remarkably quickly. AI can write the copy, templates can build the landing page, design systems can create the interface and analytics can tell us which variation performed best.

    None of those things are inherently bad. I use plenty of them. They make us faster and remove a lot of repetitive work.

    The problem comes when efficiency starts replacing thinking.

    AI is particularly interesting because it has learnt from what already exists. Ask it for ideas and, unless you push it somewhere unusual, there’s a reasonable chance you’ll get a polished version of something you’ve seen before. Combine that with templates, competitor research and optimisation data and it becomes remarkably easy to produce perfectly competent marketing that looks remarkably similar to everyone else’s perfectly competent marketing.

    The shortcut gets shorter, but the destination gets busier.

    Maybe we need a different 80/20 rule

    Perhaps the answer isn’t to stop following best practice. It’s to stop letting best practice account for 100% of what we do.

    I’ve started thinking about an 80/20 approach. Not the traditional Pareto principle, but a simple rule for experimentation.

    Let 80% of what you’re doing be informed by what you already know. Use established patterns, previous results, customer behaviour, analytics and experience. Do the sensible stuff that gives you a reasonable chance of success.

    Then deliberately leave 20% for something else.

    Something your competitors aren’t doing. Something you can’t find a case study for. Something that doesn’t have an obvious template. Maybe even something that feels slightly uncomfortable because you can’t point at another company and say, “They did it first.”

    That 20% could be a strange campaign idea, an unusual piece of direct mail, a completely different approach to your website or a bit of humour in an industry that normally takes itself very seriously.

    It could simply be saying something that everyone in your industry knows but nobody else is willing to say.

    The 20% probably won’t all work

    This is perhaps the important bit.

    Some of the 20% will fail.

    That’s fine.

    If every marketing experiment succeeds, I’d question whether you’re actually experimenting. If you already know something will work because you’ve seen it work somewhere else, you’re not really testing anything new.

    The trick is making failure affordable. Don’t gamble the entire marketing budget on an unusual idea. Don’t rebuild the whole website because somebody had an interesting thought in a meeting.

    Make the experiment small enough that getting it wrong doesn’t really matter, but large enough that getting it right teaches you something.

    That makes the 80/20 split quite useful. The 80% keeps things sensible. The 20% gives you permission to explore.

    What happens when the 20% works?

    This is where it gets interesting.

    Something from that experimental 20% might outperform the safe stuff. Perhaps customers respond to it. Perhaps people remember it. Perhaps it starts conversations that your carefully optimised campaign never did.

    At that point, you haven’t copied somebody else’s shortcut. You’ve found your own.

    You can refine it, measure it and understand why it worked. Eventually it might become part of your dependable 80%, leaving another 20% available for the next experiment.

    And eventually, if it works particularly well, your competitors might notice.

    They might even start copying it.

    At which point it’s probably time to find another shortcut.

  • The Button I Nearly Pressed

    The Button I Nearly Pressed

    I filled my car up this morning and paid the highest price for petrol I can remember paying. Not exactly a great start to the day, but everything else about the experience was completely normal.

    I used pay at pump, filled the car, paid and was about to leave when a row of faces appeared on the screen asking how I felt about my experience.

    I normally ignore these surveys, but this time I was very close to pressing the unhappy face. It had nothing to do with the pump, though. The pump worked, the payment worked and there was no queue. I was annoyed because I’d just seen how much it had cost me to fill the car.

    It got me thinking about what that little survey is actually measuring.

    Presumably all those button presses end up somewhere. Maybe there’s a dashboard showing customer satisfaction across different petrol stations, different days or different times of day. If enough people answer, it probably produces some quite convincing-looking data.

    But what happens when petrol prices suddenly increase?

    If the number of unhappy faces goes up at the same time, has the experience actually got worse? Or are people just more annoyed about how much they’ve paid?

    There are probably dozens of things influencing that response which have very little to do with the thing being measured. Someone might be late for work, stuck in traffic, having a bad morning or irritated that filling their car has just cost considerably more than it did a few weeks ago.

    Pay at pump makes it even more interesting because there isn’t much of a customer experience in the traditional sense. I did almost everything myself. I filled the car, operated the terminal and paid without speaking to anyone. The petrol station provided a working pump and payment system, but beyond that there wasn’t much to judge.

    Yet I’m still being asked how satisfied I am.

    The problem isn’t necessarily the data itself. If more people press the unhappy face one week, then more people pressed the unhappy face. That’s a perfectly valid measurement.

    It’s the meaning we attach to it that becomes questionable.

    Imagine looking at a dashboard and seeing customer satisfaction drop from 82% to 69%. You might start looking for problems with the payment process, staff, queues or the condition of the forecourt.

    Now imagine putting average petrol prices on the same graph and seeing them rise sharply at exactly the same time.

    It doesn’t prove that price caused the drop, but it would certainly make you think twice before deciding the customer experience needed fixing.

    And this goes well beyond petrol stations.

    We collect an enormous amount of data because it’s easy to collect. Website engagement, conversion rates, satisfaction scores, and countless other metrics get turned into percentages and graphs. Once they’re sitting on a dashboard with a red or green arrow next to them, they start to feel very authoritative.

    But a precise number doesn’t necessarily mean we’ve precisely measured the thing we care about.

    Sometimes the most useful question isn’t why a metric went up or down.

    It’s whether we’re actually measuring what we think we’re measuring.

  • Why I Built My Own Design System

    Why I Built My Own Design System

    Using PHP, SASS and Tailwind to make website development faster, more consistent and easier to maintain.

    Working in-house as a web developer and digital designer means my days can be quite varied. I might spend the morning developing a new page, the afternoon looking at analytics or SEO, and somewhere in between find myself working on branding, UX or a marketing campaign. Occasionally, I’ll even get the camera out to photograph products or create imagery for the website.

    It’s one of the things I enjoy about working in-house. There’s always something different to get involved with, and I get to use a mixture of creative and technical skills rather than concentrating on just one discipline.

    Recently, I’ve been working on a website rebuild and decided to approach things a little differently. Rather than developing individual pages and repeatedly writing similar code, I’ve been putting together my own lightweight design system.

    It’s built around PHP modules, SASS and Tailwind CSS, with an emphasis on reusable components, consistency and making future development easier.

    Nothing particularly groundbreaking in terms of technology, but that’s not really the point.

    Here is an example fo a visual design system I created for Clook.

    What is a design system, and why bother?

    A design system is essentially a collection of reusable components, styles and conventions that help keep a website consistent.

    At one end, that might simply mean having an agreed set of colours, typography and spacing rules. At the other, it could involve extensive component libraries, documentation and development frameworks.

    For me, the appeal is somewhere in the middle.

    I wanted a way to create pages quickly without having to make the same design decisions repeatedly. Buttons should look like buttons, spacing should be predictable, and elements such as testimonials, feature grids and calls to action shouldn’t need rebuilding every time they’re used.

    There’s also a longer-term benefit. Websites are rarely finished. Content changes, products evolve, designs get refined and new requirements appear.

    Having a system in place makes those changes easier to manage.

    Building something practical

    I didn’t want to introduce a complicated framework or create a dependency on something that might become difficult to maintain.

    Instead, I’ve been using technologies I’m already comfortable working with.

    PHP handles the page structure and reusable modules. SASS helps organise the styling, while Tailwind provides utility classes for quickly creating layouts and handling common spacing and responsive requirements.

    I’ve also been applying principles associated with object-oriented development, particularly separating responsibilities and keeping related functionality together. The module examples themselves use procedural PHP, rather than classes, but follow the same broader aim of making code easier to reuse and maintain.

    The result is a growing collection of components that I can use across different pages.

    Here’s a small selection from the current module directory:

    modules/
├── call-to-action.php
├── faq.php
├── feature-benefits.php
├── feature-grid.php
├── hero.php
├── image-text.php
├── intro.php
├── product-cards.php
├── product-comparison.php
├── proof-strip.php
├── team-grid.php
├── technology-strip.php
└── testimonial.php

    Each module has a particular responsibility. Some are fairly simple, while others handle more complicated layouts and content.

    The important thing is that I can reuse them without copying large sections of HTML between pages.

    I simply include the module in the HTML and pass it some information to use.

    An example: reusable testimonials

    A testimonial section is a good example because it’s something that might appear on several pages, but with different content.

    Previously, I might have written the HTML directly into each page. That works, but it creates more work when something needs changing.

    With the new approach, I define the content in an array and pass it to a PHP module.

    Here’s a simplified example using fictional testimonials:

    <?php
$testimonials = [
    [
        'quote' => 'Really pleased with the service.',
        'name' => 'Alex',
        'detail' => 'Customer',
    ],
    [
        'quote' => 'Helpful support and a great experience.',
        'name' => 'Sam',
        'detail' => 'Customer',
    ],
];

include __DIR__ . '/modules/testimonial.php';
?>

    The module handles the presentation, while the page controls which testimonials appear.

    If I decide to change the appearance of testimonial cards, adjust their spacing or improve the responsive layout, I can make those changes in one place.

    It’s a relatively simple approach, but when you’re working across a growing website, those small efficiencies start to matter.

    Keeping the visual identity consistent

    Another part of the system involves centralising the brand settings.

    Rather than scattering colours and other design values throughout different stylesheets, I’ve created a PHP helper that defines a set of defaults and can read overrides from a JSON configuration file.

    Here’s a simplified example:

    function brand_settings(): array
{
    return [
        'name' => 'Brand',
        'primary' => '#ff7200',
        'primary_dark' => '#cf5d00',
        'ink' => '#142329',
        'surface' => '#ffffff',
        'radius' => 10,
    ];
}

    The full helper also validates values loaded from the configuration file, including checking that colours are valid hexadecimal values and that border-radius settings fall within an expected range.

    Those settings can then be turned into CSS custom properties:

    :root {
    --brand-primary: #ff7200;
    --brand-primary-dark: #cf5d00;
    --brand-ink: #142329;
    --brand-surface: #ffffff;
    --brand-radius: 10px;
}

    This provides a common reference for the components.

    SASS gives me a way to organise component-specific styles, variables and more complicated styling rules. Tailwind sits alongside it, handling much of the routine layout work.

    I’m still refining where one approach ends and the other begins. There’s little point having three different ways to control the same thing, so keeping that relationship understandable is important.

    Speed matters, but consistency matters more

    The obvious benefit of reusable components is speed.

    If I need to create a new page, I already have a collection of elements to work with. Instead of starting from scratch, I can concentrate on choosing the right components and arranging the content.

    But consistency is probably the bigger advantage.

    When you’re building pages individually, small differences can gradually appear. Spacing changes slightly, headings behave differently, buttons develop variations and layouts become less predictable.

    These aren’t necessarily major problems individually, but collectively they make a website harder to maintain.

    A design system helps reduce that drift.

    It also encourages me to think about design decisions at a component level rather than treating every page as an isolated piece of work.

    That doesn’t mean every page has to look the same. The components provide a consistent foundation, but there’s still plenty of flexibility in how they’re combined.

    The in-house advantage

    I think this approach is particularly useful when working in-house.

    Unlike working exclusively on development projects, my responsibilities cover quite a few different areas. Development is only one part of the job, alongside design, content, SEO, marketing and improving the overall user experience.

    Sometimes I have a full day to concentrate on development. Other times, I might only have an hour or two between other responsibilities.

    Having an established collection of components makes it much easier to pick things up again without having to revisit decisions I’ve already made.

    It also makes experimenting with page layouts less time-consuming. I can concentrate on how information is structured, what needs communicating and how someone might interact with a page, rather than spending that time recreating familiar elements.

    That’s where I see the greatest value.

    The system isn’t simply about producing pages more quickly. It’s about reducing repetitive work so I can spend more time thinking about the problems that actually need solving.

    Knowing when not to complicate things

    There’s a temptation with projects like this to keep adding functionality.

    Every repeated element becomes a component. Every component gets configuration options. Before long, something intended to simplify development becomes another complicated system to maintain.

    I’ve been trying to avoid that.

    Not everything needs to be abstracted, and sometimes a straightforward piece of HTML is perfectly adequate.

    My general approach has been to create modules when there’s a genuine reason for them, rather than trying to anticipate every possible future requirement.

    The same applies to the technologies involved. I could probably achieve similar results using a larger framework, but I don’t necessarily need one for this particular project.

    I’d rather have something relatively simple that I understand and can maintain.

    A system that grows with the website

    The design system is still evolving, and I expect it will continue to change as I develop more pages and encounter new requirements.

    There are components that could be improved, opportunities to reduce duplicated code and areas where better documentation would help.

    But I’m already finding the approach useful.

    After more than twenty years working across design and development, I’ve become increasingly interested in the processes behind the work, not just the finished result.

    Good design isn’t always about creating something new. Sometimes it’s about recognising patterns, removing unnecessary decisions and making things easier for the next time.

    For me, that’s what this project is really about.

    Less time rebuilding things I’ve already built, and more time concentrating on the work that needs creative thought.

  • I built it because I could

    I built it because I could

    There are already plenty of tools online for creating social media graphics.

    Canva. Adobe Express. Figma. And probably hundreds of smaller SaaS products doing variations of the same thing.

    I didn’t build this because I thought the world needed another one.

    I built it because I could.

    Solving a very small problem

    Creating a social graphic isn’t particularly difficult.

    But when you’re regularly creating graphics for LinkedIn, Instagram, blog posts and other bits of content, you start repeating the same process.

    Create the document. Set the dimensions. Add the colours. Position the type. Drop in an image. Export it.

    Then do roughly the same thing again at another size.

    What I actually wanted was something much simpler.

    Write a headline, choose an image, pick a layout and generate the sizes I need.

    More importantly, I wanted those graphics to feel consistent without having to consciously recreate the design every time.

    So I started building a small tool to do exactly that.

    Deliberately limited

    One of the things I like about building tools for myself is that they don’t need to cater for everyone.

    A SaaS product needs options.

    Lots of fonts. Lots of templates. Lots of controls. Integrations. Accounts. Cloud storage. Collaboration. AI features.

    My tool doesn’t.

    It only needs the things I actually use.

    That constraint turned out to be one of its best features.

    Rather than staring at a blank canvas every time I want to create something, I’ve already made most of the design decisions.

    There are a handful of layouts, a set of colour combinations, some image treatments and the output sizes I regularly need.

    I can concentrate on the content rather than designing the container around it every time.

    AI helped me build it

    This is also one of those projects that probably wouldn’t have happened quite as quickly a few years ago.

    AI helped me mock up ideas, work through bits of JavaScript and PHP, troubleshoot things and iterate on the interface.

    Instead of spending ages planning the application, I could get something working quickly and then react to it.

    Does this control need to be here?

    Would it be useful if I could change this?

    Can I export all the different sizes together?

    Build it. Try it. Change it.

    That’s probably where I’ve found AI most useful in development. Not necessarily doing the thinking for me, but dramatically shortening the distance between having an idea and having something tangible enough to test.

    And it runs on my computer

    There’s another thing I quite like about it.

    It doesn’t need an account.

    There’s no subscription.

    There’s no service sitting somewhere on the internet that the application depends on.

    I run it locally on my Mac.

    Open it in a browser, create what I need, export the images and close it again.

    There’s something quite satisfying about software working like that.

    It became genuinely useful

    What started as a little experiment has ended up becoming something I actually use.

    I’ve used versions of it for my own projects and I’ve found the same idea useful in my in-house work too.

    That’s probably my favourite kind of side project.

    Not something built because I’ve identified a market for it.

    Not something that needs users, subscriptions or a launch on Product Hunt.

    Just a small piece of software that removes a repetitive job from my day.

    Could I have used an existing SaaS product instead?

    Absolutely.

    But then I wouldn’t have learnt anything building it.

    And sometimes, “because I could” is a perfectly good reason to make something.

  • Give AI Something to Find

    Give AI Something to Find

    The usual advice is to post regularly. Keep the feed active. Talk about what you’re doing. Promote the next event. Share the cake sale. Post some photos from the office.

    There’s nothing particularly wrong with any of that.

    But most of it has a very short shelf life.

    A post promoting an event next Tuesday isn’t particularly useful on Wednesday. An offer ending this month isn’t much use next year.

    As AI starts changing how we find businesses and information online, I think there’s an argument for businesses putting more effort into the things that don’t expire.

    Social media is part of your business’s footprint

    For years we’ve thought about Google when deciding what information businesses should publish online.

    We build service pages. We write articles. We optimise websites.

    But people are increasingly asking AI assistants the sorts of questions they previously typed into Google.

    “Who can help me with this?”

    “What companies specialise in that?”

    “What’s the difference between these services?”

    “Which businesses have experience working with companies like mine?”

    That changes things slightly.

    An AI system trying to answer those questions needs information to work with.

    Your website is obviously part of that. But your wider presence online can potentially contribute too, depending on what information an AI service can access, index or retrieve.

    Social media therefore doesn’t necessarily have to be thought of purely as a feed.

    It can be part of the information that exists about your business.

    What does the internet actually know about your company?

    That’s an interesting question for any business to ask.

    Imagine someone had never heard of your company before.

    Could they work out what you’re particularly good at?

    Could they understand the problems you solve?

    Could they tell who your customers are?

    Could they understand why someone might choose you rather than a competitor?

    And importantly, is that information actually written down somewhere publicly accessible?

    A business might have decades of experience locked inside the heads of its employees while its social media accounts mostly contain Christmas opening hours and photographs from networking events.

    That’s quite a strange imbalance when you think about it.

    This doesn’t mean posting every day

    This is actually where I think AI could make social media slightly more manageable for smaller businesses.

    You don’t necessarily need to become a content machine.

    Instead of worrying about finding something to publish every morning, spend some of that time creating useful evergreen content.

    Explain something customers regularly misunderstand.

    Answer a common question.

    Talk about how you approach a particular problem.

    Explain why your industry works the way it does.

    Share some knowledge from someone who has worked in the business for twenty years.

    Talk about a customer problem you’ve solved.

    Explain something that genuinely differentiates you from competitors.

    One useful post a week might tell the internet considerably more about your business than five disposable updates.

    Build a library, not just a feed

    Perhaps that’s the bigger shift.

    Instead of thinking:

    “What can we post today?”

    Think:

    “What should somebody be able to learn about our business?”

    Then start filling in the gaps.

    Over time, your social channels become something more useful. There’s a post demonstrating your expertise in one area.

    Another explaining a service.

    Another answering a difficult customer question.

    Another showing how you approach a problem.

    Another containing insight from someone within the company.

    Six months later, those posts haven’t necessarily lost their value.

    You’ve gradually created a public library of information about the business.

    The audience might arrive much later

    This is the bit I find particularly interesting.

    We’re accustomed to judging social posts almost immediately.

    How many impressions?

    How many likes?

    How many comments?

    Did anyone click?

    Those numbers aren’t meaningless, but perhaps they’re no longer the complete measure of whether something was worth publishing.

    The person who eventually benefits from something you publish today might not see the original post at all.

    They might encounter the information through search.

    They might find it while researching your company.

    Or increasingly, an AI assistant might retrieve information from across the web while trying to answer their question.

    That doesn’t mean we should start filling social media with content written for robots.

    Quite the opposite.

    It means businesses have another reason to publish genuinely useful information about what they know.

    Give AI something useful to find

    There are plenty of unknowns around exactly how AI platforms will use social content, and access varies considerably between platforms.

    But the underlying principle is fairly straightforward.

    If useful information about your business doesn’t exist publicly, it can’t easily be discovered.

    You don’t need to post five times a day.

    You don’t need to manufacture opinions just to satisfy an algorithm.

    And you probably don’t need another photograph announcing that there are cakes in the office kitchen.

    Keep posting the things happening in your business.

    Just make sure some of what you’re publishing will still be useful when the cakes are long gone.

  • AI First?

    AI First?

    AI has become an incredibly useful problem-solving tool.

    Give it an error, a piece of code or a description of something that isn’t working and it’ll happily work through possible solutions with you.

    But I’ve been thinking about what happens when AI becomes the first approach to every problem.

    I recently had a UI element that wasn’t behaving correctly on a particular device. I’d gone through various possible fixes with AI, but none of them really solved it.

    Then I stopped looking at the suggested solutions and thought about the problem myself.

    I had an idea.

    It wasn’t groundbreaking or particularly clever, but it worked. More importantly, it was an approach AI hadn’t suggested.

    That got me thinking about experience.

    I’ve been building things for the web for a long time. Over those years you accumulate thousands of little bits of knowledge: things you’ve broken, strange browser behaviour you’ve encountered, approaches that failed and solutions that worked.

    You don’t necessarily consciously recall all of that when solving a problem. Sometimes you just have a hunch worth trying.

    And that’s where I have a slight concern about vibe coding.

    Someone can now build surprisingly sophisticated things with relatively little development experience. That’s genuinely impressive.

    But if AI is also responsible for diagnosing every problem, where does that underlying experience come from?

    If you’ve never spent time debugging something yourself, getting things wrong and understanding why they went wrong, it’s much harder to recognise when AI is leading you down the wrong path.

    AI can give you an enormous head start.

    But there’s still a lot of value in knowing enough to occasionally say:

    I’ve got another idea.

  • After 10 Years of Bootstrap, Why I’ve Moved to Tailwind

    After 10 Years of Bootstrap, Why I’ve Moved to Tailwind

    I’ve been using Bootstrap for well over ten years. It’s been a familiar part of my development workflow for so long that starting a new project without it would have seemed a little strange.

    I’ve always enjoyed working with CSS and SCSS, creating my own components and having control over how websites look and behave. Bootstrap provided a reliable foundation for that, particularly when it came to responsive layouts and grids.

    But recently I’ve made the move to Tailwind CSS.

    Not because I’ve suddenly decided Bootstrap is outdated or because Tailwind is the latest thing everyone seems to be using. The decision has more to do with how my approach to development has changed, particularly since moving in-house.

    I’m becoming increasingly interested in building design systems rather than simply designing individual pages. Systems that provide consistency, reduce unnecessary work and make it easier to develop a website over several years.

    And that’s where Tailwind has started to make sense to me.

    Working in-house changes how you think

    When I first moved in-house, I was the first dedicated digital lead to join the team. There was a considerable amount of work to do, including reinventing how the brand presented itself digitally.

    Over the years, I’ve helped reshape that identity, establishing a more consistent visual language and improving how the brand is represented across its website and wider digital presence.

    That involved a lot of creative work, but also plenty of development, experimentation and reconsidering how things were structured.

    One of the differences between agency and in-house work is the relationship you develop with a brand.

    Rather than moving between different clients and identities, you’re continually developing the same one. You become familiar with its strengths, its limitations and all those little inconsistencies that inevitably appear over time.

    And while brands naturally evolve, you’re not making fundamental changes to their identity every few weeks.

    Once you’ve established a visual direction, the challenge becomes maintaining that consistency while continuing to introduce new content, features and functionality.

    That’s where I’ve started thinking more seriously about design systems.

    Building a system rather than another page

    For me, the ultimate goal is relatively simple.

    I want to be able to create a new piece of content, whether that’s a product page, a landing page or an entirely new section, and have it fit naturally into the existing website.

    The typography should be consistent. Spacing should follow established rules. Colours, buttons, containers and responsive behaviour should already be considered.

    I shouldn’t have to revisit those decisions every time I create something new.

    Of course, that doesn’t mean every page should look identical. There still needs to be room for experimentation and creative thinking.

    But there’s a difference between making a deliberate design decision and repeatedly solving a problem you’ve already solved.

    A good design system should take care of the latter.

    I’ve started thinking about websites less as collections of individual pages and more as collections of reusable components.

    Hero sections, feature grids, product cards, testimonials, comparison tables and calls to action can all become part of a shared system.

    Once those components are established, creating something new becomes more about choosing the appropriate structure and concentrating on the content.

    And importantly, when something needs changing, it can be updated consistently rather than having to revisit dozens of individual pages.

    Why Tailwind?

    Bootstrap already provides many of these things, so why change?

    For me, it comes down to control and how much of the framework I actually need.

    Over the years, I’ve spent a considerable amount of time customising Bootstrap. Changing variables, overriding component styles, adjusting spacing and creating additional SCSS to achieve something slightly different from its defaults.

    There’s nothing particularly wrong with that approach. Bootstrap is designed to be customised, and its Sass architecture makes that possible.

    But I increasingly found myself using its grid and utilities while replacing or heavily modifying many of its visual components.

    Tailwind approaches things differently.

    Rather than providing a collection of predefined interface components, it gives you smaller utility classes that can be combined to create your own.

    That means I’m making more of the visual decisions myself, rather than adapting an existing component to fit what I want.

    For someone who works across both design and development, that’s appealing.

    I can establish the brand’s design tokens, define consistent spacing and typography, and build components around those foundations without having to work around a framework’s existing visual identity.

    It’s not necessarily less work initially, but it feels more appropriate for what I’m trying to achieve.

    I’m not abandoning SCSS

    One thing I was keen to retain was SCSS.

    I’ve used Sass for years and still find it incredibly useful for organising styles, creating reusable patterns and managing more complicated components.

    Moving to Tailwind doesn’t mean I suddenly want to put every styling decision directly into HTML.

    I’m finding that the two approaches can complement one another, provided their responsibilities are clearly defined.

    Tailwind is useful for layouts, spacing, responsive utilities and common styling decisions. SCSS remains useful for bespoke components, complex selectors and styling that makes more sense when managed separately.

    I still like having organised stylesheets and being able to understand how a component works without reading through an enormous collection of utility classes.

    The important thing is avoiding duplication.

    I don’t want one set of colours defined in Tailwind and another collection of slightly different values scattered throughout SCSS.

    The same applies to typography, spacing and breakpoints.

    Those decisions need to come from a shared set of design tokens, with a clear approach to how they’re used throughout the project.

    I’m still refining that balance, but I like having the flexibility to use whichever approach makes the most sense for a particular task.

    Only compiling what I actually need

    One of the features that particularly appealed to me was Tailwind’s approach to generating CSS.

    Most of the websites I work on are built using PHP, with reusable templates and components making up the individual pages.

    Tailwind can scan those PHP files, identify the utility classes being used and generate the CSS required for them.

    Rather than starting with a large collection of predefined component styles, the build process produces CSS based on the utilities it finds in the project.

    I like that approach.

    If I’m not using a particular utility, there’s generally no reason for it to be included in the generated stylesheet.

    It also fits nicely with the idea of creating a streamlined design system. As I build new components or introduce additional layouts, the generated CSS reflects the utilities being used.

    There are some considerations, particularly when working with PHP.

    Tailwind scans source files as text rather than executing PHP, so dynamically constructing class names can cause problems if the complete classes aren’t visible to the scanner.

    That’s something worth understanding before getting too carried away with generating classes programmatically.

    Custom SCSS also needs its own compilation process, so there’s still some thought required around the overall build workflow.

    Nevertheless, I appreciate the idea of generating the utility CSS the project actually uses rather than carrying around a collection of styles that may never be needed.

    It’s a relatively small detail in the wider development process, but one that appeals to my preference for keeping things organised and efficient.

    Thinking about the fiftieth page, not the first

    Something I’ve become increasingly conscious of while working in-house is the difference between building a website and maintaining one.

    Getting the first few pages designed and developed is only the beginning.

    Over time, new products appear, existing services change, marketing requirements evolve and new ideas need to be accommodated.

    You might need a different type of comparison table, a new promotional section or a completely different way of presenting information.

    Without a consistent system, those additions can gradually introduce inconsistencies.

    A slightly different button here, some additional spacing there, another variation of a component that already exists somewhere else.

    Individually, none of these things seems particularly significant. But over several years, they can make a website increasingly difficult to maintain.

    That’s what I’m trying to avoid.

    By investing more thought into reusable components and design foundations now, I’m hoping to make future development more straightforward.

    It should also make it easier to experiment.

    If the underlying design decisions are already established, I can concentrate on how best to communicate something rather than spending time recreating the same visual patterns.

    And when the brand does evolve, having those foundations organised should make introducing changes considerably easier.

    A different way of measuring efficiency

    We often measure development efficiency by how quickly we can produce something.

    How long does it take to build a page? How quickly can we turn a design into a working website?

    Those things matter, but I’ve started looking at efficiency over a longer period.

    If a component takes a little longer to build initially but can be reused across twenty pages, that’s potentially a worthwhile investment.

    If changing a design token updates the relevant elements consistently, that’s time saved in the future.

    And if a new page can be assembled from existing components without compromising the visual identity, that’s a sign the system is working.

    There’s also a creative benefit.

    Repetitive design decisions take time and attention. Reducing them leaves more room to think about content, user experience and the problems that actually require a new approach.

    The aim isn’t to remove creativity from the process. It’s to create more space for it.

    Still learning, still experimenting

    I’m relatively new to Tailwind, and after more than a decade of Bootstrap, there’s certainly some muscle memory to overcome.

    I still occasionally find myself reaching for familiar Bootstrap classes without thinking.

    There are aspects of Tailwind I’m getting used to as well. Long strings of utility classes can become difficult to read, and there’s a balance to find between keeping things flexible and creating reusable components.

    I’m also conscious that it’s possible to overengineer a design system.

    Not every variation needs its own component, and not every styling decision needs to become a configurable option. Sometimes a simple piece of CSS is all that’s required.

    I don’t want to replace one collection of unnecessary complexity with another.

    What I do want is a development environment that feels considered, maintainable and flexible enough to support the website as it continues to evolve.

    Bootstrap has served me well for a long time, and I wouldn’t hesitate to use it again if a project called for it.

    But at this stage, Tailwind, combined with SCSS and reusable PHP components, feels like an interesting direction.

    It’s encouraging me to think more carefully about the relationship between design and development, and how the decisions I make today will affect the work I do several years from now.

    Ultimately, I want to spend less time rebuilding things I’ve already designed and more time improving the website.

    Because the real measure of a good design system isn’t how quickly you can build the first page. It’s how easily you can build the fiftieth.

  • The value of being a polymath

    The value of being a polymath

    “Jack of all trades, master of none.”

    It’s a phrase I’ve heard plenty of times during my career, and usually not as a compliment.

    We tend to like specialists. Pick a discipline. Get really good at it. Put a job title around it and stay within the boundaries.

    My career hasn’t really worked like that.

    A big part of it has been driven by curiosity.

    I like learning how things work. I like making things. And when something catches my interest, I have a habit of disappearing down the rabbit hole to find out more about it.

    Looking back, that curiosity has probably been one of the most useful skills I’ve developed.

    Photography was always there

    Photography has been a backbone running through most of my creative life.

    It taught me to look.

    Composition, light, colour, timing and observation all became part of how I thought about visual things. Even when photography wasn’t directly connected to my day job, the things I learnt through it followed me into my work.

    Then there was graphic design.

    For the early part of my career, design was the bread and butter. Typography, layout, branding and visual communication were the things I spent my days thinking about.

    But the web was becoming increasingly important, and designing something naturally made me curious about what happened next.

    How was it built?

    How did the browser turn this design into something interactive?

    Could I do that bit too?

    So I learnt to code.

    One thing leads to another

    Coding eventually grew from another skill into a large part of my career.

    Design became web design. Web design became front-end development. Development led further into PHP, JavaScript, WordPress, hosting, performance, SEO and the infrastructure sitting underneath websites.

    The interesting thing is that the previous skills never disappeared.

    I didn’t stop being a designer when I became a developer.

    I didn’t stop thinking about photography when I became a designer.

    Instead, the skills started stacking on top of each other.

    Today I can look at a website and think about the code behind it, the user experience, the typography, the brand, the performance, the search visibility and the infrastructure it is running on.

    I don’t think those things are separate problems.

    They are parts of the same system.

    Full stack means more than code

    We normally use “full stack” to describe developers who can work across the front and back ends of a website.

    I’ve always thought about my own version of full stack a little more broadly.

    Code is part of it, but so are design, branding, UX, photography, marketing and increasingly creative coding.

    I don’t claim to be the world’s greatest expert in every one of those disciplines.

    That’s not really the point.

    The useful bit is being able to connect them.

    A technical decision can affect design. A design decision can affect accessibility or performance. Branding can influence UX. Hosting can affect SEO. Marketing can expose a product problem rather than a marketing problem.

    Knowing enough about each part means I can often see those connections.

    And professionally, that has done me a lot of favours.

    Sometimes breadth fits. Sometimes it doesn’t.

    Not every workplace has valued that way of working.

    I’ve worked in environments where having a broad range of skills was useful and encouraged.

    I’ve also worked in places where the expectation was much narrower.

    You’re here to do this particular thing.

    So do this particular thing.

    There isn’t necessarily anything wrong with that. Some organisations need deep specialists and clearly defined responsibilities.

    But I’ve realised over time that I’m at my best when there is some room around the edges.

    When I can ask questions.

    When I can wander into another discipline.

    When an idea doesn’t immediately belong to somebody’s job description.

    Discovering in-house

    I’m currently in my first genuinely in-house role, and it has made me appreciate the value of being multidisciplinary much more.

    Working on one brand and one business over a longer period changes things.

    Rather than completing a project and handing it over, you live with the consequences of the decisions you make.

    You can design something, build it, watch how people use it, measure it, change it and then rethink it entirely.

    I’ve been able to move between development, design, UX, branding, marketing, performance and creative projects depending on what problem needs solving.

    That freedom has probably brought out more of my creativity than roles where my responsibilities were more tightly defined.

    And perhaps more importantly, it has shown me that curiosity isn’t necessarily a distraction from the job.

    Sometimes it’s the thing that makes you better at it.

    The spaces between disciplines

    I’ve become increasingly interested in those spaces between disciplines.

    What happens when you mix programming with art?

    Photography with data?

    Branding with technology?

    Marketing with behavioural thinking?

    Design with infrastructure?

    Some of the most interesting things I’ve made haven’t fitted neatly into a category.

    That’s increasingly where I like working.

    There is a temptation in a career to keep narrowing.

    Choose your thing. Become known for it. Specialise.

    There are good reasons for doing that.

    But there is another path.

    Keep learning.

    Keep collecting skills.

    Keep following things simply because they interest you.

    Eventually those seemingly unrelated interests start connecting.

    Maybe “jack of all trades” isn’t such a bad thing

    I don’t know whether I’d confidently introduce myself as a polymath. It sounds a little grand.

    But I increasingly recognise the value of having a polymath mindset.

    For me, that means curiosity before specialisation.

    It means knowing that learning photography might improve your design. Learning design might improve your development. Understanding development might make you better at thinking about UX, marketing or infrastructure.

    You don’t necessarily know where the next useful connection will come from.

    And that’s part of the enjoyment.

    So perhaps being a jack of all trades isn’t something I need to defend.

    After more than two decades of collecting skills, I’m starting to think the collection might be the point.