A few years ago, we started writing about an experiment called “The Hammer and The Chisel” that we were trying on projects. It has become something we’ve talked and written a lot about, and others have too. In this post, we’ll share how the concept has evolved and suggest some things to watch out for if you choose to employ the Hammer and Chisel concept.
Before that though, here’s a quick definition of what Hammer and Chisel is (taken from this wrap-up post from our Designing Web Design Culture series):
“The developer cranking out raw code with minimal styling is the ‘hammer.’ Then, the ‘chisel’ (many times, the visual concept’s designer) takes another pass, polishing styling and interactions...the end goal is to incorporate a higher level of design polish as the project progresses to ensure the design remains intact and cohesive.”
As we’ve employed this technique on projects, we’ve continued to learn where this approach works and where it can fall apart.
After starting Hammer and Chisel, our team continued to grow, and we sensed some frustration and heard questions from team members on what this concept meant for their roles on projects. We recently held a team roundtable discussion around what had been working and what improvements we could make. Here’s what came out of that discussion.
Roles vs. Tasks
Before this discussion, some team members had felt boxed-in, forbidden to touch certain hammer or chisel tasks based on their job titles. This hadn’t been the original intent at all—we had wanted a developer with a background or comfort level doing design work to be able to do polish tasks they felt comfortable with. Discussing this surfaced the idea that the Hammer and Chisel concept shouldn’t be role-based—meaning team members shouldn’t be assigned to EITHER do the hammering or chiseling. Rather, the team should evaluate the skills, background, and comfort level of team members from the beginning of a project and develop a task-based approach.
Each of our project teams has a different makeup based on the skills of the individuals. Now teams can take advantage of these differing skillsets. A recent example of this is an internal intranet we designed for a returning client. The project team was made up of a frontend designer and two developers, each with a high comfort level with design/polish work. While our Frontend Designer, Andrew, led the design effort, the team was equipped with the knowledge that anyone could pick up polish tasks and run with them.
Surfacing Secondary Tasks
Another issue we had encountered was how to surface our team’s core skills (HTML/CSS, Design, UX, UI, Ruby, Javascript, etc.) prior to every project. We discussed how we could document team member’s skills and share them with everyone on the team. What about secondary skills like data visualization, game development, or music production? All of these abilities could come in handy for projects in corresponding industries or for placing team members on projects.
So, we created a Google Survey to collect this data and share it with the team. Now, in addition to a team conversation at the beginning of a project, individuals’ skills can be accessed anytime.
Leveling Up
Another thing the team had noticed about the Hammer and Chisel approach was that we had lost some of the “leveling up” of team members. By that, I mean pairing on tasks, where a designer and developer may spend time pairing on a module they’re building. The designer comes away seeing how the module is built, and the developer comes away with some learned design principles.
We decided to be vocal about when to pair during a project. Certainly budget and timeframe are factors, but if a developer wants to pair to learn how to make a module fit with the established visual language, we want to support it. That’s valuable learning time.
Big Takeaways
You may have noticed some themes in our findings: communication and flexibility. Good communication at the beginning and during projects is key to making sure everyone has the same expectations and that the Hammer and Chisel concept is serving its purpose.
This is what our definition of the Hammer and Chisel has evolved to be:
Hammer tasks consist of cranking out raw code with minimal styling, and chisel tasks consist of the polishing of styling and interactions. The end goal is to incorporate a higher level of design polish as the project progresses to ensure the design remains intact and cohesive.
We’ve learned a lot from implementing our Hammer and Chisel process. We’ve found that having a team meeting at the beginning of a project can help to get everyone on the same page, which also enables teams to be flexible in how they work. And surfacing the team’s skills will help everyone know each person’s comfort level and even help with resourcing projects. We hope these findings are helpful to your team as you seek to improve your design and development processes and support your designers and developers working together.
