Information Architecture and Design - Technical Design

Technical Design

This encompasses what we call design in traditional software development, i.e.:

  • Application architecture

  • Solution architecture

  • Object model

  • Class and sequence diagrams

  • Database schema

The level of technical design required for a CMS project can vary quite dramatically. In most CMS solutions, much of the technical design has been done. If the site being built is content-oriented, there is no need for any technical design. For sites that have interactivity, i.e. extensions, technical design will be required—but once again, it depends on the level of complexity. At its greatest extent, it will cover object models, class diagrams, and database schemas.

As a minimum, all projects should capture the custom classes. For a large complex project, there should be documentation that covers custom classes, interaction, object model, class diagram, and database schema.

The following diagrams represent technical design details for the Good Company project (http://www.goodcompany.com.au). This was a project that included custom content, workflow, interactions, and extensions. The Good Company website was centered around finding volunteers to help community groups. The core was a "wish" that a community group would post on the website, and then volunteers would search for wishes and apply for one that they could help with.

The first step was to capture the overall model.

In this diagram, we can see that the wish is central to the model. A wish is provided by the community group and then is assigned to a volunteer who is a member of the volunteers group. We also show the Good Company staff (GC Staff) as a member of the staff group. So, what we have captured here is a high-level overview of the main objects in the system and how they relate to each other, as well as, the core users and groups that need to be set up for appropriate permissions to be applied.

Following on from the overall model, there are interactions required for volunteers and community groups to sign up. The following diagram shows the flow for a community group to sign up.

What we can see in this diagram is that there are a number of steps that are required for a community group to be accepted on the site. Not only do they have to enter their details, they also need to be approved by a Good Company staff member, as well as confirming that they have completed an induction. This is capturing business logic and is important to get right as it can be costly to change at a later date—not to mention the impact on the business.

The next diagram defines the wish content class: all the attributes that are required, whether they are mandatory, the type of attributes, whether it's available to the public, etc.

Finally, at the end of all of this, there's an underlying database schema that indicates how the information is to be stored.

Along with the database diagram, a class diagram would be created of each class that was to be programmed within the system. Note that in this case we are referring to classes in their traditional sense, not content classes.

The following diagram shows the definition of the wish class. The full class diagram would show ALL classes and how they relate to each other.

Once the underlying details have been captured we can look at the way the interfaces will be structured. In particular, there was a need for administration screens to be defined for how the custom content was to be managed.

The following diagram is an example of the high-level administration functionality to be captured. It shows that there were screens for the viewing and editing of content for each group of users. Given that the community groups had the most functionality, there were more screens required.

From the overview, the details of each screen were captured in a wireframe. The following wireframe shows what would be on the screen when a community group was editing the details of a wish.