Alley works with some of the largest and most prestigious nonprofit publishers in the world, including prominent research organizations, foundations, academic institutions, and government agencies. In a recent discussion among leaders in the sector, a communications executive raised challenges that her organization had in maintaining a poorly coded website, giving her pause on using a web agency at all for their next project.
“[We] are frustrated over the mess of code created by the agency who did our last site design… What suggestions do you have for managing the project to avoid the problems of the past?”
At Alley, we encounter this situation fairly often, usually with remorseful buyers who need code remediation, which can quickly turn into a partial or complete rewrite.
Here were my recommendations for selecting a quality-obsessed web partner and then managing the redesign:
Selection Phase
1. Ask for sample projects and review them for code quality, not just visual quality. i.e., have your front-end developer look at the samples. (Some code quality issues can be discerned from looking at the public code.) Run audits for accessibility and page performance on the sample sites. There are free utilities for this.
2. If there is a Request for Proposals (RFP), or in the proposal process, make sure that it explicitly probes for information on the firm’s clear testing and quality assurance process, specifically around code, not visual design. How experienced are they? Do they have chops on complex web engineering projects, not just visual aesthetics? What tools do they use? Do they do rigorous internal code review? Do they have a multi-environment/repository framework in place? Do they employ unit tests and check for regressions before deploying code? You may not feel like asking all of these questions, but some flavor of them will give you an idea if the firm is a solid choice for engineering and a good choice for design. These are two different disciplines.
3. Take a quick peek at their staff list of engineers. Do they have any? If so, see if they have any public code repositories (GitHub, Bitbucket, etc.) that you can look at to get an idea of their engineering abilities and code quality.
4. Do the firms do their own engineering or do they use sub-contractors or freelancers? This can be fine sometimes, but it might give you some insight into how seriously they take the engineering part of a web project.
5. Ask for references. Ask those past customers specifically about code quality and maintainability. After all, most of a website’s life takes place after it’s launched, not in the process of getting to launch.
Management Phase
1. Clearly communicate up front and in the statement of work that you, the customer, will manage the code — not just use the content management system (CMS) — after the redevelopment. Require that things are documented and commented (in the code) enough for your own people to manage it. Your organization may have staff turnover: you don’t want all institutional knowledge to leave with them and the web firm.
2. Follow along. Review the work as it’s being done. Do your own quality assurance. The “acceptance criteria” on a piece of work are for you. If they aren’t met, it’s not done.
3. Ask for a web style guide as a deliverable if the hangup in the past has been inconsistent application of visual treatments. This will ensure there is one source of truth, and it directly feeds the website. It’s also handy for editors and staff designers.
4. Be sure that the work is warrantied. Write it into the contract. If you notice any performance issues, bugs, or irregular code after the work is allegedly “done,” you’ll have a way to make sure it’s addressed at no additional cost to you.
5. Get training from the firm for your developer(s) and for your editorial and communications staff so everyone knows how it’s supposed to work and how to use it. Sometimes this process can turn into another opportunity for quality assurance.
Websites can be hard! This upfront commitment in selection and management can help make them successful.
Be sure to check out the next part of this series – Five More Things: Stakeholder Management Tips to Avoid a Messy Codebase by Rebecca Viser – to learn more about how to start tackling your next web project.