When an organisation redesigns its website, the conversation soon turns entirely to tools, features and mock-ups. Since the Pocket Films Festival in 2005, whenever I build a working tool with a team, I start with the people who will use it, and the technology comes afterwards, without being any less demanding for that. This article opens a series on commissioning a website, structuring its content, its day-to-day life and the place of artificial intelligence.
A team so happy to be building its website
In a cultural institution, I saw a team so happy to be building its website that it forgot why it was building it. I understand that pleasure very well, having built websites myself for some twenty years: you watch the home page take shape from one week to the next, and at every meeting there is something new to look at. But who is this website meant to serve, and who will keep it updated once the contractor has gone? These questions were usually asked at the start, often very well, in a statement of intent or a specification, and then lost sight of along the way.
I don’t think this comes down to the people involved, but to a professional habit I have already described in Building professional tools with the teams: in the cultural sector, and in many others, the working tool is readily seen as a matter for technicians, and it gets delegated, with a specification made up of a list of features.
Three people, and three minutes between two appointments
First there is the editor who updates the website every week, in between two other tasks, and who should not need to understand the site’s architecture to put a news item online; I devote an article to her, An editor should not need to understand the site’s architecture to publish.
Then there is the administrator, who creates a new section when a new scheme comes along. Around 2010, when I rebuilt the website of the ACID, the filmmakers’ association that supports the theatrical release of independent films, the team gained the freedom to add a section, and to move and reorganise content. With SPIP, the software behind that site, moving a section breaks neither the links nor the page addresses, which is not the case with every piece of software; I explain this in A link that never breaks.
Finally, for the Azimut platform of the Maison des pratiques artistiques amateurs in Paris, the people who come looking for information, sometimes in three minutes between two appointments, are amateur artists. The artists we consulted before the redesign, from the autumn of 2023 onwards, mainly told us of three needs: to be listed somewhere, to network, and to share resources and good tips. To my mind, a website should be judged by what it allows these people to do, far more than by its list of features.
This is how I understand Ivan Illich’s sentence in Tools for Conviviality (1973), which I have already quoted in Setting the table: “Tools foster conviviality to the extent to which they can be easily used, by anybody, as often or as seldom as desired, for the accomplishment of a purpose chosen by the user.” For a website, that purpose is the why, and it is up to the team to set it, together with the people it serves.
When publishing is a chore, content grows stale
In the first year of the Pocket Films Festival, in 2005, we had a rather static “showcase” website. From the second year on, we had it rebuilt with SPIP by a contractor, Neodicio, so that it could follow the life of the festival week by week. When publishing is a chore, people publish less often, the content grows stale, and nobody comes looking for it any more. That is why I don’t see the comfort of the people who run a website as a matter of ergonomic detail, to be sorted out at the end if there is any budget left.
The word you will hear from your contractor for the part of the site where you write and publish is back-office. At the ACID, we built the website and the databases over a year and a half, so that the structure of the information could take shape as the team used it, and a good part of my work consisted of listening to its needs and training the editors. For Azimut, from February to June 2024, we regularly presented the back-office to the MPAA team while it was being built. This is how small snags come to light, for example a required field that is only flagged after saving, when the text has already been lost. They are not serious, but the frequency of publication depends on them, so I suggest planning a period for adjusting the back-office after the first few weeks of use, before the public launch.
Otherwise, it is the team that adapts to the tool: people keep a list in a spreadsheet, alongside the back-office, for a case it does not cover, and after a few years this workaround has become a procedure; I come back to this in A contractor leaves a way of working behind. None of this exempts anyone from technical rigour. In 2023, the website of the visual artist Virginie Houdet, created eight years earlier, had been broken by a security flaw because the software had not been updated. When I rebuilt it, I made sure it displayed well on a phone and responded much faster, and she started updating its content again. By delivering a website that is slow, or unreadable on a phone, we fail to respect the people who use it; that is the subject of Technical rigour is not the enemy of the human, it is its condition.
Client, contractor, and the people who will use the building
In French building terminology, which is also used for IT projects, the maître d’ouvrage is the one who commissions, and the maître d’œuvre the one who designs and builds. Between the two, there is often an assistant à maîtrise d’ouvrage, who helps the client write the specification and check what is delivered. For some years now, professionals in building and urban planning have also been speaking of assistance à maîtrise d’usage, user-side project support: it means accompanying the people who will occupy a building, before, during and after construction, so that they can live in the place as they see fit. On 22 October 2019, in La Garde, the Provence-Alpes-Côte d’Azur branch of the Centre national de la fonction publique territoriale, the French training body for local government staff, devoted a training day to it, whose programme spoke of an “emerging cross-cutting discipline”.
I borrow this expression for websites. Whoever provides user-side support helps the client to formulate their needs and to check the work, as in conventional project-management support, and in addition makes actual use the criterion for their decisions, including when it contradicts an initial intuition.
For me, this is also a way of working that belongs to cultural rights, in the sense that each person taking part in the project, whatever their role and their ease with technology, knows something about what needs to be built. For Azimut’s visual design, we worked with the graphic designer Martha Dro, herself an amateur artist who uses the MPAA for the shows she takes part in: she knew the artists’ needs from the inside. It is to bring this kind of knowledge into the project that it is better to ask the team “what would you need to work better?” than “do you approve this?”. You then hear needs that nobody had put into words, often because people had long since given up voicing them.
I practised this method long before I gave it this name. Around 2010, at Périphérie, in Seine-Saint-Denis, before building a contacts database, we spent three days with the whole team on the structure of the information, the fields to keep and a first prototype, with each person bringing the point of view of their own job. In Les Lilas, between 2019 and 2022, we drew up the department’s data map with the cultural affairs department before building its tools. Along the way we found spreadsheets in several copies and, for every official invitation, files going back and forth between the mayor’s office and the department; I recounted this support in Experimenting together to become autonomous : seven years with the cultural affairs department of Les Lilas.
The order of work I suggest, and what it costs
The redesign of Azimut shows this order quite well. We carried out the consultations with artists starting from the existing site, alongside technical studies; the raw material of a website is almost always already there, and what is missing is the structure, which I go into in Reading your own website before redesigning it: the content inventory, starting point of any redesign. We then chose the tool, SPIP, a free software package, so that the platform could evolve without depending on any contractor, not even my agency. The basics for discussing this choice with a contractor are in Why understand how the web works, and what the site can become also depends on the format in which your content will be stored, which I discuss in In what format are your twenty years of content stored?. The first version went live on 7 June 2024, with a deliberately minimal design, and we waited to see how the team and the artists took it up before moving on to new features and the visual design. The official launch took place in February 2025; I recounted how it was made in Strategy, design and technical implementation of the « Azimut » platform.
Who will keep the website updated after it goes live, and with how much time each week? This question is rarely asked in a specification, and yet the lifespan of a website depends on it. In Les Lilas, the person who drove the contacts tool with the most energy left along the way, and it was a work-study trainee, hired for a year, who kept the Lil’Art tool going and developed it according to what the team actually did with it.
It was the Pocket Films Festival that first convinced me to work in this order. I founded it in 2005 with the Forum des images and ran it until 2010, and we were able to think big with a small team because our working tool was built alongside the festival, over six years. Every week, we asked the team what it would need to work better, and the tool evolved accordingly, until it ran the festival from start to finish, from contacts and the reception of films to invitations and logistics.
Working in this order takes time and money: time from the team during the project, for regular sessions like those for Azimut, and money set aside after delivery for further development, whereas many contracts only provide for keeping things as they are. In return, you don’t have to redo everything every five years, and the team, which understands its tool and holds the access to it, can develop it with or without a contractor. In 2009, the quotes we had requested to develop the festival’s website were too high; since it was built with SPIP, I was able to redesign it myself, and all the content from previous years was preserved. With artificial intelligence, this kind of ownership is now far more within reach of teams; that is the subject of What artificial intelligence changes in taking ownership of your own tool.
Three questions remain that no contractor can answer for you. Who will publish, and with how much time? What can you leave out of the first version, as we left out Azimut’s visual design? And how much money are you setting aside to keep the website alive after it goes live? Once you have answered them in the specification, you have described a tool for use, and you can then make the technical choices with full knowledge of the facts; I come back to this in Writing a specification that talks about objectives.
The pleasure of building is a good driving force, and I am not suggesting giving it up, I know something about it! I am simply suggesting that, at every stage, we ask ourselves who we are building for, and to do what.
