Every project has constraints. When we are approaching a project, one of our primary focuses is asking, “How do we add value?” Relationships in general take work, and starting a relationship requires finding mutual ground. Our projects often involve content organization and strategy, a custom design (with user experience planning), a pattern library, and either integration support or actually hooking all of that up with a backend. This is usually where we find ways to add value when starting a project with a new client.
Recently, we started a relationship with a new organization. At first, we saw the usual needs, but as we worked on getting to know these folks, we realized they weren’t ready for a pattern library, and they weren’t concerned with having a Sparkbox custom design. To quote our Vice President, Rob Harr, “When working with clients, we need to make sure that we are putting their needs first.” Our client had a healthy budget but several complex needs to prioritize and resolve in an intentional, iterative way. What our client most needed was to learn how we work and to find a way to take our efficiencies and bring them into their internal team while getting our guidance to address their most pressing issues. As with all our projects, we didn’t want to build a website; we wanted to help an organization. To meet the needs of our client—we did something we’ve never done before—we forewent our usual design and development approach and opted for purchasing a premade template. Establishing a new site, teaching, and planning to improve and customize in the future were the priorities.
I was brought on to this project for my experience as a designer and frontend developer. Working with a template is a new kind of challenge. We pulled apart the template and stitched a layout that met our requirements. A designer’s eye was needed to extract the design elements of the template and mesh them with the brand identity of our client. While there were times of frustration, the challenge was rather exciting. I’d like to share some of the things I learned with this approach should you ever find yourself in a similar situation.
Choosing a Template
Choosing a template is like working in reverse on a website. The starting point is browser and device testing. Just as you would thoroughly test a website while it is being built, the template needs to meet your client’s needs for browser support—otherwise, you’re not saving much time. Secondly, look at performance. If the template maker offers a demo page, run that site through webpagetest.org. Check to see if the template is using outdated practices like font icons or hacks. If you are working in a CMS, consider using a template made specifically for that CMS first. However, it may turn out that the more flexible option to your client’s needs is a straight HTML template. With just an HTML template, nearly any CMS can be fit in to work.
Those who will be working on the project should give the template a thorough code review. It is way too easy to select a template solely based on the design. Yes, the goal is to find a good design, but the code *must* be usable. If you are a project manager or designer tasked with finding a template, be sure that the person applying the template weighs in on the code and structure.
Breakdown and Organize
Go through and breakdown and organize the template into a build system you are comfortable with. libSass is a good option to generate CSS via a Node-based build utility. Try to find a template that supplies Sass files, or do the leg work and break apart the template CSS into more manageable chunks. If you’re using a preprocessor, take advantage of variables and find and replace common properties, namely font stacks and colors. Utilizing variables will ease customization of the template. Even if you use a preprocessor, consider adding on a post processor as well. Adding Autoprefixer is a great way to increase browser compatibility with minimal effort.
While this process is critical for efficiency, don’t get carried away breaking down and organizing the code. Do the bare minimum to ease customizing and working with the template. Cut out what you can. If the whole template is not needed for the project, cut out that code. This will (at the least) provide some performance wiggle room. You may decide early on to not use the carousel or lightbox features of the template, giving way to complete removal of those features from the codebase.
Working With The Code
Be prepared. The code may be far from ideal. It is ok to relax your standards and shed some pride. If you’ve chosen to use an existing template, you’re likely there for reasons that mean you should relax your standards. Seeing how others approach writing a template may help you learn something new or help solidify how you would otherwise approach the problem. You may have to come to terms with redundant CSS or undesirable class/element selectors.
An important thing when working with a template is to follow the conventions of the template. If the template follows a naming pattern for classes, try to conform to that approach. It’s a good practice regardless. But also be extra studious with leaving comments. You need to explain that redundant selector. I find it easiest to separate the template CSS from my customizations. Using a base SCSS file, load in the default template partials first, followed by any customizations afterward.
Final Thoughts
As a frontend designer, utilizing a template is a foreign concept. I am spoiled by working on my own designs or working with other designers. A template removes that relationship to the design and requires a level of humility and grace. Templates can disrupt your normal process, but the goal is still to provide an excellent product for your client. Our client is thrilled that the website could make them look so good. The client’s excitement and our stronger relationship with them makes the squabbles with the code worthwhile.
