What Is Architecture-First Legal Content Development?
When someone assigns a legal content page, it can be tempting to start writing almost immediately. You have the topic. You know roughly what needs to be covered. Maybe you have a brief to work from. So you open a document and start drafting.
We worked that way for years. Eventually, we started noticing how much of the finished page depended on decisions we were making before we wrote it. The more attention we gave those decisions, the less we had to figure out while drafting. That realization became the basis for architecture-first legal content development.
The idea is simple: writing the page should not be the first time you decide what you are building. And once you look at legal content that way, the usual jump from assignment to draft starts to look a little different.
What Most Legal Content Development Looks Like
Most legal content starts with a brief. You get the assignment, see what you’ve been asked to cover, and start writing.
We worked that way for years.
The brief wasn’t the problem. It gave us what we needed to begin. But once we started writing, we’d often find ourselves stopping to make decisions about the page that hadn’t been made yet.
Maybe we knew the topic, but we hadn’t decided how the page should move from one idea to the next. So we figured it out while we were drafting.
For a long time, that didn’t seem unusual. Writing a page naturally involves making decisions as you go. But after enough legal content projects, we started noticing a difference between decisions about the writing and decisions about the page itself.
Once we saw the difference, it became easier to separate the two. If we were stopping in the middle of a draft to decide how the page should work, we could make those decisions before we started writing instead.
This is our thinking behind architecture-first legal content development.
What Is Architecture-First Legal Content Development?
Architecture-first legal content development means deciding how a page needs to work before you start writing it.
The topic alone can’t tell you that. Two pages can cover the same area of law and still need to do very different jobs. Architecture is where you make that distinction. Instead of starting with everything you could say about a topic, you start with what this particular page needs to accomplish.
This is also where architecture differs from a brief. A brief gives the writer the assignment. Architecture takes that assignment and looks more closely at the page the writer is being asked to create.
An outline is different too. You can put together a perfectly reasonable set of headings and still have sections that overlap or spend too much time on something the reader didn’t need from this page. Architecture gives you a reason for the choices behind the outline before you settle on the headings themselves.
Writing has its own job after that. Once you know what the page needs to accomplish, you can focus on explaining the subject in a way that makes sense to the person reading it.
Architecture-first simply moves those page decisions ahead of the draft. The next question is what, exactly, you can decide that early.
What Does Architecture Consider Before Drafting Begins?
So what are you actually deciding before you write?
A lot of it comes down to questions you might otherwise run into halfway through the draft. Answering them ahead of time can change what eventually makes it onto the page. Architecture considers questions like these:
What is this page supposed to do? A workers’ compensation page written for someone who was just hurt at work has a different job from a page explaining one narrow question about an existing claim. Covering the same area of law doesn’t make them interchangeable.
Why did the reader come looking for this page? Someone searching a specific legal question usually wants to get to the answer quickly. The page shouldn’t make them work through a long introduction before getting there.
What has the website already covered? A new page doesn’t need to repeat an explanation another page already handles well. Sometimes its job is to pick up where that page leaves off.
What does each section need to contribute? Two sections can sound different on an outline and still end up doing the same job once they’re written. Catching that before drafting gives each section something different to add.
Where could this page repeat something unnecessarily? Legal topics naturally cross over from one page to another. You can decide what belongs here without rewriting information the website already gives the reader somewhere else.
What will the reader still need to know before they leave? A page can cover its assigned topic and still leave the reader with an obvious unanswered question. It’s better to notice that before the page is finished.
None of these questions tells you how to write the page. They help settle what the writing will need to do. When those decisions are made before drafting, you can see the result in the finished page.
Why Architecture Changes the Finished Page
Think about the last legal page you read all the way through. You probably weren’t thinking about how it had been planned. You were paying attention to whether you could find what you came for without having to work too hard to get there. Architecture affects that experience before the writing begins.
You can tell why the page exists. A page about what happens after a denied disability claim shouldn’t spend most of its time giving a general introduction to disability benefits. The reader came with a more specific problem, and the page should stay with it.
The sections build on each other. The reader shouldn’t finish one section only to find the next one backing up and explaining the same idea again. Each section should give them a reason to keep reading.
Information shows up where you expect it. If the page raises a question, the reader shouldn’t have to hunt several sections later for the answer. Planning helps keep related information together instead of scattering it throughout the draft.
The page doesn’t feel like it could live anywhere. A legal page should make sense on the website it was written for. It should fit with what the firm has already published without sounding like another version of a page that already exists.
None of this guarantees what happens after someone visits the page. Architecture simply means the writer isn’t waiting until the draft to decide how the page should work. After thousands of legal content projects, we knew we didn’t want to leave those decisions to the drafting process anymore. Eventually, we developed a formal way to make them before the writing began.
Why This Philosophy Became a Methodology
We didn’t set out to create a methodology. For a long time, architecture was simply part of how we prepared to write.
But the volume of the work changed what we could see. After planning more than 20,000 legal pages, we had worked across enough practice areas and websites to recognize when the same issues kept coming back. We also knew we couldn’t rely on memory every time we planned a new page.
We needed to be consistent about the questions we answered before drafting and the decisions we made from those answers.
The philosophy came first. The methodology came later.
The Acadia Method™ grew from the way we had learned to approach legal content before we wrote it. Formalizing that work gave us a consistent way to use what we had learned across future projects without treating every new assignment like we were starting from scratch.
Architecture-first legal content development is still the philosophy behind it. The methodology is how we put that philosophy into practice.
See What Architecture-First Legal Content Development Looks Like in Practice
The Acadia Method™ grew from this philosophy and gives us a consistent way to put it into practice across the legal content we write. You’ll find more throughout the Library about the decisions that happen before drafting and why they matter once a page is finished. And if you’re looking for legal content developed with that level of planning behind it, we’d be happy to talk about what you’re working on.
