Let's assume we have created a new design package called sportswear_package. Within this design package, create a new theme and call it sportswear_theme. Our new design package file hierarchy, in /app/design/, might resemble the following hierarchy:
app/
design/
frontend/
Magento/
blank/
luma/
sportswear_package/
sportswear_theme/Because we want to use the blank theme as a starting point, the theme.xml in the root directory of our theme will look something like this:
<theme xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../../lib/internal/Magento/Framework/Config/etc/theme.xsd">
<title>Sportswear Theme</title>
<parent>Magento/blank</parent>
<media>
<preview_image>media/preview.jpg</preview_image>
</media>
</theme>However, let's also take one more customization step here. We can create variations of a theme that are simply controlled by CSS and images by creating more than one skin. For "Sportswear", we might want to have our English language store in a blue color scheme, but our French language store in a green color scheme. We could take the sportswear_theme/ directory and duplicate it, renaming both for the new colors:
app/
design/
frontend/
Magento/
blank/
luma/
sportswear_package/
sportswear_theme/
sportswear_blue_theme/
sportswear_green_theme/Before we continue, let's go over something that is especially relevant to what we have just created.
For our sportswear theme, we created two skin variants: blue and green. However, what if the difference between the two is only one or two files? If we make changes to other files that would affect both color schemes, but which are otherwise the same for both, this would create more work to keep both color variations in sync, right?
Remember, with the Magento fallback method, if your site calls on a file, it first looks into the assigned theme, then the parent theme, the blank theme, and finally, the module-specific theme files. Therefore, in this example, you could use the sportswear_theme as a common parent to contain all files common to both blue and green. You would only need to include files or CSS impacting the color of these themes.
As mentioned earlier, you can assign design packages and themes at any level of the GWS hierarchy. As with any configuration, the choice depends on the level you wish to assign control. Global configurations affect the entire Magento installation. Website level choices set the default for all subordinate Store Views, which can also have their own theme specifics, if desired.
Let's walk through the process of assigning a custom design package and themes. For the sake of this exercise, let's continue with our sportswear theme, as described earlier. We created a sportswear website and store, with two Store Views for English and French:

We're going to now assign our sportswear theme to the sportswear Website and Store View. Our first task is to assign the design package and theme to the Website as the default for all subordinate Store View:


The reason you enter default in the fields as shown above is to provide the fallback protection we described earlier. Magento needs to know where to look for any files that may be missing from your theme files.
Besides the obvious use of different themes within a package for different looks among Store Views, theme variants can be used to provide alternative frontend layouts based on date, such as holiday shopping season, or device, such as smartphone or tablet.
It would be painful if changes that affect your public site content had to be manually turned on at the exact date and time you wished. For products, you can schedule price changes to automatically take effect between any two dates and times (you could have a one-hour sale price!) simply by adding the date/time configuration in the product detail screen.
Likewise, you can schedule changes in your stores' themes to take effect while you sleep! To schedule a theme variant based on a date: