Skip to content

InPublix

The agency's SaaS platform for digital annual reports, which I initiated and owned end to end for over a decade.

The agency needed to move annual reports from print to the web, and PDF proofing was the bottleneck. I initiated InPublix to solve it and owned it end to end, from requirements to support. Clients like Peab have produced their reports on it since 2016.

Listed, state-owned and municipally owned companies have relied on it for annual, quarterly and sustainability reports: business-critical deliveries with legal requirements and hard deadlines. I built the platform technically, but the reports were always team work, where I was the expert on technology and production.

  • 10+ years in continuous production with paying clients, several relationships spanning a decade
  • Most capabilities grew out of client work, then went back into the shared platform for everyone
  • Owned the whole product: architecture, development, hosting, security, support and training, and prepared contracts and sales material together with the team

Communication & UX

Users, content and communication

For the editors

Most of the people working in InPublix are editors, proofreaders and report teams, not developers. Over the years the platform was shaped around their work: bilingual tables where the editor sees which rows and columns appear in each language, PDF templates built by drag and drop, proofreading directly in the web version, track changes between versions and an Excel import that keeps formatting.

The improvements came partly from explicit requests, but often from client conversations and from noticing that several people got stuck in the same place.

For the clients' expression

Every client has its own visual identity, but the platform is one codebase. Instead of new code per client, the editor offers combinable formats (for example H1 + small, or Button + internal) and a colour palette defined once per project in the Customizer. A changed colour definition reaches every module without coding. The base design for each report came from the art directors; my part was making it buildable and configurable.

For new clients

In a later update of the platform, in 2022–2023, I made the Figma sketches for the InPublix foundation: different navigation systems, the basic heading levels and the colour scheme. Menus and the whole interface were made as components, so they could easily be updated on every page when a new client came in. The aim was to make the process easier and tie the design to the finished code, with the same navigation, interface, modules, typefaces and colour scheme in both. The files are not available to show here.

For the readers

The clearest UX decision is the navigation, and it took shape in three steps.

The problem. An annual report is read in two ways. Some readers go through it from the start, like a printed report. Others are looking for a particular figure or section and want to get there directly.

The base solution. So every report got a beginning and an end, with paging between the pages in order, combined with an overview menu for anyone looking for a specific page.

An alternative when the conditions changed. Beckers Group's sustainability report had fewer pages and a client who partly did not want paging. That opened up a navigation with images and links directly in the menu, where the reader moves through the top menu and the pages themselves. The sketches were made together with the art director. The variant became an option for every report on the platform, switched on in the settings instead of built as a one-off.

Evaluation and adjustment. Colleagues at the agency who were not in the project group went through the report and said what they thought and how it worked. It was a simple internal review, not a task-based usability test. It showed that it was unclear what counted as a story, and that was clarified in the next version.

Accessibility. For LKF, a municipal company, an accessibility mode was built for the navigation, with a skip link, keyboard navigation and clear focus. It is also switched on per report. The example is shown under LKF among the projects.

Process

How the work was done

From a production problem to a product

InPublix started at Bysted as an answer to a concrete business and production need: the move towards financial communication and purely digital reports. It also opened up for additional sales. It has been in production since 2014 and continued under Hallvarsson & Halvarsson, where it was mainly in maintenance, focused on stable and secure operation for existing report clients.

Two tracks of development

Development always ran on two tracks. One was reactive: specific client deadlines and requests. The other was proactive: features I pushed into the roadmap ahead of need, based on patterns I saw across the client base. The chart generator and the bilingual tables, for example, were shaped by years of close work with Peab's report teams, then generalised back into the shared platform.

Working with the project teams

Structure, modules and user flows were worked out in workshops with art directors and project managers. In client projects I advised on how to work with digital reporting, often combined with printed PDF reports, and proposed new solutions when the existing ones were not enough, from the sales dialogue and follow-up to development and support.

Technical

Architecture & capabilities

Architecture principles

  • Single WordPress multisite codebase serving many customers, each report a themable, permissioned publication
  • Reusable module library (bilingual tables, charts, print templates) shared with the sister project Dbase, rather than one-off per-client builds
  • Print output generated from the same HTML source as the web view, so there is no parallel PDF template to maintain

Capabilities

  • Per-publication access control with separate read/write levels, toggleable per report
  • Configurable print templates: page selection and order saved per language, multiple templates per report
  • InDesign round-trip for proofing: HTML pre-processed and converted via Pandoc to Word; custom InDesign scripts apply styles on import, with change tracking for editors
  • /print-all: a print generated straight from the structure, without building a print template
  • Access control and early two-factor authentication, so no one reaches a report before it is published

Charts

  • A separate WordPress plugin that I built for InPublix and developed continuously with Peab
  • Each chart has its own data table and its own settings for chart type, colours, bars, legends and so on, so editors change a chart without code
  • Rendered dynamically with Highcharts, on the web and in the PDF generated from the same page
  • The same chart code was later reused in Dbase

Language versions

  • Reports are published in Swedish and English, with WPML handling the language versions
  • Translation runs through WPML's XLIFF export and import: content goes out to the translators as XLIFF files and comes back into the report as the other language version
  • Each page is linked to its counterpart in the other language, so the language switch leads to the same page rather than the start page, and search engines get the language alternates
  • Print templates are saved per language, and the bilingual tables format figures per language, so both versions can be printed and proofed separately

Design decisions

What Why Resolution
Access control No standard WordPress solution handled group-based, per-publication permissions across a multisite network Off-the-shelf membership plugin combined with custom Hooks/Actions
Print PDF generation Early versions mirrored the web structure 1:1, which broke print layout Purpose-built print engine: page picker + saved templates → HTML → browser print-to-PDF
Bilingual number formatting Manually maintaining formatted numbers per language didn't scale Figures entered once, formatted per locale automatically at render/export time