Developing a custom content management solution allows you to unleash your creativity without the limitations of pre-fab, off-the-shelf software that can hem you in (or, at the very least, present obstacles that must be designed around). Teaming up with a partner that specializes in building such systems can truly revolutionize your organization, and these services often come hand-in-hand with front-end design to complement the back end.
But what happens if you already have a solid working relationship with your own design team?
While we talk a lot about the advantages of developing custom CMS solutions on this blog, that’s not the only thing we do. We also take a lot of pride in the creativity of our experienced design team.
All the same, we have often partnered with external design agencies to develop custom CMS solutions for mutual clients. This is often a good choice when the existing design team already owns the branding and wants to maintain consistency with existing products.
These projects can be successful, but there are some potential pitfalls. We wanted to share some tips based on our experiences with such projects to help you plan for the future of your next CMS development or website rebuild project.
Splitting a web project between separate design and development teams often means that one of those agencies is losing a piece of the project—and the profit that comes with it. When a development agency is brought in to lend their expertise to a project, they may be partially replacing the design agency that originally built the site on, say, WordPress. In some cases, a (full-service) development agency may have the front-end UI for their work handed off to an outside design team.
We’ve been on both sides of the equation, and it’s natural to be disappointed and potentially worried about losing the rest of the business.
We recently worked on a project where we were brought in to build a more robust CMS for an existing site and mobile app. The freelance designer who was responsible for building out the successful proof of concept was staying on to redesign the site, but wasn’t happy about giving up control. In the end, he quit the project on short notice, creating significant delays.
It’s not possible to prevent this entirely; sometimes, a successful project will put one party’s continued role on the site in jeopardy. But as the client, you can take steps to make all parties invested in the project’s success and to incentivize cooperation to that end.
This can also pay huge dividends in exposing both teams to best practices and new ways of doing things. A design team might have suggestions for improving a CMS interface and a development agency may critique a design from the perspective of performance or ease of maintenance.
Maintaining a focus on producing the best possible project outcome can produce win-win-win situations, but only if such critiques are presented as such. Agencies that are too proud to take constructive criticism from their project partners can harm this dynamic, as can partners who use such critiques as an opportunity to undermine the other.
In any project that includes a design component, timelines can be hard to predict. When designs require client review, feedback, and approval, there are often development tasks that cannot be started until that takes place. So unless clients can be extremely disciplined in their turnaround time, projects must include significant buffers to allow for the client’s review processes.
That problem can be compounded when design and development are handled by separate teams. The development team has one more part of the timing that is out of their control: exactly when designs will be completed. For the design team, they may not be aware of the consequences of delays (including those that come about for legitimate reasons such as a client’s change of direction).
This can be mitigated by over-communication among all parties. Design teams should inform the development team of any delays as soon as possible. Sharing design drafts with the development team in parallel with the client can also help them identify any potential impacts on the schedule if additional complexity results from a design.
At NP Group, the front-end development of a website’s user interface and public-facing pages falls under the responsibility of our design team. All of our designers have experience “slicing” HTML from design files and provide direction and feedback to our full-time front-end developers. In fact, the entire front-end development team reports to our art director, Sebastien.
Of course, some agencies structure their teams differently. In past collaborative projects with outside design agencies, we have received PSD mockups and coded the entire front-end. In others, we have designed and coded a front-end UI to be integrated with a back-end (CMS) system coded by another development team.
The lines between design and development are not as hard and fast as they may seem. When scoping out a project, it’s important to clarify where one team’s responsibilities end and where the other’s begins. Failing to do so can have a big impact on your timeline and budget, and may even result in you paying to have the same work done twice.
With custom development, almost anything is possible, but some features can take more resources to build out than others. It’s important for the development team to clearly communicate any technical restrictions (or scope restrictions) for front-end functionality as well as any scoped CMS functionality that must be included within the design.
Without such guidance, projects are prone to a number of potential costly and time-consuming problems:
- Design teams may leave out features, requiring redesigns that can impact budget and timeline;
- Designers might add in unsupported or unscoped features, requiring redesigns, additional development, and/or billable change requests.
It is equally important for designers to provide guidance to developers on how their designs should translate into a website or app. Especially with “flat” mockup designs, effects, animations, and transitions all must be well documented.
Ideally, designers can even provide documentation of how they anticipate the designed templates to function, allowing developers to work in parallel and contributing to shorter and more streamlined project timelines.
In some ways, this item sums up all of our other tips. The more cooks in the kitchen, the more opportunities there are for things to go wrong.
Having a strong communication plan can help keep those to a minimum. Some questions to consider are:
- Who is the main point of contact for each team?
- What communications should include both the design and development teams?
- What are the policies for communicating changes?
- Who needs to approve (or be consulted on) designs, development strategies, and changes?
Obviously, it’s impossible to foresee all the potential problems that could arise when redesigning a website or developing a new CMS platform. Such predictions can elude even the most experienced project managers. This is especially true when separate design and development agencies are involved, adding differing methodologies and personalities into the mix.
That being said, knowing where the potential pitfalls lie ahead of time can help you navigate around them, which can eliminate the most predictable issues. Understanding that none of this is personal, you can mitigate any potential tension and be the one to clear out any communication roadblocks that can slow your project down.