In the web development and design world, terms like staging, dev, production, prod, test and QA are thrown around by agencies and internal teams alike. But every once in awhile, it’s worth taking a minute to pause and make sure we all know what these terms mean.
The intention is not to confuse, but nomenclature in tech runs rampant. We can’t help ourselves.
One question we’ve gotten in particular: What is a staging site, and why would I need one?
Let’s start with the “what” part of the question.
What is a staging site? A staging website (environment) is a non-public-facing duplicate of your live public-facing website that exists for the purpose of reviewing website changes prior to those changes being published to the live site.
Just Like a Restaurant
Think of it this way: Websites are a lot like nice restaurants.
They are supported by their own unique brand, attracting visits and transactions.
The font of the house (dining room, bar, hostess) is organized and optimized for the visitor. This experience is the production environment of a website – the user-facing, best version of itself. The part that you, as a customer, actually interact with.
The front of the house takes on the burden (and the pleasure) of directly delivering user outcomes. They give you a nice table. They take your order. They deliver the food.
But what makes each dish taste so good? How does the host know to seat regulars at ‘their’ table?
These user-centric questions are answered at the back of the house—the kitchen and offices that reside behind-the-scenes. The user has a positive, even Yelp-worthy, experience because the back of the house consistently tests new dishes, concepts business events and applies strategic decision making.
Crucial to business success, the back of the house fuels positive user experiences, just like a staging website does.
Make it. Then, Break It.
Restaurants don’t serve food they have never tasted and you shouldn’t launch untested features. A staging site is where you can test functionality, designs, copy, new user flows and conversion funnels.
You need a staging site so that you can test all of these things without messing up your current site.
Once a feature/fix/enhancement is ready to test, establish a cross-functional QA (quality assurance) process. At a minimum, staging development should be seen by the following people:
- Copywriter
- Developer
- Designer
- Someone outside the project (preferably someone with your consumer profile)
Each of these reviewers looks at the site from a unique vantage point.
This review process is vital to ensuring the user experience on the live site.
If functional questions arise, stop the discussion/development and ask how the user interacts with that piece of functionality. Balance what you want the user to do, with what the user wants to do. Look for that Venn diagram sweet spot and build there.
As Martin LeBlanc famously said, “A user interface is like a joke. If you have to explain it, it’s not that good.”
Remember: The customer comes first (most of the time).
Agency Tip: When working with your website development agency, talk to them about their development process. How are they providing you access to review enhancements and site updates? Establish a clear review and approval process up front.
Test. Iterate. Succeed.
The brutal truth is that websites are never finished. You can never sit back and think to yourself “whew, my work is done here.” Launching a new website, feature, or app is only the end of the beginning. And you are going to need a place to work on your next idea.
Staging sites provide you an environment to test messaging, reprioritize content and even build out wish-list items—and where you can begin to plan your next production release.
Agency Tip: There are many processes for planning dev releases and creating release cycles. We have had the best luck with the Agile development process. While Agile is typically used as a development term, the agile process works when applied to all aspects of business teams.
Listen to your users, even if you feel like spouting that Henry Ford quote. Delivering a product calculator, how-to video content, or even (hey!) an article explaining staging websites might be exactly what they are looking for.
Remember that the most important and functional changes might not be highly visible. Changes can (and should) also include bug fixes, solutions to UX issues, and improved site performance. Minimizing, combining, and compressing JavaScript and CSS files is definitely not a user facing change. But, performing these simple tasks can increase page speed and load time. Consumers will thank you—hopefully with their wallet.
On the flip side, self-serving enhancements are just as important. Integrating form submissions into your CRM system to properly denote and assign leads is vital to business success. Your internal business goals may (ahem, should) also include marketing automation software to improve lead generation. Even though consumers won’t see these changes, test them on a staging site before they see the light of day. Internal projects need to be balanced with user requests in the dev cycle for staging site implementation.
Don’t let yourself be intimidated. Breathe. This is freedom. Like dancing when no one is watching or rehearsing your presentation in front of the hotel mirror.
Remember, it’s just a staging site. The public can’t see it.
Try out new ideas. Do it wrong quickly and then do it right.
Finally – Nerd Stuff
Staging sites are, typically, configured as subdomains of your primary domain (Example: live website = http://www.yourdomain.com and your staging website = http://stage.yourdomain.com). This environment is for internal use only and not available for the world to access. Work with your IT resources and development team to configure your staging environment to best fit your culture/regulations.
Your team may request an additional dev environment (e.g. dev.yourdomain.com or test.yourdomain.com). In this three-stage approach, the dev environment serves as your testing site and playground for new features/designs. The stage environment is where review happens. Typically, this means that the code has been vetted, reviewed and tested and is now ready for production. Changes made to the dev environment are simply pushed to the staging environment for review and approval.
It doesn’t matter if the latest feature was built from the confines of your developer’s desk at the office or their favorite coffee shop through VPN access. Inevitably, that new feature needs to be reviewed by c-suite folks traveling through an airport. Make that review process clear and easy (and secure). Remember, user experience (UX) applies to your employees and your internal brand as well.
Work with a website development agency to ensure marketing, development and IT all have buy-in with the build/launch process. Creating buy-in is key to ensure the best outcome for your organization and end users. Improving your website improves your brand.
Leave a Reply