Over the past year, we’ve been scaling our design capabilities at Sparkbox and writing about our efforts and what we’ve learned. Some things we tried worked and some didn’t. While there are many more experiments to try and many more lessons to be learned, this post serves as a wrap-up of what we’ve done and where we plan to go.
What We’ve Done
Created a Team of Designers
It became clear that if we wanted to scale design, we needed a team of like-minded designers who would bring their own unique skills and inspire one another, not to mention increase our capacity to do design work. While we’re careful about not siloing any part of what we do, scaling design meant creating a team of “frontend designers,”a title we chose because this team creates both the project’s visual language (usually in Sketch) and has a role in engineering that vision. We created this team with a few individuals who were doing mostly frontend development and also had exceptional design skills and vision.
So far this team of “frontend designers” has worked well. The title and role changes have been good for Sparkbox’s design-scaling initiative in many ways. First, this shift has expanded our capabilities and prevented our design from becoming stagnant. Second, it’s given designers the ability to more easily carry through their vision in how they code the frontend templates, which affords for more design polish as development progresses.
Ran a Frontend Design Apprenticeship
One of the main challenges for scaling design—for any shop or agency—is finding good talent. Running a Frontend Design Apprenticeship is our way of bringing up budding talent and supporting Sparkbox’s mission of education. We believe that education helps the teacher and the learner grow. Our first Frontend Apprenticeship was a success—we had two great participants, one whom we hired, and we’re running another apprenticeship this summer.
Held Design Check-In Meetings
As the design team took shape and scaled, we needed to touch base regularly. So we started meeting bi-weekly, discussing our strategic design process and sharing project work. In conceptualizing these meetings, I imagined they would serve in part as design reviews, but we didn’t always have new concepts to show. When we didn’t have new project work to review, we instead shared our side projects and learnings, which became a great way to share knowledge, inspire one another, and, ultimately, to make one another better in the newly defined roles. We’ve since added weekly check-ins to touch base around forecasted projects and discuss any potential challenges within eyesight.
Initiated Formal Design Reviews
Design reviews are a scheduled time when all frontend designers and project team members can give valuable feedback on design concepts. It’s a great way to get more—and more varied—eyes on a project and to ensure that what we plan to present to the client meets the project goals and is in scope. As we scale design at Sparkbox, the design review conversations serve many purposes. They improve our design concepts by gathering feedback from others. They allow our frontend design team to practice presenting design concepts before presenting to clients. And the team gets to learn from others’ experiences to receive and process constructive criticism. It’s a win for everyone.
Although just recently implemented, design reviews now take place when needed, typically a few days before we show a client the design work for the first time. We’re still experimenting with format, length, and who participates, as we’ve found that we need more than an hour for the designer to state project goals, explain how the design concept helps meet those goals, and receive feedback from the team. In the future, we’ll be experimenting with the duration of the meeting and incorporating other project team members as well.
Proved the Hammer and Chisel Concept
The Hammer and Chisel was a simple concept that came out of a frontend design team exercise we did more than a year ago. Essentially, it means that as development begins, everyone plays a role. 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. It doesn’t always play out exactly this way, but the end goal is to incorporate a higher level of design polish as the project progresses to ensure design remains intact and cohesive. It also gives us the possibility to find opportunities in the details. We’ve seen great value with this approach and will continue to implement it.
Scaling design is a full-team effort. It has happened with the cooperation, collaboration, and involvement of all kinds of supporting team members. It has been exciting and encouraging to see all members of project teams embrace our design-scaling efforts. This has helped us determine what’s working, what’s not, and what we can iterate on.
As an example of how scaling design has been embraced, one of our project managers suggested dedicating meetings throughout a project to prioritizing design refinements, such as animations and interactions, so the most vital ones don’t get cut or disappear at a project’s end. Periodic design “gut checks” like this create more intentional products and remind the team where we can deliver the most value from a design standpoint.
We’ve also discovered the value of non-designers seeing the in-progress work we’re doing. At our company-wide project demos every Friday, each project team shares their current work, giving the whole team an opportunity to provide feedback and learn from one another. For the design team, this is an opportunity to share our thought process and reasoning behind the designs we’re doing, and to invite strategic insight from non-designers to make sure we’re on the right path toward creating a web built—and designed—right.
There’s Still Much To Do
Scaling design isn’t easy and it doesn’t happen overnight. We’ve taken the approach of experimenting and seeing what works, what doesn’t, and making adjustments. A different approach may work better for you. A design culture is a living breathing thing that needs constant attention and nourishment, as well as collaboration from the entire team.