Category: Behind the Build

A look behind the scenes at the decisions, challenges, and creative problem-solving that go into designing and developing websites for nonprofits and small businesses.

  • Good Web Design Starts with Better Questions

    Good Web Design Starts with Better Questions

    Clients often come to a website project with a list of things they want.

    A blog. More interactivity. Better analytics. A newsletter. More ways for visitors to engage.

    Those requests are important. But they aren’t always requirements. Sometimes they’re the beginning of the conversation.

    Good web design starts by looking beyond the requested feature and understanding what the client is actually trying to accomplish.

    Start With What the Client Is Really Trying to Accomplish

    My clients’ success matters to me. One of the most valuable things I can do during a website project is listen closely enough to ask the right question next.

    If a client says, “We want a blog,” I want to know:

    • How will they manage the blog?
      • Who will develop the topics?
      • Who will write the posts?
      • Who will approve them?
      • Who will find and prepare images?
      • Who will publish the content?
      • And how often can the organization realistically do all of that?
    • What goals will a blog help them meet?
    • How will they know it’s working?

    Because a website feature is only useful when there is a clear purpose, a person responsible for it, and a realistic process for keeping it working.

    Can the Organization Support the Feature?

    That is to say, I’ve seen organizations plan websites around the organization they hope to become rather than the organization they currently have the staff and resources to operate.

    Which isn’t necessarily a bad thing. Good web design should support growth.

    But there is a difference between planning for growth and building functionality that no one can use.

    A blog is a good example.

    Technically, building the blog may be straightforward. The harder question is whether there is someone available to develop topics, write articles, secure approvals, find images, upload content, publish consistently, and evaluate success.

    If that capacity doesn’t exist, a sophisticated blog system doesn’t solve the underlying problem or meet the desired goals.

    The Same Questions Apply to Other Features

    The same questions apply when someone says they want a more “interactive” website.

    What does interactive mean?

    Comments? Surveys? Events? Community submissions? Member discussions?

    And once people begin interacting, who will respond to them?

    Analytics raises another set of questions.

    What information does the organization actually need? Who will review the reports? What decisions will be made differently because of what the data shows?

    Sometimes the Right Answer Is: Not Yet

    Sometimes asking those questions confirms that a feature belongs in the project.

    However, sometimes it reveals that another priority is more important.

    And sometimes the answer is: not yet.

    When a client feels strongly about an idea but doesn’t yet have the capacity to support it, I often recommend building in phases.

    Build what the organization can use effectively today. Create a roadmap for what comes next. Then add functionality when the people, processes, and need are there to support it.

    Good web design isn’t about building the longest list of features.

    It’s about listening carefully enough to understand what the client is really trying to accomplish—and asking the questions that help us build the right thing.

    I’m listening, and I have questions.

  • A Simple Subscribe Button Isn’t Always Simple

    A Simple Subscribe Button Isn’t Always Simple

    As many of you may know, WordPress is my go-to website builder. Clients often ask me to integrate or embed features I am not familiar with. Today, a client sent me a link from Beehiiv and asked me to add it as a Subscribe button in the main navigation of her WordPress website.

    At first glance, that sounds simple enough.

    But when I clicked the link, it asked me to log in or create a Beehiiv account. That told me right away that this was not the public subscription link. It was an internal Beehiiv Website Builder link.

    That matters because visitors to client website.com should not need a Beehiiv account to subscribe to a newsletter.

    After logging into the client’s Beehiiv account, I saw that clients-newsletter.beehiiv.com already had subscription forms on the public Beehiiv page. Those forms work there, but they are part of the Beehiiv-hosted website. They are not the same as an embeddable subscribe form for the WordPress site.

    So the solution was to clarify the options to the client:

    • The Subscribe button in the WordPress navigation can link directly to the public Beehiiv newsletter page.
    • Or, if the client wants the subscription form to appear directly on clientwebsite.com, she needs to create an external subscription form in Beehiiv and send me the embed code.

    This is one of the things I enjoy about website work. I do not need to be an expert in every platform my clients use, but I do need to understand how to ask the right questions, test the link, and make sure the visitor experience is clear.

    A small detail like using the wrong link can create unnecessary friction for the audience.

    The goal is always simple: make it easy for people to take the next step.