Note: This is the final installment in a series of posts about the Nonprofit Web Design Process. See the end of this post for a linked index of other posts in the series.
Solution Design is the technical planning phase where we define how the back end of the website should function. All of the steps up to this point have been focused on how your website visitors experience your site and this phase is focused on the administrator experience.
Purposes for the Solution Design phase include:
Making decisions about site-wide settings and configuration details
For CMS websites, defining content types and their associated fields, authoring forms and templates
Documenting specifics of site configuration for approval and for future reference
The platform on which you’re building your website will play a large role in the Solution Design phase. Regardless of which platform you choose, be sure that your design team knows the platform well so they can be involved in the technical planning. Having a consistent team involved in front-end and back-end design ensures a successful and scalable website beyond the launch.
Each platform comes with its own set of configuration options that should be discussed and documented during this phase. Settings such as the URL for the site and any aliases, HTML title, search, analytics code, registration or login forms, etc. will all need to be defined.
For large websites that have a lot of dynamic content, the platform will likely be a content management system (CMS). There are many options for CMS: Blackbaud Luminate CMS, Drupal, Joomla, WordPress, etc. For any CMS site, we need to design a content model during the Solution Design phase, which defines how content will be structured. Our content model begins by identifying content types for the site. A content type is a group of content items that share similar attributes and layouts. News Items, Blog Posts and Bios or Profiles are common content types for nonprofit websites.
Once we determine what the content types will be, the content modeling process continues with:
Defining data/fields needed for each content type
Designing the authoring form that administrators will use to create items of each content type
Designing templates that control the display of data for each content item
By looking back at our wireframes, we should be able to begin defining the content model. Inevitably, we always wind up needing additional wireframes to define all of the various templates that need to be created. A good rule of thumb is for each content type, you’ll need at least one single template (showing how a single content item will look) and one list template (showing how a list of multiple content items will look). For example:
Here is an authoring form in Luminate CMS for a Blog Post:
Here is a Single Display Template for the same Blog Post content type:
And here are a couple of List Display Templates for the same Blog Post content type:
Our complete content model will include the authoring form, single template(s) and list template(s) for each of the content types we’ll be building for the website.
For the Solution Design phase, our deliverable is an Implementation Plan, which is a lengthy Word document that describes the configuration details and, if applicable, the content model in great detail. The Implementation Plan is a deliverable both for the client team and for the web developers that defines everything we’re building. It tends to be highly technical and therefore, we allot time to walk through the plan with the full team (clients and developers) in excruciating detail so everyone understands what’s being built. Once the plan is understood and approved, we start building the website.
This is the last post in our Nonprofit Web Design Process series! I hope you’ve enjoyed learning about the process. To wrap things up, I’ll post a summary in the coming weeks linking to each of the posts in the series so you’ll have a link to reference all of the posts.
Other Posts in this Series
Surveys and Interviews
Solution Design [this post]