Is Your Blueprint Complete?

When Summersault goes through the blueprinting process for your site, we bring many years of experience with building complex database driven websites, and as a result, we know what kinds of questions to ask and details to clarify to make a blueprint complete. 

We appreciate that many of our clients may want to work on their own blueprint, and while this can be a time-saving measure, it’s important to note that there are many kinds of questions to consider in this process.  For example:

1. Does the blueprint describe the overall workflow of the site’s functionality, from start to finish? Does it go beyond flowcharting abstract concepts and get into the specifics of navigation and “cause and effect” of a user’s actions?
2. Does the blueprint show what actions a visitor, logged in user, and administrator can perform?  Does it specify what kinds of “security” levels are available, and which ones are required to access different areas of functionality on the site?
3. Does the blueprint indicate what information needs to be stored in the database that powers the site, and what kinds of data each field will hold?  For example, if you’re storing information about a person, does the blueprint indicate that the database will store their first name and last name separately or together, and does it specify how long each field can be?  For a phone number, does it specify whether or not area codes will be stored, and if so, should they be stored with or without the parentheses used for formatting?
4. Does the blueprint specify how “validation” will work – verifying that data input on the site is in the format it’s supposed to be – and what kinds of messages or errors will be shown to the user if there are validation problems?  For example, if you have a set of required fields and one is left blank, how will the user be notified about that and given an opportunity to fix it without filling out the whole form again?
5. If the site will generate additional kinds of output, such as generated e-mail messages, Excel files for downloading, PDF reports, etc., does the blueprint specify how these output items will be formatted, what information they’ll contain, etc.?
6. For lists and reports, does the blueprint specify how they’re to be sorted?  For pages on the site with the possibility for extended content generated from the database, does the blueprint specify how pagination and sorting will work?
7. Does the blueprint specify how the data in the database will be maintained and cleaned out?  (If you’re working with a site that adds new information to the database for each visitor, you can quickly accumulate huge amounts of data that will need to be dealt with.)
8. Does the blueprint consider the hosting infrastructure required to make the site being built available to the world, and the maintenance, system administration, and monitoring resources required to keep the site running under the load it will receive?

As you can see, blueprinting can be a very detail-oriented process - check out an example of one of our blueprint functional mockups.  In some cases, the difference between “a report with pagination” and “a report without pagination” or forgetting that you need a “help me reset my password” feature can mean significant cost differences once development has begun. 

Our experience shows that addressing these kinds of questions before development begins can prevent any number of hassles and headaches that might come up.  In many instances, we’ve saved our clients tens of thousands of dollars by going through a comprehensive blueprinting process when they might otherwise have just dived in to the development phase.  It’s an area where we can add a lot of value to a project for very little time and cost.

If you do work on your own blueprint, that’s great!  We’ll be happy to help you review it, and to fill in any details or questions that might remain.