5 Common Mistakes WordPress Designers Make
As a freelance web developer who specializes in building out completely custom designs in WordPress, I’d like to cover some of the most common mistakes I see designers make when designing for WordPress.
These aren’t items revolving around design critiques or missteps in the design of a site itself, but more oversights and issues I commonly encounter.
#1) Not choosing web-friendly fonts
Now this issue isn’t exclusive to WordPress-based sites. However, it is crucially important if you are designing for the web to make sure whatever fonts you are utilizing in your design concepts are web-friendly. For free options, those fonts need to either be a core web-safe font or available through Google Fonts. If you are using a font that is available through a paid option like Adobe Fonts, cloud.Typography or an individual webfont kit available for purchase through somewhere like MyFonts, that’s fine, too. However, the cost implications should be something the end client is made aware of ahead of time and okay with purchasing.
Just because you have a font on your computer and can provide that font as a download (ttf, otf) to a developer does not mean you are legally able to use it on your site. You need a properly obtained webfont license for any and all fonts used on the site.
The last thing you want to do is go through a ton of revision rounds with a client and finally get the design approved, only to find out from your developer that the fonts utilized throughout can’t be licensed for the web or that it would be incredibly expensive to license them. I’ve had to be the bearer of that bad news before and it’s never fun.
#2) Using too many font families, styles and weights
Because fonts are frequently being pulled in from third parties, whether that’s Google Fonts or webfont kits or similar, every new font family, weight and style impacts your site loadtime. I frequently encounter designs that will primarily be using regular and bold weights of a font and then for one spot they decide to use the medium weight, for example. If you are widely using a weight of a font, that’s one thing but sometimes a random weight is utilized infrequently to where it doesn’t justify the technical overhead. It could likely either be stepped up or down in weight to prevent having to load in that additional weight.
Keep in mind that whatever font family you choose for your body copy font, you will be loading in at least 4 variations for that family alone: regular, italic, bold and bold italic. This is to accommodate styling choices that are available through the CMS when adding content.
Beyond just trying to be aware of the weights and styles needed within any given font family, you also want to limit the number of entirely different font families your design utilizes. Frequently, I see designs utilize two different font families: a body font and a heading font. That’s totally fine. However, your fonts can quickly become a heavy resource if you’re expanding beyond that. I’ve built designs incorporating 4-5 different font families before. It does start to impact loadtime so I’d recommend really trying to run a tight ship in that area and keep it limited to 2-3 families max.
#3) Using unrealistic placeholder content
Sometimes getting real content from clients can be like pulling teeth so I totally understand the need for some Lorem Ipsum and other placeholder use when conceptualizing the look & feel for a site. However, I frequently encounter designs where the chosen font sizes are never going to work when that placeholder content is actually swapped out for the real thing.
A blog post title is never going to be a comparable length to “Post Title.” An actual content heading is never going to be a comparable length to “Heading.” While choosing these basic labels may offer the client clarity about the type of content that will go there, it also typically results in using font sizing that may look great for 1-2 words, but what’s it going to look like when there are 8 words? 10+?
Instead I would recommend mocking up content with things like actual post titles if the client has an existing site you can pull them from. If a client does not have this to reference, I’d at least recommend making an effort to ensure the length of something like a post title is a bit more true to the typical average length of that content type.
#4) Overlooking defining how sections adapt based on content
WordPress is great because it puts the content on a client’s site in their control, but that’s the thing: the content on a client’s site is in their control. That means that perfect team member grid in the comp with all equal rows and columns may not be there. The design made for a blog where all the placeholder blog titles are exactly the same length definitely won’t be there. As a developer, I need to know what happens when those variables play out.
When the grids in your design aren’t perfect, what happens to the rows that aren’t full? If you have rows of 5 items, what happens if there is only 3 items in one row? Are they center-aligned or left-aligned? What happens when there is a really long post title in a grid your design shows as all completely identical in content? Do any items in a blog post grid stay even across all items despite content length, for example?
All of these kind of scenarios have to be planned for when you are building a site in a CMS where the client will step in and change the content. It’s super common for this type of thing to be overlooked.
I’d recommend making less “perfect” designs. Maybe your team grid has 4 equal rows and then one row with 1 item less than a full row. Maybe your blog landing page shows posts with unequal headers and excerpt lengths showing how the design adapts based on that. By illustrating how your design should behave when the realities of imperfect content are introduced, it’s extremely helpful in development.
#5) Ignoring inherited views for certain features
There are certain features in a WordPress site that bring a set of views to the table. Usually, in designs I get that utilize these features, a lot of these necessary layouts are ignored.
For example, say there is a design for a blog and the design includes a blog landing page and a post page. The post page has an author box that is clearly linked, as well as what looks like tags and also a category list. However, again, just the blog landing and post are what are provided. Well, what does the author archive page look like? What does a category page look like? What about a tag archive?
Here are a few examples of some common features and accompanying views, as I often see designs not fully covering the bases in these areas:
- Search: a search bar placed on your site somewhere is not enough! What does a results page look like?
- Blog: blog landing page, post detail page, author archive, category archive, tag archive, date archives (Note: some of these may match each other in layout or not be needed, like author archives.)
- Ecommerce: Shop landing, product detail, product category, cart, checkout.
- Anything with Logins/Membership Areas: account area, log in
- Any Form: form page itself, thank you/confirmation, errors
Hopefully you get the idea from these examples. Overall, there are plenty of features of a site that may have layouts that need to be defined beyond the immediate pages you think of when it comes to the functionality.