This is the second post in our Designing Design Culture series.
Frontend Designer
We experiment often at Sparkbox. We like trying out new ideas and concepts. Our tools are always fighting for their lives. It isn’t always about maximizing our efficiency; sometimes our experiments come out of an informed feeling that things could be better. Maybe we don’t know what that is or looks like, but experimenting helps us hone in and find the roots of the idea. Recently, we started asking ourselves how Sparkbox could be better at design. We have really talented designers and super smart developers. We consider design and development a spectrum, but there is a hazy area where design and development meet. Delivering thoughtful, responsive designs all the way from idea through integration has historically been our sweet spot, so making sure we’re always pushing ourselves and getting better there is important.
Our Creative Director, Jeremy, discussed a number of changes we’ve been making to scale design at Sparkbox. Many of the changes Jeremy outlined revolved around the people and culture that already existed at Sparkbox. One big step toward taking on this idea was changing titles. When I first started at Sparkbox, everyone who touched code had the title Developer. But we had some Developers, myself included, who wanted to be more involved in the design process. Now we are Frontend Designers. The title change has caused us to reevaluate what roles we fill and how we design and build websites going forward.
Process Iterations
Title changes don’t necessarily change roles. In our case, these titles better described skillsets of those workers. Not everyone fits that designer/developer spectrum the same way. That is especially true for our Frontend Designers. Some are more developer-leaning, others are more design leaning, and then there are those like myself who are in the middle. A recent project gave way to an idea from our own Emily Gray to encourage the strengths of our Frontend Designers. As the project manager, Emily was attune to our aptitudes as Frontend Designers—she knew which of us were more design-leaning and which of us were more developer-leaning. She noticed one of the developers was writing all the structure-level HTML and CSS. That developer handled the naming conventions, grid system, and other high-level decision making and code. The second developer (who falls fairly far on the “design” side) was following along after the first to refine the CSS to better communicate the design.
Like a big block of digital marble, the first developer hammered out the big chunks into a rough shape. Then the second developer went in with a chisel and polished that shape into a smooth and beautiful finish. It was a fast, fluid, and validating process for each of the developers that played well to their strengths. As the project manager, Emily saw a lot of potential for this format, and we shared in her excitement. If we could build this approach into how we work, we could manage to provide a new level of fit and finish to our projects.
The Hammer
When structuring these roles, we didn’t see the need to assign a title role. So the “Hammer” is not exclusively a role meant for someone with a developer title at Sparkbox. Instead, the role of the Hammer is left in such a way that it can vary from project to project. Depending on a project’s scope, it is very likely that a Frontend Designer might fill the role of the Hammer.
Overall, the Hammer role sees to the overarching, large-picture questions, problems, and solutions of a project. The Hammer writes the majority of a project’s HTML and the baseline CSS. Because of this, the role will often determine the constraints, tooling, and solutions for the component—and even the project as a whole—since it is in some ways configured to the Hammer’s comforts and efficiencies. This might include deciding naming conventions for CSS, structuring of Sass partials, and what PostCSS plugins are required.
The Chisel
Where the Hammer is concerned with the grand scope of frontend features, the overall form and structure, the Chisel is focused on the minutiae, the detailed look and feel. The Chisel owns execution on the enhanced experience. This role creates the animations, gets font size and spacing just right, and creates new styles outside the initial design composites. The Chisel may help out the Hammer in creating new components as necessary.
Additionally, the Chisel is a perceived performance advocate, checking how fast the site feels and reporting performance issues to the team. There is also an expectation that the Chisel handles optimizing raster images and SVGs. When working on animation, the Chisel ensures that perceived performance is maintained with proper easing and timing.
In some cases, the Chisel may also be the design lead for a project. This means they own the full design stack, from conception down to coding the final product. While this may be highly unappealing to some, take my word for it: it invigorates others.
Collaboration
The way these two roles work together is critical to their success. For starters, a these two roles should be filled by at least two people, one as the Hammer and the as other the Chisel. When the same person is put into the position of filling both roles, the Chisel role is more likely to suffer, as projects tend to push for quick progress over refinement. The most valuable advantage of these individual roles is the focus on refinement. At Sparkbox, most of our projects are several-month to several-year engagements. Of these two roles, the Hammer is most likely to remain on a singular project during that time. The Chisel, in contrast, is more likely to jump around to multiple projects, refining and moving on. For this reason, we hope to primarily have our Developers fill the Hammer role and our Frontend Designers fill the Chisel role.
We see the Hammer and Chisel working together as improvising partners, finding the right workflow harmony for that project. As problems and concerns arise, the Hammer and Chisel should come together to find a solution. The Hammer and Chisel should be reviewing each other’s work throughout the project, in particular the HTML and CSS that each writes. Ideally, the Hammer should be writing the bulk of the HTML and some CSS of a component, then handing it over to the Chisel to adjust and refine the HTML and CSS to its proper aesthetics.
Chipping Away
Every project is different, and the processes we use need to be malleable. Right now, we are rolling this out on just a few initial projects to see how this concept plays out. These roles and duties are expected to change as time exposes the strengths and flaws of this idea. Our mission remains to make a better web, and we see this a great avenue forward.
At Sparkbox, we recognize that every project is different, so we need to leave room for flexibility in our processes. This has allowed us to explore the Hammer and Chisel concept. And as we continue to explore how design intersects with development, we think this approach has great promise to contribute to our pursuit of building better websites.
