Designing a Structured Communication System for SAIL ISP: A Case Study in Public Sector Content Architecture

“A structured communication system in a public sector organisation is a designed framework that organises operational information, standardises how it is presented, and creates clear navigation pathways for staff, visitors, and stakeholders. It replaces scattered, informal information with consistent, accessible, and usable content that supports daily operations and long-term communication continuity.”

There is a specific kind of professional challenge that no course prepares you for.

It is the moment you are handed a problem that is genuinely large — not large in the way a difficult essay question is large, but large in the way a functioning industrial organisation is large. Hundreds of departments. Thousands of employees. Decades of operational history compressed into systems that have grown organically rather than by design. Information that exists but is not structured. Navigation that works for people who have been there for twenty years and fails completely for everyone else.

That was the challenge at SAIL ISP — the IISCO Steel Plant of the Steel Authority of India, located in Burnpur, Asansol, West Bengal.

And that was the project I was brought in to work on.

This case study is the full account of what I found, what I designed, why the decisions I made were the right ones for the context, and what the work produced. You can view the full project documentation on my public sector project, which includes additional supporting materials alongside this write-up.

Who This Case Study Is For

This case study is for three types of readers.

The first is anyone evaluating communication and content strategy work in large-scale or complex organisational environments — whether in public sector, manufacturing, infrastructure, or enterprise settings. The work documented here goes well beyond content writing. It demonstrates systems thinking, operational understanding, and the ability to translate complex information into structured, usable outputs.

The second is professionals considering how structured communication design applies to their own organisation — particularly those in environments where information is abundant but poorly organised, where navigation is a genuine operational problem, and where the gap between what people need to know and what they can actually access is costing the organisation time and efficiency.

The third is anyone interested in understanding what serious public sector content work looks like in practice — not the theory of government communication, but the reality of designing information systems for an organisation the scale of SAIL ISP.

The Organisation: SAIL ISP in Context

Before the design decisions make sense, the scale of the organisation needs to be clear.

SAIL — Steel Authority of India Limited — is a Maharatna Central Public Sector Enterprise and the largest government-owned steel producer in India, with an annual production of 18.29 million metric tonnes and 50,001 employees. It operates five integrated steel plants and three special steel plants across the country.

The IISCO Steel Plant at Burnpur is one of those five integrated plants. The plant began operating in 1918 under the Indian Iron & Steel Company and was acquired by SAIL in 2006. It is not a new facility finding its feet — it is a century-old industrial operation with deep institutional history, layers of accumulated process, and an infrastructure footprint that reflects a hundred years of growth.

The plant has a capacity to produce 2.5 million tonnes of crude steel per annum, built on a land area of 953 acres — making it one of its kind in the world. It underwent a significant modernisation and expansion programme costing approximately Rs 16,408 crore, completed in 2015, which introduced entirely new production facilities alongside existing infrastructure that predated the modernisation by decades.

Key facilities include the Blast Furnace "Kalyani" with a useful volume of 4,161 cubic metres — one of the largest blast furnaces in the country — alongside three 150-tonne Basic Oxygen Furnaces, two Hot Metal Desulphurisation Stations, and two Ladle Furnaces for special steel production.

To put the communication challenge in practical terms: this is an organisation spread across nearly a thousand acres, with departments ranging from coke oven operations to Wire Rod Mills to hospital management to schools to sports facilities, all operating within a single integrated plant environment. ISP has a well-developed IT infrastructure with an internal portal to interconnect departments, and dedicated systems for project finance, payroll, quarter management, and hospital management.

The systems infrastructure existed. What it lacked was the communication layer that made those systems, and the physical environment they supported, genuinely navigable for the people working within them.

The Problem: What Communication Looks Like When It Grows Without Design

Large organisations do not develop communication problems deliberately. They develop them gradually — through years of adding systems on top of systems, departments that manage their own information independently, and physical environments that grow faster than the wayfinding designed to support them.

At SAIL ISP, the communication challenge had several distinct layers. Understanding each layer separately was essential to designing a system that addressed the actual problem rather than the surface version of it.

Layer One: Information Scatter

Operational information existed across the plant — in departmental documents, in physical notices, in informal knowledge held by experienced staff, in management systems that were not visible to everyone who needed them. The problem was not a lack of information. The problem was that the information had no unified structure. Different departments communicated differently. Different types of content had different formats, different storage systems, and different levels of accessibility.

For someone new to the plant — a new employee, a visitor, an external contractor — the experience of finding information was essentially dependent on who you happened to ask. That is not a communication system. It is a knowledge network that only works for people already inside it.

Layer Two: Navigation Complexity

953 acres is not a space that communicates itself.

The plant layout at ISP includes a significant range of functional zones — production facilities, administrative areas, safety zones, entry and exit gates, welfare facilities, residential township areas, educational institutions, and sports complexes. Communication at the plant includes hoardings, banners, and boards at strategic locations for display of information and propagation of ISP's achievements in and around Burnpur steel town.

But static hoardings in an environment this large do not constitute a navigation system. They communicate what is important to leadership. They do not necessarily communicate what a new employee or visitor needs to find, understand, or access on a given day in a given part of the plant.

The navigation problem was both physical and informational. People needed to know where things were and how things worked, and those two types of knowledge required different communication solutions.

Layer Three: Structural Inconsistency

Public sector organisations of this scale and age tend to accumulate communication materials over time rather than designing them coherently. Different departments produce their own documentation, their own visual materials, their own versions of process descriptions. The result is a collection of content that is technically available but impossible to use as a coherent system.

A new employee reading materials from three different departments might encounter three different formats, three different levels of detail, three different assumptions about what the reader already knows, and three different tones. None of this is wrong on its own terms. But it does not constitute structured communication. It constitutes organised chaos.

This was the foundational design problem: not to create more content, but to create a system within which all content — existing and new — could be organised, standardised, and made genuinely usable.

Layer Four: The Gap Between Digital and Physical

ISP has a well-developed IT infrastructure with an internal portal to interconnect departments. It has dedicated systems for project finance, payroll, quarter management, and hospital management. It was the first among SAIL's sister units to have its ERP system hosted on the HANA Enterprise Cloud — a significant technological achievement for a public sector manufacturing organisation of this scale.

But digital infrastructure and communication infrastructure are not the same thing.

A staff member who knows how to access the ERP system can find financial and operational data. They cannot necessarily find out where the new Wire Rod Mill is relative to the Blast Furnace, which entry gate accepts external visitor vehicles, or which department handles the type of query they are trying to resolve. The digital infrastructure existed for operational management. The communication infrastructure needed to translate the physical and organisational reality of the plant into something navigable for every person working within it.

This gap — between what the digital systems held and what a person without specialist access or institutional familiarity needed to know — was the fourth and in some ways the most important layer of the communication problem. Closing it required both physical communication design (mapping and wayfinding) and informational communication design (structuring the knowledge that the digital systems held in a way that was accessible without requiring system access).

Layer Five: The Institutional Knowledge Problem

In any organisation that has operated for over a century, a significant proportion of operational knowledge lives in people rather than in documents.

SAIL ISP has employees who have worked within the plant for decades. They know where things are, how they work, who to call, and why certain decisions were made in certain ways. That knowledge is extraordinarily valuable. It is also extraordinarily fragile — it exists only as long as the people who hold it remain in the organisation, and it is shared only through direct conversation rather than through any systematic channel.

Communication design in this context has a preservation function as well as a navigation function. Part of what structured communication materials do is capture institutional knowledge in a format that does not depend on the continued presence of any individual person. Case studies, process descriptions, operational documentation — all of these are mechanisms for converting individual knowledge into organisational knowledge. They transform what was fragile and person-dependent into what is durable and system-available.

This preservation function shaped the content development work significantly. It was not enough to produce materials that addressed current navigational and informational needs. The materials needed to capture enough of the institutional knowledge that surrounded each topic to remain useful as the organisation continued to evolve.

The Strategy: Designing Before Creating

The first decision I made was not to create anything.

The instinct in content and communication work is often to start producing — to begin writing, designing, or building immediately. In a context this complex, that instinct is wrong. Starting with production means you are solving the wrong problem with every piece of content you create, because you have not yet understood the full shape of the problem.

The first phase of the project was entirely diagnostic. Before any structured materials were designed, the existing communication environment needed to be mapped. Where did information live? Who accessed it? What were the failure points — the moments where someone needed to find something and could not? What did staff and visitors actually need to know that they were not currently being told effectively?

This diagnostic phase produced a communication audit that structured everything that followed. It identified the specific gaps — not in general terms but in operational ones. The entry gate system and its communication with different visitor categories. The departmental zone layout and the absence of a consistent reference resource. The inconsistency of operational documentation across functions. The gap between what internal systems held and what people could access without already knowing the system.

The audit also identified something that is easy to overlook in large organisations: the difference between what leadership believes communication to be and what operational staff experience communication as. Leadership in a plant like ISP tends to think about communication in terms of announcements, achievements, and official channels. Operational staff experience communication primarily as information access — can I find what I need, when I need it, without wasting time? These are different problems, and any communication system that only addresses one of them fails the organisation as a whole.

From the audit came the design brief: a communication and information access system that would address each identified gap through a structured, consistent, and practically usable set of materials and frameworks. The brief was precise about what success would look like — not "improved communication" as a vague outcome, but specific operational capabilities that would be enhanced by the system.

The Constraint of Working at Scale

One of the most significant strategic challenges of this project was working at the scale of SAIL ISP while operating as an individual contributor within a limited timeframe.

Large organisations present a specific design challenge: the problem is vast, the resources available to address it are real but finite, and the temptation is to try to design everything at once. That temptation produces systems that are comprehensive in scope but thin in execution — systems that identify all of the problems without solving any of them at the depth needed for genuine operational impact.

My response to this challenge was to prioritise ruthlessly. Rather than designing a system that addressed every communication gap at a surface level, I chose to address the most critical gaps at a depth that would produce real usable outputs. The mapping work addressed the navigation problem comprehensively. The information architecture addressed the access problem systematically. The content development addressed the consistency problem in the most high-impact areas.

Not everything was addressed. But what was addressed was addressed properly — designed for real use, tested against real operational needs, and built to survive beyond the project itself.

This prioritisation principle is, I believe, central to the continued operational use of the materials. Materials that are built properly for a real problem last. Materials that are built partially for a comprehensive problem list do not.

What I Designed: The Four-Part Communication System

Part One: Operational Information Architecture

The first structural layer of the system was the organisation of existing operational information into a coherent, navigable format.

This is more complex than it sounds. Public sector organisations do not simply hand over their operational documentation for restructuring. The work requires understanding the sensitivity of different categories of information, the audience for each type, the format in which it is most usable, and the relationship between different pieces of information that may exist in isolation but need to connect in the communication system.

I organised operational information into a tiered structure. The first tier covered essential information — the things that any staff member, visitor, or contractor needed to understand simply to function safely and effectively within the plant environment. Zone layouts. Entry and exit procedures. Safety area identifications. Department contact structures. Emergency reference information.

The second tier covered operational detail — department-specific information that was relevant to particular functions but needed to be consistent in format and accessible to anyone who needed it, not locked within departmental silos.

The third tier covered reference material — longer-form documentation, historical context, process descriptions, and institutional records that provided depth for those who needed it without creating noise for those who did not.

Each tier had its own format standards, its own level of detail, and its own distribution logic. The architecture was not about creating more content — it was about giving existing and future content a structure that made it usable as a system rather than as a collection of isolated materials.

Part Two: Visual Mapping and Spatial Communication

The most immediately visible element of the communication system was the plant mapping work.

953 acres of integrated industrial infrastructure is an environment that requires visual communication tools to navigate. Written descriptions of plant layouts are functional for people who already know the space. For everyone else — new employees, visitors, contractors, external partners — a written description of where something is located is essentially useless. People navigate by reference to what they can see, and what they can see needs to be mapped.

I designed plant maps covering the key operational areas of ISP. Each map was built around a specific navigational purpose rather than being a generic site overview. The entry-level maps showed entry and exit gates, visitor reception points, general zone orientation, and key reference landmarks. The operational maps showed departmental locations, inter-departmental pathways, and key functional areas within production zones. The safety-focused maps identified safety zones, emergency exit routes, first aid locations, and emergency assembly points.

The plant environment at ISP spans a remarkable diversity of functional zones. Production facilities — including the Blast Furnace complex, Basic Oxygen Furnace shops, continuous casting units, Wire Rod Mill, and Bar Mill — occupy large areas of the site and require different navigation logic for different categories of user. Administrative and welfare zones — including the main administrative building, hospital facilities, staff welfare centres, and educational institutions — are separate again. The township areas surrounding the plant, which include the Burnpur Stadium, sports complexes, and residential facilities for plant employees, extend beyond the production boundary in ways that require their own navigational framework.

Communicating this complexity visually required decisions about what to include and what to abstract. A map that shows everything is a map that shows nothing usefully — it becomes a technical diagram rather than a navigation tool. The design principle I applied was audience specificity: each map showed exactly what its intended user needed to navigate, and no more.

The maps were designed to be practically usable — meaning they were legible at the scale they would be used, they included consistent visual conventions throughout so that someone familiar with one map could read any other map in the system, and they prioritised navigational utility over aesthetic comprehensiveness.

The specific navigation points built into the mapping system included all entry and exit gates with their access categories, key department locations with identification consistent across the other communication materials, safety zones with clear visual distinction from operational areas, and welfare and administrative facilities relevant to staff and visitors.

The mapping system created what the plant previously lacked: a consistent, visual spatial reference that could be used as a standalone resource or integrated into induction, training, and visitor management processes. For a plant that uses hoardings, banners, and boards at strategic locations for information dissemination — and that has used media including WhatsApp and Twitter for broader communication — having a consistent visual mapping language that worked across different formats and scales was a significant functional improvement.

Part Three: Content Development and Structured Communication Materials

The third element of the system was the production of structured content materials that could support ongoing internal communication.

The content I developed fell into three primary categories.

The first was case study materials — structured accounts of operational decisions, projects, and initiatives that documented institutional knowledge in a format that could be used for internal training, external communication, and organisational record. Public sector organisations generate enormous amounts of knowledge through their operations. Very little of that knowledge gets captured in a format that makes it accessible beyond the people directly involved. Structured case studies translate operational knowledge into communication assets.

The second was operational communication content — standardised templates and frameworks for departmental communication that could be used consistently across different parts of the plant. Rather than every department approaching internal communication in its own way, the templates provided a consistent structural starting point while allowing for departmental specificity in the content itself.

The third was reference documentation — structured descriptions of plant systems, facilities, and operational processes, written for accessibility rather than technical depth. The goal of this documentation was not to replace technical manuals but to create a communication bridge — materials that could give any reader a functional understanding of what a system does and why it matters, without requiring the technical expertise to read the underlying engineering documentation.

All content was developed in alignment with public sector communication standards — which have specific requirements around tone, accessibility, accuracy, and institutional voice that differ significantly from commercial content. The constraint of working within public sector standards was not a limitation on quality. It was a design parameter that shaped every decision about how information was presented.

Part Four: System Integration and Practical Application

The fourth and most critical element of the design work was ensuring that the three components above functioned as an integrated system rather than as three separate deliverables.

A communication system is not a collection of outputs. It is a designed relationship between outputs — a structure that determines how different pieces of information relate to each other, how they are accessed in sequence, and how they are maintained and updated over time.

The integration work involved establishing the relationships between the information architecture, the mapping system, and the content materials. The maps referenced the information architecture. The information architecture directed users to the appropriate content materials. The content materials linked back to the visual navigation system. Each element of the system made the others more useful rather than existing independently.

The system was also designed for practical application from the outset — meaning it was built to be used by the people within the organisation without requiring specialist knowledge to maintain. Public sector organisations cannot rely on external communication expertise for day-to-day operational communication. The system needed to be clear enough that staff could use it, update it, and build on it without needing to return to its designer for every change.

This practical application principle is, I believe, the primary reason the work is still in operational use within the organisation. Materials that are designed to be used by real people in real operational contexts, rather than designed to be impressive, tend to survive. They get used because they are useful. They get maintained because they are manageable.

The Framework: The STRUCTURE Communication Design Model

Across the four parts of the system described above, there is an underlying design framework that I applied consistently. I call it the STRUCTURE model, and it represents the organising logic behind every decision made in the project.

S — Scope Before Creation. Define the full extent of the communication problem before producing a single output. Diagnostic work precedes design work. This step prevents the most common failure mode in communication projects: solving the visible problem while leaving the underlying system problem untouched.

T — Tiering Information. Not all information is equally urgent, equally relevant to all audiences, or equally accessible in format. Tier information by urgency, audience, and depth before deciding how to present it. The wrong tier applied to the right information produces the wrong outcome.

R — Reference Architecture. Create a consistent structural logic that connects all communication materials into a navigable system. Individual pieces of content are not the goal. The goal is a reference architecture within which any piece of content can be found, understood, and used by the right person at the right moment.

U — Usability Over Comprehensiveness. A communication system that contains everything but is difficult to use is not a better system than one that contains the essentials in a format that actually works. Prioritise usability at every decision point. If a choice must be made between comprehensiveness and usability, choose usability.

C — Consistency of Convention. Every format decision should be consistent across the system. Visual conventions, structural conventions, language conventions. Consistency is what transforms a collection of materials into a system. Without it, each piece of content requires the user to learn a new set of rules before they can extract value from it.

T — Translation of Complexity. The purpose of structured communication in complex operational environments is to translate complexity into clarity without losing accuracy. This is a different task from simplification. Simplification can lose important nuance. Translation preserves the underlying accuracy while making it accessible to an audience that does not have specialist knowledge.

U — Usable by Non-Specialists. Any system that requires its original designer to maintain it is not a sustainable system. Design for handover from the start. The people who will use and maintain the communication system are not communication designers — they are operational staff with other primary responsibilities. The system must be simple enough to use without training and clear enough to maintain without expert knowledge.

R — Reviewable Over Time. Build review cycles into the system design from the start. Operational environments change. Departments move. Facilities are added or modified. Processes evolve. A communication system with no review mechanism will become inaccurate over time, which is worse than having no system at all — because an inaccurate system actively misleads the people who rely on it.

E — Evidence of Impact. Communication work is difficult to measure in traditional output terms, but impact can be evidenced through adoption, continued use, and operational feedback. The most honest measure of a communication system's success is whether the people it was designed for continue to use it when they have the choice not to.

The continued operational use of the materials developed for SAIL ISP is the evidence of impact for this project. Materials that are not useful do not persist. Materials that solve a real problem do.

The Outcomes: What This Work Produced

Immediate Operational Impact

The most immediate outcome of the communication system was the availability of structured navigational and informational resources that had not previously existed in this form within the plant.

Staff and visitors who previously navigated by informal knowledge or by finding someone who already knew the answer had access to a consistent, visual reference system. New employees going through induction had structured materials that oriented them to the plant environment and its operational logic without relying entirely on knowledge transfer from individual colleagues. Departments had consistent templates and frameworks for their own communication activities rather than starting from scratch with each new communication requirement.

These are not dramatic outcomes in the sense of being immediately quantifiable. Communication infrastructure rarely produces dramatic, immediate numbers. What it produces is a reduction in friction — the small, accumulated costs of people spending time finding information they should be able to access directly, of mistakes made because navigational information was unclear, of institutional knowledge lost because it was never captured in a communicable format.

Friction reduction at scale, in an organisation the size of SAIL ISP, compounds into meaningful operational efficiency over time.

Long-Term Usability and Continued Operational Use

The most significant outcome of this project is the one I did not design for directly but that has become the clearest evidence of its success: the materials are still in operational use within the organisation.

This matters more than it might initially appear.

Most communication and content work produced within organisations — particularly work produced by external contributors or interns — has a relatively short functional life. It gets used for its immediate purpose and then superseded by newer materials, or it sits in a shared drive without anyone returning to it, or it becomes outdated quickly and is therefore set aside.

The fact that the work produced for SAIL ISP continues to be used operationally tells me several things. It tells me the design was right — that the materials were built for the actual problem, not the theoretical problem. It tells me the format was right — that the outputs were structured in a way that remained usable without requiring update. And it tells me the integration was right — that the materials function as a system that the organisation has been able to maintain and continue to apply without needing external support.

That continued use is the measurement I am most proud of. It is the measurement that matters most in communication design.

Demonstrable Strategic Capability

Beyond the immediate operational outcomes, this project demonstrates a specific set of strategic capabilities that are relevant across any context involving complex information environments.

The ability to diagnose a communication problem in a large-scale organisation — to understand it at the structural level rather than the surface level — is not a common skill. Most communication work begins with a brief that already defines the solution. This project began with a problem that had not yet been fully articulated, let alone solved.

The ability to design a multi-component system where each element serves the whole — where the mapping system and the information architecture and the content materials work together rather than sitting beside each other — reflects a systems thinking capability that goes beyond content production.

And the ability to deliver work that is built for the people who will actually use it, in an environment as specific and demanding as a large-scale public sector steel plant, demonstrates the kind of contextual intelligence that only comes from taking a real operational problem seriously.

What This Demonstrates Strategically

Working Within Large Public Sector Organisations

Public sector environments have specific constraints that commercial environments do not. Communication must align with institutional tone and standards. Information has sensitivity categories that determine how and where it can be used. Approval processes are slower and more layered. The definition of success is different — not revenue or conversion, but usability, accessibility, and compliance.

Working effectively within these constraints requires both communication expertise and institutional intelligence — the ability to understand what an organisation like SAIL ISP is optimising for and to design within that optimisation rather than against it.

This project demonstrates that I can do that. Not in theory. In practice, in one of India's largest and most complex public sector organisations.

Designing for Complexity

The communication challenge at SAIL ISP was genuinely complex. Not complex in a ways that could be resolved with a clever approach to simple materials, but complex in the structural sense — where the problem has multiple interconnected dimensions that each require a different design response, and where getting one dimension right while getting another wrong produces a system that does not work.

The ability to hold that complexity in view throughout a project — to make design decisions that serve the whole system rather than optimising for individual outputs — is a capability that applies across organisational types, industries, and scales.

Creating Long-Term Value

Communication work is often treated as a short-term deliverable. Brief in. Work produced. Brief complete. The work I did at SAIL ISP is not operating on that cycle. It was designed from the beginning to create long-term value — materials that would continue to serve the organisation after the project formally closed.

That design for longevity is not an accident. It is a deliberate strategic choice that requires understanding not just what a client needs now but what they will need to do with what you create over time. Building for longevity requires building for handover, for adaptation, and for use by people who were not part of the original design process.

The sustained operational use of the SAIL ISP communication system is the evidence that this approach was the right one.

Key Learnings: What This Project Taught Me

Diagnosis is design. The most important design decisions in this project were made before a single output was produced. The communication audit — understanding the actual structure of the problem — determined every subsequent choice. In complex organisations, the temptation is to begin producing quickly. Resisting that temptation and investing in genuine diagnostic work is what separates communication design from communication production.

In practice, this means spending time in the organisation before committing to a design direction. It means talking to the people who use the communication environment daily — not just the people who commission communication work, but the staff, the visitors, the contractors, the people for whom the system either works or does not. Their experience of the current state is the most accurate map of the design problem. Everything else is an approximation.

Usability defines success, not quality. A beautifully designed map that people do not use is a failure. A plainly formatted information document that staff return to daily is a success. The measure of communication design is adoption and continued use, not aesthetic quality or comprehensiveness. Building for usability requires setting aside the instinct to impress and focusing on the question of whether the person who needs this can actually use it.

In a manufacturing environment like ISP, usability has specific requirements. Materials need to work in the conditions where they are used — not in ideal presentation conditions but in the actual environment. A map needs to be readable in varying light conditions, at the distance at which it will be viewed, by someone who may be wearing protective equipment. An information document needs to be scannable in the moment when someone needs it — not readable cover to cover, but navigable quickly when someone is looking for a specific piece of information. These practical usability requirements shape every design decision.

Systems thinking is different from content thinking. Thinking about a single piece of content asks: does this communicate clearly? Thinking about a communication system asks: does this connect to the other elements of the system in a way that makes the whole more useful? The shift from content thinking to systems thinking is the shift from producing outputs to designing infrastructure.

The practical implication of this shift is that the design process is non-linear. When you are designing a system, you are constantly moving between the detail of individual components and the logic of the whole system. A decision made at the component level has implications for the system level, and a system-level constraint shapes what is possible at the component level. Holding both levels simultaneously, throughout the entire project, is the core cognitive challenge of communication system design.

Public sector contexts reward precision. In commercial communication, a degree of approximation is often acceptable — close enough is good enough if it achieves the business outcome. In public sector communication, particularly in a safety-sensitive operational environment, precision is not optional. Information that is approximately right can be actively harmful. The discipline of precision that public sector work requires is transferable to any context where accuracy matters.

This precision requirement also applies to language. Public sector communication has standards around terminology, around the use of official classifications, and around the framing of operational information that do not exist in the same way in commercial contexts. Working within these standards is not a constraint on communication quality — it is a quality requirement in itself.

Long-term value requires designing for the people who were not there. The people who will use the SAIL ISP communication system in five years were not part of the design process. Designing for them — for the staff member who joins after the project is long closed, for the visitor who has never encountered the system before — requires imagining the system from the outside rather than from the inside. That outside perspective is what makes communication design genuinely serve its intended audience.

Scale changes everything. Communication design at the scale of SAIL ISP is fundamentally different from communication design for a small team or a digital-native organisation. The physical dimensions alone — 953 acres, multiple distinct zones, thousands of daily users — create design requirements that simply do not exist at smaller scales. The number of stakeholders with different communication needs is vastly larger. The number of potential failure points in the system is correspondingly larger. And the consequences of those failure points — in an industrial environment where navigation and information access have direct safety implications — are more serious than in most contexts.

Working at this scale required a kind of thinking about communication that I had not fully developed before this project. It required thinking about edge cases — the visitor who arrives at an unfamiliar gate, the new employee in their first week, the contractor working in an area they have not previously accessed. Good communication design at scale has no edge cases. It works for everyone, including the people it was hardest to design for.

Summary

• SAIL ISP (IISCO Steel Plant) is one of India's largest integrated steel plants, operating across 953 acres in Burnpur, Asansol, with a production capacity of 2.5 million tonnes of crude steel annually

• The communication challenge at ISP had three structural layers: information scatter across departments, navigation complexity across a large physical environment, and inconsistency of format and standard across existing materials

• The system I designed had four integrated components: operational information architecture, visual plant mapping, structured content development, and practical system integration

• The STRUCTURE model — a named framework covering eight design principles — provides the organising logic behind every decision made in the project

• The continued operational use of the materials within SAIL ISP is the primary evidence of impact

• This project demonstrates the ability to diagnose communication problems in large-scale public sector organisations, design multi-component systems, and produce work that creates long-term operational value

What I Would Do Differently

No case study that is only about what went right is worth reading.

The one thing I would change if I were approaching this project again is the distribution of time between the diagnostic phase and the production phase. The diagnostic work I did was valuable and set the project up well — but in retrospect, I could have gone deeper. Spending more time in conversation with the staff who would actually use the communication system before designing it would have produced outputs even more precisely aligned with real operational needs.

The gap between what someone in a design or strategy role believes a user needs and what that user actually needs in practice is always wider than you expect. Closing that gap requires listening at a level that feels inefficient but pays off in adoption and sustained use. I closed it reasonably well on this project. With more time and more structured user research, I could have closed it further.

It is a learning that shapes every communication design engagement I undertake now.

Frequently Asked Questions

What is a structured communication system and why does a large organisation need one?

A structured communication system is a designed framework that organises information, standardises how it is presented, and creates consistent navigation pathways for all people who need to use it. Large organisations generate enormous amounts of information through their operations, but without a designed structure, that information becomes inaccessible — scattered across departments, held informally by individuals, or formatted inconsistently in ways that prevent reliable use. A structured system converts information from a resource that only some people can access to one that anyone who needs it can find and use effectively.

How does communication design work differ from content writing?

Content writing produces individual pieces of content — articles, documents, announcements, reports. Communication design produces the system within which content lives — the architecture that determines how different pieces of information relate to each other, how they are accessed, by whom, and in what sequence. A content writer asks: does this communicate clearly? A communication designer asks: does this system serve the people who need to use it? The two skills are related but distinct, and designing effective communication for large organisations requires both.

Why is continued operational use the most important measure of success for this kind of project?

Communication materials that are not used are failures regardless of their design quality. The measure that matters most is adoption — whether the people the system was designed for actually use it in practice. Continued use over time, without the involvement of the original designer, indicates that the system was built for real operational needs rather than for a brief, designed in a format that real users can maintain, and integrated into the organisation's actual workflows rather than sitting alongside them. For the SAIL ISP project, continued operational use is the clearest available evidence that the system design was right.

What makes public sector communication design different from commercial communication?

Public sector communication operates within institutional constraints that commercial communication does not face in the same way. Tone must align with organisational standards and government communication principles. Information has sensitivity categories that determine how it can be used and distributed. Approval processes are more layered and involve more stakeholders. The definition of success is different — not conversion or revenue, but usability, accessibility, and accuracy. In safety-sensitive operational environments like a steel plant, accuracy is not optional. These constraints require a different design discipline — one that prioritises precision, consistency, and institutional alignment over creativity or commercial impact.

What is the STRUCTURE communication design model and how can it be applied?

The STRUCTURE model is a framework for designing communication systems in complex organisational environments. Its eight principles — Scope before creation, Tiering information, Reference architecture, Usability over comprehensiveness, Consistency of convention, Translation of complexity, Usable by non-specialists, Reviewable over time, and Evidence of impact — provide an organising logic for every design decision from initial diagnosis through final delivery. The model can be applied to any communication design project in a large or complex organisational context, regardless of industry or sector.