Dealing with design anti-patterns in web projects

Over the years I have noticed three patterns that always seem to get in the way.

  • Slight variations from page to page–AKA inconsistencies.
  • Many page specific variations–often spacing related.
  • Complex patterns with many nested components–sometimes necessary.

Thinking back about the specific projects I encountered these on, I realized there are several things at play that make them more difficult to deal with.

For one, there could have been more consistency in the original design.

Design focused tools such as Photoshop and Sketch don’t make this easy. Other than create a huge Symbol Library or copy and pasting elements from page to page, it is easy to induce small errors into the design. These might be small 1–5 pixel errors that are hard to see, or it might be just making design adjustments on a page-by-page basis. This can be further compounded when many designers work across the same files.

Today, things are changing fast and with some of the tools such as Brand.ai Sketch Library Syncing and InVision Craft Sync we are getting closer to the idea of having a Design System live within our design apps. Right now that exists in the form of a Synced Symbol Library.

But this is not a universally adopted standard, especially amongst teams with that has less design project overlap. On new designs or projects it can be difficult to think forward enough to establish these systems early on.

Fueled by deadlines, revisions, and a web team waiting on the final output we are sometimes asked to cut corners that end up being implanted in the final DNA of our projects.

Once you know the basic layout and have an understanding about what are the different components being used. Ask yourself, how can I cut up this site or app into specific components or building blocks and then re-build the site using only these. This exercise could be the basis of a future Symbol Library but will also force you to fundamentally consider issues such as component spacing holistically, rather than as a page-by-page affair.

But this burden doesn’t only stand with the designer or design team.

It is also something that can be resolved early on by the dev team prior to a build out. By thinking about how you might cut up and create components out of these design artifacts, you are fundamentally asking yourself the same questions. Is the spacing consistent from page-to-page? When there is something that is page specific, could it be created in a more modular way?

As Symbol Libraries become more widespread in conjunction with tools such as Coded / Living Styleguides or Pattern Libraries, we are finding ourselves creating much larger systems that are cyclical in nature. Rather than taking the waterfall approach with each new redesign: a new set of design files, a new set of CSS patterns, a new set of HTML components, we are quickly moving towards a world where the production components are influencing and updating the Symbol Libraries that are being remixed into new designs.

So in effect, design is becoming a 2 stage affair. There is the initial push where brand guidelines, color, and style are infused into a system. And then there is this layout approach of arranging pre-existing patterns to create new flows, experiences, and pages.

However, there is one missing part from most teams. This is translating the initial designs into performant front-end code and translating components back from code into Symbol Libraries. This is where the Design Systems Engineer comes in. Making sure the translation keeps the design intent strong and creates documentation and systems to smooth the process for all.


Originally published at James Stone.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.