As information architects, we love tools that help clients think about the structure of their content. One which we’ve found particularly helpful is what we call our Technical Architecture document. It’s a spreadsheet that defines the structure of the site. This approach is not uncommon, especially within the Drupal community; however, we have promoted this spreadsheet from information architecture tool to site generator. By automating a once manual process, we’ve introduced some really exciting opportunities around rapid prototyping and efficient product iteration. I’ll get into the details of that in a follow up post. For now, we’ll look at how we move from sitemaps and wireframes to the technical architecture document in a way that sets us up for rapid prototyping.

From Wireframes to Technical Architecture Document

After the initial discovery phase of identifying goals, personas, user needs, core content and sitemaps, we build out wireframes for the project. The structure behind this content really comes together when we then translate those wireframes into the technical architecture document.

As mentioned above, this document breaks the site down into the specific content types, fields, vocabularies, terms, users and other units which together comprise the entirety of the project. You can look through and make a copy of the document for yourself -
Technical Architecture document template

Sitemap

First we translate the sitemap as defined in our wireframes into separate rows in the technical architecture document.

Now we can specify the nature of each page and work with the client to define path aliases.

Content Types

Next we group all of the content into distinct types. We’ve been keeping these potential groupings in mind as wireframes are built out, but it is here in the technical architecture document where we explicitly define them.

Here is an example of the Course detail page (as shown above) translated into a content type and its associated fields.

This is where the structure of the content begins to take shape. We have identified the discrete fields which together form a single course. We can also now define field groups and help text where that is relevant and helpful.

Fields

The fields we saw in the content type sheet validate to fields referenced here. This sheet is where we hash out the finer details of each field. We bring the client into conversations around this sheet when necessary (such as help text and default values), but allow them to concern themselves primarily with the sitemap and content types.

Next we define in the same level of detail the remaining components of the site, including field groups, vocabularies, image styles and user roles.

Here is a look at user roles and their associated permissions.

This document is a great way to model content and inform developers as to what would be built. It also reveals to clients the underlying structure necessary to implement the functionality and form proposed in the wireframes.

Of course, there are still limitations in representing a course page in a series of rows and columns. The concept of structured content is now more clear, but it is not until a content author can create that Methodology of Science course that the picture truly comes into focus.

This is the exact situation prototypes were made for. In the next post I’ll dive into how we’re using the technical architecture document to automate much of the build process, enabling us to quickly create these prototypes.