- August 4, 2011
Make Sweet Systems Sweeter
- @alliwagner
- Developer
At Happy Cog, process is not sacred. We respect process, but we are constantly looking to improve the way our projects run; especially with regard to transitioning between project phases. Last week, Yesenia Perez-Cruz described how she crafts sweet systems and digital cupcakes.
This week, I’m going to show you how we turn those cupcakes into a well-built tower of yummy cupcakery.
In her article, Yesenia discusses the “Working Styles” document. This is a Photoshop file which serves as a running log of all content types and design decisions in the projects visual design. This is extremely useful to me, the developer, for several reasons. First, it promotes consistency. Consistency is an important factor because every deviation from the established pattern (be that a border style or margin value) means additional CSS to handle the exception. Additionally, Working Styles aids development as a single location for the project’s color palette, a detailed view of the typographic system, and the grid, serving a 10K foot view of the design system.
Recipe for Success: 1 cup design, 1 cup code
A beautiful design system is about finding the same balance of consistency and variety. Too systematic and the design becomes predictable and repetitive. Too much variation and the system is confusing and overwhelming.
I work with talented designers who define and maintain this appropriate balance. They don’t simply design comps, but rather craft visual systems for each and every project. This attention to detail gets me 95% of the way to successful presentation development. The remaining 5% is what the handoff meeting is for.
After the client signs-off on design and before template build begins, we have a Design to Development handoff meeting. Before the meeting, developers review the designs and prepare questions such as, “What does this look like with JavaScript turned off?” and “What happens here on text resize?” We also discuss whether or not it’s appropriate to consolidate styles in certain instances. For example, there may be two very similar button styles which can be consolidated into a single style. It’s at this point that we decide on rules as marching orders for building our templates. This sounds something like “all buttons that point to payment pathways should be red and uppercase.” These trump rules are documented and referred to in development, eliminating the need to return to Photoshop to update. If you don’t already, I encourage you to consider folding handoff meetings into your process. These meetings have proved to be huge time-savers as we work out questions and inconsistencies then and there instead of midway through development at the risk of wasted time and resources.
After template build is complete, designers circle back and visually QA the work thus far. They review templates in their browser of choice (::cough::Chrome::cough::) not necessarily seeking pixel perfection, but rather accurate translation which honors the design system crafted.
When reviewing, our designers often use Webkit Web Inspector or Firebug to investigate bugs and let developers know which styles they’d like to update. These updates are logged in our bug tracking web app of choice, Lighthouse. Alternatively we often just have a quick chat together, in front of a browser, manipulating CSS to find a solution. I, for one, especially appreciate these collaborative moments. It’s been a great opportunity to get to know the people I work with, turning teammates into partners.
These tools and meetings we have in place become critical for our success in taking designs to code. What sorts of things have you integrated into your process to see projects to success?