When your company’s website is working well, it’s a conversion machine turning interested visitors into free-spending and viable prospects. The birds are singing and you look like a genius.
But how often does this really happen?
We all know that friction points occur in the getting-to-market web development process. Some of the hassle is a natural result of coding resources doing things in new and innovative ways. But much of it has to do with miscommunication, information gaps, and lack of repetitive, mutually beneficial processes between marketers and developers.
While neither side is ever going to speak the other’s language with 100% alignment and fluency, there is a way to help minimize the pain points and maximize useful and productive collaboration—and that’s in having a transparent web development team process for all sides to see into the fishbowl.
Here’s why you need this, and how to build it. First, let’s look at things from the dev side of the house.
What your developers are thinking when you ask for something
Marketers seem to only interact with web developers when they need web work done. They wonder why the project they asked for “isn’t done yet” and question if the dev team are being team players.
Designers and developers get anxiety when the same problems reoccur. This is also the source of the crickets Marketing may be hearing—developers glued to their screens trying to fix the problem (or come up with some solution, quick fix or long term) rather than show up empty handed. Here’s where the disconnects happen.
Disconnect Scenario #1
When marketers say “We need this live, stat!” Developers wish you knew:
- Asking for “just get it done and up” means you’ll likely get quick-fix coding layered on top of existing code, which will eventually “weigh” the site down, make it run less efficiently, and increase the likelihood of something going wrong.
- When there’s little to no communication, web developers don’t know who the stakeholders are, what the project ideally should look like via user interface and visual designs–leaving them with lack of clarity on what to build.
- The initial vision for the site gets lost in a long game of telephone.
Disconnect Scenario #2
When marketers say: “What happened to [insert feature name here]?” Developers wish you knew:
- They don’t know either! Without a process for documented history and version-controlled code, there’s no easy way to see who, what, why or when.
- One general test login that everyone uses means no one knows who made a particular change or why it was made. Having user specific log-ins can avoid this.
Disconnect Scenario #3
When marketers say: “Something broke. I’m not sure what happened.” Developers wish you knew:
- Marketers want to add third-party tools (like leadforms, campaign pop-ups, untested plug-ins) to heavily optimize landing pages for the behavior they want to influence. These don’t always get QA’ed before going live, and increase the likelihood of something going wrong.
- People store content and styles “in other places” so there are many disparate sources of truth to maintain.
- Unorganized and randomly-injected CSS styles can lead to inconsistent and broken designs and experiences, rendering the site less user-friendly and downright unpleasant.
Sometimes there’s no other choice but to start reworking projects from scratch rather than spending even more time attempting to investigate and unravel an impossible web. That costs unnecessary time and money—and prevents the real work from getting done.
“Ok, this all makes sense” you’re probably saying. “But how do I wave my magic wand and fix this?”
It’s all about the process
Glad you asked. As this article blatantly hinted in its title, you need a process—and here are the broad overarching steps your organization should take to establish one.
1. Establish the stakeholders
The people who make day-to-day decisions about your website are rarely the same people responsible for implementing them. A transparent web development team starts with accounting for everyone who will be a part of running the site, as well as all the stakeholders who influence major decisions. Those may include:
- Customer Service
2. Before the build, set up key development components
Before any work begins, it’s imperative that a transparent web development team environment is established.
The goal here is to build the structure for a well-documented, version-controlled codebase that positions for future growth and avoids mistakes of the past. Specifically, you need to create an environment upfront where development hours aren’t wasted hunting down and fixing code conflicts. Here’s what to incorporate:
- Web Host. The right one improves the speed and performance of your site exponentially.
- Development Environments. You’ll be able to build new features and pages and do QA before launching to the public.
- Bitbucket or Git integration. Version controlled code is how teams code synchronously with visibility. Anyone can see changes happening in real-time,easily collaborate on the work being done, and address code conflicts before pushing live.
- Continuous Integration/Continuous Deployment (CI/CD) tools. These handle all the hard work getting files from your repositories to your production servers.
- Wiki Documentation. Include tech stack, functional specs and dev practices so that any team member can jump in, and understand how to make changes the right way.
- Jira for backlog management to track and prioritize bugs, issues and wish list items.
3. Improve and iterate with strategic prioritization of features, bugs and maintenance
In order to reach production milestones on time and on budget, and hit go-to-market schedules, changes and updates must be prioritized and tracked accordingly.
Not every stakeholder can (or should) get top priority, but giving them visibility into the process and why they may have to wait can help reduce unnecessary meetings, power trips and turf battles with the judicious use of:
- Backlog Management. Your backlog is a combination to-do and wish list that grows over time. Internal stakeholders need to unify behind a system that prioritizes requests so the site can put its best foot forward all the time.
- Dev Planning. Items in the backlog should never be worked on until clear requirements for the task are clearly defined. This encapsulates everything that must happen before work begins, like gathering and writing the requirements for development, UX and visual design. Having a schedule with key milestones. Using weekly or monthly sprints to organize what will be worked on next and plan releases.
- Staging/QA. Complete work and QA on the staging server first. The advantages of this include a live environment for feedback that mimics production, and is easily edited without affecting business as usual.
- Regular Health & Security. Check for code issues, technical performance and user experience across devices. Maintain the framework and updates to plugins. Check that forms work properly without security holes.
- Approved releases. Once QA is complete on staging for all tasks included in each release, they should be marked as approved. Only then are updates released to production. Add release notes to your Wiki for future review as needed.
- Post-launch checks. After development wraps up, run cross-browser checks and address any bugs.
What are the results?
We spent this whole article talking about the benefits of the developers having a process, what about you? When internal communication and collaboration become standard operating procedure here’s what B2B Marketers, get:
- Empowerment for all sides of the business to work efficiently, productively and collaboratively—without stepping on each other’s toes.
- Benchmarks so you can effectively measure what changes may have driven either positive or negative business outcomes.
- A website that stays user-friendly for customers and staff
- A culture of transparency and organization
- New messages and features on your site into market faster without screwing things up
- Increase in your success measurements and KPIs