One of the greatest lessons of my life happened in 4th grade. The assignment was simple, straightforward, and one that you wouldn’t think required much thought: Describe how to make a peanut butter and jelly sandwich.

“I got this,” my nine-year-old self probably thought before I set out to write this down. “I’ve been eating PB&J for YEARS at this point, so how hard could this be?”

As it turns out, there’s a whole lot of detail you need to include in preparing something as simple as PB&J. And all of my years of experience as a consumer of the product did little to prepare me for how to instruct others in how to best create it. This was made painfully and hilariously obvious to our class by our teacher, Ms. Perry. She proceeded to re-enact the instructions with a delivery that in hindsight was a combination of Lucille Ball in the candy factory, and Bob Newhart as the driving instructor.

The two moments that most stand out to me were when Ms. Perry simply stacked the jar of peanut butter on top of a slice of bread, put the jar of grape jelly on top of that, and topped the whole thing off with another slice of bread. The other was when she wasn’t instructed to use a knife and made a delightful mess smearing peanut butter and then jelly onto bread with her bare hand. Lesson learned.

I remembered this experience the other day when I sat down with one of our senior developers, Tim. We talked about the fundamental elements of a Drupal site, how they relate, and — most importantly — the order in which elements need to be determined.

We talked about nodes, content types and fields, and how having a thorough understanding of these and what they need to be are often the key component in ensuring a client’s web site is built on time, on budget, and is in line with the client’s expectations.

Drupal is a very powerful, flexible content management system, and nodes are the primary means for building out web pages. And just as rights are balanced out with responsibilities for creating an effective, functioning society, so too is the need to establish a bedrock foundation of nodes, content types and fields from which flexible renderings of data can be done easily and efficiently.

The front-facing nature of most of the traditional IA and design processes, however, can make this a challenge. Strategic goals are established that then get put into visual representations through wireframes and designs. This is not, inherently, a bad process. However, problems can occur when there is a lack of clarity around how content makes it from the CMS to the webpage, how it needs to change and how this might evolve over time. Also, this is often not the primary focus or expertise of most clients (nor should it be) and makes it easy to gloss over.

A simple way to guard against this is to take a “trust but verify” approach. You can trust that any information you need to display on a page can be done, so long as it exists and is in the proper structure for working through your content management system. That said, it’s helpful to verify the following:

• The content exists
• Everyone knows what it is and what it is trying to represent in real life (e.g., a publication, a product, a user profile, etc.)
• Everyone knows where it exists
• Everyone understands how it can be pulled in and any parsing of the data is verified up front
• Everyone is clear what might need to evolve over time with this data
• Everyone is clear on whether the content will be updated over time, who will be updating, and how they are expected to do so
• Everyone is clear about everywhere this information needs to live on both the site and the web as a whole

It’s helpful to think of this as something of a natural revolution on the web. In the earliest days, content and styling were intertwined on every individual web page (R.I.P. <blink>). Later, we witnessed the rise of cascading style sheets (CSS) that work best when data is kept separate from the “presentation layer.” We’re currently in an era where organizations need to think about a digital presence that extends well beyond their own web site(s).

In an age of responsive design websites that require choices to be made about what and how pages render on mobile devices, and with application programming interfaces (APIs) that can extend your organization’s public data well beyond your website, a fluency around how data is structured and flows needs to be at the core of any digital strategy.

This approach isn’t a “nice to have” option that companies can elect to ignore. Doing so is done at one’s own risk.

About the author:

Chad Capellman is a former journalist, web producer and project manager who now works as a digital strategist at Taoti Creative, a Washington, D.C.-based Drupal-focused digital agency that works with non-profit, government and commercial clients.

This post originally appeared on NTEN.org