When Design Meets IA: Building Content That Actually Works
Roland Muts and I gave the following presentation at LavaCon 2025.
TABLE OF CONTENTS
What Is Design (and Why It's Bigger Than You Think)
Design is the practice of using visual elements to create a complete and cohesive user experience and communicate a message effectively. That definition sounds straightforward until you realize how often organizations apply it only to external, customer-facing surfaces — the brand, the website, the product interface — and overlook the internal ones. Portals, intranets, and HR systems are content experiences too. For the employees who rely on them, those internal platforms are every bit as important as anything facing the public. When we talk about design in this context, we mean both: the full range of environments where someone needs to find, use, and trust content. If the design of those environments is beautiful but the content can't surface correctly — because the architecture behind it doesn't support what the interface promises — the design fails. That's the core tension this presentation explores.
The Content Strategist Role
Content strategists do more than write or organize content — they translate business goals into content initiatives and advocate for content as a strategic asset, not an afterthought. The role involves developing user personas and user journeys, conducting usability studies, and leading cross-functional efforts to build content-based support for end users. Equally important is the work of providing guidance and insights to stakeholders who often don't think about content until something breaks. In an age where AI is increasingly used to surface and synthesize information, the value of well-structured, intentionally authored content is only growing. Content strategists are the people in the room making the case that what gets created, how it's structured, and where it ends up are not separate decisions. They're all part of the same problem.
The Information Architect Role
Information architecture spans two distinct domains, and understanding the difference is essential. The management information architect works with source content: harmonizing requirements, developing content structures for reusable purpose-based units, and defining metadata usage so that content can be created consistently and at scale. The delivery information architect works on the other end: designing the IA for content delivery platforms, instantiating user journey logic into the actual experience, and defining the metadata that supports navigation, filtering, and search. Most organizations have more delivery contexts than they have centralized sources — and every delivery context needs its own architecture or content will fail to perform. These two roles have different vantage points, and when they don't collaborate, gaps open up between what the content can do and what the platform expects.
Who's in the Room? Setting the Context
At the start of this session, we asked the audience to identify their roles: content strategist, information architect, both, or neither. The mix of hands reflects what we see across the industry — these roles blur in practice, especially in smaller organizations where one person wears several hats. Whether the title matches the role or not, the work described in this presentation applies to anyone who touches content structure, delivery, or the experience of finding and using information. The distinction between strategist and architect isn't about hierarchy — it's about perspective. Both perspectives are required for the kind of collaboration we're going to walk through.
The Project: One Source, Multiple Delivery Targets
The project Roland and I have been working on together for over a year is a real-world example of what it takes to get design and information architecture right — together. The goal: deliver optimized content to an internal platform from a single DITA source, supporting both HR and Sales teams. The challenges were significant. The existing platforms needed to be extended to accommodate new display requirements and content types. The management IA had to be expanded to handle those additions. And access to certain deliverables had to be controlled based on team permissions — meaning metadata wasn't just an organizational nicety, it was a functional requirement. This project became a working model for the kind of collaborative process we're describing: not design first, then IA, but both, in conversation, from the start.
Design Without Information Architecture
A design developed without consulting the information architecture can be visually strong and even well-optimized for user experience — and still fail. The problem isn't the design itself. It's that beautiful interfaces make promises the back end may not be able to keep. If the design doesn't align with the delivery IA, content won't surface the way the experience implies it will. If it doesn't account for the management IA, the pipeline that feeds content into the system may not support what the interface expects. And if it doesn't engage with the content workflow at all, production teams are left trying to reverse-engineer what the design assumed. Many of us have been in a content experience — an LMS, a portal, a wiki — that looked expensive and intentional but made it impossible to find what we needed. That's what design without IA produces: a confident exterior and a broken interior.
Story: Portal Design for HR and Sales
The requirements for this part of the project were straightforward: control access to HR content through permissions, make deliverables easy to find, and surface new deliverable types that didn't previously exist in the portal. The design response was equally clear — add new panes to the portal to display HR and Sales content, and organize those panes to support actual use cases rather than just categories. The goal was to give HR and Sales teams a place to go where their content was already organized for them, rather than asking them to search through a system built for a different audience. On paper, this was a reasonable and workable plan. In practice, the portal had constraints no one had fully accounted for — constraints that only became visible when design and architecture tried to connect.
Reality Check: What the Delivery Platform Couldn't Do
When we tried to implement the portal design, the platform revealed its limits. It didn't use metadata values to aggregate and display content — which meant the organizational logic built into the design couldn't actually work the way we'd planned. The portal didn't support filtering on the metadata facets we needed. It wasn't extensible enough to accommodate the new deliverable types we were adding. And it didn't authenticate users based on permissions — so the access controls that were central to the HR use case weren't technically supported. None of these were surprises that better design would have prevented. They were platform constraints that only surface when someone asks the question: does the delivery environment actually support what this design requires? That question has to happen before the design is finished, not after.
The Ideal: Collaboration to Remediate Platform Gaps
The path forward in a situation like this isn't to discard the design work or start over on the architecture. It's to bring the content strategist and the delivery information architect together to figure out what remediation is actually possible. In this case, that meant collaborating with the portal delivery IA team to design a solution that worked within real platform constraints — not the idealized ones we'd assumed. This kind of remediation takes time and goodwill that wouldn't have been needed if the collaboration had started earlier. The lesson isn't that design is wrong or that the portal team failed. It's that the conversation between design intent and platform capability has to happen at the beginning of the process, not as a late-stage correction.
Information Architecture Without Design
The mirror problem is equally common. An information architecture developed without engaging delivery teams or design may be technically sound — well-structured for content creation, aligned with reuse goals, metadata-rich — and still fail to connect to the platforms it's supposed to feed. IA developed for individual deliverables may not account for how a delivery platform actually receives and displays content. And if the content workflow hasn't been mapped alongside the architecture, the pipeline from authoring to publication to the end user experience may have gaps no one planned for. The IA can be exactly right for what it was designed to do and completely unable to function in the environment where it has to live. Structured content is not self-delivering. It requires a delivery context — and that context has its own requirements.
Story: Management IA for HR and Sales Content
On the management IA side of the same project, the requirements were to structure content for reuse, extend the existing DITA implementation to handle new content types, and render subsets of content to different deliverable outputs. The goal was to support omnichannel publishing, localization, and efficient content reuse for HR and Sales teams — without duplicating content or abandoning the existing structured authoring foundation. The architectural approach drew on out-of-the-box DITA topic types and elements, designed for flexibility and extensibility, and defined output patterns specific to each deliverable type. This was solid IA work. What it didn't fully account for was how the delivery side — the portal — would need to receive and display that content. That gap, again, was the problem.
Reality Check: What the Architecture Missed
When the management IA met the delivery environment, the gaps became visible. On the design side, there were no user journey requirements that defined how deliverables should be accessed — so the IA had no guidance on what the end-user experience actually needed to support. On the delivery IA side, there were no platform-specific display requirements for the deliverable outputs, and — again — the portal couldn't extend itself to handle the new deliverable types. This is what it looks like when both sides do good work independently and still end up with a broken experience. The content is correctly structured. The design is coherent. But because they were developed in separate tracks, neither one accounts for what the other needs. The result is remediation — more work, more time, and a harder conversation than anyone wanted to have.
The Ideal: Design IA in Tandem
The fix isn't sequential — design first, then IA, or IA first, then design. It's concurrent. The management IA needs to be developed alongside the delivery platform IA, with active collaboration between both tracks from the beginning. And the content strategist needs to be in that conversation, making sure that platform permissions are understood, that delivery requirements are defined, and that the pipeline connecting content creation to the end-user experience is actually planned. When these conversations happen in parallel rather than in series, the gaps that show up as late-stage crises become early-stage design decisions — much cheaper and much less disruptive to address.
Design and Information Architecture in Collaboration
When design and IA work together from the start, several things have to be true. Requirements must be clearly defined — not just at a high level, but with enough specificity to identify where design intent and platform capability might diverge. User journeys need to be mapped for each actual user, not as a general exercise but as a foundation for both the IA and the delivery design. Collaboration with delivery platform teams has to happen during IA development, not after it. The design itself must be grounded in realistic platform capabilities — not what a platform should be able to do, but what it actually can do in its current state. And the change process — the workflow, the approvals, the handoffs — needs to be understood before the architecture is finalized, because content that can't get through the pipeline is content that won't reach anyone.
Story: Optimized HR Process Support
The most complex story from this project involves an interactive HR process experience — a portal feature where HR staff could log in, indicate what they were doing (onboarding a new employee, for example), and have the relevant content, forms, and templates surfaced to them automatically rather than requiring them to search. The requirements included access to templates, the ability to train an AI model on HR process content, and a new way to display process deliverables in the portal. The design called for an interactive process experience, with AI providing users with the appropriate templates based on where they were in the workflow. This is the kind of feature that only works if every layer — the content structure, the metadata, the delivery platform, the AI integration — is planned together. None of it can be designed in isolation.
How Collaborative Process Design Works in Practice
Building this kind of interactive process experience requires a sequence of steps that cuts across every role involved in content creation and delivery. First, the HR processes themselves have to be mapped — not assumed. What does the existing process documentation actually say? Is it current? Does it reflect how work actually happens, or how it was supposed to happen before the last portal made it impossible? Interaction points have to be defined: where does an HR staff member need to hand off to payroll? Where do forms need to appear? Where does a manager need to be notified? Then UI storyboards can be developed, supporting content identified, metadata values assigned, and the AI model trained on the content that results. Content structures are developed last — simple, reusable, and powered by the metadata that connects everything. The process diagram isn't a deliverable; it's the working instrument that makes everything else possible.
Why It Works
The collaborative model Roland and I use on this project works for reasons that are easier to describe than to replicate. Different perspectives — mine from the management IA side, his from the content strategy and delivery side — provide coverage that neither of us would have alone. Knowledge sharing between disciplines supports co-development: when I understand what the portal needs and he understands what the content structure requires, we find problems before they become crises. Issues get resolved quickly because we're talking frequently, not just regularly — and we document what we decide so that knowledge doesn't get lost in the next meeting. Update cycles are short because we test ideas and fail fast rather than waiting for a full implementation to surface problems. And the collaboration itself is open and based on trust, which means challenges surface organically instead of being discovered at the worst possible moment.
Roadblocks and Challenges
The list of things that get in the way of this kind of collaboration is long. Lack of shared accountability turns every discovered gap into a game of hot potato — nobody's group owns it, so nobody fixes it. Politics, competing interests, and organizational kingdom-building work against the unified approach that cross-functional content work requires. Egos and trust issues make it hard to leave room for other people's contributions even when those contributions are exactly what's needed. Resources and commitments pull people out of collaborative work in favor of their primary responsibilities. Time zones, especially on global projects, shrink the window for real-time collaboration to something almost unworkable. Working styles and perspectives mean that what feels like productive co-creation to one person feels like chaos to another. And in many organizations, there simply is no corresponding role — no one on the other side of the conversation with the authority and knowledge to be a real partner. None of these are reasons to stop trying. They're reasons to go in with your eyes open.
Strategies That Make Collaboration Stick
The strategies that actually work are less about process and more about how people work together. Co-working sessions — not status meetings, not project check-ins, but protected time to work alongside each other — are the single most valuable practice Roland and I have. Full access to each other's artifacts means we're not operating from summaries or secondhand information. Shared accountability, structured through something like a RACI matrix, means that when we find a problem, we already know whose job it is to address each part of it. A clear decision maker prevents the situations where good ideas stall because no one has authority to move them forward. Leading with questions rather than positions creates space for other people's contributions — especially from the people who actually do the work day to day, not just the ones who manage it. Preparing focused information before stakeholder meetings — no more than five questions, sent at least 24 hours in advance — means that the people who need to contribute can come prepared to do so. And setting clear expectations for participation keeps everyone at the table, even when the work gets complicate
If the challenges described here feel familiar — design and architecture developed in separate tracks, content that doesn't perform the way the experience implies it should, collaboration that stalls before it starts — I'd be glad to talk through what that looks like in your organization. Book a discovery call with me today.
