For far too long, we at SVT approached user needs by adding new systems — each with its own user interface, each with little ability to talk to the others. The result was complexity, friction, and a growing gap between technology and the editorial teams it was supposed to serve. Journalists adapted as best they could, juggling logins and formats, often bending their workflows to fit what the tools allowed rather than what the story demanded.
When we started building Astrid, SVT’s in-house CMS, we didn’t begin with a 40-page spec. We began with proximity. Developers and our UX designer worked alongside editors and reporters — not just in structured meetings, but in the everyday hum of the newsroom. We observed how breaking news really gets filed, how images are selected under pressure, how deadlines shape decisions. That closeness — physical and cultural — shaped everything.
The result is a tool that doesn’t just support editorial work — it understands it. Astrid wasn’t built for journalists. It was built with them. That distinction may sound subtle, but in practice, it made all the difference. Instead of chasing feature parity with commercial platforms, we chased relevance. Instead of building what the market said newsrooms should want, we built what our newsroom needed — even when it looked messy on a whiteboard.
That collaboration gave us something more valuable than any requirements document: context. We saw the reality of news production up close — the speed, the shifting priorities, the need for tools that enable creativity rather than stifle it. We heard the edge in someone’s voice when a system got in their way. We learned that the smallest delays — seconds, not minutes — can derail a tight publishing flow. And we felt their relief when a fix landed — not three sprints later, but the same afternoon.
It also made us acutely aware of how different newsroom environments shape different needs. SVT has over 30 local newsrooms, many of them small teams working independently to cover their regions. Their constraints and priorities aren’t always the same as those in a large national editorial office. The tools had to scale down as well as up — staying lightweight and fast, without sacrificing quality. We learned to balance complexity with clarity, ensuring Astrid could adapt to both breaking national coverage and a one-person newsroom working late on a Friday.
Astrid was built in that space — between the deadline and the deploy. It evolved out of real pain points and real newsroom rhythms. Features didn’t come from abstract brainstorming; they came from editors tapping you on the shoulder to ask, “Can this be quicker?” or “Can this be easier, more streamlined?” Often, the best ideas came from casual conversations — over coffee, or while watching a producer try to publish a story in the middle of a breaking news event.
That kind of feedback loop doesn’t scale easily. It’s noisy, it’s messy, and it doesn’t fit cleanly into agile ceremonies. Sometimes, users didn’t know what they wanted — only what they didn’t. So we listened, sifted, tested, and iterated. And we kept showing up. We kept shipping. Even when it meant revisiting a “finished” feature because it didn’t quite work the way the newsroom needed it to.
And in the end, we built a CMS that gives users what they actually need — one that people genuinely like using. In this industry, that’s almost a miracle. But it didn’t happen by accident. It happened because we worked in the newsroom, listened hard, and cared as much about the people telling the story as the platform that delivers it.