Parallel website production
When I first started building websites 15 years ago, I did it all; design, CSS, server-side coding, database building and anything else you can think of. In the years since then, each role has become more complex and it’s only right that they are filled by specialists. Instead of one developer building a website from start to finish, each part of the site is now built by different developers that specialise in the role.
The most basic website is made up of four distinct parts: user experience (UX), user interface design, front-end development (CSS and HTML) and back-end development (CMS or Bespoke). Throughout my career, I’ve always been interested in the relationship between each of these disciplines. How do they communicate with each other? How is work passed from one phase to the next? How are changes handled? What happens when one discipline has too much control over the process? After all, each discipline has different motivations and different requirements — so each will have to make compromises or there would never be a finished project.
Series Website Production
From my experience, the development process usually happens in series, meaning that one phase follows the next. It’s almost always done in the same order, although the front-end and back-end development are sometimes switched depending on the needs of the project.
This process model is common because development time is expensive and rework is costly. In this model, each phase has to be signed-off and approved before the next phase can begin. If everything happened at the same time, work would have to be done again on each phase to make them fit together in the end.
Overlap between each phase is usually very minimal. When one discipline is finished, the next gets started. There may be handover meetings at the boundary between each phase to explain the project and how everything works so far. Aside from that, there isn’t much collaboration between each discipline. They probably aren’t even working on the same projects at the same time!
At best, this process is a compromise for several reasons:
- When there’s a change, it has to go back through each phase of the process, even if it doesn’t impact each discipline.
- The disciplines aren’t working collaboratively and any opportunities that are discovered later in the process are usually lost.
- Communication at each boundary is critical, but it’s impossible to completely cover everything.
- Any questions from a later phase to an earlier discipline are not relevant to that developer’s current work and it may be difficult for them to make time to answer or even bring their mind back to that previous project.
- Integration between the front-end and back-end is messy and inefficient since those disciplines often use different tools and environments.
Parallel Website Production
The goal of a parallel process is to address all of the issues with the series process model while still making sure that resources aren’t wasted. First, we have to realise that UX and wireframing are key. With those parts, we can build a near-complete prototype of the site using tools like Axure. Next, we need to make sure that the content is as accurate as possible for each template so we know we’re building to meet the needs of the customer’s content.
When the prototype wireframe is built, we have the following defined:
- Templates (home, product details, etc.)
- Sitemaps (the relationship between the templates)
- Header and footer requirements
- Template content
After that, we take the website apart into each of its separate blocks and look for any commonality between the elements. We usually do this by printing out the wireframes, taping them to a wall and going through each template individually to create a map of the building blocks that make up the site. When we’re finished, we have a map of the site we are building and can move on to define the dynamic elements of each block.
State defines the dynamic elements of each block. It’s a definition by which data the back-end systems (CMS, e-commerce, etc.) are allowed to change the block. We use it as living, adapting documentation that tells us how a site should behave with different content. Any state change can be tested in the wireframe prototype and can be easily pushed through to each block state definition.
At this point, we have a definition for the website, what it’s built out of and how each part can change. Now the design process for all disciplines can start because we have a defined each block and a simple interface of how each block can change. How?
- As with series production, design can start now. The difference is that now they know all the blocks they need to design and how they could change by content. As soon as a design for a block is finished, it can be passed to the front-end.
- Front-end can start now. They have the definitions for the blocks, so they can begin building the HTML and how it reacts dynamically. When design finishes a block, front-end can style them as they arrive. They also know which blocks go into each page so they can build each page easily.
- Back-end can start now. They have the definitions for each page and they know which elements need to be dynamic. They have all the information they need to build the back-end of the site.
They’re working on the same project, at the same time, and they’re doing it together. That means each discipline can do their separate work while knowing they’re all working toward a common definition. The wireframe becomes a central point where all of the disciplines can ask questions, collaborate on solutions, share ideas, spot improvement opportunities, and update documentation.
This model works well for all disciplines… until it’s time to integrate the HTML and CSS into the back-end. The integration work can be very wasteful and it unnecessarily ties up both the front-end and the back-end. One way to solve the issue is to create a single page application with tools like Angular or React. However, that decision should be made carefully based on the needs of the project. A single page application isn’t always the right solution and they have their own set of disadvantages.
As an alternative to creating a single page application, we have developed a server-side headless approach. This approach gives us the benefit of server-side rendering while completely separating the front-end and back-end build process and still using the state definition as the interface.
Our method is different. Our method is about collaboration, communication and a common goal. All of these things contribute to a stable, high-quality website that meets the needs of your customers and enables us to provide rapid response long-term support. Our method is about making your website work for you.
