When creating custom, interactive data visualizations, adjustments are part of the process. Whether it’s tweaking the visual display after testing with real data or editing the surrounding text when embedding the viz in a webpage. These are expected, iterative improvements that keep the project on track.

But then there are the other kinds of changes. These are the ones that come out of nowhere and feel urgent, such as when a client’s marketing team suddenly wants to change a headline after the viz is already live. Or there are also the changes you know are coming, like monthly data updates.

These are the moments where configurability can be a game-changer. By coding the visualizations with some flexibility in mind, I can empower clients or team members to independently do small changes quickly and we all save time and communication overhead.

What do I mean with "Configurable" in Data Viz?

I am talking about enabling non-technical users to update elements of a coded data visualisation on a website. This could be anyone with access to the website, such as a member of the client's data or marketing team. They can then edit texts or underlying data without knowing how to code.

Why does it matter?

Small changes, like fixing a line of text, can be surprisingly annoying. If making that change means sending emails, creating tickets, and waiting for replies, it sometimes gets ignored with a shrug: “Not important enough.” Especially if it's involves changing the same text again and again.

But when these little, unrealized tweaks add up, the final product ends up weaker than it could be. After all the effort already put in, that’s frustrating and feels so unnecessary to me. In many cases, simple independent configuration could make some of these improvements instantly, saving time and making the end result shine.

Advantages for the client and team members:

• Agility & Speed: Making changes independently is faster and avoids extra process and communication steps.
• Autonomy & Confidence: Working with someone halfway around the world can feel intimidating. Being able to make quick updates yourself creates a sense of control and relief.
• Ownership & Trust: Giving clients the power to manage small changes can strengthen the trust in the relationship.
• Cost: Project scope and budget discussions can focus on meaningful improvements, rather than minor tweaks.

From my experience, it’s not about whether the options actually getting used. Simply knowing you can make changes already creates some trust and confidence.

Tips & examples on how to realize configurability

How you implement configuration options always depends on the specific requirements of the project and especially its tech stack. Here I am thinking of a visualization that lives inside a client’s website with a CMS like Webflow or WordPress.

Making text configurable

In general, I try to avoid hard-coding text in the visualization whenever possible, especially for longer phrases like headlines or explanation paragraphs. These are usually the parts that receive the most changes.

→ Tip 1: Do not create surrounding text in the code

If the visualization is embedded in a CMS, create the surrounding text directly in the CMS and embed the visualization container below or between the text elements. This makes updates easy and avoids touching the code. It sounds obvious, but this means that when you look at your coded end result individually, it might look 'half-done' because the surrounding text is missing.

→ Tip 2: Use simple variables for text in the embed code

If the text cannot be easily extracted (e.g. due to a more intertwined design), you can allow separate text configuration with JavaScript variables. Since all websites run on some JavaScript, the most universal solution is to use the window object, which can be set in the CMS along with the embed code. Yes, technically that means the client touches some lines of code but well named variables and a good comment go a long way to make this super easy for non-coders as well.

<script>
  // Configure text by changing the following lines
  window.customChartConfig = {
    title: "This great chart headline communicates the insight",
    subtitle: "Metric X over metric Y",
    source: "Source: GreatResearchInstitute Z, conducted in 2026",
  };
  ... remaining embed code ...
</script>

In general, I avoid configuring data-visualization-specific text elements like axis labels. Changing axis labels late in the process can make charts misleading or break layouts if the text is longer than expected. These changes are also rarely requested, and if they are, they should be discussed properly.

Making data configurable

Making the data behind a visualization configurable usually requires more effort than just making some texts editable and it highly depends on the project and tech setup whether it makes sense to give the client the option to change the data themselves. A simple data configuration is not useful when the data either never changes or when a change in the data requires way more complex edits in the overall project (e.g. a different data structure, necessary data cleaning steps). But if the project requires frequent, but relatively simple data updates, it's important to provide a way for the client to handle them independently without relying constantly on my development resources.

Data lives in a database or is accessible via API

The easiest scenario is when the data is stored in a database and can be fetched through an API, with the client able to maintain the database or the database is sourced with real-time data. In this case, the visualization automatically shows the most current data, and no additional configuration is required.

Data is static

Often, data is stored in a static file, such as Excel or CSV. In these cases, I typically implement one of two approaches to make simple updates straightforward:

→ Tip 3: Use Google Sheets and fetch data programmatically

If working with Google Sheets is an option for the client, I transfer the data into one or more sheets and activate the “Publish to the web” option as CSV for the relevant sheets. The visualization then fetches the data directly from the published sheet, so any updates in the sheet are reflected immediately in the visualization. This approach effectively makes the data “live”.

→ Tip 4: Replace an externally stored, static CSV file

Alternatively, I fetch the data from a CSV file stored on a server (e.g. on a cloud platform or in the CMS media uploads) that is accessible to the client. In the embed code, I create a variable for the data URL that points to the externally stored CSV file. The client then uploads the new data file and updates the data URL in the embed code to the see the updated visualization. I avoid replacing the original file directly so a rollback to the previous version is easily possible.

In both cases, it's important that the data structure (e.g. the table, column names, data types, data format) stays the same, with only the row contents changing. If not, the data visualisation will not work because the code does not know about the new data structure.

But not everything should be configurable

Just to be clear: configuration can enhance a data visualization project, but the goal is not to make everything editable. This is not about turning every project into a full-fledged data viz editor. Design and data viz decisions, such as the type of visualization, the visual display, the layout, they styling, and the color choices, are made consciously during the design and prototyping phase for a reason.

That's why I do not enable clients to configure styling settings, layout choices, or color palettes. If changes to these elements are needed, a proper conversation about the reasoning and best approach is necessary.

Communication, communication, communication

Communication is key in every project, and configuration options are no exception. If clients don’t understand how to use them, they obviously won’t be used. I usually combine a short written guide, often a PDF sent by email, with a quick screen recording showing the steps in action. If needed, I also hop on a video call and walk the client through the configuration on their own machine, giving them a trial run so they feel confident using it independently.

Some configuration might only be needed months later, so a clear documentation is essential. Even something as simple as an email with a clear subject line about the configuration can save time and reduce friction later on.

But what if...?

But what if adding configurability makes the project more complex?

Yes, it can require more coding and documentation effort than hard-coding everything. However, providing the right options at the right moments usually leads to a better end result. The key is to think about configuration needs early in the project rather than as an afterthought. Planning upfront ensures it adds value without unnecessary complexity.

But what if the client breaks something?

It can happen, but the risk can be easily minimized. Clear fallbacks in the code, input validation, and limits can prevent most issues. Documentation should also explain how to restore the previous state if something goes wrong, like I mentioned above.

But as a freelancer, don’t you want the client to depend on you for changes?

For small wording updates or a CSV upload? No. Those are the kinds of changes I would never invoice for. The goal is to free clients to make minor adjustments themselves so that my time is spent on real project improvements and impact-driven iterations.

Configurability isn’t about handing over control blindly. It is about giving clients the right tools at the right time. Small changes become easy, projects run smoother, and everyone can focus on meaningful improvements.