Sparkboxers love working with clients and collaboratively adding value to client businesses together. In seeking to find balance, we’re always working to adjust our process to get things right. Something I noticed about many projects I led a few years ago is that the collaborative pendulum had swung so far to “collaboration” that I was almost just having clients dictate exactly what they wanted, especially when it came to design. Trying to be that false version of “collaborative” did a disservice to both our talented designers and our loyal clients. I wanted to make sure our design team felt fully supported and trusted so that they could do what they do best—create ridiculously impressive designs. These are the techniques I’ve found as a project manager to do just that.
Setting Up Design Strategy
Understand the Project and Set Goals
The Sparkbox team works in service to the goal of a web built right, and we believe achieving that on individual projects starts with a plan to achieve business and user needs. We don’t just have designers who know how to make an amazing looking site, we have designers who understand that design is meant to be evocative in order to be effective. No two sites should ever be the same, because they are meant to achieve different goals and create a different impression. We want users to feel our clients’ sites. We want users to be moved to act. The first key to being a more supportive project manager to designers has been to lean on my penchant for strategic, logical, goals-focused decisions.
Typically, Sparkbox projects start with intentional discoveries that culminate in solid documentation that allows us to start building the right things right away. Project managers lead these discoveries and the documentation effort. By interviewing stakeholders, reviewing client materials and analytics, and directing in-person strategy meetings, project managers help form a stronger and stronger opinion about what the build project needs to be. One key document that has helped us deliver better designs are Project Briefs. The Project Brief is a couple-page document that covers project background, goals/metrics, and a few other items that vary from project to project.
The discovery process—and resulting documentation—makes for a powerful, synchronized Sparkbox and client team. By having clear, agreed upon high-level goals, our designers can strategically explain how they treated a primary call to action to help drive users to the right place, for example. And our entire team can be empathetic and make better project decisions by understanding the overall context the project is happening in. It’s a great first step toward better design.
Let’s pretend Sparkbox has been asked to work on a new website for Electric City. Here’s how part of the Project Brief might read:
Based on this Project Brief, our team understands that Electric City needs to step away from its typical conservative design. This means the existing brand needs reimagined and pushed in a new direction that shouldn’t be held back by what exists today. This is exciting, but will also prove a challenge as we work through design.
Goals help us speak the same strategic language as our clients. To fully express design takes more. Our Experience Strategy documents cover high-level direction for content, user experience, and design. One key piece of the Experience Strategy is branding language that describes how users should feel when they experience the new site. This language acts as a visual vocabulary for our design efforts.
Many clients have brand guidelines, but it’s common for those to be out-of-date or under development during redesign efforts. And, let’s be honest, there’s no better way to truly understand the guidelines than to poke and prod and ask questions. So we find that a common, simple exercise gets us on the right track. As with any good exercise, the value is in the discussion. Listening closely to the way the client team describes the brand and taking good notes is paramount. Just as important is to note where strong agreement and disagreement happens, and to ask follow-up questions where discord is present. This is a great opportunity for the whole team to get involved, but the designer and project manager should be leading the charge.
Electric City’s visual vocabulary might be something like this…
By gathering a visual vocabulary—again, a collaborative endeavor—we arm our designers with the language to explain our strategic design recommendations in our customer’s words. By agreeing on these items upfront, our clients and designers have strong connections they can make while discussing design. The more we can help clients focus on those strategies and what the site needs to say and how it should make users feel, the more our designers are able to express that and have strategic discussions about those decisions with our clients.
Now, in a future presentation, the designer could say…
Carrying Out Design Strategy
The strategic techniques above are the biggest wins I’ve found as a project manager to support design getting off in the right direction. However, a project manager’s support doesn’t stop there; there are still ways project managers can be helpful throughout the creation of designs.
Push Forward on Designers
Scheduled reviews and clear expectations for timing tend to be critical for designers. It is incredibly hard to claim design is ready for the client—to feel confident. At Sparkbox, we aim to support designers by pushing forward with timelines that allow for intentional team reviews with enough lead time for feedback to help shape decisions. These team reviews include UXers, content strategists, and developers to get well-rounded collaborative feedback.
As the project manager, I try to semi-roleplay with designers during reviews and think what questions the client will have. It’s always nice to anticipate potential areas of conflict to either resolve them or be prepared to offer good rationale. I try to make these internal reviews be as close to the client conversation as possible to allow the designer to see how to adjust and where to add extra examples or explanation. For the Electric City site, our initial review might point out that our use of colors is far from conservative, and we’ll need good rationale to explain why we picked them. It might also show that the reliance on animations and interactions is so central to the site that we need to do something special to highlight (and feature those) in an effective way during the presentation. The designer can use a simple prototype or share example animations alongside our design to help us express this well for the client. And the developer can help make those happen and vet how realistic those animations and interactions will be.
Push Forward with the Client
We believe Sparkbox clients find the best value when they surrender their initial expectations and are willing to go on a journey with us to plan and execute their sites together. With good designers and well-thought out designs, we usually have great conversations with our clients about the design that is grounded in what the site needs to be, not what a particular person on the client’s team does or doesn’t like personally. This intentional framing means we are able to listen to our clients’ feedback and ask thoughtful questions to gain a better understanding and evolve the design together.
With good designers and well-thought out designs, we usually have great conversations with our clients about the design that is grounded in what the site needs to be, not what a particular person on the client’s team does or doesn’t like personally.
However, there are times that our clients ask us to really push them out of their individual comfort zone as a company. In these situations, we tend to find a bit more resistance to our design work, even though it’s what the client—and we—believe they need. For Electric City, being a conservative company with historically conservative designs and intentionally seeking a sleek, progressive design heavily increases the likelihood that no matter how amazing and well-presented the design is, it will be difficult for the client to accept right away.
These scenarios—where our client is really pushing in a different direction for sound reasons—tend to require extra project management support. As the project manager, by the time we get to design, I’ve worked through lots of questions and concerns with the client. I almost always have had more opportunities to build trust with the client than the designer has. I’ve learned that in addition to arming our designers with the tools they need to effectively communicate the validity of our designs, I also need to be willing to stick my neck out to support those well-thought-out designs. It can be as simple as asking the client to let the designer get all the way through the design review before asking questions. I can also show my design support by coming to meetings armed with research that supports our recommendations. No matter what it looks like, the most important part is that I help the designer remind the client that this design is intentional and adheres to what we all agreed was right during planning. A healthy dose of support goes a long way.
I also need to be willing to stick my neck out to support those well-thought-out designs.
When considering design feedback from our clients, our team needs to remain open to change, but not too quick to change. We need to continue to peel away at why our clients are reacting how they are reacting and help them discover why they are reacting that way. Then we need to give some time for everyone to think and come back ready to make a plan to move forward.
Of course, we have to be willing to adjust, and it wouldn’t be real collaboration without that. Working with people requires us to be inquisitive. We have to ask a lot of questions every step of the way to develop useful understandings, goals, and shared language. And then we have to keep asking a lot of questions to encourage designers and clients to come to the right decisions. It takes more than talented designers to make an effectively evocative site. We all play our part.