As Zivtech’s Marketing Manager, I’m by far not the most technical member of our staff. Since the developers see our website from a different perspective than I do, it’s sometimes challenging to communicate the changes that the marketing team would like to see. I can explain an idea, but I won’t necessarily know how it will look once it’s executed. This is where Probo comes in.

Probo was originally created to solve an internal workflow problem that we were experiencing at Zivtech. It’s every development team’s goal to deploy features quickly, without negatively affecting a functioning system. Our team’s pull requests would often get held up by busy lead developers in the review process, impacting our efficiency. Once we deployed changes, we still had to see if the result was what the project stakeholders, marketing team, or project managers actually wanted. Probo’s initial focus was to prevent these bottlenecks, speed up delivery time, and get decision makers involved in the process from the beginning.

Other continuous integration tools only focus on automated testing and faster delivery. Probo is different because it provides a link to a whole new copy of your site for every pull request. The link is accessible for any person you send it to, whether he or she is a project manager, client, or marketer. It builds quality assurance and user acceptance testing into the process.

Using Probo as a Marketer

I recently asked our developers to make a change to the ad callouts on some of our site’s pages. We could feature resources and events in these callouts, but not blog posts.

One of our developers created a pull request and triggered a Probo build, then sent a link to me for review. The link took me to a sandbox site that looked just like our real site. When I looked at the ad callout, I realized that it was unclear where a user should click on all of our ad callouts. I passed this feedback along to the developer. He added a “read more” link and triggered another Probo build. Once approved, the ticket was passed along to our front-end team for theming.

You can also use Probo for back-end changes to your site. Our CTO, Jody, wanted to improve the usability of our blog post content type. There were a lot of unnecessary, unused fields and some mandatory fields that stayed the same for every post. She cleaned things up and sent me a link to a Probo build. I had never used Probo to review back-end changes, and it made the process significantly easier. Rather than her having to explain which things she added, removed, or changed, I could go to the link and simulate the new process for creating blog posts. This was really helpful, and now publishing blog posts is faster and easier.

The same process occurs each time we need to make a change to the site, making it easy for our entire team to work together. Probo creates a visual environment for us less technical users and allows all team members to get involved when and where they’re needed. Not only does it eliminate bottlenecks in the development process, it also allows project decision makers to get involved earlier on, ultimately enabling a more efficient workflow and better results.