What if there was a designer at the project kickoff meeting? What if that designer was able to provide time-saving and value-adding ideas throughout the project? What if that designer wrote some frontend code to help polish the product and reduce the time spent pairing with a developer? At Sparkbox, we’ve pushed for the last several years to do just that, including at least one designer on most projects from start to finish, and we’ve found it to be very valuable. In this article, I’ll explain why we’ve made this shift and how it helps us better serve our clients.
But Why?
The problem we were trying to solve by bringing in a designer at the beginning was the disconnect that can happen in the typical flow of a web project. It’s not uncommon to see a waterfall process like this:
The designer receives a project brief.
The designer starts work on the interface design or maybe starts with a wireframe.
The completed designs are handed off to a developer who interprets the designer’s work.
The developer communicates with the designer when details about the design are unclear.
The code ships without much input from the designer.
While that process might work fine for some projects, we can do better. There must be a better way to ensure the final product looks and functions the way the designer intended. For example, what happens when the client wants to add another page? Or, how do you handle those pesky, awkward screen sizes? By having a designer on board from start to finish, we’ve been able to improve our workflow and answer questions like these.
What We’ve Found
At Sparkbox we have been utilizing a designer from the start to end of most projects, and have found it to be valuable for many reasons.
It Saves Time
If a designer is involved from the beginning, static designs do not need to be as fleshed out and communication can happen faster. A designer can iterate and expand on the initial design vision while the project is being built. The amount of pre-code design work that we do at Sparkbox depends on the team and the client. If the client is more visual, they might want to see more before approving screens or pages for development. If the team is comfortable designing in the browser, then we move faster through static designs in order to start writing production code as soon as possible, to which the designer can contribute if they are comfortable writing code.
At Sparkbox, our designers—we call them Frontend Designers—all write some level of code, which allows us to be more closely involved in projects during development. Each Frontend Designer has a different skillset; therefore, some take their code work further than others. I personally hone in on HTML and CSS and leave the JS and backend code to the full-stack experts.
As we explored having designers write frontend code, we needed a name to describe their roles on projects. We boiled down everything to the analogy of a sculptor’s hammer and chisel. This is something we’ve written about before and looked at how it can be helpful in maintaining design vision. In a general sense, a “hammer” can be a developer or designer who has a deep knowledge of frontend code. It’s their job to hammer the rough shape of the website, component by component. The “chisel,” a designer who codes, then goes through and cleans up the rough components and refines the interface to match the design vision. This designer should have a strong knowledge of design and CSS. While not every designer can code, we’ve found this approach to be very valuable for saving time that would have otherwise been spent pairing or endlessly changing design comps.
It Results in More Cohesive and Polished Designs
The designer owns the look and feel of the product, which means they pay attention to the details. While the product is being built, the designer can polish details that developers without design expertise might miss. Things like animation, typography, and spacing can be refined as the project grows, not to mention addressing the layout gotchas that can occur at different screen sizes. These design refinements tend to get cut as projects come to a close and budgets are tight, but by keeping a designer on a team throughout the entire project, we’ve been able to ship more polished work that follows the original design vision.
It Allows the Designer to Do Their Best Work
The designer is part of the team from start to finish, so they know the ins-and-outs of the project and the client’s needs. Therefore, they can make more educated decisions and recommend solutions to create a better product and save time. By knowing more about the project as a whole, designers can do their jobs better.
In early meetings with a recent client about a redesign of an existing microsite, we were able to recognize the need for a higher-fidelity wireframe than we would typically use, in order to communicate the different ways to organize and layout the site’s content. This higher-fidelity prototype allowed us to get buy-in from the client on a unique page structure that truly lets the content shine. Because of this, we were able to move the project along faster and, since our designers write code, the design was easier to develop.
We had a similar experience working with data scientists at another client to build a portal for sales teams. In the kickoff meeting we were able to help everyone get on the same page for the look and functionality of a key component. Because we were involved from the beginning, we were able to take the client’s idea and quickly conceptualize a solution that would elegantly and clearly display the correct information, and be technically feasible.
It Helps Us Handle Project Changes
Changes happen. The client might want to add a new page or re-work a component to save development time. A designer can quickly provide an updated design or just make the changes themselves in code. Often, this saves time by allowing the designer to speak directly with the client or developers to reach a better solution on the spot.
With the project mentioned above, as we came across screens that did not have static designs, I was able to quickly develop the pages themselves, as opposed to building out a full, static design and handing it off to a developer. This saved an entire step in the process and allowed us to focus on delivering a complete, well-designed product.
When Is Including the Designer From Start to Finish Valuable?
Admittedly, we are still iterating on this idea at Sparkbox to ensure we have the best strategy in place for future projects. In our experience, this method would not work well on every project, but it is most valuable if you have a design-heavy project such as building or redesigning a site. These projects tend to have specific time or budget constraints that drive us to a set launch date.
Try out this method of including a designer in the entire project for yourself! Take the basic idea of including a designer from project start to finish and mold it to fit your organization’s workflow. Don’t be surprised if you see more polished products delivered in a shorter time period.
Resources:
Meagan Fisher and Andrew Couldwell talked about this idea of bridging design and development at a recent Sparkbox Maker Series event.
Learn more about our paid full-stack and frontend apprenticeships.
