Help Me Help You
Practical tips for designers from a WordPress developer
With @daraskolnick
Hi, I'm Dara.
Nice to meet you!
I'm @daraskolnick basically everywhere on the Internet.
A little about me.
I...
- am from Toronto
- am both a web designer and front end developer
- run my own (very) small business
- do lots of WordPress development work in partnership with designers who don't code
- have been developing WP themes for 10 (!) years
This talk is for...
- Independent designers who don’t do their own development (or other designers who work remotely with developers)
- Designers creating custom themes from scratch (not child themes)
- Developers who want to help their designers make their lives easier
This might not be quite as useful for...
- Larger teams where designers and developers work side-by-side every day
- Designer/developer hybrids who always do everything
- Designers who design in the browser
Why is this important to talk about?
- There’s often a lack of communication between designers and developers
- Designers and developers are often frustrated with each other
- It shouldn’t be this way. We’re on the same time!
(Team awesome website, that is.)
Things (some) designers think about (some) developers
- Why does the finished website look different from my mockup?
- Why do they keep saying ‘no’ to things? Are they just grumpy?
Things (some) developers think about (some) designers
- This is pretty, but have they actually thought about how this will work in a browser?
- Why isn’t this design more consistent and systematic?
- Uh oh, this design is totally going to fall apart with variable content.
With a little education on both sides, we can fix these problems.
This talk is organized into parts of the project life cycle
- Before design begins
- While you're designing
- After development is complete
Part One: Before design begins
1. Choose a good developer
Development is not a commodity.
We're not all the same!
WordPress is not inherently “easy” or “hard” for clients to use. The developer makes all the difference.
👎 site admin experiences
👍 site admin experience
Solution: Ask your potential developer what they do to make websites easy to update for non-technical clients
Ask to see examples!
Some developers pay more attention to detail than others
Snoop around their portfolio!
Resize your browser
Do their websites fall apart at any point?
Do you see horizontal scrollbars?
Is their text actually text or is there text inside images?
Text in images is bad for performance, accessibility, and SEO. Also, hard for client to update
Check out their spacing
Is there enough padding around their sites?
Are text and form elements spaced nicely?
Loading time
Do their sites take forever and ever to load?
Note!
Some of these issues might be out of the developer's control.
But a good developer will often fix these issues and they shouldn't be all over their portfolio.
Ask yourself: is this developer a nice person?
"Soft skills" matter
Do they use a lot of jargon and talk at you with a superiority complex?
2. When should you bring your developer on board?
👍
Bring them on board before design has begun
👎
Designing without a developer in mind and assuming that anyone can do the job is a recipe for disaster.
👎👎👎
Even worse: handing designs to a client and then telling them to find a developer.
💩 💩 💩 💩 💩
This will make you look bad to your client
Things I’ve seen in designs that weren’t passed by a developer first
Oh, the things I've seen...
- Fonts that were all non-web fonts
- Completely random element placement (position absolute all the things!) on a "responsive" site
- “Mobile designs” for a responsive site that bear very little resemblance to the full-sized design
- Graphics that rely on Photoshop blending modes
- Huge images that would take forever to load
- Extremely inconsistent page designs
This puts your developer in an awkward position
They have to let both you and your client down.
Good communication is a must.
Ask your prospective developer lots of questions!
Questions to ask before the project starts
- What browsers and devices do you test on?
- Who’s going to enter the content?
- Who’s responsible for creating mobile/tablet sized designs?
- Does the client need training? If so, who’s responsible?
Questions to ask while designing
- Will [insert layout idea here] work in WordPress/on a responsive site?
- Can I pass something by you before I send it to the client?
Part Two: The Design Phase
Q: What software should I use?
A: Whatever you’re comfortable with… within reason.
Popular choices
- Photoshop
- Illustrator
- Sketch
Good developers should be able to work in different programs. They’re just tools. Though if I find out your design is in InDesign I might mark up your quote ;)
Whichever app you choose...
...use vectors as often as possible!
Why vectors?
- We need to create Retina/HiDPI graphics
- It’s 2015 and SVGs are very well supported
- Design elements are crisp and clean at any size
- Makes your life and dev’s life easier
If you're using Illustrator or Sketch...
You're already designing with vector assets. High five!
If you're using Photoshop...
- Use shapes
- Paste in vector graphics from Illustrator as Smart Objects
Keep your design files organized
Name, order, and group your layers
👎
👍
Delete layers you're not using anymore
Use Layer Comps (if you're using Photoshop)
Layer comps
- A layer comps is a snapshot of the state of your layers a particular point
- Layer comps toggle different layer order and visibility
- This is perfect for different states (hover state, active state, nav menu opened, swapping out images in a carousel, etc.)
A couple of other tips
- Don't put all your page designs in one big file
- Always use whole pixels numbers
Use a grid!
Why should I use a grid?
- Keeps your designs neat, tidy and balanced
- Devs can't make wrong assumptions about spacing and sizing if everything aligns to a grid
- Good devs should work with whatever grid you prefer or can offer suggestions if you don’t have one
A few grid resources
Be consistent
Developers are very literal
If your font styles, spacing, and sizing of elements is inconsistent from one page to another, we’ll be confused and might make incorrect assumptions.
If your designs aren't consistent, your developer’s implementation probably won't be great either.
You and your client will be sad.
Solution: style guides!
Do this before you get too far into designing, for your own sake.
Style guides should contain
- Typographic styles (paragraphs, unordered lists, ordered lists, headings 1-6, blockquotes)
- Colour palette
- States: hover, active, focus
- Form inputs (minimum: single line text input, multi line text area, submit button)
- Any other styles repeated throughout your site
Use paragraph and character styles
Think in terms of templates and modules, not just unique pages
Things developers love
- Re-usability
- Patterns
- Consistency
Further reading: Atomic web design
WordPress sites are all about repetition
- Page templates
- Custom post types
- Variations need to fit within a system
Think about the variations in a WordPress site, too
The simplest, standard page
The 404 page
(Almost everyone forgets this!)
Fallbacks for missing content
(e.g. what if the client forgets to upload a featured image?)
Hover/focus/active states throughout the site
(Otherwise, your developer will leave it out or make it up.)
Other things some designers have forgotten
- Blog comments
- Navigation menu dropdown (submenu)
- Image with caption
- Search results
- Form styling
What about responsive design?!
Responsive sites don’t just happen.
Some newbie designers and clients think that “WordPress takes care of mobile”. Nooooooo.
Who should figure out the responsive website?
If you leave it to your developer, make sure they’re okay with that and that they’re good at design.
Resource: mediaqueri.es
Responsive design shouldn’t be an afterthought
Things to think about
- How should the site navigation work?
- Are buttons and links easily tappable?
- Should the font sizes and spacing change?
- Does the mobile browsing experience feel good?
Mobile first?
Mobile last?
My favourite:
Mobile concurrent!
Keep the smallest version of the site in mind as you’re designing the largest and vice versa. Switch back and forth.
Responsive site = same content at all sizes
Not hiding 3/4 of the content
Please design responsibly!
Brownie points
Think about how your website will behave between the largest and smallest sizes.
Think about performance
Much of this is up to your developer, but here’s what you can do
Performance tweaks
- Limit the number of web fonts
- Limit the number of huge (non-tiling) images
- Don’t just hide half the site in the mobile view
- Teach your client about resizing and optimizing images (Resource: ImageOptim)
Part Three: While development is happening
Part Four: After development is complete
Let your developer know if anything is broken
Tell them what OS, browser and device you’re using! This is extremely helpful information for debugging.
Test the admin side of the website
- Add in content yourself, make sure the workflow makes sense
- Try variations in content (e.g. different lengths) to see how the site stands up