Building Ourselves, Part Four
This blog post is the last in a four-part series that outlines how — as the saying goes — we’ve been eating our own dog food: creating a new brand for ourselves, changing our name, redesigning our website’s user experience, and then prototyping and launching the site.
In Parts I, II, and III of this series, Scott exposed our process for branding strategy and design work by describing how we did that work for our own company. It turns out that it’s really hard to do this work for yourself—we didn’t get it right the first time, but finally found new designs, new layouts, and new messaging that we loved.
But then we had to build it. That’s where the dev story starts.
An Interlude on CMS Choice
Depending on who you ask, our tech work is the least sexy part of what we do. The pretty pictures just aren’t there — it’s hard to get screenshots of the backend that don’t look like they were taken in 1998. That’s not because the technology is old, but rather because content management systems (CMS) tend to be high on functionality and low on aesthetics.
For our clients, though, it’s a crucial part of the story. What we choose and how we implement it can either make their jobs easier or cause them everlasting distress. This one decision – which CMS platform to build the site in – ultimately defines the client’s relationship with their website, so we like to take the time to understand all of the requirements as well as the skill sets of those who will be maintaining the site: the admins.
Some clients don’t know what a CMS is when we start a project, others have had bad experiences with one or another, or have heard about some (often WordPress), and others have had experience creating their own websites from scratch. We do a tech discovery when we start a project and ask some important questions that help us come up with a recommendation for a CMS:
- How flexible must the system be?
- What types of services or content will we integrate with?
- Is there a data migration effort, and what is the size of that content?
- Who will administer the content and how technically savvy are they?
- What did the client love/hate about the previous system? What were they not able to do that was important to them?
- What kinds of features and content are planned for a future time?
Choosing a CMS for Our New Site
When it came to rebuilding the Smith & Connors site, I knew from the start that we’d use SilverStripe. I loved it for this project because I could throw together a backend that would be ready for use in just a few days.
We knew the basic structure of most of the pages, so while we waited for the site’s UX design to gel, we could still write narratives, cut images, and migrate blog posts. As each frontend template was completed, we would get early validation on the design, or in some cases, tweak the layout and styles to support the actual content.
Elegance and Simplicity
With the recent release of SilverStripe 3.2, I was delighted by the design improvements they made to the backend CMS: cleaner layouts, improved visuals, better overall user experience (we have since upgraded to SS 3.4).
The upgrade to the CMS backend resulted in crisper images, colors that contrast better, clunky tabs replaced by simplified links, and better organization of navigation elements. The newer blog module is built for less scrolling and easier management of your posts.
Making Patterns on the Frontend
Once the backend was in place, we turned our eye toward frontend development (the “front” of the site...the part that visitors experience).
I used a tool called Pattern Lab, which enables us to create design systems starting with the most basic elements (headers, buttons, links), followed by more and more complex groupings of those elements (menus, headers, text, images, footer, ….) until we have styles for all components used on a site.
I worked closely and iteratively with Talie, who designed the site, to fine-tune the styles in the browser. Being bi-coastal with me in Boston and she in Portland, we do a lot of our work on videoconference. I share my screen and we make immediate decisions about what looks good. We are modifying the site in real time. We then had final style definitions that could be applied directly to the website templates.
Pattern Lab allows us to create a prototype that isn’t connected to the CMS yet, so we can play around a bit at this point. This was the basic prototype for our new site: http://prototype.smithandconnors.com/public/
The benefit of using Pattern Lab is it nails down the styles with reusable elements quickly. Designers love it because it identifies inconsistencies and enables us to hone the design in browser. Developers love it because everything we do in Pattern Lab will be used in the final product. Producers love it because it saves time and eliminates questions.
As the client in this case, we loved it because we got insight into the final product early on. Usually we’re not the client, so this last point is crucial. So much of what we do revolves around building trust with our clients. Surprises are the worst, even when delivered with the best of intentions. When our clients are treated like a real partner and given access to real designs they can play with early, we are all more likely to succeed.
Smith & Connors 2.0
One thing about being your own client -- you never stop bothering the agency for changes. We’ve got ideas for improvements. Stay tuned.