You’ve gotten your winning results and now you want to implement the changes permanently. Fantastic! To do this, you'll work with a developer to integrate the changes permanently into your codebase.
Sometimes, handoff to a developer can be a delicate process. If the optimization team hasn’t prepared the developer for implementation, the project may hit a slow point or even end up on hold indefinitely. A new feature may test well but take a month of your developer's time to build. By looping your developers in early and updating them regularly, you'll smooth the process of implementing permanent changes and build a stronger optimization culture in the process.
To implement the changes that you decide to make, your developer will translate Optimizely’s jQuery variation code into the framework your site is built on. In the beginning, you might be able to add Optimizely’s variation code directly to your site, but over time this process won’t be sustainable, especially after you implement changes from multiple experiments. A developer will translate the variation code and integrate it into a part of your site’s framework. This process requires familiarity with both your site’s codebase and Optimizely. It may also require the developer to translate some of Optimizely’s client-side script into server-side script.
You should also share your results document with the developer. A detailed plan provides context for the changes to be implemented. Your results document also offers a glimpse into the power of Optimizely to create a quick proof-of-concept before fully dedicating developer resources.
Only site changes that have been tested and validated with data should be passed to the development team for implementation. Integrate your communications about the site build with your developers’ communication systems -- often JIRA or Trello.
Create a unified record so potential communication gaps, such as the overlapping deployment of live features and experiments, don’t cause conflicts that break the site.
The workflow might look something like this:
- Create an experiment based on your experiment plan, with your developer’s input.
- Analyze the results of an experiment and make decisions based on your results.
- If a variation is successful, duplicate the experiment and set traffic allocation to 100% to show all visitors.
- Share results with stakeholders, including the developer.
- Developer enters Optimizely experiment and reviews variation code with the project manager.
- Developer abstracts the code and builds a permanent feature in the production environment; then, verifies that the new feature works correctly.
- Developer notifies the optimization program manager when the feature goes live.
- Optimization program manager turns the experiment off and archives it.
- Implement the same feature in your development environment, if you have one.
- Integrate your implementation process with the systems your developer uses to track projects to execute the handoff smoothly.
As your optimization program matures, incorporate your experimentation program with your developer’s sprint cadence.
You should also involve the developer in the experimentation cycle. You may notice a decrease in the time it takes to translate successful changes to your live site, but the effort it takes to set up a new experiment may slightly increase. These shifts are good signs: they mean your developer is becoming more deeply involved in experimentation. You’re probably running more complex experiments, too. And by involving your developer early, you smooth the way for the very last step -- optimizing your live site.
Optimizely makes it easy to create variations with static HTML, but a developer can help you design more efficient, dynamic experiments. Changes that you make with the Visual Editor generate code that’s executed in the browser after your site loads. Inefficient changes can balloon into hundreds or even thousands of lines of variation code. For example, you may want to make a button more prominent, so you use the Move and Resize feature and edit the color a few times to get it just right. With every change, a new line of code is generated. Hundreds of lines of code can cause performance issues such as flashing.
A developer can also think ahead about how to abstract variation code into the code base. Then, when you decide deploy changes to the live site, they can build new or altered features more efficiently.
You can learn more about involving your developers and implementing variations on our Knowledge Base.