And you may find yourself, with a poorly functioning website. And you may find yourself, with a backlog of unusable content. And a search tool that doesn't find things. And you may ask yourself, well, how did I get here? The answer is almost certainly caused by overlooking the critical phase of Site Architecture.
Establishing an information architecture is a fluid task that informs the entire software development life cycle at THOR. We infuse our design and technology decisions with architecture that supports business objectives, design goals, and technology tools. The process is always custom and can take on various meanings depending on the nature of the work at hand.
The Shape of Data
On medium and large scale development efforts, the role of deciding how to structure data is a hidden task that some non-technical teams overlook. You can think of data architecture (or its technical name, schema) as the foundational layer of a quality website. Despite popular belief, determining how to structure information doesn't have to be a daunting process. It's something you can tackle as a team even before engaging a professional studio like THOR.
As a matter of fact, establishing a schema is a process we encourage our clients to begin before engaging with us. We suggest completing this exercise by identifying content that is working on the site, content that feels stale, and content that is missing. Part of the discovery process that will follow this initial effort builds upon these findings and involves a deep site audit that picks up where our clients leave off. Taken together, the process catalogs the entire site and informs our team at THOR in regards to content that should be migrated and content that should be left behind.
In our analysis we look at sites in modular segments and pinpoint where disparate content types overlap and how others may be reusable in the future. THOR develops data models that steer our design and development work which results in flat information hierarchies that link elements to create varied views of a site's content.
Wireframing a Site
A wireframe is a basic diagram that shows the position of modular elements that form each page of a website. By generating a wireframe and agreeing to its structure with our clients, we are able to begin the design process with a foundation for our user experience that is sensible and accounts for all of the content we’ve identified in the early architecture phase.
At this point in the process, architecture, wireframing, and design begin to blend as we advance into the specific aesthetics of the site. We approach this task with a combination of knowledge gathered over years of experience and an ongoing review of current design inspiration and aspirational sites identified by both our internal team and the client. The resulting wireframe creates the first glimpse of the overall roadmap to a complete site. This is the 30,000 foot view of the site. An expansive look at the site at a moment in the process when adjustments can still be made without budgetary ramifications.
Framing a Website
In tandem with the design process on any given project our development team will build the data models established in the architecture phased into then chosen CMS or database platform. We start this process by manually migrating representative content items into these new models to test how well our assumptions play out in a live setting. We use feedback from these trials to fine tune our efforts and iterate on this process until we obtain the results we’re looking for.
This process of confirming our assumptions, validating our technical direction, and collaborating with the client to verify the project direction is critical to the development process. It allows us to move forward consistently and confidently with the knowledge that the systems we have in pace are sound.
During this early phase, and while our design and development team are both up and running on their respective tasks, we also begin training our clients to work with their site. In order to build early confidence and familiarity with the platform chosen for a project we have our clients begin to explore the CMS. This involves logging in, adjusting content, exploring the dashboard, and witnessing how their actions in the backend of the site affect the front end.
In some instances, dependent on the scope of a project and the outcome of our test content, THOR may outline a more extensive migration plan which features a mix of manual and scripted migration into the new platform of choice.
Scheduling and Cost
Architecture can be thought of as the 'glue' in the life of a project: it fuses together many of the development phases yet does not stand alone. As such, it's hard to scope this type of work outside of a full website build in which THOR will add architecture into our design and development deliverables.
We encourage interested parties to explore our Website 101 explainer series, where we guide clients through our varied offerings. Our CMS, Headless, and Custom website builds all feature architecture as part of the process. If you have questions about how architecture tasks work at THOR, reach out and we'd be happy to start a conversation with you: