Modular Design

In a web project there are usually different departments involved. For example: Software development for the backend programming, frontend development for HTML, CSS and Javascript and the design department. Maybe some of the participants are even from different company, a design agency for frontend development and design and a IT company for the backend programming. Usually each department works on its own and there is little to no interaction between them.

1. The designer creates mockups or photoshop layouts to visualize the design of the website.
2. The frontend developer creates a static HTML/CSS/Javascript prototype based on the layout.
3. The backend developer takes this static prototype, dismantles it completely and rebuilds it using templates and a server-side programming language.

This automatically leads to the typical lifecycle of a web site.

The Typcal Lifecycle

At the start of a web project one important thing is often underestimated. Change! The design is often created on the assumption that it does not change. But with such a static approach a static sequence is started. After three to four years the website needs a general overhaul because it does not look “state of the art” anymore. The design has to be reworked, to be attractive again. A new project starts beginning to create a new design over and over again.

Other aspects of a web project usually follow the same pattern. The technical implementation is defined at the start of the project. Modifications or updates during development are not considered, because all starting requirements are met by this baseline. If the customer wants to add a new feature, it is validated against this baseline set at the project start. If it fits or can be integrated, good, if not the customer has to start a new, big project where the baseline is updated.

Often a technical update is combined with the design update, but the larger the project, the longer the web page has to run “unchanged” because of the amount of money the project consumed. So instead of shrinking the cycles to incorporate more changes and get more flexibility, we get the opposite instead.

This is typically called "relaunch", where everything is built from scratch.

But the internet is dynamic and we should incorporate Change at the very beginnig of your project.

Project Management

This static approach also leads to a project management that is usualy static. Meaning the project management usually follows the waterfall model. But the waterfall model handles change badly. So every question that arises during frontend or backend development throws the project back.

Getting questions back to the designer at this point disrupts the flow of the project. The projects time, budget and quality are in danger! The design, which was already completed and approved has to start over again.

Not only after the launch of a new web design, but also during the projects implementation you are starting to fall behind as technical possibilities, new ideas and competitors progress.

Software Architecture And Design

Change is nothing new in software development. Each part of the source code should be changeable at any time. In large development teams this is living reality.

What makes this operational at all, is the software architecture in my opinion. Simply spoken the software architecture defines layers and columns or components and creates a map of your software. On this map each requirement and each piece of source code is represented. The map can be illustrated in different levels of detail or scale, depending on what piece of the software you want to see in detail. When conducting a change, the map shows all pieces that have to be updated or involved. This ensures maintainability and quality of the source code, even in highly volatile projects.

But how does this apply to the design process? As the design process is usually the first steps in a web project, it is important to avoid the “old tracks” that lead to the static and inflexible structures described initialy. So instead of creating mockups and photoshop layouts to visualize the design, a "design map" is needed that incorporates change and flexibility. The parts of this map could be:

1. A styleguide, defining global design rules like fonts, colors, logo, gaps and spaces etc.
2. A list of areas like header, footer, content columns defining one or several page layouts.
3. A list of modules defining functional units and design elements wich can be used to build the web pages.

Using a modular structure, as described in my article Frontend Architecture provides a flexible system that helps to incorporate change while developing a frontend design. This also automatically changes the flow of the project substancially. Instead of having one coordination meeting after the design work is finished, there can be one for each module that is passed on to the frontend developer.

As you progress module for module, it is not difficult go get the backend development on board as well. Some modules may have no backend counterpart, others usually are very backend heavy. Is having your designer listen to the two developers discussing what kind of data the database returns for different scenarios really a problem? I think not, he may catch a case, he has not considered in the design.

The consequence of this modular approach is that all departments, including the customer are working together much closer. And they work together from the beginning to the end of the project, so if questions, problems or changes emerge later in the project all participants are still on board.

Even without Agile Software Development or Scrum the static creation of the design is replaced by a modular system that emphasises on collaboration and communication. The result may look the same, but the difference becomes obvious when you add change a module, add a new feature or modify a global design element like the primary color!