Designing a Gutenberg-Powered Theme: Music

Kjell Reigstad walks through his experience designing a block-powered theme.

Last week, Allan Cole and I shared a new Gutenberg-powered theme called Music. In this follow up post, I’m going to take you through the design process for the theme. At its core, this felt a lot like a typical theme design process, but I did learn a lot about block-based design along the way. 


When Allan and I decided to make this theme, we already had a homepage comp featuring a handful of blocks. That comp did a great job of setting the tone for the design aesthetic. To get things going, I decided to apply that aesthetic to the other default Gutenberg blocks. I worked through the Gutenberg Blocks Sketch document from my last post, updating styles as I went.


Working this way was great for a couple reasons. First, it helped me focus — I’d never designed a block-optimized theme before, and this kept my design explorations squarely on the blocks themselves. I thought,  “Gutenberg is all about blocks, right? I’ll design some blocks.”

Second, the Sketch file allowed me to see every single block style in one place. In effect, I was creating a sort of pattern library as I went. I thought this was pretty cool, and figured it’d come in handy later on when we began development.

As I got further through these block designs, I realized the need to see all of these individual blocks in context; I’d design a wide-width cover image block, but I had no idea how it’d look in use. So I began dragging blocks around and stacking them up to get a sense of how they’d feel together.


This helped a little bit, but still wasn’t enough. At this point, I realized something that should’ve been obvious: blocks are not a theme. They’re just part of a theme. By designing blocks first, I’d been avoiding the big picture. Users will never see blocks all by themselves — they’ll exist within full pages. I needed to design more pages. 


My initial homepage design comp introduced a rough idea of a header and an off-centered text column. I began by duplicating that initial page and clearing out all the blocks on it, then pulled together some sample content. Looking at the project through the lens of my imagined client (the band Superserious), I was able to think through examples of blocks and block combinations that might exist on a real site: the columns block to display album information, the table block to display tour dates. This felt much more effective than randomly placing blocks on a page.

Around this time, I hit my stride, design-wise. I’d lay out a page using my existing blocks and the sample content. Then I’d iterate and experiment with everything on that page. Once things looked right, I’d migrate any new block tweaks back to the global symbols and start fresh on the next page. After a little while, I ended up with a solid set of sample pages.


Backing up and thinking about page design helped me shift focus to other, more traditional components that needed to be designed too: archive pages, page footers, post headers, etc. Designing these wasn’t all that different than it would’ve been without Gutenberg. In a way, we’ve all been designing with blocks all along — we just hadn’t called them blocks. Take a look at this entry summary:


If I’d designed this theme pre-Gutenberg, I still would’ve designed each one of those pieces — they’re all fairly standard parts of a theme. But thanks to Gutenberg, each piece is part of a clear pattern library, to be reused throughout the design by me and by the user. That’s pretty cool.

I’d gone into this project thinking I’d spend most of my time styling individual blocks, but I ended up splitting my time pretty evenly between designing block variations and overall page elements. In that sense, this wasn’t as drastically different from a traditional theme design as I’d anticipated.


I’d been getting ongoing feedback from Allan throughout the process above, but once we were happy with the page designs above, we gathered  with the rest of the Theme team to get broader design feedback. To help with that process, I pulled all my comps together into a prototype. This took just a few minutes to do, and really helped others get a sense of how the theme will work in practice.

I created two separate prototypes with Invision: one for desktop and one for mobile. If my transition from block design to full-page design was about looking at the bigger picture, these prototypes stepped back still further: they showed us the context around that big picture. We were all able to see the designs on-device and test some basic interactions. 

The team’s feedback was (as usual) very helpful — we made some subtle revisions to text contrast, adjusted a number of margins, and kicked off a lot of iteration on the mobile menu treatment.


Allan had been focused on the build from the beginning, and had the majority of the framework in place at this point. After our design feedback session, I jumped into the code too.  

From the development angle, we’d already determined a few things in the design that we couldn’t do, or that would take too much effort. For instance, in my initial design comp I’d had a series of backgrounds run down the page. Gutenberg doesn’t have a method for doing something like that today; despite my wishful design thinking, there’s no method for layering a background behind a group of blocks. We could’ve accomplished it through customizer settings, but we shelved the idea in favor of keeping things simple. We also abandoned a bunch of the play buttons I’d originally included, since those’ll require some custom blocks (more on that later). 

Once I jumped into the code, my main revelation was that there were way more block options than I’d originally anticipated. A number of blocks had options I’d never noticed before. I hadn’t realized that paragraph blocks could be set to full width, or that cover image blocks could be floated left or right.

In addition, I realized some design decisions I’d made were actually supposed to be user-editable: I’d overlooked the fact that users can edit the text alignment and image opacity for the cover image block. This required more design exploration, but it guided us towards a much more customizable theme — definitely a win in the end.

Beyond those updates, the majority of the design-oriented development work involved minor fixes and adjustments — polishing up the CSS to make sure it aligned with the intent of the original design. 

Next steps

Now that we’ve had our initial release, Allan and I plan to build a separate plugin with complementary music-centric blocks, like a tour dates block and a mashup of a cover image and an audio player. We’ll hope to showcase those at some point in the future.

In the meantime, keep an eye out for the next post in the series: Allan’s experience from a development perspective.


Music: A Gutenberg-Powered Theme

Announcing the Music theme: an exploration of how Gutenberg can transform theme design and development.

A couple months ago, I created a Sketch document to assist with the design of block-driven themes. I posted about that here on Themeshaper, and provided a couple short examples of how it could be used in a theme design workflow.

Since then, Allan Cole and I have been working to make one of those examples — a site for an imagined band named Superserious — into a working example of a Gutenberg-powered WordPress theme. We named the theme “Music.”

Allan and I set out to experiment, learn, and create a resource for the community. We’ve documented our experience designing and building this theme, and will be publishing our notes in a series of posts here on Themeshaper.

To kick things off, we’re releasing Music on GitHub today. We’d love for you to give it a spin, tinker with it, and explore how it works with Gutenberg. Here are a few things to look out for:


Our design goal for the theme has been to show that it’s possible (and encouraged!) to make a Gutenberg theme that doesn’t necessarily look like Gutenberg. We wanted to create something bold and a little experimental; a theme with somewhat aggressive, non-standard styles.

Gutenberg gives users unprecedented control over their site design, opening the door for variety and experimentation. Our favorite example of this is our cover image blocks. They look great out of the gate, but users can adjust the image, alignment, and color to achieve a wide range of looks:




You’ll be happy to hear that the overall theme development process wasn’t all that different with Gutenberg. Common patterns like headers, footers, and loops work just as you’d expect in a Gutenberg-powered theme.

In many areas, Gutenberg makes things easier for both users and developers. For instance, full-width header images used to require a custom-built customizer or theme option solution, but now they’re essentially built in. This was important to keep in mind while building the theme, and was a very positive change for development.

Creating stylesheets for blocks was pretty straightforward. Expanding on the built-in stylesheets in _s,  we added a blocks.scss file to the SASS directory and placed all of our block-specific styles and overrides there. This kept everything nice and organized and is likely to appear in _s in the future.

Since Gutenberg is output by the_content(), we learned to take special care with any wrapper divs that might clip or obstruct the expected behavior of Gutenberg blocks. We’ll talk more about that in a follow up post.

Block Styles

We’re truly excited about the custom editor styles that ship with Music. These styles are a breakthrough: they give users a much clearer sense of what their visitors will see on the front end.

Best of all (for theme developers at least), the editor styles were a breeze to integrate! We built all of these in over the course of just a few hours.

Like most of the work we do, the Music theme is open source. You can find it on GitHub:

If you’d just like to see the front end, feel free to click around our demo site here:

In many ways, designing and building this theme was similar to the way we’ve made themes in the past — but we did carve out a few new practices along the way. Allan and I will be sharing them with you in upcoming posts. In the meantime, we encourage you to download, install, and experiment with Music yourself!


Read part two of this series: Designing a Gutenberg-Powered Theme: Music

What Developers Need to Know About Theme Design

Making a theme is really exciting. It’s a great way to practice your coding skills. It could be a good way to bring in some extra pocket change. Best yet, seeing someone use something you’ve built is incredibly rewarding.

I’ve watched the quality of theme design get better and better in the directory in the last few years, but I still see a lot of themes that look the same. Free themes still lag behind premium themes in terms of design quality. You can help change all that. You don’t need a design background to make good design decisions: a developer conscious of design can still make a good-looking theme.

Here are a few general tips and tricks you can apply to your themes to give them a solid design base, regardless of your background.

Pick a Direction

When planning out your new theme, have a specific user or use case in mind. That use case shouldn’t be “a theme for everyone.” Your use case can still be pretty broad — “a modern theme for small businesses” is still targeted enough for your ideal user to solve a specific goal by using your theme. Alternately, you can get super specific, giving yourself a prompt like “a food blogging theme targeting smartphone photographers.” Each theme idea has a different set of constraints, and by embracing and sticking to these constraints, you can make better themes.

Once you have a direction in mind, think through that scenario and what your target users would need. The more you imagine how people are going to use your theme, the stronger your concept becomes.

For a modern business theme, think about what a great business website needs. If the company has a physical location, site visitors need an easy way to find an address or directions. People visiting the site need a way to contact the business, via phone, email, or contact form. The theme needs strong page templates, but probably not a unique blog template. It probably needs a navigation bar that can support up to a dozen or more pages at various levels. Typography should probably be strong and serious. A business might also need to display their products, so you could consider adding support for popular e-commerce plugins.

On the other hand, an amateur food blogger, especially if they don’t have a nice camera, needs a theme that focuses more on super strong typography. Photos should be present, but de-emphasized in case they aren’t top-quality. The theme’s users need a way to easily display recipes. Maybe this means building a plugin that pairs with the theme for extra feature support, or maybe it means really nice post styling. A variety of page templates probably aren’t extremely important, but well-styled category archive templates are. Type can have a little more personality, but still has to be readable.

In both situations, you want to have a strong responsive design so site visitors can browse on their phones or tablets. After all, 50% of web traffic comes from mobile devices.

Look at other themes and websites that fit within your use case. Find five really great ones and figure out what makes them great. Take these insights and apply them to your theme.

Visual Design


Typography is probably the most important part of the vast majority of themes. What’s a site without text? Type needs to be clear, readable, and context-appropriate. There’s a couple rules of thumb you can use to make sure your theme’s typography looks good.

The hardest part of theme typography is picking the right fonts. The “popular” sorting option on Google Fonts is a surprisingly okay place to start looking for a font to use. Try to pick fonts that have multiple weights. Depending on the font, a light or semibold weight might be more appropriate than just regular or bold. At the very least, avoid using fonts that don’t come with bold or italic. There is (finally)! a “number of styles” filter in Google Fonts that you can also browse through. Don’t trust Google’s recommended font pairings — they’re actually pretty poor.

If you want to combine a serif and a sans-serif and you’re unsure which typefaces to pick, go for a font family. These are built to have similar features and will naturally pair well. Some families on Google Fonts include Merriweather Sans and Serif, PT Sans and Serif, and Noto Sans and Serif.

When in doubt, use font combinations from sites you like.

Once you’ve chosen your font(s), you need to style your text to be readable. This means using appropriate font sizing. Don’t make someone squint! Use at least 14px or higher for your body text. If 14px looks too small, don’t be afraid to go up to 16px, or even 18px.

One of the biggest issues I see concerning type on themes is an overall lack of line height, which is the space between each line of text. As a general rule of thumb, my headers are always between 1.2-1.4 the size of my font, and my body text is almost always between 1.4-1.6 the size of your font. And the awesome thing about line-height is you can even just use line-height: 1.4 instead of having to calculate the actual pixel value.

As a general rule, paragraphs shouldn’t be more than 50- 75 characters long. This helps keep them nice and readable.

Finally, limit the number of font styles. I mentioned earlier that you should look for fonts that have multiple font weights. While you should seek these out, don’t combine too many different font weights and sizes, since they negatively impact your content’s hierarchy and flow.


There is a lot of psychology around color. You don’t need to be an expert in color, but learn a little bit before you pick them for your theme. Colors also have different meanings in different cultures, so keep your audience in mind when picking your palette. For a good introduction to color theory, watch Aaron Jorbin’s presentation on

Color also affects whether or not your users will be able to view your theme. Keep in mind contrast when designing your themes — contrast that’s too high or too low makes it hard for people, especially people with visual impairments, to read your text and navigate through the site. Keep in mind people with low vision or color blindness.

Don’t use too many bright or bold colors. They’re great for emphasis and drawing attention to specific parts of the page, but too many strong colors can make your theme hard to look at, or can make it difficult for people to find the most important content on the page.

Soften your blacks. Pure black doesn’t really exist in the world around us, and pure black on the web ends up looking harsh and unnatural. Add hints of color to your black by going up and right in most color pickers, or go for a dark grey.

If you’re struggling with color, here’s some things you can do:

  • Stick to dark text on a light background with one or two accent colors. You can’t go wrong with dark grey text on white.
  • Use a site like Adobe Color or Colour Lovers to find nice palettes.
  • Borrow color palettes from sites you like.


Let everything breathe. Use ample white space between separate elements in your theme.

Finding the right balance of whitespace is hard. When in doubt, l o o s e n  t h i n g s  u p  a  l i t t l e. (Just not your lowercase text — only add letter spacing to uppercase text.)


Don’t go crazy with the details. Less is more.

For example, consider if the drop-shadow you’re using adds a necessary sense of depth to your theme, or if it’s purely decorative. If it’s necessary, tone it down a little. In general, don’t use drop-shadows darker than 25% opacity. The same can be said for gradients; try to keep gradients subtle.

Use animation sparingly. I mean really sparingly. Inappropriate animation is jarring and detracts from your theme. Motion should only be used to show change, not for decoration.

UX Design

There is nothing worse than finding a theme that looks awesome and does what you need, only to install and activate it and find a thousand options you need to hand-configure to make it look like the demo.

Many of WordPress’s core philosophies revolve around simplicity and ease of use:

  • Great software should work with little configuration and setup.
  • Design for the majority.
  • Decisions, not options.
  • Clean, lean, and mean.
  • Striving for simplicity.

You should take these core philosophies to heart when creating your themes. Cut the number of options down to what’s absolutely necessary. For example, instead of letting people control every single color in your theme, let them choose two or three and generate a color scheme based on those colors. Make smart defaults and informed assumptions. If you include options that can be previewed, put them in the Customizer. Stop using gigantic theme options and settings pages. They are almost universally a bad experience for users.

Lastly — user test! If you’re creating a premium theme, you owe it to your users to make your theme as easy to set up and use as possible. is relatively cheap and easy. Running as few as 3 user tests will catch the majority of your theme’s issues.

Free theme? No budget? Ask around for some beta testers. Don’t want to? Then at the very least, set up your theme on a couple different demo sites. Try it on one totally new, empty site, and then try setting it up on a site that already has content. Record your screen as you set it up. If you did well and remembered where everything was — awesome! You can now use that video as documentation. Did you struggle? Figure out where the process broke down, and fix it.

Love the idea of user testing? Read Rocket Surgery Made Easy by Steve Krug. It’s short, concise, and explains everything you need to know to run a good user test.

You don’t need to be a designer to make a good theme — you just need to be conscious of your design decisions. Now go forth and theme!

Behind the Design of the Forefront theme

If you’ve read my previous articles you’ll recognize the title of this post. For those of you who are new, these are my thoughts behind the themes I’ve designed. This time, I’d like to talk about Forefront — a responsive Business theme.

Continue reading “Behind the Design of the Forefront theme”

ThemeShaper Re-Themed

It’s been a while but we finally changed the theme on ThemeShaper! No need to scroll to the footer it’s using Further designed by the illustrious Takashi Irie. We’ve made a few modifications using a simple child theme but it’s pretty close to the stock theme. For now. I’m sure there will be many tweaks over the next few weeks and months.

For the historically minded this is the first theme on not designed or built by me — we should have done that sooner! That said, I hope to continue the tradition of unusual design choices here with more experimentation and the use of cutting-edge magazine themes like Further (check out the infinite scrolling on the home page).

Let us know what you think!

Image courtesy of DBduo Photography

Behind the Design of the Ryu Theme

Much like I did for the Further theme, I’d like to share my thoughts behind Ryu — the free theme I released recently.

Yes, you guessed right. It’s named after the main character of the classic game. If you know why the character was named Ryu, you will understand why I named this theme Ryu, too. 🙂

I mentioned this in my previous post about the Further theme, Behind the Design of the Further Theme, too that I strongly believe that we, as WordPress theme designers, should create amazing themes for specific purposes/audiences rather than multi-purpose themes that are just good. In many cases, themes designed for a specific purpose or a targeted audience perform better when people use them for that purpose. I’ve created Ryu specifically for the Facebook, Tumblr, and Twitter generation of personal bloggers.

Continue reading “Behind the Design of the Ryu Theme”

Behind the Design of the Further Theme

Recently, I released Further — Automattic’s first premium magazine theme. I’ve been given a chance to write about my thoughts behind its inspiration, design, and development. I hope this gives you something to think about as you design your next WordPress theme or website.

Continue reading “Behind the Design of the Further Theme”

The Genericons Icon Font Story

Icon fonts are a truly great hack. They’re lightweight, scalable, and a clever way to use vector-based images on the web at a time when SVG just doesn’t have enough popular browser support to be practical. Despite starting out life as a hack, icon fonts are like the sprites of vector graphics, and I think they’re here to stay.

Enter Genericons, a new icon font made especially for blogs by Joen Asmussen with contributions from Sheri Bigelow and Takashi Irie. They were designed with simplicity in mind to keep a minimal, “generic” aesthetic so they can be used in a wide range of projects. They look sharp at small sizes because each icon has been aligned to on a 16×16 pixel grid.

Continue reading “The Genericons Icon Font Story”

Don’t let Lorem Ipsum decide the fonts used in your WordPress Themes

Have you checked the character map for the web font you use in your WordPress theme?

Thanks to all web fonts, nowadays we have much more choices for fonts in our WordPress themes. You might have checked if your theme looks good with Lorem Ipusum text but I’m afraid that’s not good enough. Lorem Ipusum text doesn’t have all digits, punctuations, and symbols from the Basic Latin character set. A WordPress theme should support at least all the Basic Latin characters, and this is only assuming your theme will be used for English language. This seems to be basic but often it’s overlooked. Continue reading “Don’t let Lorem Ipsum decide the fonts used in your WordPress Themes”