Designing for the web can be weird. If you’re a web designer, you know what I’m talking about. Compared to designing for print, there is an array of different constraints to be aware of when tackling the web, such as performance, accessibility, screen size, different browsers, and different devices. On the web, almost nothing is certain.
How can we make sure the final site maintains the vision of the design concept? We have been experimenting with new project roles at Sparkbox that appear to help solve the problem of maintaining design vision. This article focuses on the who, how, and why of these new roles, and examples of the value they provided on a recent project.
It’s important to note that when we say “design vision” that doesn’t mean there’s an expectation for the final site to look exactly the same as the initial design. Rather, the final site should have the same overall look and feel. With the fluid nature of the web, designers and developers have almost come to expect the completed site to look at least somewhat different than the initial concept. Our new project roles help ensure that the design vision is maintained as the site is built.
We highly value beautiful design and quality code, and seek to bring the two related fields of design and development closer together. We do this through valuing empathy, encouraging designer/developer pairing, and—most recently—through taking a closer look at our project roles.
Redefining Roles
At Sparkbox we recognized that not everyone fits nicely into the mold of designer or developer, but rather, there is a spectrum between the two that creates a gray area where the two fields overlap. Those at Sparkbox who have skills in the gray area of design and development have replaced their title of Developer with Frontend Designer.
When the title change was made, we also recognized new project roles emerging which helped to cement the responsibilities of the Frontend Designers, account for different, individual strengths within the group, and explain how their roles could change from project to project. We call these roles the hammer and chisel.
(Philip Zastrow wrote a fantastic article about this concept and you should read it before continuing.)
The Hammer
In summary, the hammer is a frontend designer or developer who is responsible for “hammering” out the frontend components for a project. This usually means writing most of the HTML and enough CSS to get components working. They also might be involved in determining the naming conventions and other overarching pieces of the frontend build.
The Chisel
Here’s where we start to see how these roles help solve design vision discontinuity. The chisel follows the work of the hammer. It’s the chisel’s job to ensure that the small, yet important, design details are not missed while the project is being built. For example, line length, font size, breakpoints, spacing, and color are all details the chisel is responsible for. The chisel can also help ensure that the original design vision is maintained throughout development—especially when unforeseen changes occur, such as the need for a new page design. The goal is to hammer and chisel—build a foundation and refine—throughout the life of a project to avoid only building a foundation and never being able to refine due to budget or timeline constraints.
Think of it like a sculptor who works only on small sections at a time. Without the chisel, the sculpture would not be smooth and polished. Without the hammer, the chisel would take too long and the basic shape would not be correct.
All Together Now
After using these roles on a few projects, we are already seeing the advantages of working this way and, in particular, how it helps us maintain design vision. It can be particularly valuable if the original designer on the project is also fulfilling the role of chisel.
I personally had this opportunity on a recent project where I started with a static design in Sketch and then helped build the website by writing code and fulfilling the role of chisel. This gave me the opportunity to cultivate the site design from start to finish.
If you think about it, designing a site in Sketch or Photoshop is almost like sketching a painting on paper before working on the canvas. You’re designing, just not in the final medium. You cannot know exactly how things will look or work once the site is built. Therefore, it’s all the more important that a designer be involved throughout the development process to refine and improve the site design as it is built.
What’s The Value?
I’m glad you asked.
Time Saved
Picture this: you’re the designer on a project without the hammer and chisel roles. The design needs to be polished and refined at multiple screen sizes before being sent to your developers, so you spend hours stressing over the details to get everything just right. Then, after development starts, you learn that the client wants a different typeface. You panic. Now you have to re-do all of the static files because the typeface is larger and will not fit properly into your designs. There must be a better way!
With a designer involved as a chisel, the static designs do not need to be as polished or complete. They merely serve as a way to quickly visualize design ideas (including color, typography, and layout) and as a tool to communicate the design vision and aid developers as they establish the site structure. This allows for more time to be spent refining design details in the code, which is one step closer to the final product. A chisel can test, visualize, and solve design problems in the code as opposed to a static design file. This reduces repeat work in the static files and means you only have to refine the design once, in the browser, which saves time and money.
Because the chisel works directly in the code, he/she is familiar with how the project is structured and can build entirely new components by adjusting the styles of existing code. This happened recently while we were working to redesign a website for Shoes for Crews, a leader in slip-resistant footwear. As the chisel, I focused on maintaining the design vision while refining the hammer’s work. Toward the end of the project, we were tasked to build a list of product features, and I noticed that we could utilize code from a previously developed list of product features to make this new list. The basic framework was already there so we didn’t need to start from scratch. By writing new styles and refining the design in the browser, we were able to achieve a drastically different look in a relatively short amount of time.
Attention to Detail
The chisel minds the details and helps maintain design vision to ensure that the final site embodies the direction laid out in the original static comps. This makes designers happy because their vision will actually make it out the door and not get cut with budget constraints. And it makes clients happy because they receive a refined, well-designed product.
Without the hammer and chisel roles, many projects can fall victim to the opposite: wasted time in static files and developers who are left to make design decisions for anything that is not defined in the design files (other screen sizes, new pages or components that come up later in the project, etc).
Clarity for the Unicorn Roles
The hammer and chisel roles help to define the so-called unicorns of the industry, those who have strong hybrid design and development skills. Some are more development focused; others, like myself, prefer to design and build smaller components; and some don’t want to ever write code. At Sparkbox, all of the Frontend Designers have different strengths and these roles allow us to use our strengths best on each project.
Empathy Building
Here at Sparkbox, empathy is one of our core values. The hammer and chisel model helps us build empathy for other aspects of the web development process.
For example, I am a Frontend Designer who knows more about design than development but wants to learn and grow my frontend development skills. The hammer and chisel model allows me to write code as a designer. Not only do I come away with more confident development skills, but I also learn more about how sites are built on a more granular level which will help me make better design decisions on the current project and in the future.
Can This Work for Me?
If you are a designer who is frustrated by how projects look after development, I would encourage you to advocate for more involvement during development. If you are not comfortable with code, that’s okay, you do not need to be a master. In fact, I would encourage you to just learn the basics of HTML and CSS to the point that you are comfortable with making small adjustments that will increase the visual appeal and improve a site’s design. For a lot of folks, there’s satisfaction when you roll up your sleeves and help build the site that you designed. For a print designer, it’s like holding a printed piece that you personally labored over through the entire printing process from proofing to press checks.
Where’s the catch? Using these roles does mean that the designer should have some knowledge of HTML and CSS. At least enough to get started with the basics and a desire to learn more through being exposed to code in real projects and more collaboration or pairing with developers. This does not mean that designers need to be master developers. The bulk of the development work should be left to the experts, but, chisels can write different levels of code depending on their experience. Some hybrid designers/developers find it very satisfying to be heavily involved in both design and development. The hammer and chisel roles allow them to thrive.
Every company, team, and organization is different, therefore this hammer and chisel model will look different depending on the environment you are in. Maybe your solution for maintaining design vision will simply be to advocate for more design refinement from designer/developer review pairings throughout development as opposed to leaving it for the end. For us at Sparkbox, the hammer and chisel model works. It truly does help solve the issue of maintaining design vision, but we will always be refining the way we work and having conversations about how we can improve.
