How to build development systems (for a web site)

A tool as clever and focused as PatternLab can help break those habits. Essentially, PatternLab is a tool for organization. Rather than trying to organize a build in my head, or in spreadsheets, I can see it laid out in the browser. As software it’s an imperfect tool, but as a concept and process it has strengths. I’ve learned that in order to build good systems I need to plan the work, focus on the project basics, and maintain flexibility.

Create a plan

Most projects I work on have some established design before I begin. In these cases, it’s import to develop a plan. For me, the process is as follows:

First, I will review all the design assets I have available. Sometimes, (most of the time) not everything is there yet and I should expect changes. It is important to get a good sense of what a design allows for, and to develop priorities early in a project. I index all of the design assets I’ve been given, and document each individual component. Any assumptions, questions, or notes about planning can be helpful later on.

Next, I’ll have a conversation with the design lead on the project. We’ll review the current state of the design, and I ask as many questions as I can. Having a solid understanding of design principles will come in handy. I ask about type scales and grid structure. We discuss components that don’t fit into the established system, like fonts or stylistic elements. We find and refactor pieces of the system that lack consistency within the design.

Finally, I’ll map these individual elements and consult the project schedule to put together a development plan. Typically, this plan follows a schedule previously determined by our clients, and by how far along the design has progressed. With a plan in place I can execute the parts of the system whose completion will be most beneficial long term. If I come across a conflict I can identify it sooner and bring it up with the larger team.

Start with the Project Basics

I used to dive head first into a specific part of a page when beginning a new project. The header and footer would often be the first, followed by each distinct page, all written from scratch. The results were a hornet’s nest of jumbled and inconsistent code.

To avoid this I like to define a baseline (color, fonts, grid structure, UI elements, etc.) and make it as complete as possible. A well defined baseline helps to avoid redundant CSS needed to override previously established styles– redundant CSS creates more work for the developer, those who test the code, and whoever is stuck with it in the end.

Be Flexible

The strength of building a system is flexibility, but this requires a degree of caution. Carefully planning development project helps a great deal, and there are a few more useful tips to enable flexibility.

Build Patterns

Using a tool or approach like PatternLab will encourage the re-use of code. The less code written the more stable a build becomes. Fewer points of failure, conflict, or confusion are introduced to the project. The work becomes easier as a project progresses by making code do as much work as possible. Consistency is engendered by avoiding subtle rendering differences that occur when repeating code for similar elements.

Write consistent code

Decide on, and follow, an approach for each new pattern to be introduced. Consistent code allows developers to transition smoothly from each component to the next and there is less delay when picking up older work. Consider using or modifying an established methodology such as BEM or SMACSS. There should always be purpose and meaning behind code, beyond simple semantics.

Break down code into discrete chunks. A good rule of thumb is if CSS goes beyond two screens worth of scrolling, then break it out into smaller partials.

Leverage Sass and other front-end build tools, and automate as much as possible. If code is not automated, it’s more vulnerable to error.

Document as You Go

It’s not just a pain to document after the fact, it’s likely to be flat out wrong. Writing documentation (for requirements, code, content, etc.) as the code is actually written will be more accurate in the end. It’s particularly import to translate project requirements into proper documentation.

Be Clever

Writing clever code (through PatternLab or similar) creates a flexible and adaptable system. Clever code permits for in depth consideration of components and how they relate to each other, which makes development easier. New components are often just simple adjustments to existing ones; by keeping a healthy dialog with designers new components can be built rapidly.

Get Better, Always

The most important lesson I’ve learned this year is the benefit of constantly revising my development methods by learning to use new tools, and experimenting with new processes and practices. Maintaining thoughtfulness within our work will make development projects go faster, be more enjoyable, and improve the overall quality of deliverables. It could be as simple as using an old standby in a new way or a complete rework of an entire process, but keep looking for the tools, processes, practices, and ideas that lead to a better web.

Back to Top