Database Schematics vs. Wireframes

Wireframes are at the heart of the no-handoff process. A functional wireframe is built at the earliest possible moment, usually after just one discovery meeting. Its how we assess sitemap and navigation, forms, representative page content, and interactive elements in their natural habitat.

But for sites with complex relational databases you also need a database schema. I use a custom excel based system, but tools that give a visual representation like dbplanner are also good. The database schematic should be built concurrently with the wireframe, illustrating how users will interact with the db and testing our assumptions quickly and early.

One of the benefits of the custom system my teams currently use is that we can add additional columns to the excel doc that dont ultimately become part of the database, but are used to build the admin tools or other forms that interact with those tables. Notes for users, custom field labels, and special field behavior are all captured in custom columns in the schema and available for the entire team.

The schema becomes part of our shared team language. Its critical that all team members, even those who dont think of themselves as ‘techy’, learn to read them if not write them. The db schema is a concrete and accurate communication device, and alongside the functional wireframe – when both are done right- constitute 90% of a website build.

The db schema and functional wireframe are indispensable communication tools for the internal team. Other stakeholders with no direct role in building the website may or may not be able to comment directly on the schema – dont be afraid to try! The wireframe however can be read and understood by all team members.

A web team that has embraced both the visual/functional wireframe and the highly technical db schema has leapfrogged most of the issues that plague multi disciplinary teamwork: lack of common language and vocabulary, and lack of tools to communicate clearly and accurately.