Designing an events service that does not depend on events

Before proposing anything, I measured the existing service.

The Region's events platform held 269 visible events, active and past, organised into 12 thematic categories. The service existed and was already in use; what failed was how the experience behaved once a citizen arrived.

The first problem was booking. Across those 269 events there were thirteen ways to book: on the website, on external sites, in-person, free entry, email, invitation, forms, phone calls and more. Thirteen ways to do the same thing meant citizens had to relearn the rules every time. The service had no grammar of its own: it inherited the grammar of every source that supplied an event, then passed that inconsistency on to citizens as if decoding it were their job.

The second problem was discovery. Almost half the events, 123 out of 269, carried a single thematic tag. An event with one tag can be found only by someone searching from exactly that direction. An exhibition tagged only as "Culture" stays invisible to a person looking for something to do with children, a weekend idea or an activity near a particular place. The classification was poor, and not through carelessness: it had been designed from the side of publishing rather than the side of searching.

The third problem was depth. Only 16 of the 269 events had any second-level content: an article, extra material, a reason to stay beyond date, place and a short description. For most events, the service ended where the card ended.

Together, these numbers describe a service that behaved like a noticeboard: a place where events were posted, each with its own rules, waiting for someone already interested to come and find them. It worked for people who knew exactly what they wanted, and left out everyone else, the majority.

The obvious move would have been to improve the existing model: unify booking, enrich tags, clean up categories. That was necessary, and not enough, because it left the founding assumption intact, that the service was valuable only for the events it listed. So I stepped back and asked what the service could become if it stopped seeing itself as a noticeboard.

The first step was to say what the service was not. It was not an event creator: others create the events. It was not an event organiser: the machinery that produces them sits partly outside the regional administration. It was not an event planner: the calendar is set by many parties, and not by the service. Three disclaimers that sound obvious, and that a service forgets the moment it tries to justify itself through the quality of what it hosts. We could not guarantee that the events would always be good, plentiful or right for whoever was looking. We could work on everything around them.

The design question became: how can people build a relationship with the service, whatever the number and kind of events on offer? The answer could not sit inside the events alone. It had to be found in everything around them: how people discover them, choose them, prepare for them, use them while they happen and come back later. The shift was from event listing to event experience.

A question like that cannot be answered by adding features. Before deciding what the service should do, I had to decide how it should behave. The image I kept throughout was simple: the service should behave like the owner of a record shop who can always find you the right record for your mood.

A good record-shop owner does not put the whole catalogue in front of you and leave you to it. They ask what kind of day you are having, understand what you want to hear even when you cannot name it, and put something in your hands you might never have found alone. They do not choose for you; they narrow the field enough for your choice to become possible.

The first place the image touched the product was the service's most basic behaviour.

The existing platform told people an event existed: date, place, description, sometimes a link to book. Then the relationship ended. The new concept reframed the service from informative to interactive, a place that accompanies people across the whole arc of the event: before, it helps them discover, choose, book and prepare; during, it stays available through tickets, location-based information and on-site interactions; after, it keeps traces of what people saw or did, helping them return and discover something similar later.

The target journey stretched the experience across three moments, before, during and after, and five channels: web, app, email, social and QR. The service stopped being a page to consult and became a companion.

From this model we explored nine solutions and brought seven into the concept: integrated booking and ticketing; location-based notifications; recommendations based on previous interactions; a personal calendar; notifications along the event journey; reviews from people who had already attended; and post-event content that keeps the experience alive.

Two of them made the shift especially clear. Integrated booking brought the old service's thirteen procedures into one flow, giving citizens a single grammar instead of thirteen inherited ones. Location-based notification was the one solution where the service left its own perimeter to meet people where they were, through the apps they already use to move around: a notification that reaches you while travelling towards Milan behaves less like an archive than like a service that understands your situation.

There was a limit, though. Many of these solutions depended on organisers adopting them: integrated booking works only if they manage registrations inside the service, post-event content only if someone uploads it. The fragility we had started from, dependence on parties outside the service, had reappeared one level up, and it changed how we judged the concept: between two solutions of comparable value, we preferred the one that depended less on behaviour we could not govern.

Once we had decided the service should accompany people, the question was how. We explored two models, and the choice between them is the most important concept decision in the project.

The first was the catalogue, familiar from the large streaming platforms: all the content is there, sorted by type, and the user browses, filters and chooses. Its strength is abundance. The second was discovery: the user starts from themselves rather than from the full inventory, from what they feel like doing and the kind of moment they are in, and the service narrows the field to what answers that intention.

The catalogue exposes everything and leaves orientation to the user; discovery takes responsibility for orientation. We chose discovery. For a public events service, the catalogue assumes a user who already knows what to look for, and that user is the minority. Most people arrive with something vaguer: a free afternoon, a train journey, a wish to do something without knowing what. A catalogue leaves them scrolling until they tire; discovery gives them a way in.

A good recommendation listens before it shows. On the homepage, that became a direct question:

What do you feel like doing?

Below it, the service offered six entry points, written as user intentions rather than administrative categories: find ideas for your free time; discover a place in the region; pass the time; listen to a podcast; visit virtual worlds; experience Milano-Cortina 2026. They were written from the side of the person looking, not the institution publishing.

One of them mattered more than it looked: "pass the time". It was not the most functional label, nor the clearest category, and that was the point. It admitted a real behaviour: people do not always arrive with a task; sometimes they arrive with time. A tourist on a train, someone with half an hour before an appointment, someone who does not yet have a question. A public service that makes room for that is doing something small but important: designing for the people who have not yet worked out what they want, and not only for those who already know how to search.

Of the nine solutions we explored, one was deliberately left out: networking. The idea was to let people registered for an event see the other participants and connect before or during it. On paper it was appealing, and the Region was interested: it added a social layer and gave the concept a feature with obvious presentation value: beyond the event, you found the people. I proposed it myself, at first. Then I proposed not building it.

The first reason was feasibility. When we mapped the nine solutions on a matrix of strategic value and feasibility, networking fell low. It was less a feature than a community, and a community on a public platform needs structural moderation: people, daily oversight, legal responsibility and reputational risk over what users write. None of that sat within the Region's perimeter, and promising it would have meant building something destined to go unmaintained.

The second reason mattered more, and it made the decision final: networking did not fit the character of the service. A service that accompanies people through everyday moments, reachable and without thresholds, asks little of them. Networking asks a great deal: it exposes you, assumes you want to be seen, and moves the service from the everyday to the exceptional occasion, and from openness towards exclusivity, where an active community rewards those who take part most and leaves the occasional visitor at the margins. It was the opposite of the direction we had chosen.

Networking failed the control criterion twice over: it depended on a critical mass of active users the service could not guarantee, and on moderation the Region could not sustain. Removing it cost us a feature that looked good in presentations and that the client liked. In return we gained a service that could hold without daily community management and stay true to its character. For a public service, that is a fair trade.

A service needs a name, and a name is a product decision: it sets the character before the citizen opens the page. On this one decision the control left my hands, and it is worth saying how and why.

With the copywriter, we explored several directions. Some were cautious, keeping "Lombardia" explicit and adding a verb or an idea of experience: Vivi Lombardia, Lombardia Experience, Lombardia 360. Others were bolder, breaking from the regional name to build a brand from scratch: Revent, Viving, Espublica. The bold names interested me more: a name that does not lean on the territory forces the service to stand on its own. They were also riskier, and in a public body the risk around a name is a long conversation.

The Region was undecided, and indecision over a name is not resolved by another presentation. The choice was handed to an internal vote in the Communications department. Lombardia Experience won, one of the cautious options; the bold ones went out in the first round.

It is not the name I would have chosen alone, and I will not pretend otherwise. Still, it is correct, it says what the service does, and it keeps "Lombardia" where the Region wanted it: a compromise rather than a leap. Yet what matters here is less which name won than who it now belongs to: the people who have to use it and defend it for years inside the administration, not the consultant passing through. A name imposed by the consultant and weakly held by those who inherit it dies at the first hard moment; a name voted for by the people who stay is one someone will defend. Handing that decision to the department that lives with it was the first of two points where I let go of control on purpose, and it was no surrender: holding on would have weakened the service rather than protect it.

The second point where I let go of control was the handover. I worked on the concept until January; after that the service passed to the team, who carried it to release, with the final interface built by the junior designer I had worked with for months. A concept that stops working the moment its author leaves has failed, however good it looked on paper. The proof that this one worked is that it went on coherently without me.

That coherence did not arrive on its own, and it is the part of the craft I most want to describe. With the junior designer, the work was not explaining solutions to copy. We worked through epics and journeys, walking the flows from different angles before fixing any screens. Designing the interface too early freezes decisions in the shape they took that day; working first through journeys keeps the choices open and lets the service's character surface before its appearance. Once that character is clear, the interface becomes something another designer can carry forward.

This is where the vision, the record-shop owner, did its work. It was the criterion the team could use to decide whether a new screen belonged to the service or betrayed it.

A shared compass is worth more than a list of instructions, because instructions cover the cases you predicted, while a criterion covers the ones you did not see coming.

The work with the junior designer was less about handing over answers than about building the criterion he would use to find his own.

The service is online now, as Lombardia Experience. What interests me about a release, months after the concept left my hands, is what survived and what changed, because that is where you see whether the decisions held.

The discovery model survived. The live homepage opens with the same question as the prototype, "What do you feel like doing?", and uses thematic entry points in place of a grid. The most important concept decision, discovery over catalogue, reached the citizen as designed. The everyday, close-at-hand personality I had tried to give it is legible in the finished product without anyone having to explain it.

The team also widened the perimeter, and here there is an honest thing to say. The live service no longer covers only events: it holds podcasts, virtual worlds, regional places, itineraries and an entry point for Milano-Cortina 2026. Some of it was already present but disconnected in the old footer; the team brought it into the discovery logic instead of leaving it as scattered links. Rather than betray the concept, the expansion applied it to a wider perimeter.

An event ends. After that there is nothing left to design inside the event itself. For a long time, public services built around events have worked like megaphones: switched on when there is something to announce, quiet when the calendar empties. They work in the peaks and vanish in the gaps, and the gaps are most of the year.

Designing the service instead of the event means working on those gaps: asking what the service does on an ordinary Tuesday, when there is nothing remarkable to promote, because that is where people decide whether to come back or forget it. The Olympics will pass, and the service will still be there, with its local festivals, its small-town exhibitions, its afternoons with nothing dazzling to offer. A service built for those afternoons can carry the Olympics too; a service built only for the Olympics would not survive the afternoons.

I have no usage metrics to show. The service is young, and the numbers that would say whether people actually came back are not in my hands: registrations, repeat visits, retention. It would be easy to fill this space with estimates. I will not. For a concept project, the more telling evidence is different: the personality given to the service months earlier held as it passed through a team that carried it forward and expanded it without me, and reached the citizen intact.

The service began as an events platform. It became a way to help people find something to do, even when they did not yet know what they were looking for.

Afterword

The distinction holds beyond this project. Public work often runs on the energy of an occasion: a deadline, a big event, funding tied to a date. That energy is real and worth using.

The discipline is to spend it on what stays useful once the occasion has passed and the attention moves on, rather than on the occasion itself.