In the past year, I’ve had the opportunity to work on 4 full website redesign & development projects at Smith Brothers Agency. My greatest takeaway from each project has been the process we used as a team to get the site from strategy to launch – and oddly enough, not one project has used the same creative process twice. In my opinion, this inconsistency in process has helped our creative team to consistently make outstanding work. The natural environment of the web is always changing, so our creative process should mimic its environment. (Just to be clear, we are not totally reinventing the wheel at the start of each project, but we are continually challenging our ideas.) There is no status quo for our websites – there is only the best possible talent and effort applied to each individual project.
We currently use a sprint approach for website creation – each segment of the project is broken into mini deliverables that team members focus on and meet within 1-3 week periods. The project kicks off with an in-depth evaluation of the client’s current brand platform and website. Our team uses the findings of the evaluation period to solve problems and to shape a digital plan of attack. Once a solid digital strategy is formed, the project transfers into the design phase where all of these great thoughts and concepts are visualized to be later executed in the development phase. After development is completed, we put the website through a thorough testing and then bring the whole team back together to review the work as a whole. We start back at the first phase and evaluate what we’ve created. How can it be better? The process cycles through again until we’ve created the best possible end product.
While this method has gained us many successful moments, we seem to struggle at the point in each project where design transitions into development. Imagine a relay race where the designer is handing off a baton to the developer, the developer starts sprinting towards the finish line, but the designer receives news [client revisions] that she’s still in the race and needs the baton back. How can she start the relay over? Or better, how can she work with the developer to run together? We’ve managed to ease this fragile transition by using Interactive Style Guides (ISG).
Interactive Style Guides were born from evolving the creation of Style Tiles from a Photoshop document to the browser. They are a compilation of the basic elements that make up each website – typography, HTML elements, images, fonts, and colors – that are built in the browser as a guide to show clients the overall creative direction of their website and a starting point for the developer to begin the project’s build phase.
SAMANTHA WARREN DESCRIBES STYLE TILES AS, “A DESIGN DELIVERABLE CONSISTING OF FONTS, COLORS AND INTERFACE ELEMENTS THAT COMMUNICATE THE ESSENCE OF A VISUAL BRAND FOR THE WEB.”
Quickly after crafting the first Style Tile in the browser, something clicked between the developer & designer on our team – every single web project consistently uses a few basic things, so if the developer works on building these elements couldn’t the designer work on the visual aspect at the same time? Imagine that relay race again, because this is the point where the designer & developer start running together.
Let’s talk a little more about the process: while the designer is visualizing the website, the developer sets up a development website for the client (a development website is a testing environment set up on our server space), a file structure, and automated systems (I prefer to use Gulp). At this point, the design has barely started, and we’re already easing that shift into development. Next, the developer builds out the basic HTML elements – the elements in our guide were determined after researching & comparing different templates here. The final (and most important) step is the designer communicating the design to the developer. The designer can do this by mocking up documents in Photoshop, generating a list of styles, or simply sitting with the developer and working off the browser together. Regardless of which method the designer selects, there needs to be a lot of collaboration here between the two roles.
(ON A SIDE NOTE: ONE OF THE BIGGEST BENEFITS TO THIS APPROACH IS THE ATTENTION PAID TO THE WEBSITE’S TYPOGRAPHY. TOO OFTEN, TYPOGRAPHY IS LOST IN TRANSLATION FROM A PHOTOSHOP MOCK-UP TO THE INTERFACE.)
What I find to be the best part about this process is that when it comes time to present the ISG to the client, the team can actually present it on the client’s own development website. The ISGs lend a more realistic experience during the presentation (think: clients can hover over links, resize screens, enlarge text, etc.) And lastly, when the inevitable client revisions come after the presentation, they do not hinder the pace of development, since there is already that big head start – the server is set up, the file structure created, the tasks automated, and the basic HTML elements built. While the designer is revisiting the visuals, the developer can begin building out the website’s unique modules (look for an article on the next step in our process soon). The revisions process is also speedier, because design changes are easier to make to a stylesheet than a Photoshop document.
A consistently changing creative process is good when working with a consistently changing platform. Make change happen by evaluating how your team can make its process better after each project. At Smith Brothers, we recognized the need to ease the transition between the design phase and the development phase in our sprints. The solution was to start running these two phases in tandem by using Interactive Style Guides.
Interested in what happens next in our process? Look for our next article on adding modules to the Interactive Style Guide.