Iveco Beyond Lab

Two separate scopes. On the public site the work was development: Statamic architecture and implementation, responsive frontend build, and the editing workflow set up for the internal team. The visual design came from Iveco's internal team.

On the internal platform the split was the other way round. The work there was UI design, on the interface the team uses to build forms and manage the submissions that come through them.

Iveco Beyond Lab is an innovation programme run by Iveco Group, focused on mobility and transportation. Design was handled internally and the build was handled by Bitboss.

The requirement behind the project was less about the site itself than about who would be running it afterwards. In large organisations content management tends to accumulate technical debt: small updates turn into tickets, and every edit depends on someone with the right access and the right knowledge being available. The platform needed to end up in the hands of non-technical internal teams, who would publish, edit and manage applications without going through a developer each time.

The site runs on Statamic, built against a design system that was already defined by Iveco's internal team. That changes what the implementation work is about: the visual decisions were made, so the question was how much control to hand over in the CMS.

The answer was none at the layout level. No editable blocks, no way to rearrange or restyle a section, since the design system exists precisely to prevent that. What the internal team can do is add content. List sections use replicators, so they can add as many items as they want without touching the structure around them, and the open and closed challenges are handled as collections for the same reason: new entries appear where they belong without anyone having to build a page for them.

The result is a site the team can keep filling on its own while the design stays exactly as it was delivered.

Beyond Lab runs on open calls, and each one needs its own form. Handling that as a development request every time would have put the programme's pace in the hands of whoever was available to build it.

The internal platform exists so the team can do it themselves: build the forms, define the steps, set the notifications, and read the submissions that come in. The UI work was making that possible for people who aren't developers and don't think in terms of fields and data structures.

The main problem in an interface like this is that the person using it has to hold a structure in their head while assembling it one piece at a time. Everything is organised around removing that: what you're building stays visible while you build it, configuration is separated by task instead of stacked into one long form, and submissions are kept apart from the tools that generate them.