Why write requirements? Well, let’s imagine you want to produce a mobile app, but you don’t have the programming skills. So, you find a developer who can build the app for you, and you describe the idea to him. Surprisingly, when he showcases the app for the first time, you see that it is not exactly what you want. Why? Because you didn’t provide enough detail when describing the idea.
Besides the user’s needs, what’s another vital aspect of an app? Your first thought might be its design. That’s important, correct, but before you can even think about the design, you need to get something else right: the data. Data should be the cornerstone of everything you create. Not only does it help you to make more informed decisions, but it also makes it easier to account for edge cases, or things you might not have thought of otherwise.
If you were planning to race your car, you would want to make sure it could handle the road, right?
Imagine racing a car that is not ready for the surprises of the road. A road that is going to require you to twist and turn constantly, and react quickly to the elements.
You would find yourself on the side of the road in no time.
A well-outfitted car, on the other hand, is able to handle the onslaught of the road and, when the dust settles, reach the finish line.
Well, think of your website like the car and conversion optimization like the race. Too many companies jump into conversion optimization without preparing their website for the demands that come with testing.
Get the Technical Optimizer’s Checklist
Download and print off this checklist for your technical team. Check off each item and get prepared for smooth A/B testing ahead!
By entering your email, you’ll receive bi-weekly WiderFunnel Blog updates and other resources to help you become an optimization champion.
But proper technical preparation can mean a world of difference when you are trying to develop tests quickly, and with as few QA issues as possible. In the long-run, this leads to a better testing rhythm that yields results and insights.
With 2017 just around the corner, now is a good time to look ‘under the hood’ of your website and make sure it is testing-ready for the New Year. To make sure you have built your website to stand the tests to come, pun intended.
In order to test properly, and validate the great hypotheses you have, your site must be flexible and able to withstand changes on the fly.
With the help of the WiderFunnel web development team, I have put together a shortlist to help you get your website testing-ready. Follow these foundational steps and you’ll soon be racing through your testing roadmap with ease.
To make these digestible for your website’s mechanics, I have broken them down to three categories: back-end, front-end, and testing best practices.
Back-end setup a.k.a. ‘Under the hood’
Many websites were not built with conversion optimization in mind. So, it makes sense for you to revisit the building blocks of your website and make some key changes on the back-end that will make it much easier for you to test.
1) URL Structure
Just as having a fine-tuned transmission for your vehicle is important, so is having a well-written URL structure for your website. Good URL structure equals easier URL targeting. (‘Targeting’ is the feature you use to tell your testing tool where your tests will run on your website.) This makes targeting your tests much simpler and reduces the possibility of including the wrong pages in a test.
Products to include:
Products to exclude:
Products to include:
Products to exclude:
On the other hand, the second example shows a company that structured all of their product URLs and categories. Targeting in this case uses a match for the substring “/engines/” and allows you to exclude other categories, such as ‘wheels’. Proper URL structure means smoother and faster testing.
2) Website load time or ‘Time to first paint’
‘Time to first paint‘ refers to the initial load of your page, or the moment your user sees that something is happening. Of course, today, people have very short attention spans and can get frustrated with slow load times. And when you are testing, ‘time to first paint’ can become even more of a concern with things like FOOC and even slower load times.
So, how do you reduce your website’s time to first paint? Glad you asked:
Within the HTML of your page:
Within the head tag, move the code snippet of your testing tool as high as you can―the higher the better.
Minify* your JS and CSS files so that they load into your visitor’s browser faster. Then, bring all JS and CSS into a single file for each type. This will allow your user’s browser to pull content from two files instead of having to refer to too many files for the instructions it needs. The difference is reading from 15 different documents or two condensed ones.
Use sprites for all your images. Loading in a sprite means you’re loading multiple images one time into the DOM*, as opposed to loading each image individually. If you did the latter, the DOM would have to load each image separately, slowing load time.
While these strategies are not exhaustive, if you do all of the above, you’ll be well on your way to reducing your site load time.
3) Make it easy to differentiate between logged-in and logged-out users
Many websites have logged-in and logged-out states. However, few websites make it easy to differentiate between these states in the browser. This can be problematic when you are testing, if you want to customize experiences for both sets of users.
This will make it easier for you to customize experiences and implement variations for both sets of users. Not doing so will make the process more difficult for your testing tool and your developers. This strategy is particularly useful if you have an e-commerce website, which may have different views and sections for logged-in versus logged-out users.
4) Reduce clunkiness a.k.a. avoid complex elements
Here, I am referring to reducing the number of special elements and functionalities that you add to your website. Examples might include date-picking calendars, images brought in from social media, or an interactive slider.
While elements like these can be cool, they are difficult to work with when developing tests. For example, let’s say you want to test a modal on one of your pages, and have decided to use an external library which contains the code for the modal (among other things). By using an external library, you are adding extra code that makes your website more clunky. The better bet would be to create the modal yourself.
The front-end of your website is not just the visuals that you see, but the code that executes behind the scenes in your user’s browser. The changes below are web development best practices that will help you increase the speed of developing tests, and reduce stress on you and your team.
1) Breakpoints – Keep ’em simple speed racer!
Assuming your website is responsive, it will respond to changes in screen sizes. Each point at which the layout of the page changes visually is known as a breakpoint. The most common breakpoints are:
Mobile – 320 pixels and 420 pixels
Desktop and Tablet – 768px, 992px, 1024px and 1200px
Making your website accessible to as many devices as possible is important. However, too many breakpoints can make it difficult to support your site going forward.
When you are testing, more breakpoints means you will need to spend more time QA-ing each major change to make sure it is compatible in each of the various breakpoints. The same applies to non-testing changes or additions you make to your website in the future.
Spending a few minutes looking under to hood at your analytics will give you an idea of the top devices and their breakpoints that are important for your users.
Above, you can see an example taken from the Google Analytics demo account: Only 2% of sessions are Tablet, so planning for a 9.5 inch screen may be a waste of this team’s time.
Let’s say your website works in the many breakpoints and browsers you wish to target. However, you’re using images for your footer and main calls-to-action.
Problem 1: Your site may respond to each breakpoint, but the images you are using may blur.
Problem 2: If you need to add a link to your footer or change the text of your call-to-action, you have to create an entirely new image.
Use buttons instead of images for your calls-to-action, use SVGs instead of icons, use code to create UI elements instead of images. Only use images for content or UI that may be too technically difficult or impossible to write in code.
3) Keep your HTML and CSS simple:
Keep it simple: Stop putting CSS within your HTML. Use div tags sparingly. Pledge to not put everything in tables. Simplicity will save you in the long run!
Putting CSS in a separate file keeps your HTML clean, and you will know exactly where to look when you need to make CSS changes. Reducing the number of div tags, which are used to create sections in code, also cleans up your HTML.
These are general coding best practices, but they will also ensure you are able to create test variations faster by decreasing the time needed to read the code.
Tables, on the other hand, are just bad news when you are testing. They may make it easy to organize elements, but they increase the chance of something breaking when you are replacing elements using your testing tool. Use a table when you want to display information in a table. Avoid using tables when you want to lay out information while hiding borders.
Bonus tip: Avoid using iFrames* unless absolutely necessary. Putting a page within a page is difficult: don’t do it.
4) Have a standard for naming classes and IDs
Classes and IDs are the attributes you add to HTML tags to organize them. Once you have added Classes and IDs in your HTML, you can use these in your CSS as selectors, in order to make changes to groups of tags using the attributed Class or ID.
You should implement a company-wide standard for your HTML tags and their attributes. Add in standardized attribute names for Classes and IDs, even for list tags. Most importantly, do not use the same class names for elements that are unrelated!
Looking at the above example, let’s say I am having a sale on apples and want to make all apple-related text red to bring attention to apples. I can do that, by targeting the “wf-apples” class!
Not only is this a great decision for your website, it also makes targeting easier during tests. It’s like directions when you’re driving: you want to be able to tell the difference between the second and third right instead of just saying “Turn right”.
Technical testing ‘best practices’ for when you hit the road
We have written several articles on testing best practices, including one on the technical barriers to A/B testing. Below are a couple of extra tips that will improve your current testing flow without requiring you to make changes to your website.
2) Don’t pull content from other pages while testing
When you are creating a variation, you want to avoid bringing in unnecessary elements from external pages. This approach requires more time in development and may not be worth. You have already spent time reducing the clunkiness of your code, and bringing in external content will reverse that.
The important question when you are running a test is the ‘why’ behind it, and the ‘what’ you want to get out of it. Sometimes, it is ok to test advanced elements to get an idea of whether your customers respond to them. My colleague Natasha expanded on this tactic in her article “Your growth strategy and the true potential of A/B testing”.
3) Finally, a short list of do’s and dont’s for your technical team
Don’t just override CSS or add CSS to an element, put it in the variation CSS file (don’t use !important)
Don’t just write code that acts as a ‘band-aid’ over the current code. Solve the problem, so there aren’t bugs that come up for unforeseen situations.
Do keep refactoring
Do use naming conventions
Don’t use animations: You don’t know how they will render in other browsers
DOM: The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML, and XML documents
iFrame: The iframe tag specifices and inline frame. An inline frame is used to embed another document within the current HTML document
Minification of files makes them smaller in size and therefore reduces the amount of time needed for downloading them.
What types of problems does your development team tackle when testing? Are there any strategies that make testing easier from a technical standpoint that are missing from this article? Let us know in the comments!
When I was a developer, I often had a hundred questions when building websites from wireframes that I had received. Some of those questions were:
How will this design scale when I shrink the browser window? What happens when this shape is filled out incorrectly? What are the options in this sorting filter, and what do they do? These types of questions led me to miss numerous deadlines, and I wasted time and energy in back-and-forth communication.
Layout on the web is hard. The reason it is so hard is that the layout methods we’ve relied on ever since using CSS for layout became possible were not really designed for complex layout. While we were able to achieve quite a lot in a fixed-width world with hacks such as faux columns, these methods fell apart with responsive design.
Thankfully, we have hope, in the form of flexbox — which many readers will already be using — CSS Grid Layout and the box alignment module.
It’s Friday again, and I found some interesting articles for you to read over the upcoming weekend. In projects, developer, manager and product leaders still try to put pressure on the people who work on a task. Somehow they feel relieved, more secure if they do that. On the other hand, the people experiencing the pressure of urgency are struggling massively with it.
The fallacy here is that while the ones spreading the pressure feel better, the people experiencing it usually do a worse job than without the pressure.
What’s going on in the industry? What new techniques have emerged recently? What insights, tools, tips and tricks is the web design community talking about? Anselm Hannemann is collecting everything that popped up over the last week in his web development reading list so that you don’t miss out on anything. The result is a carefully curated list of articles and resources that are worth taking a closer look at.
To you, modal windows might be a blessing of additional screen real estate, providing a way to deliver contextual information, notifications and other actions relevant to the current screen. On the other hand, modals might feel like a hack that you’ve been forced to commit in order to cram extra content on the screen. These are the extreme ends of the spectrum, and users are caught in the middle. Depending on how a user browses the Internet, modal windows can be downright confusing.
To most Web developers, it sounds controversial until you hear the punchline: Last summer, the developers in charge of Google’s Chrome browser floated a proposal that went virtually unnoticed by the technology press, which was to remove support for an established W3C standard that every other browser vendor still supports. The standard in question? Extensible Stylesheet Language Transformations, otherwise known as XSLT.
In reaction to this news, most Web developers would likely shrug and say “So what?